PCI DSS 4.0: What You Need to Know

SecurityMetrics Podcast | 49

PCI DSS 4.0: What You Need to Know

"If we think back to 9 years ago when the previous version came out, the world was really different then. We now have loads of new criminals who have found new ways to steal card holder data. The way we do InfoSec has changed massively in 9 years, so we definitely needed a new standard."

With PCI DSS version 4.0 just recently released, many are left with questions about the many changes in the standard. John Elliott (Pluralsight Author, PCI, and GDPR Specialist) sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to give you everything you need to know on PCI DSS 4.0.

Listen to learn:

• Biggest additions and changes in PCI 4.0
• Why was PCI 4.0 delayed?
• Things you need to do to prepare for PCI 4.0

‍

Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide

Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide

[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.

‍

PCI DSS 4.0: What You Need to Know Transcript

Hello, and welcome back to the Security Metrics podcast. I'm Jen Stone. I'm one of the principal security analysts here at Security Metrics, and I'm very excited today to bring to you John Elliott. He's a consultant and author who, specializes in security directives. He's represented both Visa Europe and Mastercard on the PCI Security Standards Council and contributed to many of the PCI standards, including most recently, PCI DSS version four, which if you're in the PCI world, we're all abuzz about that. He's helped large companies in the financial and airline sectors with complex PCI DSS and GDPR programs.

And if you're not familiar with GDPR, that's the the European privacy directive. In his spare time, John authors online video training courses for Pluralsight. John, welcome. What did I miss?

That that was about it, really.

I'm I'm just enjoying my independence from working from a, like, a big corporate at the moment also to do a bit of writing about PCI DSS.

But, yeah, generally generally, that's it. I'm just doing a bit of consulting work. And history wise, you you summed it up. The last two years or two and a bit years I spent at Mastercard, mostly in the weeds of PCI DSS version four.

Well, I'm so excited that you're willing to talk to me. We've had you on before, and you brought us such great knowledge in the past about the PCI DSS and really helping us kind of dip our toe in the water of what is this four point o, when's it going to hit us, all of these things. Super excited to have you on the show.

And it it's a real pleasure. I do have to say something because, it's I've only recently left Mastercard and left working with the PCI standards. Everything I say is my own opinion. It's not, like, what Mastercard's opinion was. And if I make predictions about things that I think are gonna happen, it's things I think are gonna happen. It's not inside information.

I appreciate you saying that.

John said that. Therefore, Mastercard must be doing it. It's like, I don't have any of that information.

We're not going to hold you to anything that you said. Just help us understand. And and, you know, I'm I'm actually kinda glad you mentioned that because as an assessor, I sometimes will say things because people ask my opinion and I think, wow. How much of this opinion is is are people going to beat me up over later if I if I get something wrong or if things change or if I've misinterpreted something? And I think it's important to recognize we are all humans trying to sort this out properly together with the best of intent.

So, welcome to the show again, and let's jump into why.

Why is my first question? Why? Why are we I was just starting to understand three two one. I was just feeling good.

Come on. I mean, three two version three of PCI DSS was it's nine years old. It's nine years since the last version the last major release of the standard. So as a QSA, I'm glad you're just starting to enjoy it and put your head around it.

And, yes, we we're all getting our head around it. And and and I love three two one. I I can you know, I I I know this the numbers of each requirement and things like that. So it's but it's it's quite a change having a version four.

But look, if we think back to nine years ago, the world was really different nine years ago.

We very much was.

We didn't we didn't have we didn't have so much cloud infrastructure. It was fifty fifty whether you would buy TIN or buy cloud services.

Right.

Now that's completely changed. We didn't have, gosh, we didn't have EMV in the States nine years ago. You were still doing that swipe and sign thing. Right?

We didn't have three d s the the new version of the three d Secure standard for secure customer authentication for ecommerce. We didn't have the same criminals. We've got loads of new criminals who found exciting new ways of stealing cardholder data. And so and and and the way we did info the way we do infosec has changed massively in nine years.

So we definitely needed a new version of the standard. It didn't have stuff in it that was crying out for.

It didn't have anything to stop ecommerce skimming attacks Yeah.

For example. Yeah. It didn't have it didn't have quite a lot of modern technologies that people used. And so, yeah, stability is great. Right?

And and and if you I don't know if you remember, Jen, that the standard used to used to change every three years. There was the whole thing when it first came out was a three year life cycle. An organization said to the council, look. You can't change the standard every three years.

We're always trying to catch up with ourselves. And so the council, you know, had a very good, mature version with with version three. Three and and three two on on top of three wasn't a massive change. It was a minor change.

Yeah.

And so there really did need to be a new version of the standard.

Was it too late? Yeah. I I actually think it should have come out. I think there should have been a version four.

I think we should have version five now. I think we we we nine years is too long to wait. In a very fast technology moving market, nine years is too long to wait. So I and and we've seen that because of the length of time it took to birth the standard.

I mean Yeah. Heck, it took what?

It took maybe four years from people starting to talk about the standard to the standard happening, and that's a really long time as well.

And it it feels like it okay. So I actually sent this out, the links out to, some of my my customers that I know really wanna get a jump and want to understand.

And the their response when I send them the links is, are you sure? Are you sure it's actually coming out now? Because they felt like there were some some delays in when that was expected. And can you speak to that at all? Like, why maybe it took that long?

Why did it take so long?

Three two two big reasons.

The first is that in an effort to be more consultative with the industry, the council decided to do multiple requests for comments. So it started off the process with a request for comment back in two thousand and seventeen, which was like, what do you think we should change? And he got a lot of feedback. Mhmm. And then the then it issued a request for comment version, like, the first version of DSS version four, request for comment one, came out in and I wrote it down. It came in October two thousand and nineteen.

And there and I was I was actually a merchant then. I was just finishing a very big PCI program.

Okay.

So I I wrote loads of feedback.

Like, this is a terrible idea and how because because I was a bit you know, I I you know, like because I knew a lot of the people who were writing the standard book, but I'm visionary, and you have opinions, John.

Yeah. And I wrote all my opinions down in the feedback spreadsheet. Like, how on earth could anyone be so stupid to think this is a brilliant idea and things like that? Yeah.

So I gave my feedback, along with there were three thousand two hundred bits of feedback given to the council on version one of the RFC, and every single one of those bits of feedback were addressed. And I know that because that's quite soon. Just after RFC one closed, that's when Mastercard suggests I came and worked for them. And so I was sitting on technical working group doing the job I'd done previously for Visa Europe.

And the first job was to review three thousand two hundred bits of feedback from merchants and service providers and QSAs. Yeah. Some of which were my feedback telling people what idiots they were. So that was quite embarrassing.

Cell phones.

Yes.

So so that so that's one reason it took a long time because then we did a second request for comment, and we've got about two thousand bits of feedback. Every single one went through. And then because we want a lot of feedback about changing the reports and compliance in the FAQs, we did another RF. When I say we, I mean the PCI SSC. It's odd not to be part of the we, anyway. But the council decided to do an RFC feedback because for for the for the, validation documents because we're proposing quite a lot of changes to those. Yeah.

And so, really, the the first reason is is late is because we the council listened so much Yeah.

To getting feedback. And believe me, if you wrote a piece of feedback, it was talked about. Every single piece of feedback was talked about. Some for maybe thirty seconds, some for probably a cup you know, usually two or three minutes per piece of feedback.

Sometimes for half an hour. Sometimes for actually one whole working group call because it was like, well, that's a really important piece of feedback. What do we do about this? Okay?

So everything was listened to.

Some of the people who did feedback would be really sad because it was just it was rejected. It was like, no. This doesn't fit the ends of the standard. But believe me, everything was listened to. So that's the first reason. Too much. Two two three RFCs, which which the council had never done before.

Right.

The council was never prepared for that level of RFC feedback.

Right.

Like, gosh. That's a lot of work. Secondly, this COVID thing. See, normally, technical working group, when we work on the standard, we all get together in a hotel room Yeah.

In some exciting place, like I don't know. They're exciting places where usually where car brands were. So it was either, Foster City or St. Louis or, or, Phoenix, which is really nice and warm, which is where Amex is based.

But there's no good food in Phoenix. Let's just do that.

Chicago, which is really freezing. So so we usually meet in a in a hotel room somewhere near a car brand. And we do that for a week. So we do this, what we call, face to face meetings.

Mhmm. Though, we have had not a single face to face meeting since RFC one happened. Yeah. Which mean we've done virtual face to face meetings, which have been, oh gosh, thirty hours a week of Zoom or we use Webex, but that's quite tiring.

We don't get through as much. I So COVID slowed things down.

Do you know, I'm really glad that you pointed that out because on a kind of a side note to that is as we're doing these assessments, a lot of people have said, well, we've learned that we can do assessments virtually. And and and my response is no matter how hard you try to do an assessment virtually, to the same degree as the in person, you miss something, it slows it down. You don't go get those interactive. And when you're trying to develop something together, this is a creative intellectual process putting these standards together. I can't imagine trying to do this when you're not in the same room where you can have these meaningful conversations, plus the exhaustion of of doing it through screens, which is it it does add to that that level of tiredness.

And bear in mind, you know, since we since since PCI DSS version three came out when there were five brands or five brands from Visa Europe on the council, there are there are now six main brands. Well, there's still five because Visa Europe got subsumed into Visa, but UnionPay joined.

Oh.

And then also, lots of affiliates have joined. So, we had people from from India, from Canada, from Russia, from Australia. And therefore, some of these peep you know, these calls actually for me, I was I'm based in Europe. For me, these calls on the face to face meetings for a week finished at midnight.

Yeah. And so so so it does add to everyone's transition. And and, yeah, you don't get the same creative stuff. You also don't get the the the conversations over over lunch or dinner or or afterwards when you're not when all of a sudden you you say, you know, you you made a really good point there.

I think we should go back and look at that tomorrow. Now I've had time to think about it. So so if those things happened, if if you did have a we used to call them backsees. But if you did have a, let's go back and look at something because I'm not sure we made the right call there, that often took a lot longer than it would have been how we've been face to face.

Sure.

And and, frankly, when when I when I first because the council has been so good about being transparent. This This is what we're going to do. This is how we're going to do it. These are the timelines we intend to meet.

And and when they said we are going to open this up to a a request for comment, these different periods, I thought, do they know the tidal wave of information they're going to get? Do they have enough people to manage that? And then when COVID happened on top of it, I just thought, well, this is it is is just an insurmountable level of effort to meet those timelines. So I I wasn't surprised.

I'm glad that it took the the time it took to get it right.

But, yeah, that that sounds like a, a lot of very intense brain work trying to sort through with people remotely.

Yeah. And and, you know, all credit to the people who are on technical working group who did that, and especially Lauren, who you probably know, who was an absolute star at managing us and putting the standard together and and running through all the feedback.

So we couldn't tell anyone.

That's great.

I haven't personally met Lauren yet, but I but I hope to now that we're getting back to these in person meetings, which Yeah. Which have been such a struggle for a while. Okay. So, we understand now we needed a change.

I was kind of being facetious when I complained about it. But only because, look, I was finally starting to do chapter and verse on them the way my team lead can do all the time. I don't know if you know Michael Simpson, but I'll be like, hey, Michael. How do what's the answer to this?

And he can tell me exactly almost what page it's on. And and I thought, oh, I wanna be like that and everything changed and now I can't be like that.

But But but but Jen, a lot a lot of it's still the same.

We we it's it's better worded. It's clearly laid out more clearly laid out. Right? But a lot of the requirements are the same requirements. They've been tidied up. Some of the confusing language was taken out of there. So a lot of the requirements you love and are familiar with are pretty similar.

That's really good to hear because people are worried. When I ask them, you know, or talk to them a little bit, hey. Keep an eye open for this, but don't panic yet. They're worried.

They they feel like they finally have their ducks in a row for three point two point one, and then now they are not. They're they they don't know what to expect, how it's going to change, are the requirements gonna change, is how they meet it, is it going to change? And so Yeah. So the for organizations that are currently successfully meeting PCI DSS three point two point one, what's that stretch?

What is that step towards four point o gonna look like for them?

It's a big it's I'm I'm not I I the, yeah. It's I I I'm not going to make it minimize it. It's a big change. Okay?

The the first the thing that's most important is a lot of the core principles of the standard haven't changed. So although the introductory sections have been substantially reworded, in lots of cases, the council has just pulled the FAQs into the standard of FAQs that came up while in the past nine years. So it might look a lot more. There is no intent to have changed things like scoping and sampling or anything in there.

It's just, hopefully, it's explained better and more clearly with the benefit of nine years of getting feedback from the assessor and merchant and service product community.

So so that there are no conceptual changes even though it looks like the introductions changed quite a lot.

Okay.

There are fifth or sixty four I'm checking I'm checking the summary of changes. There are sixty four new requirements.

Fifty three of them apply to everyone.

Eleven just apply to service providers. So there are a lot of new requirements.

But there aren't as many new requirements as there could have been. Some of the stuff that was in RFC one, like encryption over a private network, like data leakage prevention tools. So some of those have been taken out. Hopefully, if you were to look at the standard now, it's probably what reasonable I'm I'm I'm I hesitate to use the word state of the art, but reasonable security would be that an information security professional would recognize that those were the controls that most organizations would have should have in place with some special ones added for protecting payment card data. For instance, the ecommerce skimming because the ecommerce skimming is a big problem.

Sure. Yeah. For so for me, as an assessor, I always start with security. Tell me about your security program. I wanna understand their general security stance. And if they understand things like like you just said, we should talk about ecommerce skimming, in a whole thing at some point.

A lot of people are are that I talk to now try to lean on, well, we don't have to do that because we have an iframe, and they don't understand the nature of skimming and how it's developed and how people are are worried about it. But but not to sidetrack this conversation.

Let can I just talk about timelines very quickly first? So don't panic.

Okay.

Like, you know, it's like the Hitchhiker's Guide to the Galaxy. The front page, don't panic. Yes. Right? Because the standard doesn't become effective until the first of April twenty twenty four.

Yeah. So that's two years away. Far away.

And It does.

And then the new requirements don't come into force until the first of April twenty twenty five.

Okay.

So there are three years to get your ducks in a a row.

Great.

Now but some of those requirements might take you three years. So start, but don't panic. Okay. Big changes.

There are fifty three. I'm not gonna go through them all.

The ones that I think will create problems for organizations that you need to start thinking about. Mhmm. If you store sensitive authentication data, so the full track, which hopefully no one in the world stores the full track anymore, but, like, the three digit or four digit CVV two or CID codes. Right.

If you store those pre authorization in case your authorization link fails and you wanna try it again, that needs now to be encrypted. How you encrypt a three digit number will be intriguing because it's actually really hard to do. Yeah. Because you have to pad it.

And once you've padded it, then the padding will be anyway, it's quite hard to do. Secondly, hashing. Hashing has gone away. Hashes need to be keyed hashes now.

They need to be cryptographic hashes because brute forcing of hashes is so easy that it offers no protection of cardholder data. And that's a really good example of how in nine years, hashing with a recommended assault nine years ago was okay.

It was okay. It was okay.

Okay, but it was okay. Now it's like people laugh at you if you say that's how you're protecting something.

That's not protection. What are you talking about? So, I mean, I'm glad you're mentioning these because, like you said, just because we have three years doesn't mean you should wait three years to see what what the changes are. That's that is alone a potentially a three year change to if you have architectural implications to that and and tooling implications and and personnel.

Yeah. And and if and and if you're using hashes a lot in fact, while we're talking about encryption, let's also mention that Triple DES dies at the end of, is it this year or next year? Triple DES dies pretty soon. Yeah.

Yep.

And so Should be dead now. But If you yeah.

But this it it's it's deprecated, after I'm gonna check the date. It's deprecated by NIST. And therefore, if you're using Triple DES, it won't be strong cryptography to encrypt PAN either. Correct.

So that's again, that might be a three year a three year thing of having to get code, get resource allocated, get it scheduled into your development timetable.

What are the big changes over in encryption? Certificate management.

So nowadays, you have to now in in requirement four, you need to validate the authenticity of a certificate you're relying on, whereas before you didn't.

Mhmm.

There needs to be some technical protections against phishing, and that doesn't mean telling your users not to click on phishing links. It means Oh, yeah. Measures to stop phishing links coming into the organization.

This is one of my favorite ones because in the past, what did we say? Oh, it's a personnel problem. It's your your people or your weakest link. And and and we need to stop beating up on people because the nature of how human beings react to their work and do their work, you you end up getting the most, dedicated helpful people getting trapped by phishing. And and then it's just, it's just so demotivating when we have tools that can do it. If we have if we have tools that can help people, why would we not? So I'm really glad to see that one in there.

Yeah. And so so tools tools are really important, because everyone clicks on phishing links eventually. I mean, the whole idea of phishing is it's designed to try and trick you.

Right.

I mean, there are psychologists working out how to try and trick you.

So trying to tell people not to be tricked when people are trying to trick them is really, in my opinion, just waste of time. It just makes the users feel terrible. It's just anyway, different subjects. So the requirement is that there's anti phishing technology in place, and there is requirement for training. And the training's got the emphasis on reporting phishing emails.

Nice.

Right?

Because if your protective measures have failed Mhmm.

Then the only person who might see that phishing email is the user.

Mhmm.

And, therefore, the user is the only detective control we have left to say to the SOC, this phishing email got through. Right? So so the emphasis the emphasis on the training is reporting phishing emails. Good.

Because that's a positive thing.

I think that's great because that way you put the person as the the last line of defense, not the first line of defense.

Yep. Yeah. They are. They're they're totally the last line of defense. Technology should have picked it up.

If it hasn't, then you are the last line of defense. Please help us by being a detective control. Yeah.

E comm skimming. There are two requirements to protect against major card type of e comm skimming attacks.

The first one is to make sure that the only only scripts necessary for the taking of a payment are present on the payment page That's brilliant.

And that they're authorized by management and that there is some way of checking the validity of that script.

Excellent.

So that typically means something like content security policy and sub resource integrity, although they are not specifically called out in the requirement they mentioned in the guidance.

Oh, good.

You could all because you could also use something like, some of the content distribution networks will validate the integrity of your scripts before they distribute it to the the the users the consumer browser.

Right.

And, also, you know, we don't wanna be too technologically focused in the standard. So we want the outcome in the standard rather than what technology to use.

Good point.

Yeah. And then in eleven point six point one is a requirement to detect changes in your scripts. Now I know Security Metrics, you have a product that that you sell that does that, and so do lots of other organizations. So that's now a a requirement in the standard. So, again, a protective control. Let's try and stop this happening. But we know sometimes it will happen, so a detective control.

Right. It's called, shopping cart monitor or shop shopping cart inspect is the first step, and then shopping cart monitor is to to monitor those changes.

And and it's like you said, there's a lot of groups that have it, but I wanted to give a shout out to that because, the guy that, helped develop that, his office is next to mine, and he's pretty cool.

So, good job, Erin. The important thing is that that finding those changes in the past, we used to have all kinds of marketing, and upsell type scripts on the page or or, you know, just finding out information on that page, and it made it so complex and so difficult to find out if there was anything kind of nefarious going on. So having it being limited to just what's needed to take payment, I think, is a is a great step. I'm super happy to hear that.

I I I I'm super happy that that's what TWG agreed as well, and I'm really super happy that but, you know, people tell me that content security policy and sub result integrity are really hard to do. And they're right on your whole website, but they're not on one payment page. And you could do it on one payment page. And so that that that will stop a lot of skimming attacks.

It won't stop them all. It because the payment page is still the iframe. It's not the holder of the iframe. And as we know, there are some iframe attacks.

Right? There are some attacks where you we we which, you know, Dave is is it's it's I think it's called I mean, you've done a really great podcast on Security Metrics on how to on how iframe attacks work.

Right.

But but those iframe attacks rely on badly coded, payment service providers. It relies on them not using HTTPS cookies. It I mean, you know, or a well implemented payment page should be able to be implemented in iframe and isolated from the parent page because there's no access between the document object model of the parent page and the iframe. Yeah.

And if there was, the whole Internet would fail. You know, this this separation of, of, say, margin policy is really important. And I wanna be really clear because I know people and I in fact, even people at Security Medicals have argued with me before that the parent page should be part of the payment page. That's not the way that small merchants work.

And if we were to change it, we're really worried that everyone would go back to doing JavaScript forms, and it would be a worsening of security, not a bettering of security. So the compromise is what we've got.

Right. And and, I I think that the the iframe that is well secured and from a from a trusted organization that does it well, that that is is known to to secure its payment pages is the best option for this. I wonder what the bad guys have in store for us next in in terms of, you know, it feels like if the information is out there between the user and the, whatever the where wherever that payment needs to go, that somebody is out there trying to figure out how to grab that. And, I think I I think we don't know all of the answers. There's probably things out there now that we don't know.

This episode is brought to you by our Security Metrics penetration testing team. They do a lot of pen tests. They do a lot like network layer, application layer, segmentation checks. They're very, very knowledgeable, and, some of them have even won, like, competitions at Defcon. So you can rely on these guys to know what they're doing. Head over to security metrics dot com. Learn more about pen testing.

My my prediction and when I said earlier at the top of the show that when I said predictions, it was mine. It wasn't anyone else's view. This is my view, is that that that that that will migrate to peat. There are more small payment service providers starting up, and I think they will find themselves the target of more sophisticated attacks than they have been. Yep.

And that's that's probably the biggest worry is that service providers when you can no longer steal the data back out the browser, and really, the only place you've got left to attack is the service provider. The service provider will have much more complicated attacks aimed at them.

I agree. Yeah. I agree. I'm often much more, I beat my service providers up a lot more than the merchants because I I think merchants that are relying on service providers, their big thing is they should choose good service providers.

Yeah. Of course, there are things that a merchant needs to do, but also relying on that service provider. Like you said, there's there's a lot of little boutique niche type, payment service providers out there, and and we're seeing more and more of them. So, hopefully, they're all onboard the, the, PCI train.

Yep. And let's face it. The attacks against iframes that are successful, the service provider shouldn't have passed that PCI audit given the coding problems the way they coded it. Yeah. Big change. System and application accounts weren't really called out in the standard in version three. In version four, we call them out particularly.

Okay.

It's like so there are loads more controls of system and application accounts.

Like, we they exist. They shouldn't have interactive login, but we know they do have interactive login. So if they have interactive login, it has to be really strongly managed. You can't have hardcoded passwords for them in places.

Passwords, remember, have to be encrypted. So lots of changes for system and application accounts, which if you haven't audited your system and application accounts for a few years Yeah. Might be a a load of work for you to do. Yeah.

Big one for I've got three more big ones. Yeah. Multifactor authentication everywhere for any user with access to the CDE. Hooray.

About time. And you should be doing that now. Don't wait for twenty twenty five. Do that.

Exactly. Because that's your biggest protection against phishing attacks.

I just make fun of people who refuse to do that at this point. Just like Yeah. You that's just dumb.

Automated log monitoring. So rather than manual log no. No. This is a requirement that's not really a requirement because no one does manual log monitoring.

That's insane. What does manual even mean? Are you kidding me on logs? That's crazy.

Yeah. Precisely. So it's just catching up with the world. And then finally, this is the one to start tomorrow if you plan on becoming compliant with DSS version four, is internal vulnerability scans need to be authenticated rather than anonymous.

Nice.

Your authenticated scan will find ten or fifteen times more vulnerabilities than your non authenticated scan. So it simulates lateral movement in an organization effectively. Perfect.

It can take you That's where the issues happen.

Yeah. Totally. But if you are a I have to be careful. I I have known organizations where moving from unauthenticated scanning to authenticated scanning took three years to resolve all the positives.

Yes.

This can be especially on the size of the obelisk.

What what does they call in project management? That could be your long pole.

Yep. That's that could be a really big thing. And and so if you've got a big organization and you've not done this before, I would start now.

And hopefully, they have maybe, subnetting that where they can try it in one and then try it in another and make sure they know what they're doing before they go breaking everything, but stop, you know, saying why they can't do it and just do it. I actually, chose not to read the, four point o in in-depth before I talked to you because I wanted to hear it fresh. And so that's really awesome to hear those things, and I'm excited to go look at it, and read it through today later.

Can can I advise you and also anyone who listens to the podcast to read the summary of changes document first? It's brilliantly done. I it's I I I I I was I was a a brilliant surprise when I saw it because I hadn't seen it before. It was done after I'd left technical working group, and it's really well written and is really great.

It is sitting on my desktop for my after our conversation. Very yeah. Yeah.

Definitely. Everyone start with some of your changes and then move off to the standard.

Okay. Love it. Alright. So, one of the things that is feels different is the customized approach. Tell me about the customized approach.

Well, I think it's I I really like the customized approach. Right? When it first came out, I was like I remember I was a merchant at the time. I was like, I'm not sure about this. But it's taken some work, and I think it's in a really great place.

So the customized approach is if you if as an organization, you decide to meet the security requirement in a different way. So PCI DSS has has always been massively criticized because it's prescriptive.

Yes.

And it is prescriptive. It is really prescriptive.

And and, actually, back when it came out in two thousand and eight, heck, it needed to be prescriptive. Even in two thousand and fifteen, it probably needed to be prescriptive.

There weren't the same level of knowledge of information security around that Agree.

I agree with you.

As there is now. There's a the the professions changed massively. Mhmm. The, you know, we didn't have the NIST cybersecurity framework.

Right.

Probably didn't have the CIS twenty three of all the what it was then, the sounds twenty critical controls.

Sense top twenty. Right. Mhmm.

But but that stuff wasn't around, so it had to be fairly prescriptive to tell people what to do. Yeah. Also, so you could order against it. Yes.

Right. Now that's changed. And so you could say you could say to an organization, do not let malware execute on your in your environment as a security objective.

We don't care how you do that. Right?

Right.

And so the standard will say prescriptively have anti malware solutions, but you might have you might have an EDR tool.

Mhmm.

Right? You might have an EDR tool across the organization with network monitoring plugged into it as well.

You might have some very complicated stuff Right.

That you wouldn't you that wouldn't look like anti malware.

Yes. Increasingly, I've actually had customers who have said to me, let me tell you about our security program, why it's better than what you've got, and tell me why we can't use this. You're asking me to do something that is nonsensical in this environment. And I would say, let's talk about how PCI works. And so we would try and find a way together. And so that's why I'm excited about this, this customized approach because what it sounds like is it's it's having respect for organizations that have a mature cybersecurity program.

And how does that meet the, objectives of, protecting cardholder data?

Totally. So so, you know, a really good example is on requirement five is, like, malware the the the the security objective is malware cannot execute in the environment. I think and I'm paraphrasing it, but it's something like that.

Okay.

Right. The the entity then just have to show what how the controls it has decided to put in place meet that security objective.

It's quite an evolved process, but it makes it makes it effectively there are two standards in PCI DSS four, which is really, I think, quite clever trick the PCI SSC pull off. There's the prescriptive way of doing it, which is called the defined approach.

Mhmm.

One that you're used to assessing and we're all used to.

Right.

And then for every single requirement, there is a customized approach objective that says why what you're trying to achieve here. Mhmm.

And if you can achieve it another way and and prove to an assessor that you're achieving it Right.

Then you're good to go. Yeah. Love it. Designed for security mature organizations that understand running controls and doing risk. Yeah. It's not designed for smaller organizations who who should still follow the defined approach.

Yeah. I I agree with you. And it's it's not the intent is not to let people get away with something.

The intent is not to, you know, sidestep some of the these requirements that the intent is, good security can be done in different ways.

And so understanding that. But like you said, very few small organizations are gonna take that approach.

Yeah. But for I mean, the best example I talk about is zero trust. If you properly rolled out a zero trust model in architecture in your organization, lots of bits of requirement eight don't really apply.

Yeah.

But but the objective of what's in requirement eight does apply. Mhmm. For instance, you know, something like, you know, stolen you know, criminals can't use bad criminals can't use stolen passwords or something. Well, zero trust fixes that. Yeah? Yes. And so if you're using zero trust, then you can still do PCI DSS without having to implement stupid security controls that don't make any any use in your environment because you have something else that does the same job.

Right. Right. The I think the password requirements is is one of the most obvious to most people, in terms of, you know, the difference between a customized approach and the prescript the prescriptive approach, which is, and I don't know what the because I haven't read it yet. But the the old rules where it said seven characters and had to be changed these things and it had this complexity, you know, so so there's this way of doing it.

And the organizations that I would work with, some of the the more mature ones, the larger, more complex would say, our password requirements far exceed what you're asking for, but it doesn't in a different way. It doesn't have the specifics. How do we how how do we match this up? And so I I think the customized approach is really, it's very different from a, because people say to me, well, isn't customized approach just the same thing as, shoot.

What was it when they couldn't meet it and they had to do something Compensating control.

Compensating control.

It is not the same concept because it the the customized approach, you are meeting the the requirement, in a nonprescriptive way, but it is fully functional. The, compensating control is you cannot meet this for some reason, and so you're gonna put some other layers on there that are not required.

A Band Aid. Right? Pardon? Put a Band Aid on it. Yeah.

Put it exactly. It is like a Band Aid. And so, I I think helping people understand those differences and I don't know if there's a guidance that's gonna come out on it. We're just self evident or whatever.

There is a wow. Yes.

There is a document I understand in preparation, which is gonna come out in about June Okay.

Which is I can't remember what it's called. It's it's it's like a guide to PCI DSS four. So it'll have some, like, worked examples of how to do the customized approach. It will go into more details. I again, it's a document that I've not been involved in. It's it's it's what the working group are working on now.

You know, there was some stuff that didn't make the standard Mhmm. Because the standard was getting so long. So we we had a we've written some guides about the customized approach and it's like, should we go should it go in the standard? Should it go in a separate document? It's not in the standard, so I guess it's gonna come in a separate document.

I shouldn't talk about it too loudly. Your security metrics is gonna make me do a blog post about it. So so, okay.

Unexpected elements. Was there anything unexpected in four point o? That anything that kind of surprised you or that would surprise other people?

There There are some hidden gotchas there that that you might go, oh, I didn't expect to see that.

I I should say there were three RFCs, so the industry shouldn't be that surprised by anything that's in the standard place.

Attention.

Yeah.

There are two things that are unexpected and that aren't in the summary of changes in the report on compliance Okay. Which I know will was dear to your heart as an assessor, Jenna.

First firstly, something can be in place or it can be not in place. Yeah. So as before, we've now got a third option, which is in place with remediation.

What does that mean?

You went you went in as an assessor, you looked at something, and you went, uh-uh. That's not there, is it? Now I I was a QSA as well, so I know that's what happens a lot.

We do that all the time. Yeah.

And the entity goes, shucks. Missed that. Let's be let me put that back in place. And as long as that happens in the course of your audit Yeah. You'll accept it as the controller's in place.

That's now in place with remediation. It wasn't in place when you looked at it to begin with. Now it's in place. You as an assessor are happy that it will be in place again if you looked at it again because they worked out why it wasn't in place, and they put it in place. Okay.

People will game it. I know.

People will do preassess. Oh my gosh.

Yeah. But the the intention is to make it more obvious to management that when you went in as an assessor, fifty percent of the controls weren't in place. So when the manager signs his AOC off Yeah.

He's gonna say, why why is half it in place with remediation? Because sometimes that's not really escalated up to the people who are responsible in the organization. Yeah. It's it's, like, hidden below.

And so there's there's two intentions. One is that management will see that some of the control that they that they have believed themselves were in place all year were actually not in place when they were looked at by an assessor. And secondly, if I if if I'm buying services from you as a service provider Mhmm. And I see you have some things that were in place with remediation, well, everyone will do.

Yep. And they still pass with that. Right?

They're still pass they're still compliant.

Okay.

They're still a compliant rock. It's just that we're making clear the thing that happens when QSA's go in and they look and they it's an assurance exercise. Yeah. I I I I I you I'm not sure I've done it to screw you.

I I talk a lot of conferences about what's the point of having an annual audit. Yeah. Everyone goes, it's like, oh, so we can be compliant and prove to the guard brands. It's not.

It's the only day you get independent assurance your controls are working apart from from criminals. You have two chances of getting your your controls assessed. Yeah. One is with your QSA.

Second is with a criminal. I know I'd rather find my control wasn't working. Yeah. Yep.

Right? And that's why assessment that's why assessment's there. It's not to report to the card brands and go, oh, aren't we all clever? It's actually so that you as an entity find out whether the controls you believe are in place are in place.

But I love that. I mean, you you really brought it into perspective for me when you said what the intent was. You know, who is seeing the difference between in place of with remediation as opposed to in place and how that elevates it to the people who are decision makers, who are the ones putting money towards, time resources, who are managing that those times and resources and who are able to affect change. Right?

So, that that helps me a lot as an assessor and hopefully the the organizations, you know, if, if that conversation is going to be elevated on what something wasn't in place and then was put in place, why and what was the effort, and and how can it be prevented from happening in the excuse me, in the future. Right? So, I appreciate you you addressing that. Got my mind going in a completely different direction on that idea now.

Yeah. PCO has always been criticized as a point in time assessment. And right. And and a lot of the feedback on the original two thousand seventeen feedback was make it not a point in time assessment.

Right? But we didn't really but that's hard to do. We want people to be able to manage the the the way they run their controls. Yeah. Right? But the assessor should come in, and and if they assessor find the controls or requirements not in place, then that should be noted if it was then put in place, and and the assessor should make sure that the entity's capable of of of keeping that control running. So it's it's trying to get more real world.

I I love it. That's great. Okay. So, is there anything in it that you think people will really like?

People really like standards.

Oh, they love them. There's there's hey. Okay. So let's get back to what you said just a second ago where where you said you have two times to get it right, either when the bad guys get in or when your assessor says, hey. You're doing great. I had a customer, two years ago who got hit by ransomware.

And when all of the dust settled, they called me and said, look, the CDE was not touched. And I said, I know because I assessed it. Right? And so, when when you have that third perspective and and something changes in the way people do their security controls, when they know there's gonna be another set of eyeballs on it from outside the organization.

So so the way they do their work, the the completeness with which they do their work, I believe that assessments are one of the great tools that organizations can use to increase their security stance. So yeah. I mean, nobody wants to have their work checked and be told they're wrong. It's very uncomfortable.

On the other hand, it's a great way to elevate that.

So, so now that I've ranted about that for a second people thinks that people will really like them.

The layout the standard's been a lot rewritten. The wording is better. It's clearer. The layout of the page is much better.

It is longer because of that. The guideline section, has we we tried really hard to take anything that was a a you must do, but some of that was in the guidance section, and that's now not in the guidance section. The testing procedures a bit so it's it's a easier and better read.

Okay.

In fact, I'd say it almost reads at some places.

People are gonna creep people will laugh at me and send me rude tweets about this, but some places it's actually is is as good as a security book.

Well, just get off Twitter and then they can't, they can't tweet it to you. Okay.

So the glossary's in there.

People will like to often people didn't know what what so the glossary's at the back of the standard now.

Do words mean? Mhmm.

Yeah. What the and more of the what do words mean, there's a what is a week, what is a month, what is a quarter, what is six months. There's a table of time periods. That's excellent.

Here's something everyone will like. If it says do it every month and you miss it by a day, you have not failed your annual assessment. Right?

Right.

You missed it by three days.

Right? But if you missed it by a day because something went like, you had an emergency business thing that day. If you missed it for a reason and it and it's within, you know, what will be considered normal and it was it's a one off, that's fine. If you miss it for you know, because you just because Fred left and it was Fred that did it and no one else did it, that's not fine. But if you miss it for genuine reasons by, like, a day or two, don't worry. So that's been added in there. So try to be more pragmatic, which is hard in the standard.

Mhmm.

What will people like? I love the customized approach. I'd like to see a version of the standard with everything else taken out and just the customized approach because it could then be an information security policy for your company.

I there's one joke in there that I found, which is in eleven point two point one, which you which is a different number now, but that's the why you have why you test for wireless network access points on a, oh, gosh. I'm gonna look embarrassed now. Quarterly basis? Is it quarterly basis, wireless access point testing?

On a costly basis?

Yeah.

Like, every four every three months, you test to see if there's a wireless access point.

Yes.

Yep. Yeah.

It's the way it's the way English people pronounce Corsa.

Well, why why aren't you speaking English, John?

I don't know. Anyway, and and in the requirement, it says, like, I don't care if you have a you know, because it says a lot of QSAs have replied said, well, the entity's got a policy against having wireless networks, so we don't do that. Oh. It says it says, like, no. You have to do this every every three months because even if there's no wireless or a policy against it, attackers do not read and follow your company policy. And that's actually in the standard mode.

That makes me smile when I read it. Because that was something that that I had to clarify over and over and over again with people. Not have you suddenly added to your wireless, but has some bad guy added to your wireless? Yeah.

Just because I have a policy against eating cookies after ten doesn't mean I don't. Right? Correct.

And I thought it was just really sweet that actually they've that was written in the standard. The attackers do not read and follow a couple of dollars.

I love that. I'm going to have to go find that now. That's great.

But and I I I mean, I mean, look. A standard's never perfect. Right? It's it's it's it's written by a committee of people who have different opinions.

And sometimes, you know, they they make compromises on what they think is good security as opposed to somebody else think is good security as opposed to what somebody else thinks is is good for the industry as opposed to what somebody else thinks. Well, that's an enormous cost for the whole industry. Do we get cost benefit from it? Right?

So so the standard is it it is never perfect. You won't agree with everything in it. And I've read some interesting comment from people who blog about stand you know, about PCO already. Oh, it's terrible.

It's like, no. It's not terrible. It's not perfect. We could all make it better. I there are bits of it that I don't think are very good, and I spent two years writing bits of it.

Okay?

Well, people who write cranky things are that's how they they get people to click. So, you know, take a shot with a grain of salt. I think it's one of the best standards out there, and I assess against, quite a few. So Right.

I think it's I think it's, like you said, pragmatic. I think there it that compared to many standards, it's highly pragmatic.

Yeah. And I and I think this version is on the whole if you take it you can criticize different little bits of it. Like, you might say iframe should be in the not in SAQA, for example. Yeah.

You might say you might you can find little bits you could criticize, but but if you take it as a whole, I think it's a damn good job by the by the whole industry for the whole industry.

Terrific. Well, any last piece of advice you can offer to organizations who are moving to four point o?

Don't leave it. Don't think twenty twenty five is a long way away because if you, you know, if you need to buy stuff, it's not in this year's budget. So you need to get it in the next budgetary cycle. Yeah. It might not be in this year's change program. You need to get it into next year's change program or the next year after change program.

Terrific.

Right. So in in big organizations, service providers, level one merchants, there's a lot of work to do.

Well, so if people wanna read more about what you have to say, which is a lot and great great stuff, where where's the best place place for them to read your stuff?

So so the joy of not working for a car brand or anyone where you've got a internal marketing department says, no, John. You can't go on podcasts and you can't write things. The joy of working for myself is that I can now write things. So I'm I'm blogging at p c I dot rocks.

Yeah. It's actually a domain or p c I rocks dot substack dot com. Okay. And I'm trying to write intelligently and not snarkily about the standard and hopefully give some insights into why things are the way that they are.

And, also, one of the problems that brand a brand can never really write about what other brands do. So Mastercard couldn't write, and the Visa way of doing it is this. The PCI Council will never say what the brand compliance rules are because they don't know them because they're antitrust.

And so I'm in quite a useful position that I can write about what the standard says, also put that in terms of what are the brand's responsibilities, what's the acquirer's responsibilities, what's the assessor's responsibilities, I. E. Who who's gonna be liable, and and who cares about these things? And so mix the standard with the brand compliance rules at the same time. And I think I'm the only person writing in that area at the moment.

And I I hope that's really useful.

Yep. Excellent. Well, thank you so much for coming on and talking to me today. I really enjoy it.

Thanks for having me again. It's been a pleasure. Great.

We'll talk to you again soon. Thanks for watching. To watch more episodes of Security Metrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.