PCI DSS 4.0.1 isn't new anymore, but a lot of businesses are still struggling with the same requirements. Jen Stone talks with Matt Halbleib, Director of Assessments at SecurityMetrics, about the parts of 4.0.1 that continue to cause problems for small and medium businesses, and what to actually do about them.
Chapters
00:00 Intro
00:39 Meet Matt Halbleib, Director of Assessments
01:17 Why 4.0.1 is still tripping people up
02:04 Advice for getting started on the right foot
04:37 Getting management buy-in and assigning a project manager
07:32 Why scoping still matters
09:26 Targeted Risk Analysis explained
13:22 What changed with MFA
15:34 New service provider responsibilities
20:34 Logging and alerting requirements
24:39 Password Requirements and advice
26:58 Compensating controls: how to use them correctly
28:57 The customized approach: Don't do it!
30:04 E-commerce: why this is where breaches are happening now
35:41 Wrap up
🔗 Resources
PCI DSS 4.0.1 Standard: https://blog.pcisecuritystandards.org...
Shopping Cart Monitor: https://www.securitymetrics.com/shopp...
SecurityMetrics PCI DSS resources: https://www.securitymetrics.com/blog/...
About the Guest
Matt Halbleib is Director of Assessments at SecurityMetrics, where he's worked in information security for nearly 19 years.
Transcription of What Businesses Keep Missing for PCI 4.0.1
Jen: Hello and welcome back to the Practical Cybersecurity Podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics, and I'm very excited to have with me today the Director of Assessments here, Matt Hall.
Matt: Thanks, Jen. Happy to be here.
Jen: Tell people a little bit about your background.
Matt: I love my background. I've worked in IT for a long time, done information security for a long time, and I've been here at SecurityMetrics almost 19 years.
Jen: That's great — it's a great place to work. I hope I get to work here for the rest of my career, too.
Matt: Same. There are some great people here.
Jen: So I asked you to be here today because when we look at small and medium businesses — even large ones — trying to meet PCI DSS 4.0.1, we've been on the 4.0.1 version for a while now, and people are still struggling with a lot of the new aspects of it. I thought we could talk through that. It was a big shift from 3.2.1 to what we've got now. Before we dive into the problems and how to solve them, give people some quick advice — what's going to make this successful for them?
Matt: I don't want people to feel bad about the fact that they're maybe still not rocking this, because honestly, the IT environment changes at a really rapid pace. I've been doing PCI specifically for 19 years, and when I first started, nobody was in the cloud — that wasn't a thing. Even decent-sized organizations were skeptical about putting their information in the cloud. Now it's virtual machines, it's the cloud, it's a mixture of both. Technology just keeps moving, and you have to apply the principles behind the PCI requirements to that changing landscape. That's not an easy thing to do.
Jen: Exactly. I think another struggle is for groups that have been doing this a while — they get into a "we know what we're doing, here's how we do it" mindset, and then new requirements come along that they haven't done their homework on. Part of it is we actually have to read and understand what the requirements are saying to us.
Matt: Oh yeah, absolutely. We give a copy of the PCI DSS to pretty much all our clients.
Jen: And it is riveting reading. It is not an easy read, for sure.
Matt: It's important to actually read the requirements, though. When the Council moved us from 3.2.1 to 4.0.1, they put out a document summarizing a lot of the changes, which is a nice start — but it's not enough to just read over the summary. You need to go read the requirement itself and figure out what they're saying. And get the PDF version, not the ROC template — the PDF has a lot more guidance in it.
Jen: Right, because some people have never read the full standard, so they don't know there's a guidance column in there that actually supports them.
Matt: Right — it's meant to help you understand what the requirement is trying to examine. So please, do your homework.
Jen: I think another challenge is that sometimes we as assessors are working with the technology team, and they're trying to supply things for us to examine, but the business hasn't established a project manager. What are your thoughts on how having that kind of organizer on the client side helps?
Matt: Number one, you really have to have senior management buy-in. If senior management doesn't really want to be PCI compliant, it's going to be an uphill battle. So whatever mechanism you need to sell this to senior management — help them understand why it's important for the business, why it can be a business driver, why it can actually improve their posture with clients, being able to say "we know PCI, we know what we're doing, and yes, we protect your information." Get that senior management buy-in, and then get somebody on your side to drive it, because the Council calls this "business as usual" — it's supposed to become part of what you do every day. If you're newer to the process, or revamping your program, you need somebody who can drive these changes across the organization. It can't just be the IT guy — it's not just his requirement.
Jen: It isn't.
Matt: There are business processes that get impacted by a lot of these changes.
Jen: Absolutely. And a lot of times the IT folks get stuck with it — not just because a lot of things are IT-related, but because the IT team (and I have so much respect for them on this) are able to take something they've never done before and make something of it. That's part of the mindset of that group, which is great, but it can also exclude the business needs and business drivers. Organizations that put somebody from the business side in charge of managing the process just come out better.
Matt: Yeah — find somebody who can speak both languages. You don't have to be super technical, but you need to know the right vocabulary on the technical side, and also be able to speak to management.
Jen: Before we jump into some of the 4.0.1 requirements — can we talk one more time about the importance of scoping?
Matt: That's my favorite topic. It's easy and hard at the same time. Like I said, get the standard and read it — specifically the executive summary, because it gives a lot of detail on what's considered in scope and out of scope. They spend a few pages on this: what stores, processes, or transmits card data, and what's connected to or impacts the security of those systems. Once you internalize that, it makes more sense when your assessor comes to you and says "show me a firewall" and you're looking at two zones that are connected, thinking "that doesn't touch PCI" — but they talk to each other, and that matters.
Jen: Right, and you might be missing a chance to exclude things if you haven't scoped properly — or you might be adding things in that just make everything harder. Scoping is really two things: what's the environment in scope, and what requirements are applicable. Finding that connection is critical to a good assessment. We've done entire episodes on scoping, so I don't want to make this one about that — but it really is important.
Jen: Let's dive into 4.0.1 requirements that are still tricky, even though we've been on this version for a while. Starting with the Targeted Risk Analysis — can you explain what changed with risk analysis, and what can make it less challenging?
Matt: Good question, because there's still some misunderstanding out there. Under 3.2.1, you just had to have a risk assessment — and pretty much everybody treated that as one organization-wide, program-level risk assessment. 4.0.1 moved away from that. Now there's a Targeted Risk Analysis, which is specific to certain requirements within PCI that need a defined periodicity. Simple example: it used to be you just had to check, at least annually, that systems not commonly affected by malware were still in that condition. Now you have to have a TRA that documents how often you're going to revisit that. The good news is the PCI Council has documents you can download from their website that both explain it and give you a format to build one.
Jen: Exactly, and it's so much easier when you have something to start with. One thing that hits a lot of SMBs is how frequently you check the device the card interacts with — now you need a TRA to decide that frequency.
Matt: Just look at the template they provide and ask: what am I trying to solve here? How frequently does this need to happen? What's the risk involved? What controls do I already have in place that might make this an easier task?
Jen: And what characteristics of your specific environment do you need to account for — because they're not all created equal. If you use a payment device only one time a year — a lot of universities do this, where the band comes in once a year and pays for uniforms — the rest of the time it's locked away. In your TRA, you might reasonably say you don't need to review it every week because it's locked in a drawer most of the year. But that decision has to be documented.
Matt: Exactly — the process by which you arrived at "we're only going to look at this at X frequency" has to be in that TRA.
Jen: Document the risk, document the environment, and say "here's the decision we made, and here's why." If you've got payment terminals out where the public can access them, and nobody's watching them at night, people can mess with them — those probably need inspecting more often than one sitting right next to your cashier where someone's always watching it.
Matt: Right, and I think a lot of businesses understand, at a gut level, how frequently things need to happen. The TRA is the "show your work" part of it — it's where you can say, "we did consider that."
Jen: Exactly. And I think it's actually a good thing, because it lets people make choices about how they run their business.
Jen: Then there's MFA — multi-factor authentication. It's crazy, just a few years ago people hated it, didn't want to do it, and a lot of people still don't love the extra code. But now not only do we have MFA, it's been enhanced for 4.0.1 and covers a lot more areas. Why do you think that is?
Matt: The threat factors and attack surface of the environment have changed — phishing, whatever it is, unfortunately the bad guys have more and more ways to get into systems. Having independent, true multi-factor — not two things you just know in your head, but something you have, something you know, something you are — two of those three make it much harder for an attacker to get into your environment. Hackers get in, steal all the data, publish it, and people can go buy whole databases of stolen credentials. Good, true MFA is very helpful there. And with 4.0.1, if you're standing at the actual keyboard of your server or system, you don't have to have MFA — but basically everywhere else, you do.
Jen: And I think it's very important, because human beings are notorious for reusing the same email and password across multiple things. If there's a breach and somebody gets that combination and starts trying it everywhere, MFA is what slows them down.
Jen: Let's move to new service provider responsibilities — it's not just getting their AOC anymore. Tell me how they've amped up the service provider relationship.
Matt: Requirement 12.8 has been around a while, but there's more emphasis now on the five sub-requirements — having an actual program for engaging and managing service providers. In a large organization, you might have a two-person shop trying to do PCI, and it's easy for something to get submitted to purchasing, which just finds a vendor for you, and then you find out they're not PCI compliant. I've talked to merchants and service providers who come to us wanting a ROC, and I'll ask where and how they're doing business. If they're hosted somewhere, that's fine — you can still be PCI compliant — but I need to know: do they already have their own AOC? Are they already compliant? That simplifies things. If not, they have to become part of your assessment. Or, if they don't want to play ball, the vendor might just tell you they don't want to do it — and then you've got a business decision to make. Those five sub-requirements: you need a program to engage with and monitor them, you need legal agreements in place, and a big one is a responsibility matrix.
Jen: Right.
Matt: This should be something you and your service provider work on together. Maybe they have a starting point, maybe you do — but it's critical that both parties know who's managing which requirement.
Jen: I think it's important because those agreements often happen at the business or purchasing-department level, and by the time it reaches the operational team, nobody knows what they're supposed to do versus what the vendor is doing. A critical security control can drop through the cracks because "we thought you were doing that" / "we never said we were doing that." Some organizations will give you a pretty comprehensive responsibility matrix, but they don't have to — and that's where a lot of SMBs trip up: if you can't get one from them, what do you do?
Matt: That's challenging. If they're not interested in establishing "you're doing this for me, I've got these other responsibilities" — whatever it is, physical security, badge access, camera monitoring for a hosted data center — you need to know they're handling that. Those things have to be defined so you know what to expect of them, and they know what to expect of you.
Jen: And it doesn't always come in the form of an actual responsibility matrix — sometimes you have to parse through the agreements and contracts to find those things out. By building that matrix yourself, you'll find the gaps, so you can have additional conversations with the service provider, or recognize where you need to step up.
Matt: I'd also recommend — if you're a medium-sized business with a separate purchasing department — go work with that department directly. Say, "if you ever buy anything for this environment, please reach out and ask me a question first." I'll give a prompt answer: "go for it" if it's just more server hardware, but "let's talk" if you're engaging a new service provider, because I want to be involved in that process. Otherwise it gets messy — "we hired this new guy" and then everyone's asking "wait, what's he doing for us? He's not doing that? Then who is?"
Jen: Let's jump to another big challenge: logging and alerting. This has always been a requirement, but it's broader and deeper now — more is required. Can you describe that?
Matt: A couple of things. One, you have to have automated review of the logs. It used to be okay to say "I look at them once a day, manually."
Jen: That's an impossible task, honestly.
Matt: It really is. This is where AI is a hot topic for everybody, but it's clearly one area where it helps — a lot of modern SIEMs have AI built into them now to identify truly potentially malicious actions, whether from an external party or a malicious insider. Proper logging, plus that analysis, helps you identify what happened and what was affected, so you know what to clean up.
Jen: And it's not just "I'm collecting these logs and I'll have them when you want to see them" — it's also, when properly set up, giving you an alert so you can look at something in sufficient time. And this is the part that's really important: acting on it. I've talked to our forensics team, and they'll say a breach happened even though the company had logging, had a SIEM in place, had alerts — but nobody responded to the alert. It's a full-circle thing, and it can be really challenging for an SMB.
Jen: What can they do if they don't have the internal resources or expertise? What's a good approach — outsourcing?
Matt: Yeah. Obviously that costs money — but like anything in business, it's a trade-off. If you go open source, that typically takes more effort from your own team to implement, manage, and maintain. If you buy a product from a vendor, you can rely on their expertise and you don't have to educate yourself as much. Same in the logging world — that's their whole business, taking your logs, doing the first triage, and telling you "this looks like a real event, pay attention" instead of you drinking from the fire hose of every log that comes through.
Matt: And there's one other change in 4.0.1 with logging — the ancillary systems you've always had to look at. It's a TRA thing again: you need to be logging those and figuring out at what frequency you inspect them. A lot of times we like to collapse our PCI environment down to a small footprint, but the first intrusion happens somewhere else, and then there's lateral movement by the attacker. If you're monitoring logs out there too, you'll catch that before it reaches your PCI environment.
Jen: That's definitely a great way to see malicious activity happening, so I understand why it's a control — but it definitely feels like a big lift for a lot of SMBs.
Matt: There's no way around the fact that it can be a lot of work.
Jen: Let's talk about password security controls — we've always had these, but the requirement's been amped up.
Matt: 12 characters now.
Jen: Used to be seven. Five more.
Matt: Which, frankly, isn't that hard — I personally do way more than that. But we're security people.
Jen: I write a little sentence to myself, and that's my password.
Matt: Which is good and bad — if someone knows your hobbies, they can probably guess it.
Jen: Honestly, here's what I actually do: I use a password manager. Then you can have a password as long and complex as you need, and you don't have to remember it — it manages that for you. Yes, it costs a little something, but I think the trade-off is worth it.
Matt: That's actually quite good, and it's the next step up. I get it, it's hard to memorize these passwords — a passphrase is great if it helps you remember something longer, because longer is better than more complex. You do need some numbers and letters in there to increase entropy, but length is what makes it harder for an attacker to brute-force. It doesn't have to be more complex — add some words you'll remember. Password managers are worth the money, because they let you have a different password for everything. You mentioned an email password getting compromised, and then people reuse that same password and username elsewhere.
Jen: Password managers are the way to go.
Jen: One last thing in this section: compensating controls. We've had these before, but they've been amped up too.
Matt: Compensating controls have been around a while, but your QSA should be doing a good job making sure they're properly designed. That means you have to properly identify what you're trying to protect against, define your controls, identify any residual risk, and figure out how to mitigate it — then design it so you can actually maintain it. It shouldn't be a permanent fixture. It's meant to cover a period of time where you can't quite meet the PCI control as written, so you're covering the risk a different way. And if you make it too hard to follow, your users will just go around it.
Jen: And I like what you said about it being temporary — like 12.3.1, which says if you've got old, end-of-life stuff, you need a plan for how you're going to fix it. That same principle — what's your plan to actually resolve this — applies to compensating controls even outside of end-of-life scenarios, and it really needs to be discussed with your QSA. You don't want to just have the same compensating control again this year, and again next year.
Matt: No — it needs to be a real step toward a better solution.
Jen: I didn't want to skip the corollary to compensating controls, which is the customized approach. Most SMBs are doing an SAQ, so they're not eligible for it — but what are your honest feelings on it?
Matt: Don't do it. We've talked about this before, and honestly — don't. It's a lot of work.
Jen: If you read all the Council's documentation on it, they put the whole burden on you: "You want to use the customized approach? Okay, here you go — you have to do all this work" to prove you're meeting the control in a different way.
Matt: Yeah — you have to do a risk assessment on it, design the control, figure out how to test it. There's a lot of work behind it. It's just easier to meet the requirement as written.
Jen: Now we come to a section all about e-commerce, and I wanted it to have its own section, because this is by far the most challenging thing I see for SMBs. It's a big change, and it's really important, because this is where we're actually seeing breaches happen. Let's talk about Requirements 6.4.3 and 11.6.1 — starting with, why do you think this continues to be the hardest part of 4.0.1 for people?
Matt: A lot of breaches, card-present fraud, various kinds of fraud, are going down significantly with chip cards and everything else. So attackers move to the next easier target, which frankly is online e-commerce. There were technologies we didn't think were quite possible a few years back — iframes and things were newer, and people assumed you couldn't get scripts inside them. Now we know you can.
Jen: And by "we," I mean the general "we" of humanity — not me personally. We find out attackers are smart, too, and that's one of the difficulties of being on the defender side: we have to be perfect almost all the time, or at least catch an attacker very early in the process, because there's no defending against every zero-day. That goes back to logging — if you've got good logging, you'll see that something's unusual, catch it early, and act before it causes a lot of problems.
Matt: That's exactly why 6.4.3 and 11.6.1 exist — attackers found good ways into these systems in ways we didn't expect, sometimes through the advertising on your payment page. Even if you're all buttoned up, your advertiser might not be, and scripts can get onto your page through that.
Jen: That's one of the questions I get as an assessor: "Can you show me your inventory of payment page scripts?" And they'll say, "What's a payment page script — you mean anything that handles the payment process?" No — every single script on that payment page. Then it gets into "how are you defining 'page'?" — because there's a difference between a static HTML page where all the scripts are visible, and a page built dynamically through the DOM, where who-knows-what shows up at different phases. It's every script that could possibly appear in any iteration of that payment page. It can be a lot.
Matt: It can be. And this requirement isn't going away, so you have to figure out how to deal with it. One thing I tell people: this goes back to business decisions — you might not like it, but simplifying the actual payment page so it doesn't display as much can help.
Jen: So it doesn't have to pull in all that information for your marketing team and every other purpose.
Matt: Right — so it doesn't burn a bunch of your resources maintaining and monitoring scripts as they render in the client's browser.
Jen: This can be difficult to tackle on your own — and there are a lot of good solutions out there. I don't usually like to get salesy, but I'm going to ask special dispensation here, because we have something called Shopping Cart Monitor, which I genuinely love. As an assessor, I talk about how it's agentless, which matters if you're coming from an IT operations background — you don't want to put another agent on things, you want to keep stuff off your machines. It does its job well, and it's an excellent product. I wanted to mention it because a lot of what we do here isn't just "here's a challenge" — it's "here's some advice on how to meet it." There's a lot out there, but I do want people to consider Shopping Cart Monitor.
Matt: Like you, I know we're not here to push our own products, and I'm not — but I do genuinely believe it's a great one.
Jen: I really do too. And like we said about logging — sometimes you outsource it — 6.4.3 and 11.6.1 are genuinely hard to meet entirely on your own. If you break the requirement down, it has to be done, it has to be logged, it has to be alerted — there's a lot the requirement demands. It can be challenging, so this is one of those areas where it's worth looking at outside help, especially for SMBs.
Jen: We've got a lot more points on this we could go through, but I feel like we've really captured what I was hoping to get out to people today. This has been a really great conversation — thank you so much for spending the time.
Matt: Thanks for talking with me, I appreciate it.
Jen: And thank you all as well — hope to see you again on the next one.
.svg)