Decrypt PCI DSS 4.0 Special with John Hetherton

Listen on:

• Spotify
• Youtube
• Apple Podcasts
• Amazon
• iHeartRadio

This episode of Decrypt is a discussion between Shane and John Hetherton, Head of Compliance at Evervault, on the retiring of PCI DSS v3.2.1 in favour of the more robust v4.0. They cover the differences between the two versions, what the change means for organisations that handle online payments and how moving to v4.0 presents these organisations with an opportunity to rethink their security posture.

Shane Hey, John, thanks for joining.

John Hey, Shane, how are you?

Shane Good. Thanks. We always like to start the podcast off by asking guests how they got into security and what their background is.

John Yeah, no worries. So for me, I kind of almost fell into security, quite a few years ago at this stage, so I had a, I did a degree, came out of college, applied science and computing, and basically went into sysadmin role in financial services. I did that for a couple of years and I had a friend who moved into the Infosec space within that bank and thought I might like it. So I moved over from Sysadmin into Infosec in that bank, stayed there for a few years, kind of cut my teeth learning how Infosec applies to regulations and financial services and what it takes to run a bank security, which was really cool. A really good foundation to start off your career. From there, fairly typical again, we did consulting, was a consultant, made my way up through the ranks, eventually ended up leading a PCI practice globally for a couple of different consult, these under different guises through acquisitions and stuff. So that was really interesting, got to see a really diverse cross-section of kind of customer problems and PCI use case, as well as the usual NIST and ISO and all those kinds of things. So standards have always kind of been the backbone and best practice for security that I've been involved in. That I took on a role as global head of cybersecurity for pretty big companies, 6,000 people, global footprints. Did that for a couple of years, again, really interesting to be on the industry side as opposed to just on the consulting side. And then joined Evervault coming up nearly two years ago at this stage. So yeah, here in Evervault and running the internal compliance and info sec kind of responsibilities that we have to look after. So PCI, SOC 2, GDPR, all that good stuff, as well as contributing to products where I can, so, but the useful kind of solutions we can bring to various different use cases and industries. So that's kind of a different, it's kind of a different pivot for me moving to this kind of software based company, whereas previous to this have been more traditional kind of security roles and consulting. Cool. And the subject of this podcast is the new PCI version 4. I think before we can kind of dive into the details there.

Shane It'd be great to just hear about what PCI even is in the first place, if you wouldn't mind giving some background for talking about what the new changes are.

John Yeah, yeah. So I'll give you I'll give you the 40,000 foot view. There was we hear all day. So basically PCI is around since 2005 ish. It's basically out this the payment card industry data security standard. And the idea is to have a consolidated standard and apply to all systems, people, processes and technologies that are used for processing credit card data. What had happened in the past was Visa had their own standard, MasterCard had their own standard, and a bunch of other big payment brands had their own standards. If you wanted to process their cards, you had to abide by their specific set of cyber security rules. So they consolidated, formed a PCI council, formed the standard, and now the PCI council looks after the whole kind of shooting gallery there. So it's standards, auditor quality, reporting, all that kind of good stuff. So it's been through many iterations over the years. Current version we're on is version 3.2.1 and that's as it has been through the entirety of its life cycle, PCI has been very prescriptive. So you must do X or you fail, you must do Y or you fail. So there are hundreds of controls and if you fail one you don't get the certification. So that's kind of where it's been up until now. And then we're gonna dive into it a bit deeper later on, but we're moving to a model where we can adopt an outcome-based approach. And so they will give you the intent of a control, and then they will say, you can either use this defined and prescriptive approach, or else you can come up with your own way and achieve the intended outcome. So that's one of the real kind of primary differentiators between version 3.2.1 and the upcoming version 4. So that's a big one and it'll be interesting to see what the uptake is like on it because there's a good bit of overhead involved in that customised approach as it's being called.

Shane And at Evervault, we were one of the first companies, I think, to achieve the new PCI version for, as a level one service provider. What did that involve and why did you decide to move us forward as quickly as we did?

John I'd been following it for quite some time. So obviously in my previous roles, I had a lot of kind of clients who were and kind of level one service providers that needed to be PCI compliant. So I was kind of well aware and contributed to the development of the standard in terms of RFQs and stuff like that in the past. So I was well aware of what the standard was going to look like, very comfortable about the different changes, new controls and stuff like that. And I was also very comfortable when I came to Evervolve in terms of getting my arms around what our environment was, what the scope looked like and also knew that we had a really good kind of security posture and alignment with version 3.2.1. So all of those kind of factors together meant, and I suppose that the last thing was I had a, we had sufficient runway up until our next audit where I could either make the decision to pull the trigger on version 3 or version 4. And so I had a good six months prep and thinking about it, what the changes were going to look like and had been working on those up until our audit. So yeah, when we kind of reached out to our auditor and we said, look, we're ready to go version four, it was definitely very early days. The auditor hadn't done any V4 audits before, which is not unusual at that time. So we achieved level one to version four in July this year. So it was a bit of a learning experience for the QSAs, I think it's fair to say, and a bit of a learning experience for us, which was good. So yeah, that's why I had that feeling that we could do it. I felt comfortable in the knowledge of the scope, what the new standard entailed, and how that really applied to our environment. So that's kind of why I pulled the trigger on it early. And what it also meant was, we could give, a better understanding of what version 4 would look like to our customers. So by really being in the thick of it, we can understand what the nuance in the problem is. And then given our solutions solve PCI problems, I knew that would only contribute to like better product development, more insights and ultimately helping our kind of customers get where they need to be with PCI. And you mentioned that we were already compliant with version 3.2.1 before migrating over to version 4.

Shane What did the migration process itself look like?

John Yeah, it's kind of standard methodology, certainly when you're coming from that kind of consultant background or audit-based or standards-based kind of framework, if something new comes out. So first thing you have to do is understand your scope. Second thing you have to do is read what the changes are. So PCI Council, again, have a lot of good documentation and they've been doing webinars and things like that in terms of what the changes look like. The new standard alone is like 360 odd pages of content. And then if you want to fill out like a level one report and compliance or rock as we have to do the actual template alone with no content in it is about 500 pages. So there's a lot to go through. But again, I was kind of comfortable with it. I knew what the story was. But if I wasn't as kind of entrenched in PCI as kind of my previous career had led me to be, I think that the best approach would be for an organization to read it, understand what's happening anyway. And then if they're not comfortable with what the new standard actually means to our environment is to get their QSA in. So it's like, read the standard, apply the new controls and the standard to your scope, execute a gap analysis, fix anything you find in that gap analysis. Run it by your QSA if you're feeling anyway unsure, and then you effectively become audit ready and then pull the trigger on the audit. It is worth talking to QSAs. So we have two QSAs, two different companies that we like to bounce various ideas off, and whether that be products or whether it be about our own internal compliance, as things change, it's pretty healthy for me, I think. We have two different sources, we use BSI and Prescient, and they will give me a view on something, I'll have my own view, and then we kind of come to a consolidated, consistent approach with the way we handle PCI DSS, both internally and in our products. So it's worth getting an extra set of eyes sometimes. And if you're working with the QSA, who's actually gonna do your audit, you get a level of defensibility and insight as to what their thought process is when you actually have to go down the audit process. So it's handy from that perspective as well that you're not going into a version four audit completely blind. QSA might have a completely different perspective on the way you've interpreted something. So it's definitely worth getting that stuff boxed off upfront without any surprises when it comes to audit time.

Shane And aside from the auditors that we use, are there any tools or products that you find particularly helpful as we're going through the migration from version three to four?

John Yeah, so we use Vanta quite a bit. So I like Vanta because it helps me operationalize quite a lot of the things that are easy to forget, I would say, and just keeps you on a path. And then again, because we use Vanta and we have SOC 2 and GDPR and all that kind of good stuff, we take advantage of the overlapping nature of a lot of those requirements. And because they have visibility into our cloud accounts, they're pretty much continuously checking our compliance posture. So it simplifies that. And if there are any ever kind of changes that might come up and that need to be reviewed, it flags them pretty quickly or allows some of the other engineering teams who own processes in there to fix things pretty much in real time, which is a really handy kind of feature to have as well. Yeah, I think just automating a lot of the manual processes that we normally have to do makes your life a lot easier as effectively a one person GRC in compliance team.

Shane But outside of that with V4, were there any kind of big gotchas or things that you're kind of surprised at or things people should be thinking about?

John Yeah, I think there's so we used the customized, we pretty much went for the defined approach for version four. So we stuck to what we knew apart from, we used the customized validation for one control. And I think a lot of people are gonna come up against this where basically cloud service providers don't provide you with like automatic lockouts of accounts and things like that. So what we did was we worked with our QSA to come up with a customized validation for additional controls we have. So everything in Evervault is certainly authentication wise, is based on hardware, IAM, hardware keys with FIDO2 and U2F and stuff like that. So that's a really strong control. It's not specifically mandated in PCI, but it helps us across a number of different kind of areas from IAM to phishing protection to quite a lot of different things. So we use that quite extensively and it's a great mitigation. So for that customized validation piece, we worked with the QSA to basically say, with the use of hardware-based authentication keys and a bunch of other controls that we can implement, we kind of said, right, we're gonna take that lockout control, replace it with a customized validation because we believe the intent is met by the new set of controls we had. But the gotchas with that were, it takes a lot of time. So we have to figure out what the intent is and how we achieve that intent. We have to document it up. We have to devise our own set of controls to make sure that we keep on top of maintaining that requirement. We have to give them to the QSA. The QSA has to approve those. Then the QSA has to derive their own tests to make sure that they can audit that properly. And then they have to actually go and audit it. And it can't be the same QSA who… devises the controls and then subsequently audits the controls. So we only did that for one control out of hundreds. So I think if people are thinking that this new customized validation piece is going to be an easy way to offset some of the work in PCI, they're going to be in for a surprise. So that's just one thing to be aware of. There's a good bit of overhead going with the customized validation piece. From talking to a few QSAs as well who've done the auditor training, there are external vulnerability scans or ASB scans as they're called, they're really cracking down on. So missing one in a quarter is going to be a big fence now. What can happen there sometimes is somebody moves role, the person who was executing the scans is no longer there, it's no longer taken up by somebody who just didn't know that they had to do it, and therefore you miss a scan or you miss a couple of scans in the six month period. So what the council are saying is they're cracking down on that big time and whether it actually happens or not because what some people are saying is you won't be able to get your attestation of compliance if you've missed that and you would have to wait to have four successive quarters again of clean scans, which seems kind of bonkers to me, but we're going to have to see how that one plays out. But I think try and get in front of us. Just automate the scans and make the model submit if you can, especially where they're clean, it's pretty simple. So it's worth definitely keeping an eye on that one. And so customized validations are completely new in version 4.

Shane Outside of those, are there any completely new actual controls that are in v4 that aren't in v3?

John Yeah. So there's a bunch of net new controls, and then there are, I think, just about 60, 64 maybe. kind of number depending if you're a service provider or merchant. And then there's a bunch of controls that have just been updated. So in the majority of cases the net new controls only become effective in March 25. But some of the controls that have just been kind of updated over time to reflect changes in the technology landscape and so on will come into force in March next year. So there's things in there like payment page tamper detection. So if you are like running an iframe, collecting card data through an iframe, you basically have to be able to verify that the content that you're intending to serve from your web server, CDN or whatever, and the actual content that arrives in the consumer's browser has not been tampered with. So there's a bunch of tools out there now to actually help people do that. Kind of SRI, CSPs, and cores, all become much sharper focused in a big effort to try and mitigate these e-skimming attacks that are still quite prevalent. And so that comes in. Controls have been applied to some of the self-assessment questionnaires for version four that weren't there previously. So SAQA again, which was like the panacea of scope reduction, where you basically outsource your card processing to a third party entirely. The iframe model for that is the most common one. And now you have to ASP scan the web server that's kind of calling the iframe, which is a new requirement as well. That's not currently in version three. You have to execute phishing simulations, SBOMs, so software builds of material are now required. There's new requirements, start of each of the 12, there's a new control, start of each of the 12 requirements that says roles and responsibilities have to be specifically defined for each of the activities called out in your policy. There's a bunch of stuff, to be honest, but from a technology perspective, like getting your S-bombs kind of sorted out, your scanning sorted out if you're in SAQA, those are kind of big ticket items, and especially that figuring out. How you're gonna do those time projects is also important too. So it sounds like anybody, unless you're just fully outsourcing their PCI environment, if they're doing that, the migration from V3 to V4 is gonna be quite a lot of work, probably more than people had expected. How much time do we have? Today is the 23rd of November. Yeah, when do they have to figure this out? Yeah, that's the thing. We're seeing people coming to us now. So I have, because we went so early, I was, I had a little like a very good runway. I was extremely comfortable in that knowing that we could achieve what we needed to achieve as a level one service provider handling millions and millions and millions of car transactions every year. So there's absolutely no doubt that we need to maintain level one PCI DSS compliance. We were going to have to do version four anyway in its entirety. So I was like, plan for this in advance. I gave myself like six months to do it. And our environment is pretty very well managed, it's clean. So I knew the path I had was going to be fairly straightforward. Other organizations who have much bigger, less well controlled, so we're in a cloud environment, so that gives us a lot of benefit in terms of automation, rebuilding. You know yourself, we put out brand new versions of machines instead of trying to retroactively patch and stuff like that on a very frequent basis. That gives us a big step up. There's a lot of organizations who are manually patching boxes, who take time to patch, who are scared that if they patch something, it might break, and so on and so on. So for those organizations who have big kind of footprints or are heavily manual, like if you haven't started, if you need to be PCI compliant, you need to process card data directly, you need to be doing it now or as soon as possible. But what we're actually finding is a lot of organizations are coming to us saying, look, we know PCI 4 is coming. It's gonna be a massive uplift for us. And their consideration now is really reevaluating whether actually upgrading that entire environment, spending all that engineering time to do that uplift is worth it, or whether they just completely reevaluate and say, do we actually need to handle the credit card data passing through our environment at all? And so companies are coming to us saying, look, how can you help? And obviously we can de-scope organizations from having to process that card data and playing text. They don't have the keys to decrypt anything. So we can effectively de-scope their environment from, you know, hundreds and hundreds of controls down to like 29 controls, allowing to SAQA. So those are the two big considerations. Do you need to have that car data running through your environment? Lots of companies would have said, oh, we're compliant already, it's already working. I'm not gonna upset the Apple cart here, but what version four does is it gives you or forces you to reevaluate to say, do I spend my engineering uplift actually getting version four compliant, or do I just take the one-time hit, swap out and de-scope my environment, and then you kind of get rid of much of the engineering and what someone would say is overly burdened some kind of compliance obligations under PCI and certainly under four that they have to execute. So they can pick and choose and more so decide to spend their valuable time either on product or executing security that is truly risk-based as opposed to being security by compliance, which a lot of people will debate whether compliance and security or security is compliance. That old argument, you know. Yeah, I think we have a very firm stance on it. But yeah, obviously we're biased when it comes to people outsourcing their PCI environment. But it does seem like even some of the most mature payments teams who've been running in-house environments and so on for years are starting to think much more about outsourcing it and so on. So it is interesting to see.

Shane Just to wrap up, are there any last minute tips or words of advice that you have for people that are thinking about getting compliant with v4? Yeah, I think it's definitely worth

John Like if you're not sure what's going to happen, like I would suggest talking to your QSA or very really understanding whether you need to handle card data in kind of plain text at all, or whether it needs to go through your environment at all. That's really the first step. During any QSA work result, the first question they will ask you is, does this card data need to go through your environment? If it does, fine, we make the environment compliant. If it doesn't, just get rid of it. Absolutely get rid of the data. And you not only minimize the risk of card data breach and all the things that come along with that. So, I mean, if you're responsible for a card breach and the pan CVV expiring name are stolen, you can be looking at fines of up to $18 per card. And if you're a big processor, that those figures can stack up pretty quickly and you're in some serious fine territory. And not only that, but the card brands can stop you processing cards. So you could also be looking at a window where you're just not able to operate your business. So if you basically de-scope and the risk of card breach is completely reduced, you kind of not only reduce the engineering effort and the cost and all that kind of good stuff of becoming PCI-4 compliant, it also reduced the risk of card breach and so risk to the business of stopping basically. And so that's what my one key thing would be like, understand if you really need to have that card data flowing to your network. If you don't just outsource that risk to somebody whose primary job is to look after the security of card data. That's nice and actionable.

Shane John, thanks for joining us on the podcast and I'll see you back at the office.

John Sure. Thanks, Shane.