SecurityMetrics Podcast | 20
3 Myths about PCI Compliance that Cost You Time
John Elliot has a knack for illuminating the relationship between security and compliance. With over ten years in information protection and compliance consulting, and as Director of Industry Standards at Mastercard, John helps explain the relevance of security and industry standards to customers and those in the wider payment ecosystem.
John Elliot sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to reveal the three biggest myths about PCI DSS compliance and how they hinder security.
Listen in to learn:
- How the PCI Security Standards Council and the major card brands work together.
- The areas of compliance that are most critical and timely to preventing data breaches.
- Tips for organizations to make PCI “business as usual,” maintain compliance controls, and stay compliant through major changes
Resources:
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.
3 Myths about PCI Compliance that Cost You Time Transcript
Hello, and welcome to the SecurityMetrics podcast. My name is Jen Stone, and I'm one of the principal security analysts here at Security Metrics. Before we get started, for the first time, we're going to do a correction on something I said last podcast.
The, stand up comic was not Mike Birbiglia. He was John Mulaney, and that's, something you can look up.
We have another John with us today, John Elliott. I am super excited to have you here today, John. Thank you for joining me. Would you please introduce yourself?
My name's John Elliott. I I'm on the industry standards team at Mastercard, which means that I work, with the other five card brands on the PCI SSC to help develop, the PCI standards. And I also look after our customers and their customers when they've got questions about the PCI standards.
Terrific. Terrific. So, obviously, today, because we have you, we're gonna talk about PCI.
Sometimes we talk about other security standards and things. PCI is very much, kind of a universal thing that that a lot of people, especially if they take credit cards, people are at least familiar with the word PCI, but some people don't know. So let's start with the basics. What is PCI, and why do we have it?
That's that's that I don't wanna keep saying that's a great question, but as a kickoff, that is a really great question. Because, you know, people do PCI, but they sometimes don't think about it enough. So, look, PCI is the PCI itself, just those three letters, per payment card industry, there's sort of two bits to it. So the PCI Security Standards Council is a standards making body, a bit like ANSI or ISO or any other standards making body you've heard of, but with a bit of a wrinkle because it was set up by the five card brands.
That's Mastercard, and and four others. You can look at the website to find out what they are. Okay. Nice.
The the piece well, yeah. Come on.
And I actually really enjoyed that.
Okay. Keep going.
And and and and PCI PCI develops security standards. It develops the PCI Council develops fifteen security standards. So there are lots of different security standards. Most people have heard of PCI DSS.
And if I say PCI to people, they think of the DSS, the data security standard. It's like the number one thing that it does. Right. But there are fifteen others.
There's the the the point of interact we call them point of interactions. You might call them should you call them chip and PIN machines in America?
I call them POSs because I think it's funny, because it stands for other things as well. But but, yeah, we can call them chip and PIN. We can there there are a lot of things people people refer to that the device Yeah. The swiper. Okay.
So the thing that you swipe or stick or tap your card on.
Sure.
Right? We we we call them POIs, but there are standards for those. There are standards about the way the PIN is encrypted. There are standards about the way the PIN is decrypted. There's standards about the way that the PIN actually gets to you as a cardholder.
Right.
So there are fifteen different security standards. DSS is the main one that people have heard of. And the question is like, so that's what PCI standards are. The question, why do we have them?
Because bad guys steal cardholder data Right. And try and commit fraud with it. Okay? They've been doing that for the past, I don't know, fifteen years.
And so we have to have security standards to protect the whole payment ecosystem.
Right.
Right away from the card being sent to the consumer and every time the consumer uses the card. Now here isn't it really funny? We used to have there used to be five well, because there are five card brands. Mhmm. Every card brand had its own security standards.
Oh.
And I remember I remember when they, like, disagreed with each other. Mastercard security standard would say, you must have a fifteen character password or nothing. And Visa's would say, oh, you must have a twenty character password or nothing. And it's like, so so it's a real problem for for the whole industry and the merchants Right. To actually get to get to actually work out what it was that they had to do. And so they came together in, I think, about two thousand and six and formed this body, the PCI Security Standards Council, to develop security standards so that there was one standard that people had to follow.
Nice. So, so we've got the council and we've got Mastercard and and the other card brands.
What's the difference? And and, how do they work together to create this thing?
Yeah. That's that's that's a really interesting and complicated problem. But but a lot of people struggle to to, I don't say, get their head around, but the understanding of this is really important. So the Security Council, the PCI SSC, just develops the standards.
Right? And and on their own, they're just standards. I mean, you can print them out. You can read them.
They're very exciting as as probably, Jenny, you know, because you work you work in this industry.
Memorized. It's amazing.
Yeah. Okay. So but the really important thing is that without a card brand telling somebody to comply with the standard Mhmm. They're just, you know, written security standards.
Right.
And so so the big difference is that Mastercard and and the other people, we will each have compliance programs that say certain types of organizations, certain classes of organizations has to comply with one or more of the fifteen different PCI standards.
So the Security Council makes the standards. We use those standards in our compliance programs for our customers, and our customers are acquiring banks and issuing banks Right. To say how though how they should use those standards to secure cardholder data. Is is that clear?
It it it is. And it I think the enforcement part is, a lot of people don't understand that means that if you don't follow PCI and, your acquiring bank can say, you know what? We don't wanna be your acquiring bank anymore. Like, if you're not if you're not secure, why should anybody let you take credit cards?
It's absolutely right. It's the acquiring bank's risk profile of which merchants they wanna do business with and which merchants they don't want to do business with. A merchant that has a breach of cardholder data can be a significant liability for that acquiring bank, and so that's why they would use PCI DSS as a benchmark to say, this merchant wants to look after cardholder data securely. We're happy to do business with them.
So it's a it's a way to spur conversation and encourage secure, behaviors by merchants and the and the banks that that's, that take care of them.
That's right. Because our our contracts with our customers we are all the acquiring banks are our customers. And our contracts with them says, when you sign up a merchant, you will have in your contract with that merchant that they must comply with PCI DSS.
So, does PCI DSS apply to everyone in the world that touches cardholder data?
That's that's a great question because it's a sort of popular misconception that it just does.
Like, oh, you've got card I mean, I've heard so many people say, well, you've got cardholder data. PCI DSS applies to you. It's like, it only applies to you if someone's telling you that you have to comply with it. Now the fact is that most people who touch cardholder data will be told by someone to comply with PCI DSS. If you're one of our customers, if you're an acquirer or an issuing bank, in our contract with you, we'll say you will comply with PCI DSS.
If you are a merchant, your contract with your acquiring bank will say you will comply with PCI DSS because both any card brand that has has a deal with that acquirer will say put that in your contract.
Right.
If you contract as a merchant directly with another type of card brand, we won't mention them, but some card brands contract directly with merchants, that contract will say comply with PCI DSS. So, generally, people formally in the cardholder ecosystem will have to comply with PCI DSS because they're contractually obliged to. There's a there's a whole another class of organizations that will comply with PCI DSS, which are service providers.
So they don't comply with PCI DSS because they wake up one day and think, oh, I touch cardholder data on behalf of organization x. I know.
I'll comply with PCI DSS because does that.
Surprisingly, organization x's contract with that service provider says you will comply with PCI DSS. So practically, the answer is that everyone most people in the world who touch cardholder data will comply with PCI DSS because it's a contractual requirement. There are some people that touch cardholder data that don't have to comply with PCI DSS.
So so the consumers have payment cards, but they don't have to comply with PCI DSS. They have to look after their payment card as their issuer tells them to look after their payment card. So when you've got your card, you'll have got this long document that says probably things like, you will not write the pin down on the back of the card Right. Or tell it to anyone. You will keep it secret. You will tell us if you lose your card. So you have a whole set of security obligations put on you by the person who issued your card.
But it's not the same as as, complying with PCI DSS.
Absolutely not.
Okay. So, I thought it was interesting where you said, but the the service providers are are spurred on by contracts with their merchants. I see that most frequently, kind of inaction in, higher education.
So a lot of times in higher education, there's a lot of little merchants, and they they work with a lot of different little service providers that may or may not have known they were going to have to comply with PCI DSS. So then I end up having conversations with some of these smaller, new ish service providers that are just learning. Yes. If you're going to to create soft if you're gonna develop software, if you're gonna host, a a payment page, those types of things, and then they get to learn about it. And they're always so excited.
Yeah.
It's it's it's an interesting surprise if you've signed a contract and you've not realized that when it said comply with PCI DSS, I think, yeah, I'm sure I can tell you.
Yeah. Yeah.
Yeah. Because it's a fairly detailed security site.
It is. And I like that about it. It gives a real defense in-depth approach to protecting, any kind of, information that you don't want to be let out. But, it's very, very good for cardholder data. So, you've been working, with DSS for, what, ten years, I think, you said?
I've yeah. I've it's been a it's been about a lot. I think I I think I call it I I think well, I I started off as just a general security person. And then one day, someone twisted my arm and said, can you do some risk assessments for some of our customers to comply with this PCI DSS thing that I'd never heard of? I have to be really honest. So I went so I went and just did some, like, requirement twelve risk assessments.
And the company I did this for, they were a QSA company. They said, oh, this is really interesting. Would you like to be a QSA? And I thought QSA, a qualified security assistant, probably like you are, too.
As I am as well. Yeah.
Okay. So so but for everyone else, someone who who's authorized by the council to to to do CIDSS assessments. And I thought, no. I don't want I don't wanna get into payment security.
But the thing I wanted to get into wasn't going well at the time. I thought, oh, I'll do it for a couple of years. Okay? So I went to to QSA training, and I qualified as a QSA.
And then after about two or three years of being a QSA, I'm actually really enjoying helping people secure payment card data because I really got into it.
Another car brand we had a car brand in Europe called Visa Europe, and they asked me to join Visa Europe. And so I worked there for a few years writing PCI standards, I do in fact, it's pretty similar job to what I'm doing now. And then I went and spent some time in a very big merchant and got them PCI DSS compliant and then came back to Mastercard. So yeah. In all, that's about ten years.
That's that's really well. So it's funny because I said no to this job three times before I said yes. And like you, I really got into it. I really enjoy helping people secure their information.
And, oh, the, PCI Europe, conference that's happening, I'm speaking on risk assessments for PCI. So Oh, wow. It's like kind of kind of parallel, John. Yeah.
So, what's some of the main things that you've learned in that ten years?
Wow.
I I could go on for hours. We haven't got hours in the podcast. Let me give you let me give you three things. Okay? The the first thing is that people and when I say people, I mean everyone, merchants, QSAs, all sorts of people don't actually read the standard enough.
Yes.
They often say what they think the standard says or what the standard used to say or what they believe the standard should have said if only the people writing the standard had done the job properly. Okay?
So so so they'll tell you know, you'll often hear a merchant say, well, PCI requires me to do this, and I'm thinking Doesn't you know?
Yeah. It doesn't actually say that.
It'd be quite Yeah. It'd be quite good if it did, but we didn't put that in. You know? That's not in the standard. So the first the first thing is that so if someone's and and actually, I I look on Stack Exchange quite a lot. Do you look at ever Stack look ever look at Stack Exchange?
I do Kate, except for that and then it makes me get into arguments. So I do occasionally.
Yeah. But and sometimes you'll see there, someone posts something that says, well, we've got the PCI auditors in and they say we need to do this. And I look at it and go, oh, but it doesn't say that. So the first thing I would say is, like, read the standard.
Like, I when when I'm doing when I used to do consulting engagements, I'd walk on-site and I'd give people copies of the standard. Mhmm. When someone who says PCI requires, it's like, no. Which requirement number?
Let's look at it specifically. Does it say that?
Or is that we is that what you're interpreting it to say or you haven't actually read it, you're just believing that's what it says.
So that's that's the number one thing is that people don't apply the standard as it's written quite a lot.
The second thing is that there is loads of brilliant information on the PCI SSC website.
There are thousands of frequently asked questions. There's lots of really great guidance documents. Mhmm. On the Mastercard website, a Mastercard three sixty or Mastercard slash SDP, we've got loads of FAQs and really useful information about PCI DSS as well.
What what I find people do is they just don't look at the information that's available. They think, oh, I don't know how to interpret that. I'll make a guess. Mhmm.
So so so the second thing that that I see go people get wrong with DSS is they don't read all the resources that's available for them.
I I I I agree. I've seen that actually quite a bit. They they don't even know where the document library is or that it exists on the PCI site. And so that's something that that is a very frequent conversation that I have.
And it's so frustrating because you someone comes to you with this thing and they say, well, we decided to do this and we've done this and we've done this and and it's like but if you'd read the guides on the PCI SSC website, we say you don't need to do any of that. Or sometimes they say, I don't know how to do this. It's like, there's a document there that tells you exactly what you need to do. Mhmm.
You know, it's a really great example. There's a lot of merchants and a lot of merchants struggle with tokenization solutions, like, how should we deploy tokenization solution? There's a brilliant guide about the criteria you can use to evaluate tokenization solutions and make sure they're implemented properly and they're providing good strong tokens Right. In the document library.
Right?
Or even something as simple as scoping. But, you know, I'll get especially people who are new to d PCI DSS, how do I scope my environment? And so I know we send them the document from from the document library. It's excellent.
Yep. Yeah. And then, you know, as a consultant, I used to think, you know, is it fair for me to, like should I just advise them or should I just send them the document?
Right. Where where is that balance between that? Where's that balance? Yeah. Well and and then, of course, you have to be careful as the assessor.
How do you fairly assess without doing the work for them? And so that's why I find the document library valuable because I can point them to it with and then they can go and do their research and put the things in, and then it's not me making the things happen. Right? And so Absolutely.
So it's a it's a constant balance between am I advising? Am I am I reviewing? Am I assessing? Where where are we in all of this?
Yeah. So the document library, I find very, very helpful for that.
So so those those, I think, are probably the two main things that I've learned that that that if you just said ten years ago what you think you'll learn, it would have been something technical, not something about how people in my understand.
Yeah. Right.
And then, and this is really related to to the first one, is that there are lots of myths in PCI DSS, like popular folklore Right. That people just seem to accept as fact. And it's like, but where where did that come from? So so that's the third thing is that I often end up saying to people, no.
That's a that's not true. That's a myth. And they start, but I've read it on the Internet. It's like, just don't believe everything you read on the Internet.
Do you know, I act I love we talked a little bit about myths when when I initially was asking you if you'd be interested in in coming and talking to me. And, and so, I have some of the myths that we discussed earlier because they're very interesting, and I wanted to to, to go over a couple of them with you. Starting with Sure. If you don't and I hear this one all the time. If you don't store data, PCI DSS doesn't apply.
Yeah.
And and I hear that lots of times when I hear especially from service providers, and and I hear it from merchants who outsource storage to service providers. It's it's like it's a it's a really great wishful thinking myth as well. But, you know, PCI DSS applies to you if you store or process or transmit cardholder data, any of those things.
So so it doesn't matter if if you don't store it, you're processing and transmitting it. You know, most attacks nowadays, if you look at most criminal attacks and I know Security Metrics has got a PFI practice, so you have a lot of inside knowledge about the way that attacks happen.
So I'm sure you can back me up on this.
Most attacks are what we call in transit attacks. Mhmm. In memory attacks or in transit attacks. Yep.
It's very rare now that attackers steal cardholder data from lots of storage on disk because no one stores cardholder data on disk anymore unless it's really strongly encrypted. Because when they did, criminals used to steal it. So everyone's worked out that's a really dumb idea. Yep.
So let's So, yeah, DSS applies if you touch cardholder data.
So it doesn't matter if you don't store it.
But that that's such a popular And then there was an another phrase that got added in the was it three point o?
Or could affect the security of?
Yeah.
And I I well, I don't know which exact one it added that that. But so a lot of times that the security or or sorry. The service providers that we talk to will say, I don't do any of those things. And then you have to say, well, do you develop the code that goes on their page for the payment?
Okay. If that has JavaScript skimming, attached to it, if it's if it's improperly configured, if you have, cross site script, if you have all of these, potential issues, could that cause a problem with cardholder data? Oh, yes. It could.
Alright. That's in scope. Right? So helping people understand that the purpose is we're trying to protect cardholder data helps them understand Yep.
How it applies to them. Alright. I also get told of this one a lot. It's legal.
It's a legal requirement.
You you bet. And, actually, I have to be careful. It is in some countries a legal requirement.
Which ones?
Yeah.
Or I mean, that's a really rude pop quiz question because It is.
It is. It's a really, really pop quiz question.
I I'm going to I'm gonna go with, Turkey wrote it international law. Saudi Arabia wrote it international law. A number of countries have written it international law Okay. As has a number of US states.
So it appears in state law Oh, okay. I think six US states.
Well, so now I'm feeling deficient, and I need to go study because I didn't know the answer to a question that I asked you. So I'm gonna not go and just go study. We're making a note.
Yeah.
And afterwards, I can send you the list of US states where where they've run interstate not federal law, but interstate law. Great.
But, generally, it's not a legal requirement. Generally, it's a contractual requirement.
Where it is a legal requirement, obviously, the enforcement's not from the card brands. It's from the government and the state. Wow. So that's quite a different thing.
That that is a different thing.
And I But for most unaware.
Most people, it's not a legal requirement.
Great. Now I'm gonna get fired because I didn't know everything.
So my next myth that that we didn't write down is you don't you don't you don't have to know everything.
Oh, wait a minute. You mean we can look these things up?
We can look these things up. And that's actually a a big failing of a lot of, qualified security assessors that they'll often trust their memory rather than trust the document.
And, you know, I think this is something that, this is why I continually go back to the documents. I don't have it all memorized. I don't know the answer to everything. So when somebody sends me a question, I make sure to look it up because Yeah.
There's a lot there, and and there's nuance. And so I don't wanna get it wrong. So, I'll I'll keep looking things up. And, as a QSA, though, I guess as a side note, that you've heard of the the, the imposter syndrome, maybe.
It's something that a lot of QSA's that I've talked to feel like that is a real thing because we don't know all of these things off the top of our heads. We don't know the answers to everything, and we don't know how every tool accomplishes everything that it that it accomplishes.
And so that leaves you kind of in a position of, well, if I don't know all of these things right there, am I really qualified to do this? And I think the answer is probably yes as long as you're willing to look it up.
The answer is yes as long as you're willing to look it up and take the time to speak to your client and get your client to explain how this thing you've never seen works and how it how it fulfills the requirement.
That's I mean, that's pretty much most of the assessment time.
For me, anyway. I don't know how other people always do their jobs, but, yeah, it's a lot of learning everything all of the time. I I wanted to, jump to this one. PCI is a technical issue, so you don't have to involve the business.
Oh, man. Yeah. And I I've as as a QSA and working for card brands and as a consultant, I've seen lots of organizations trying on the journey from being PCI DSS noncompliant to trying to get PCI DSS compliant. And the biggest there are a few biggest mistakes.
I can't have a few biggest mistakes.
I'll let you.
I'm gonna I'm gonna have this as the biggest mistake. The biggest mistake is giving it to the technical people because they treat it as a technical problem. And, actually, the thing with PCI DSS is it's it's about the footprint of cardholder data in the organization. Where where does the organization store process transmit cardholder data?
And the first question I ask as a consultant is, do you need to? Do you need to have that cardholder data there? Do you need to store it there? Do you need to do you need to process it there?
Why is that big database there? How does your business processes work? So I'm very much focused on business process engineering as a first step in PCI DSS compliance to say, well, why are you doing that? And so, well, we did that we've done that for the past fifteen years.
Yeah. Do you get any value from it? No. Okay. To secure that's a two million dollar problem.
Do you get any value from it that's worth a two million dollar problem?
No? Okay. So and that's a business conversation that technical people generally don't have. And I'm gonna give you a really cool example, which is of a big sports stadium.
Do you remember when we could go and watch sports in stadiums? Before times? In the before times. Yeah.
And, this sports stadium realized it needed to become PCI DSS compliant. And it's got point point of sale all around the sports stadium for beverages, for food, for you call them concessions, don't you?
That's what I'm saying.
Concessions. Yeah.
They have concessions all over the sports stadium. And they needed to make all these concessions PCI DSS compliant. And and what they decided to do was eventually, by doing some business analysis, was put in a point to point encryption solution, which meant they needed new point of POIs, new new chip and pin machine.
In doing so, they made a case that they should put contactless in. And actually, the contactless sped up the time through the bar, which a sports event, you want people to the bar quickly so the queues are not massive. Mhmm. And the the by the the cost justification for doing this ended up being the contactless implementation because they also cut down on their cash handling massively.
Mhmm.
They cut down on the number of ATMs they had to have in in in the building.
And it was a business decision that got them PCI DSS compliant by buying new POIs, but, actually, it paid for itself really quickly. And and only when you have those conversations with business owners that could say, well, have you thought about doing this or have you thought about doing this, that will give you a business benefit as well as a compliance benefit and a security benefit, that's why it's not a technical problem. It's a it's a business process problem to begin with. Then it's a technical problem.
Right. Those are some of my favorite conversations. I've I've, lost two customers in the last, few years because I introduced them to the concept of, P2PE or point to point encryption.
And they were small enough that they did not need, an assessor to assess them. They put in, without the but they wanted it because of their the the complexity of their solution. Once they had the p p to p e and they were able to self sign with confidence, and, and I'm sad because one of them was near a really cool little zoo.
And what what you know, you you kind of like going to to these places and seeing the people, but it's more important to give them a solution that works for them.
Yeah.
It cost them less money and and gives them greater security. So that's what I do is is help them reengineer sometimes.
So people who become PCI certified, and then they say, I'm compliant for a whole year.
Yeah.
Tell me about that interesting myth.
As as you well know, they're compliant for the day that they were compliant. They were assessed as compliant. Okay? The a PCI DSS assessment is a point in time assessment. Yes. It's gonna look up processes and procedures behind it, which should hopefully keep you compliant, but it is a point in time assessment. And so you can be noncompliant the next day because you could turn your firewall off.
Right.
You could do all sorts of things. And so the the key to being compliant is to make compliance business as usual. So the fact you're certified on day one, on the next day, you still have to keep all those business processes and those requirements up. And and I know, I've you know, having worked in merchants as well, that's a real that's the hardest bit. That's really the hardest bit.
Yeah. So that's, those were some fun myths. I wish we had time for all of them, but maybe we can have you come back and talk talk again. But, let's, let's move on to a couple more things, here today. We've talked a lot about the standard and about compliance.
People a lot of times will say to me that it's just compliance. It has nothing to do with security. Doesn't it doesn't translate into real security.
And, this is one of the things that bothers me when people say it because it's so far off the mark. Can you speak to that?
I I can, but I I need to try and do it without using bad words. Alright. Because I I get cross with people like that.
Yeah.
It it you can do PCI DSS as a compliance exercise, and you can get compliant and become and be insecure in doing it if you want to do that.
Right? We have all, as assessors, have clients who try and twist the words of the standard or the scoping or whatever to get a compliance tick. So it could just be compliance.
Sure.
Right? But that's about the organization.
However, if you implement DSS as it's written, it will make you secure. It is a defense in-depth with lots of technical controls. Yes. And if you implement all those technical controls, even if only ninety percent are running most of the time because it's really hard to keep, what, two hundred and eighty four technical controls running at peak performance every single day Sure. Because it's a defense in-depth standard, you'll generally be secure.
It's it's about your attitude to it.
And there's a very famous saying that, you know, no one who's BCIDSS compliant has been compromised. If they were compliant with all the requirements at the time, they probably don't lose cardholder data.
Right.
It's a good technical security standard.
It is.
The downside of it is it's prescriptive because it tells you what you have to do. And you might say, well, I don't wanna do that. I wanna do something else that has the same outcome, which hopefully we're gonna fix in PCI DSS version four.
Right. Which will be exciting to to learn more about, once it's released.
So people say, alright.
We're suddenly, we realize we have to be assessed rather than self assessing on the PCI, standard. And that's the point at which a lot of especially larger larger organizations find out that what they thought was true about themselves is not true about themselves, and they have more to do than they can get done.
And so what and and so they have to take a kind of an intermediary approach.
Yeah. It and as as an assessor, you've seen this lots of times when somebody else comes in and looks at how well an organization is complying with the standard and they think, wow. I thought I was doing better than that. And it's actually done a big ask because the question is, well, what do you do first?
Right.
If you've got if you've got a hundred or a hundred and fifty requirements that you thought you were doing okay at, but actually, they don't meet the rigor of the standard, that's a big thing. And there's actually a great document in the council website called the prioritized approach, the PCI SSC PCI DSS prioritized approach. It's a big spreadsheet.
Basically, it takes all the two hundred and eighty five ish PCI DSS requirements, and it breaks them down into six sections, which we'll call do first Mhmm.
Right the way through to do last. Right. Doesn't actually call them that, but that's what it means. Yeah. And the ones in the do first are the ones that give you the biggest security benefit straight away.
There's things like patching in there Right.
And default passwords and decent passwords. You know? And if you look at the compromise reports that we all that that you will see because you work for a PFI company and I see because I work for a card brand. You know, most compromises are down to bad patching, terrible passwords, and default passwords.
That that fixes most security problems. So the prioritized approach says do the things that give you the biggest benefit first, then do the things that give you the next biggest benefit second, and then the things that give you the next biggest benefit third. And often, if you're not if you're going from that that that I I was self assessing to I now did a QSA who's gonna really look at whether I'm doing the job properly. Through that transition period, your acquiring bank's going to support you.
Yes.
You're not the first organization that this has happened to. You won't be the last. And therefore, you know, your your acquiring bank will probably suggest you use the prioritized approach. If they don't, you should go to the acquiring bank and say, I'm gonna use the prioritized approach. I'm going to report to you where I am on those six, I think they're called milestones.
Six milestones. Yes.
Phew. Thanks.
And I'm gonna I'm going to, you know, I'm going to get to milestone one by the end of quarter two. I'm going to get to milestone two by the end of quarter three. And the acquiring bank can then see you're taking payment security seriously. You're trying to fulfill your contractual obligation to be to be compliant, and you're doing it the right way rather than thinking, oh, hang on.
Let's look at PCI DSS, which is the cheapest and easiest requirement to meet. That's twelve point one, write a security policy. Let me write a security policy first. It's like, no.
No.
Number one, go and go and patch everything.
Patch everything.
Yep. That is, that is the most critical. That's where we see so many breaches. And and when it's not in place, it makes me just kinda shudder.
Yeah. Now, Jen, having worked for a really big merchant, patching everything's not easy. No. So I know we can we say this thing like, oh, just patch everything.
Yes. I know it's really hard. But frankly, it's the best really hard thing you can do. There are other really hard things that I've seen organizations do, like, say, oh, we're gonna implement privileged access management.
That's great. Okay? That's not in the standard, and it's really hard. And it's a great security thing.
Yeah. But you haven't patched everything yet. Right. And there's no point doing anything else until you've patched everything.
Yeah. Because the bad guys break in in two ways.
Number one, they attack your users and they get their credentials.
When they've got their credentials, they then use privilege escalation because you haven't patched.
Right. Right. Right.
And I and I So it's the second thing after the phishing I certainly didn't mean to be flippant about the patching or about really any security controls.
I think maybe it's just because it's the thing that I see so often where when you bring it up, people say, oh, yeah. I mean, we have a patching program, but then the patching program isn't taken seriously.
But I know that if there's a patch that comes out off cycle, the the disruption that it can cause. So before I became a a security analyst, I was, I was in IT operations.
So I get the chaos that You've been on the other side.
Yeah. From, hey. Can you just patch that? You bet.
Moving on from the prioritized approach, I I see a lot of companies who think they're compliant, but they struggle with the whole what you just said a moment ago, making PCI DSS business as usual.
How can they fold the concept of the security from the standard into their their regular day to day?
Wow. I'm there's there's two answers for this. So I'm gonna give you my consulting answer first. So, like, if you hire me, which I don't do anymore, but if when I did, if you hired me to do PCI DSS, I would make sure your program lasted a year after your first assessment.
Right? Now most programs finish with the first assessments.
QSA comes in. They you get your report on compliance. Everyone's really happy. The program team disperses, and then all the controls do this gradually over the next twelve months.
Mhmm.
And, actually, the success of a PCI program is to have all the controls continue to do that. Right. And you can only do that if you end the program at the end of the sec at the end of the second at the end of the second assessment. Correct. So that's my consulting tip. Mhmm.
My nonconsulting tip is, basically, you need an internal assurance function. You need something internally that's checking those security controls that are in place and working because they won't on their own. Right? There's just no way that they will work on their own. And and if you look at the Verizon payment, report that looks at entities a year after they've done the an assessment. I'm sure you SecurityMetrics, you have exactly the same experience and publish exactly the same thing. Its controls just decay on their own if they're not looked after.
Right.
So without an internal security function, sorry, an internal assurance function that says, okay. I'm now gonna check that the antivirus or the anti malware controls are in place. I'm gonna check that the patching was done. I'm going to check this was done. Because in operations, if if there's a fire, you're going to put the fire out and not do the patching.
Right? Right? And so somebody needs to hold you to account to say, I'm really sorry, but this is in our contract with our acquiring bank. We have to do this patching thing because, a, it's part of a compliance thing, and, b, you know, that's why that's that's how we're gonna get compromised.
So you're just putting off a a temporary fire effectively. So you have to have an assurance function to make sure that everything in PCI DSS is happening in business as usual. I know that's a real pain for a lot of organizations because they're like, well, how do we do this? One of the really cool things is at the back of PCI DSS, there is a an append there's about three or four appendices.
Most people never read them. Right? But there's one there's one that's really cool. It's called the designated entity supplemental validation or DESV.
Mhmm. And and that's written for entities that the card brands think needs special attention, typically. It's up to us who we apply it. Mhmm.
It has all the requirements in it to make PCI DSS into business as usual. It's about having management commitment. It's about having someone as the highest level that's responsible and accountable for compliance. It's about having the policies and processes in place and making sure that they're working.
It's about an assurance function that's testing all the main requirements of PCI DSS are in place so you don't find out when the QSA comes that you haven't done your quarterly vulnerability scanning. Right. You find out at the end of the first quarter. You find out before that because someone's looking at it.
You find out that all those regular things that are in DSS happen.
Mhmm.
And and the other thing it's very concerned about is is the thing that breaks PCI DSS compliance for for for organizations is number one is control decay, and number two is change. So the CDE will change. The people in the organization will change. Yes.
The organization will change what it does. All of those change things typically need managing to make sure they're brought back into compliance. Or if you're really lucky, you can manage to be compliant through the change. But, typically, that change has happened.
Sally left. Sally used to look after this. No one's looking after this. Somebody in an insurance function needs to pick that up and say, yeah, but we haven't we haven't done that.
This thing that we're supposed to be doing, we're not doing anymore. Sally did it. Who's taking it over? No one's taking it over.
Okay. Who is going to take it over? All of that is in the DESV about making sure PCI DSS is embedded into your organization. Because without it and I'm sure you've seen as a QSA.
You go back a second year and all the good work that you saw that that you were that you were you were assessing as people were doing it and providing a bit of advice by providing documentation or pointing people in the right direction, all of that good work is undone, and they almost have to kick off a second PCI DSS project to get compliant again. Yes. So they've not got so ignoring the security sorry. Ignoring the compliance problem there, they're gonna have some security holes.
For sure.
And those are security holes that probably the senior management think they've nailed. Mhmm.
Right? And and so that's why this assurance function of making sure that you keep compliant, that you keep the core requirements in place.
And and if and if you're starting off doing this, look at what's in milestone one and two of the prioritized approach. Say to yourself, this year, we're going to focus on keeping everything that's in milestone one and milestone two running a hundred percent at the time, and this is how we're going to do it, and this is our commitment to it.
Because that will keep you secure Sure.
For for ninety five percent of organizations.
Absolutely. And and you I I see it. Like you said, senior management thinks one thing and they're either disconnected or they're not taking it seriously. They just consider it, well, it's something IT does. And so the visibility into it is not there. So having somebody internally making sure reporting back, making sure the people who need to know who are making decisions about spending, who are making decisions about, resourcing, they need to know, but they have to care about it before Absolutely.
What they know applies to the the regular business functions of the organization.
Yeah. And I think, you know, one thing is to make is is there's two things for that person. Number one is get them on an internal security assessor and ISA training course because then they've had the same training that QSAs have had. And the second thing is is don't put them inside the IT department because they're at you're you're basically you're asking them to hold the IT department or the technology department or the operations department. You're asking to hold them to account. So they probably they probably need to be somewhere else in a risk function, even maybe in an internal audit function.
Yeah. Because those separation of duties, if they feel pressured by the if they're telling their boss that, oh, hey, boss, you need to make sure that this happens, and it's the same people doing the work as we're reporting on the work, that there's not enough separation there to to to create the the impetus that that for for making sure it gets done.
John, this is, we are out of time, but, man, I really enjoyed talking to you, and I'm super, glad that you had the time to do it. And I hope that I'll get to to have you back on the show again, next season.
Yeah. What it'd be really great to be able to come back once DSS is formed, and we can talk about it. Yeah. But, you know, I I I'm awesomely pleased I can tick one thing off my bucket list.
Well, I've Be on Jen's podcast.
I appreciate it, John, and I hope you have a great rest of your day. Thanks very much.
Thank you for joining us again here at the Security Metrics podcast. I hope I see you again next time. Thanks for watching. To watch more episodes of Security Metrics podcast, click on the box on the right. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)