Watch this to learn how to address the new PCI v4 requirements and to make sure you're ready for the PCI v4 Implementation Date.
In this webinar, Gary Glover (VP of Assessments) and Matt Halbleib (Director of Assessments) will discuss:
Read our white paper PCI DSS v4.0 What You Need To Know here.
Get your copy of the SecurityMetrics PCI Guide here.
To get started on your next PCI audit, request a quote here.
This webinar was hosted on March 26, 2025.
Gary: Hello, everyone. Welcome to our webinar today. I'm Gary Glover, and I have with me Matt Halbleib. We both work on the SecurityMetrics audit team here, and we're going to be having a fireside chat, even though we don't have a fireside, about the future-dated requirements, which soon will not be future-dated because March 31st, 2025, all of those things become active. All of those new requirements are active. So we wanted to spend a few minutes, go through them, talk about them, and let you guys listen in to our discussion. We'll give you some insights into these new requirements that you're all going to be meeting right away. Feel free to send in questions. We'll attempt to answer. If we can't get to you, obviously, we'll be sending out any answers or trying to direct you to media that we have available. Alright. I'm the VP of our department. Matt is the director of our department here at SecurityMetrics. We've both been here a really long time. Sixteen years for Matt…
Matt: Seventeen and a half.
Gary: Seventeen and a half for Matt. Twenty years for me. And so, hopefully, we'll have something that you may have some interest in. We're going to basically go from the top down through the standard, talking about the ones that we feel are worth talking about. I can say that we won't be talking about every single one because not every one is really needed. Some of them have been pretty simple changes and little documentation things or whatever. We won't be talking about those. But some of the major ones, we will be giving you some of our opinions on and some of the things that we think people are going to need to really focus on. We're going to start right off on 3.4.1, which is concerning remote access and disabling the acquisition, the copy, the paste, the ability to get PAN data when you're remoted in and using some sort of technical controls to disable that, talking about really what can be done. Matt, what do you think about when we read that requirement?
Matt: Obviously, I mean, as it says in the requirement, for those who need the ability, that's fine. But for anybody who doesn't need the ability, you have to find some way to make sure that they can't. That may mean reengineering a business practice or a business process to…
Gary: Always a good idea.
Matt: Yeah, limiting cardholder data, always a good idea. But, the simple answer may be just to reengineer a business process so that people don't even have access to the data that they could potentially copy if they're remoting in. Otherwise, you're going to have to come up with a technical control of some kind, and that may not be supported by your current software. You'd really have to then investigate what are my options?
Gary: Does that mean, Matt, that the actual VPN solution has to prevent this?
Matt: Good question. But, no. There are other ways that you could potentially prevent that. But, if they're VPNing directly in and have complete access to the card data, displaying it on screen, playing it on screen, everything else, and they're not someone who needs that ability, then the VPN itself probably wouldn't, but you might have to implement some other controls on that individual's laptop or however they're remoting in, right, whatever their hardware is, to disable the ability to copy down data, maybe disable the USB ports, prevent the screen capture, things like that.
Gary: It's not some amazing technology that's there, but it is something you've got to think about.
Matt: Yeah. Absolutely.
Gary: The next one then we're going to be moving right through is 3.5.1.1. And these are exciting. Follow along. Get out your copy of the standard. Follow along with the numbers here. And this one is dealing with keyed hashing. And there needs to be a new method of hashing. If you've been doing hashing before, that's great. But now there needs to be a different type of algorithm, and that really deals with having something like an encryption key. What do you think about that?
Matt: Yeah. I'm glad you brought that one up because I think people have known, obviously, if they've read the standard and these changes. They've known that keyed hashing is going to be a thing. But what they might not have paid attention to is the fact that they have to manage that encryption key. The other later requirements, 3.6 and 3.7 in requirement three, now start to come into play. Not only does it have to be a strong key, it has to be well managed, split knowledge, dual control. treat it just like an encryption key.
Gary: Treat it just like an encryption key. it's not just adding a new algorithm and throwing a little key in a file somewhere. You have to have the controls around that. Not that you don't know how to do that. People know how to do that already. it's just adding that new key to be managed in the same way and then making sure that your algorithm really does support that. I was on an assessment a while back, and we were looking at the details of the algorithm that they were implementing. And the more I dug into it, it looked like a key, but it turned out not to really be a classical key. And so we went through the definitions, talked about the actual features of the algorithm, and ended up having to change the algorithm because it really wasn't meeting. spend time really learning about the algorithm in detail that you're going to be implementing and make sure that it's meeting all the requirements of 3.5.1.1.
Matt: Yeah. And doing cryptography is not always the easiest thing. If there's a library out there that has a validated random number generator and the ability to generate keys, good keys and things, I'd recommend using that. It's better than trying to roll your own. That's difficult.
Gary: The next one's still in 3.5, 3.5.1.2. And this one is really, we don't have a whole lot to say there. Basically, it just says after March 31 of 2025, you can no longer use full disk encryption as a method for protecting the card data.
Matt: Yeah. There were some people in some systems where it was challenging to implement some sort of field-level encryption in the database or whatever it was. They relied on disk-level encryption, which really only protects the data when the machine is off. And there were requirements around that in terms of the passwords and that sort of thing, but it's only going to be allowed now specifically for removable media and stuff. if you're relying on it to protect your server, not going to be allowed anymore. You'll have to figure out a better encryption solution.
Gary: And, frankly, we haven't seen that very much over the past number of years. I mean, some people are using it, but typically most are not using that technology.
Matt: True.
Gary: But if you are, make sure that you're thinking about that. We're jumping all the way to section five now. Section 5.4.1. So in other words, section four was easy.
Matt: Yeah… Mostly.
Gary: This one is on phishing protection and training. And, specifically, what are the things they're needing, they're wanting, in this requirement to both do some sort of a technical control to prevent phishing, but also training. What are your thoughts on this requirement?
Gary: Phishing is just one of the most common attacks. They're exploiting the human element, which has always been the weak thing. you're going to have to all of a sudden implement some sort of technology on your email server to detect and hopefully prevent most phishing attacks. The question, if people are thinking about it, they're going to go, does that mean my email server's in scope?
Gary: We had that discussion just recently in the global executive assist roundtable meeting, and I think that's an interesting point. I don't know that it makes a whole lot of sense to all of a sudden when people have worked to get email servers out of scope to now say, phishing is part of this new control, and it's on your email server. Does that bring it into full PCI DSS control? I think it comes into that same category of, let's look at the things that make sense to look at on this server. I'm not sure that we really want to come out and say, and I don't know the council does either, that all 250 requirements now need to be put on your email server. That would not be realistic.
Matt: Yeah.
Gary: To us, I think as assessors, what we'd be looking for is to see, is the phishing system there? Is it implemented? Does it seem to be working?
Matt: Yeah. And are you training your people to resist that kind of attack?
Gary: Because if the phishing doesn't come from email, it may come from the phone. 1 There needs to be some training element in phishing protection to help people understand, identify who's calling you on the phone. If it sounds suspicious, it might be. Figure out ways that you can confirm their identity or go check with somebody who they're talking about.
Matt: Yeah. There's a lot of those different kinds of phishing attacks. I mean, PCI, I think, specifically is talking about the mail server when it talks about phishing. Just because I don't know that there's all the controls around vishing and all the other -ishings that there are.
Gary: Right.
Matt: But training your employees to be resistant to it.
Gary: To be thinking about it.
Matt: Yeah. And the typical tactics used in those kinds of emails, whether it's impersonation or trying to give a sense of urgency, which is always one of their things, and trying to apply that subtle pressure to you to think, oh, I've got to take care of this right now. Instead of following your proper procedures, I shouldn't get all that credit card information. I shouldn't dump all this info out and send it in email to this guy, but he's pushing and it's the CEO and whatever. train them to spot that and follow the right process and that they won't be punished if they follow the right process.
Gary: Exactly. we know that there might be controls on the email server, but it may not catch everything. That's why it's important to have that kind of training for sure.
Matt: Yeah.
Gary: Now we're going to jump to section six, 6.3.2. And this one deals with bespoke software, which is sort of a weird name. Bespoke means software that you've written yourself. I don't know where the term bespoke came from, but it could just say software you've written yourself. But,
Matt: Or that somebody wrote for you.
Gary: That's true. Somebody could have written for you. That's custom.
Matt: Yeah, just for you.
Gary: Custom software. And keeping an inventory of that software and any third-party libraries or packages that are used in that software, who's really looking after those? What are some of the things that this implies in an audit situation?
Matt: Yeah.this is one of those for if you've asked somebody to write some software for you, one of the things you should definitely get from them is sometimes what they call the software bill of materials, which is a detailed outline of all the software and libraries and things that are included in this software that you have. If you're doing it yourself, you need to create that because as we all know, there have been many vulnerabilities in the past. Yeah. We use this library in our software. There's a function in it that's found to be vulnerable. If we don't know that's in our software, our software could be vulnerable to that specific attack, and then we'd never patch it because we forgot the fact that it's in there. Really, this requirement is trying to get us to track all the software we're using, including packages and things that are in our greater application, monitor that for vulnerabilities and exploits and things, and then patch it as it comes up.
Gary: As an additional documentation process, making sure you're keeping those things, might be new to people who are developing their own software because it feels like, hey. I developed it or had it developed for me. Everything's good. We're just asking now to up the bar a little bit and say, you've got to keep a little bit better track of that. Document it, make it so that we can audit it. So we can see some evidence that you're doing it. That's what we're going to be looking for as assessors when we come online.
Matt: Which is often what we have to do. People say, oh, yeah. We're doing that. And I say, prove to me you are.
Gary: Show me some evidence.
Matt: Show me that you're doing it if you don't have the documentation.
Gary: And we're not saying there's one form of that documentation as everybody knows. There can be various ways you can do that. We're just looking for some evidence item that says you have a process for looking at these third-party libraries. You're making sure that they're updated. When was the last time it happened? When did you last think about it? That kind of stuff.
Matt: Yep.
Gary: Now moving on, we're going to stay in section six for a little bit here. 6.4.2. And that one has always been about web application firewalls. And that's a thing or an entity. It could be hardware, software, or even a third-party cloud service or whatever that sits in front of your web presence and watches the traffic coming in and out and making sure that it's not identified as something obviously malicious.
Matt: Specifically, like the OWASP top ten stuff.
Gary: Like that stuff. What is the change in that requirement now?
Matt: Yeah.it's funny. We've both been at this long enough to where we remember a WAF wasn't even a thing, and that was a future-dated requirement at one point.
Gary: That’s right.
Matt: And at the time they introduced that, they said you could either do some sort of manual code reviews or an automated code review as opposed to having a WAF, an actual piece of hardware that's doing or software or whatever doing the job. But now with 6.4.2 here coming out, they're just going, you know what? The manual and the code review stuff, it's not even an option anymore. You have to do a web application firewall of some kind.
Gary: Plenty of options, cost-effective.
Matt: There are plenty out there now.
Gary: It's just the thing that you need to do. It's a technology that is pervasive. And you just need to have one.
Matt: Yeah. When the original requirement came out to have a WAF, there really wasn't much out there. And people always came to us and went, what do you want me to do?
Gary: Yeah. I remember there were patching modules and things like that that we could install.
Matt: There were just maybe one or two things you could do, and that was about it. But now there's lots of them.
Gary: Now there's lots of them. Use them.
Matt: Yeah.
Gary: That gets us to the drum roll… 6.4.3, which is one of the … if there's any requirement that somebody knows by number without having to look it up, this might be it. And that's talking to the scripts that are running on a payment page or on a referring payment page.
Matt: You've been doing a lot of work in that area.
Gary: I've been doing a lot of stuff in this area, over the past six months or so. And so this is a requirement, I think, that will be one of the more difficult things to do, and people have had almost two years to work on this. Granted, there are many solutions that are still being built and improved and rolled out in the industry if you want to use a solution provider for doing that. But 6.4.3 really basically just says, do you know what scripts are running on your payment page? Now that may be a page that you coded yourself, and it has fields that are ingesting credit card data, moving them to a processor, etcetera. Or it could be a page where you have an iframe or a window that you look through to someone else's page on another site. The page that contains that window, that iframe, what are the scripts that are running on that referring payment page? And those are the things that we're finding out through our forensics team that are being the real problem for small merchants and ecommerce pages and specifically SAQ A merchants.
Matt: Those are the ones that are being exploited?
Gary: Those are ones that are being exploited. Now the council did recently make a change in the SAQ A, and we can talk about that a little bit later, I think. But right now, we're talking about just the, like a service provider or somebody who just needs to comply with this requirement. It means that you have to then know all the scripts, know where they came from.
Matt: Do I have to document them?
Gary: And then you have a document. Maybe it's a spreadsheet. Maybe it's a tool that you've got, and you now have to not only say, here's what it is, and here's where it's from and what it's for, but who authorizes it to be here. And somebody's actually got to say, I'm going to put my initials here saying, I've authorized this one. Maybe it's some sort of a marketing script or something like that. But just knowing what's there… initially, I think this requirement was added by the council to help people be aware of how many scripts are there. We've seen up to three hundred scripts on a referring payment page before. And so do you know what's there, and do they always have to be there? And so it was an incentive to say, oh, do I need that? If I don't need it, get rid of it. Type of thing.
Matt: Along those lines, what are some strategies somebody could use to help them with this?
Gary: I mean, there are many tools out there. JScrambler, SecurityMetrics has a tool, Source Defense. There's all kinds of people that can help you look at your website, and they can identify all the scripts that are being run. They put them in a form, let you then authorize it. Other than that, it would be manual review of the code, but it's hard to do that because they can be dynamically included at any time during the payment process. Just saying, here's my static web page, and here are the scripts that are there and the includes that are there aren't really good enough. You've got to know everything that gets loaded in during the actual payment process. executing the payment process, seeing what scripts are there is really an important thing. You may need to get some help doing that.
Matt: It's not just as simple as having one little static page with a couple of scripts running on it or whatever. There's a lot more complexity.
Gary: A lot more complexity because things can be added dynamically by bad guys. Even though you say, look. I only have three scripts. Or let… somebody came to me a while ago and said, I don't have any scripts on my payment page, on my referring payment page, so, therefore, I don't need to meet 6.4.3. Well, no. Because the DOM, the document object model, which is the virtual environment that's created by the web browser to as you render the page and as you run things and as you actually physically go through processes on the page, the bad guys can actually inject things dynamically there that isn't there in the static page. So 6.4.3 would still have to be done, Matt, even if you have no scripts whatsoever on your page?
Matt: Because it's what's executed in the client's browser.
Gary: At the very end. Yeah. It's what's in the client's browser. That process is kind of confusing to people. It's very technical. 6.4.3, you may be able to somehow kind of do it on your own. You could use some tools, but getting some help to do that, I think, is going to be really important, especially for small merchants who don't even know what a script is necessarily.
Matt: And I know we'll talk about it later, but this pairs with 11.6.1.
Gary: We're going to talk about that. And we've done, you and I and Chad and all of us have done various webinars over time on this topic. I'm sure that our marketing folks will link some of those things, perhaps in other sessions that we've done. You can get a whole lot more. We spent two hours talking about 6.4.3 and 11.6.1. Anyway, let's not get too bogged down there. Let's move on to section eight now, which is 8.3.6. And this is about passwords and that they have to be longer. What is that one, Matt?
Matt: I mean, it's simply that. It's just a comment that before in PCI, you had to have the character password and complexity and things. If you haven't moved on to some other mechanism to do your authentication… In other words, the statement the requirement says, if you're using passwords as part of your authentication process, then they now have to be at least twelve characters long and complexity is required, or you have to dynamically monitor the environment. I forget you could probably read it or something off there. But there is one other option, but it's a little harder to do than just going to twelve characters.
Gary: It's some logic on, looking at the passwords, making sure that there's not some dynamic analysis you have to be doing as people create those passwords.
Matt: Yeah. mentioning it partially just to get your people prepped that all of a sudden, maybe they were using an old eight-character password. And I shouldn't say old. I mean, they have to change every ninety days and remember four of them. But either way, they may have had one model in their head of how they were creating passwords. Now it's going to have to be bigger. And I would suggest passphrases or something. Or MFA.
Gary: And there's a lot of stuff in the industry about passwords. You can look up NIST guidelines and all kinds of different things going on there…
Matt: Passkeys, which are even better.
Gary: And MFA, and we're going to be talking about that a little bit as well. alright. 8.3.10.1, is really pointed to service providers. And if you give access to your customers to your systems, then there's a new requirement then around them changing those passwords. In other words, you have a customer accessing your service provider systems. They have a password to get in. What do they have to do now?
Matt: Yeah. In the past, they didn't say much about those accounts. But, like I said, this is not directed at merchants, but really for service providers. if I give one of my clients access to my systems to see a bunch of their transactions or whatever, they're now required to actually change those passwords on a ninety-day basis and things, before they could just use them. But, actually, we've seen attacks against that. It's not the service provider who is compromised. It was their client and their account that got compromised that was then used to log in to the service provider system and harvest card information.
Gary: Again, not necessarily a really difficult one, but it's something that you've got to have in place.
Matt: Something to be aware of.
Gary: Now, 8.4.2 is one that we've really been expecting for many years, and that deals with multifactor authentication and where it needs to be applied. Always in the past, it's been you have to have multifactor authentication when you're outside the network coming in in an administrative role or a privileged role. And now they're saying MFA has to be used for all access into the card data environment. What does that mean?
Matt: If you're standing at the keyboard of the server, they don't expect you to have an MFA there. Not that it would be a bad idea, but you don't have to have it there. But any other time you're accessing it remotely, which means you're not standing at that keyboard, you need to have multifactor authentication.
Gary: even if you're inside your office network?
Matt: Yep. Even if you've got that CDE segmented off and you're accessing the systems from within your own corporate network, they used to let you just access them remotely. Now you have to have MFA even inside your own network. It used to be just MFA for remote access into the bigger environment and then get in. Now you have to have an MFA to get into the CDE at all if you're not standing at the console, the machine.
Gary: And it seems like I remember there are some other requirements in section eight, like 8.5.1 that adds some requirements to maybe some features of an MFA system. What are some of those things that people have to think about now?
Matt: Yeah. They've had the MFA requirement for a while, which we know, two out of the three things, something you are, something you have, something you know. But now they've gone on to add some more definition to what they think is a good MFA system. It's not subject to replay attacks. the TOTP type token, changes very rapidly and things, and you can't just reuse the token to get in, once it's expired. resistant to replay attacks, has to accept all the factors before it lets you in. you can't just go, I MFA'd over here, and now I'm going to get in, and now I'm going to do something else and get to the next step. You have to actually do all of it before you're accepted into the environment.
Gary: When I've been doing assessments, a lot of things that I've got to do is I've got to talk to the client and say, show me documentation that your system can handle these things. And the features of this MFA system need to just match up with what the expectations are.
Matt: I think 8.5.1 you said?
Gary: Yeah. 8.5.1. just review those and make sure that you can provide that evidence to your assessor during the thing. Again, not necessarily hard. All the MFA guys know about it. They should be including this in their documentation. It may take a little bit of pushing and searching a little bit sometimes on this.
Matt: MFA's come a long way. And these kinds of things have been known by the people who create them and stuff. They've known they should be replay resistant and all that sort of stuff. It shouldn't be new to your provider.
Gary: Let's move on and start talking about just passwords a little bit more. there's a couple of requirements that have changed, regarding passwords in various locations stored in places that maybe only a system file can access. What are those kinds of things that people need to start worrying about a little bit?
Matt: Yeah. There is a new requirement. Sometimes, I get it, people used to store passwords in config files and things to get systems running.
Gary: To get booted up and configured as they go.
Matt: Exactly. Yeah, because it's like, what happens if it crashes and nobody's there to restart it and that sort of thing? Anyways, the new requirement is, like, nope. You don't get to do that anymore. No passwords written in config files or text files. Anything, embedded in your software or anything like that, you have to find another way to…
Gary: And when we're saying passwords in there, it's clear text passwords we’re really talking about. Let's say now a software, as it boots up, would have to then instead of looking in a configuration file and reading that password in, it may have to go out to a password vault with some sort of API, get the password from a secure storage location before it starts up. you may have to recode and rework some of your startup systems in those ways.
Matt: Yep.
Gary: 8.6.3 we’re, again, dealing with system accounts. And a lot of times in the system account is something that it's not a user. It's not like you and I logging into a system every day. It's something that either software or a system as it boots up has this password. And now the requirements state that those have to be changed periodically. In other words, you can't just keep it for ten years, the same password, even though nobody's using it every day to log in. A nonhuman entity is using it to log in. ?
Matt: Which is a big change, actually. It was really software that's starting up, and it's got some stored password somewhere. We used to just create a really long string and never change it for the most part. But now PCI is saying no. You need to examine how frequently that needs change, and you need to go out and actually change it periodically. We talk about system accounts and stuff, not logging in interactively. It shouldn't be something that if I had those credentials, I could sit at a keyboard and log in. But on top of it, like we just said, you have to change the password now. And that's a change, and people might have to reengineer some processes. I know from my past in IT and everything, sometimes you don't even know everywhere that password's being used. And you go out and change it, and the next thing you're locked out of the account because you didn't know some system over there was using it to log in and ?
Gary: And when they say periodically, what has to accompany that periodically?
Matt: Yes. The infamous TRA.
Gary: Yeah. And what is a TRA?
Matt: Targeted risk analysis. And those are some of the requirements we're not really talking about today. There's some of them where they just want you to have a periodicity in relation to how frequently you need to do something. PCI now wants you to do a targeted risk analysis on what that frequency should be. you can document, here's why we made this choice. We're going to do this weekly, monthly, quarterly. Whatever it is, you have to have some documented reason and rationale and why it's considered secure. And the council has some samples out there. They have a template you can use, and it's really not too bad.
Gary: And it really, it's just saying it's proving to your assessor, to yourselves, that you've thought about it, and you've thought about the risk. What is the risk of this system password, for example? Well, this reboots itself once every six months. Let's say it's a really good one, and it's all within this super secure environment. Maybe the risks are pretty low for that password being compromised, and it's in a password vault, all that stuff. Then you can use all those facts to say, we don't need to change this except for every six months, once a year, whatever you decide. But it has to be backed up.
Matt: Yeah. Some thirty-two-character password, super long. That on a system that nobody ever accesses sitting back in the back end there or whatever. Yeah. That's the TRA helps you tease out those items and go, I don't think you need to change it that frequently.
Gary: And that TRA, as Matt mentioned, it was it can be applied.in the old days, in 3.2.1, there was this requirement in section twelve that says conduct an annual risk analysis. And it was just of the whole company, of the whole system, and that was really vague, and nobody really understood where exactly to do that, and everybody did it differently. Now in 4.0, they're focusing on just, hey. Let's do these nine requirements that have these periodicity things on them, and let's have you document your risk analysis on that. Yeah. And it's a little bit more defined. This TRA process is a new 4.0 thing. Some of them will now be applying on March 31st where some of them probably didn't. And then some were already in place for doing the TRAs. But this one is one of those ones that will be from March 31st. You may want to think about any break glass passwords that you may have. Can those last forever? Probably not anymore.
Matt: Not anymore. No.
Gary: defining what your process is, having to explain that to your assessor and so that we understand that you know you've got to make these changes, that's okay.
Matt: Yeah. Because we will go look at the accounts you have on systems. Now, I mean, if it's a small environment, it's easy to see all the accounts and go, what is this one? Well, that's our break glass… Well, I no longer say if you get run over by a bus. Now it's hey. Your sysadmin wins the lottery and decides he's not coming in tomorrow.
Gary: Or maybe crypto. It's probably now that he made it in crypto.
Matt: Yeah. I should modernize that. Though we still play the lottery. Anyway, your sysadmin for whatever reason is not coming in tomorrow and nobody knew his password and things. The break glass, I get in small environments. People are like, we got to have some way to get into the systems. But now you're going to have to consider that password, its length, how often it needs to be changed, and that sort of thing. Yeah. TRA.
Gary: Now we're moving into section ten, 10.4.1.1. And, this one is pretty obvious to you and I. This is about saying you can't… you need to have an automated mechanism used for doing your log reviews. this is what's typically called the SIEM or a I don't even know what that stands for, but
Matt: Security incident and event management.
Gary: There you go. That's why you're the guy who does most of the audits. Using a SIEM tool is now mandated. you can't just say, oh, I review the text logs every day by my eyes. The system logs, all these different things, which when I first started doing this twenty years ago, there were people that said, I look at my Windows event log every day and application event logs and all that stuff. So, it's silly to me because everybody uses a SIEM now anyway, but now you can't say that you have a manual process.
Matt: Yeah. And, thankfully, it’s like the WAF, there being multiple options in this environment too.
Gary: There’s no excuse.
Matt: Exactly. No excuse. You can outsource some of it. You can just buy your own software and configure it to alert you on things. But there's plenty of options now.
Gary: And one thing that actually came up during a discussion with a client yesterday was, there are many different places where these logs can be reviewed in an automated way. And it doesn't necessarily mean that there isn't a human involved. There needs to be notifications. Somebody needs to send a notification, and a human needs to review it. But, a human doesn't look at this mass quantity of logs. for cloud systems, sometimes there's this tool and this tool and this tool looking at this application, this container. They don't all have to be all gathered the same way. A lot of times, they're centralized, and so cloud providers often create these centralized locations as well.
Matt: And you do need to store them according to the requirement. Three months available for immediate review, one year total.
Gary: Yeah. Yeah.
Matt: But you're right. You could do it in maybe more than one central system.
Gary: So, there’s not one automated mechanism you need to do for the whole system. I don't want to imply that. You can use multiple methods as long as you can explain to your auditor what's the process for getting those alerts to somebody that needs to look at them, and do they know where to go to look at the raw data if they need to.
Matt: because it's not like your SIEM's going to make the action for you. It just alerts a human that there's a potential for a problem.
Gary: 10.7.2 is about critical control systems and detecting if they fail and who to notify. What's your thought on that one?
Matt: This is so it used to say 10.7.1 still says, but in a few days, 10.7.2 comes in and supersedes it. Anyways, it used to say service providers had to monitor all of that.your firewalls and your quarterly scans and all those things, your IDS, IPS, had to monitor all of that. The change here at 10.7.2 is now it applies to everybody. What used to be just service providers, everybody has to do now. You have to monitor the health and functioning of those systems.
Gary: Again, just raising the bar a little bit for everybody. Plenty of ways to do that. Let's all jump on board. Section eleven, 11.3.1.2 is concerning internal VA scans. In the past, you just had to have some sort of a mechanism, Nessus, whatever tool you want to use to do those internal scans. And now what's the new thing they're asking?
Matt: Authentication.
Gary: Authentication. What does that mean?
Matt: Well, the scans used to scan the ports. And basically how the system responds, it can tell what software and things are running and what ports are open and stuff. But now whatever software you're using to do your quarterly internal vulnerability scans has to actually be able to authenticate, log in to the system, and interrogate it for the software that's running on it. The systems now are capable of it. If you have the licensing and things, they can actually log in and do that. It's a better way to do the scan. Once again, stepping it up, 10.7.1 now morphing into 10.7.2, everybody is required to do this. Authenticated scans are a better way to do the vulnerability scans. Just because all of a sudden, the system has a lot more access to the system that it's scanning, the computer it's scanning, and to what software it's running. Maybe libraries that are on the system but aren't externally visible if you're just doing a port scan.
Gary: Perfect. Now let's talk about the next one, which is 11.5.1.1. And this one is monitoring outbound covert malware channels. What the heck does that mean?
Matt: I've had people ask me that. Clients asking, what does that even mean? So, security and attackers, it's a cat and mouse game. As the defenders and the good guys up their game, then the attackers, they figure out other ways to get information in and out of companies and remotely control systems and things like that. IDS, IPS has been a requirement in PCI for quite a long time. Most IDS, IPS systems can actually or and some firewalls can actually do more of a deep packet inspection because, if somebody wants to, whether it's a command and control channel or exfiltrate data or whatever, they'll use a port that you typically allow out through the firewalls like DNS, and they'll they'll masquerade as DNS packets going out when in reality, it's not. That's a covert malware channel. And so your IDS, IPS, or maybe your firewall now, it has to be capable of monitoring for that, doing more of a deep packet inspection to go that doesn't really match the protocol. You're sending other traffic out over that port.
Gary: they may need to look at the features of your firewall, see if it's something you can turn on. Many firewalls already have this. Palo Alto's do it. Those kinds of things.
Matt: Yeah. You might have to pay a little extra money to update your licensing on your firewall.
Gary: You mean security costs money? What? This is just one of those things where we're upping the game and trying to prevent more and more stuff. that brings us to the star of the show #2. Again, 11.6.1, which is the other half of the script monitoring that we talked about before.
Matt: What do you mean by the other half?
Gary: The first one was making sure you know what all the scripts are, which has a role of, if I don't need it, I should get rid of it. Do I need all the marketing information on that page? And then now let's say, this is the part where it says, I don't have any scripts, but they can be added dynamically. There's the part where it has to be monitored. Your payment pages and referring payment pages have to be monitored on a periodicity that can be defined by a
Both: TRA.
Gary: or once a week at the minimum type of a thing. Maybe you want to do it faster if you have really speedy systems or tons of transactions going on, based on the risk. Bad guys can get malicious scripts into systems, even the ones that are protected with CSP and SRI. CSP and SRI can be part of a solution for 11.6.1, but they can't do the whole thing. spend some time really doing research on this. There's lots of presentations from various organizations. Again, JSCrambler, SecurityMetrics, Source Defense, all those different people have written lots of papers and done lots of webinars. Do your research. Again, this is something that people have been focused on a lot. I don't think we need to spend a lot of time here on it. Look for our other content, if you want more detail here. But this is probably one of the ones that's most worried about, most talked about, most debated, of the requirements that will be effective in the next few days.
Matt: Yeah.Going on that theme of upping the game. When SAQ A came out quite a long time ago, everybody thought, what? Iframes and redirects, I have to do a lot less work. But then as the attackers figured out ways to steal card data from those environments, now they're having to up the game and go, look. We didn't really know how this could be done before, but now it's obvious how we can compromise those systems.
Gary: bad guys can write a script that can reach into an iframe in various ways, which really wasn't something that was deemed not necessarily possible, but wasn't an issue.
Matt: Nobody really knew how to do it. .
Gary: And so now we're seeing that quite a bit. Out of two thousand, three thousand forensic cases we've just done, in every case where there was card data being lost, the script was not on the service provider page, not on the thing that was provided by the third-party person that you look through the iframe to see. It was on the referring page.
Matt: On the referring page as rendered in the client's browser.
Gary: And that doesn't mean just the first time it's rendered. It means rendered during the whole soup to nuts process from starting the checkout to finishing the checkout. A lot of compromises that we see only happen after you say complete purchase or after you enter the CVV number or something. That's when all the bad scripts are added. Is this a problem, yes. This is a dynamic thing. It's a difficult problem. It's pretty difficult to do a DIY solution. I'm not saying that it's impossible, but there's a lot of us that have been working on this for a number of years. And these solutions will continue to improve, and people will be figuring out stuff. But this is one of those requirements that, sometimes people think that they can do their audit just before March 31st so they don't have to do this for another year. That's a scary way to think about it. Will the assessor say I need proof from April 1st on that you've been doing this? I don't know. But we will say, show me that this process is in place and that it's working on a regular basis. Be prepared for that even if you've now just finished your audit. This is not you're not off the hook. We're almost done for section twelve. 12.3.4 is about monitoring hardware and software technologies to make sure they're all getting patches. What's the issue with this one that we're trying to prevent?
Matt: there's always been the requirement in section six there to monitor for vulnerabilities and things. And even in section six for the software development group, they told them, you should be aware of vulnerabilities and things, and those should be communicated to you. But there wasn't always a great mechanism to… There should have been maybe a great mechanism, but people weren't always as good about it as they could have been. But this requirement here in twelve is trying to up that game. We talked about a software bill of materials and things. You have to know what's running in your environment. And in all cases, not just which, I'm running Windows server 2019, whatever on these systems. I have to know not only the hardware and software that I have running, but my own software they may have created, something I may have purchased from somewhere else. I have to know what those libraries are, and I have to match that against the vulnerability information that comes out on a regular basis. And so, really, knowing what's in your environment in a better, deeper way than perhaps you have in the past.
Gary: And having a documentable, auditable process around that. Again, we're going to be looking for you, you say that you're getting all your patches. You can't just assume that it's happening. You need to check that, show us that you're doing that work. 12.5.2 This is one about scope validation and documentation. 1 In the old version of the PCI standard. This was just at the top in the introduction of the standard itself saying, hey. You should annually do your scope. Now they've moved that down into section twelve as a requirement. Now you have to have documentation showing that you have reviewed your scope at least annually. This isn't really a big deal. It's things that you're already been doing, but now we as assessors are going to be looking for that documented proof. Whereas before, it may have been, tell me when you did your last review, and we go, they did it, last September.
Matt: Yeah. And, honestly, as an assessor, I'm grateful they put it in the standard because it was I don't want to say it was implied. It was stated in the Report on compliance, which most I mean, if you went to the PCI Council website, PCIsecuritystandards.org, just download the PDF version of the ROC or whatever or not the ROC, but the PDF version of the standard. And it didn't directly say you have to do this. But then in the ROC, it asked us as assessors, what's their scope? Now it's just written as a requirement. And, frankly, I think it's a good thing in that sense.
Gary: And I can't remember exactly where it was, but I think there's something that says you have to, maybe it's in this requirement too that you have to revalidate your scope if you make a major change.
Matt: Ah, yeah. Not just annually.
Gary: Like, let's say that your head of IT moves on to a different job. Now you need to redo your scope validation.
Matt: Potentially. Or you change your firewalls. That even pairs with, like, the requirement for a pentest says at least annually and after any significant change. There are other requirements that talk about that in section six, in terms of significant changes. That includes looking at your scope. I made this change. I changed out all the hardware. I moved fromI had on-premise systems, and now I'm moving into AWS. Even though I'm replicating my architecture and everything, obviously, a significant change. You need to redo all of this.
Gary: Recheck your scope, and that leads into this next one, which is 12.10.7. You need to run your incident response plan if you ever find any unencrypted PAN where it's not supposed to be. let's say you did one of these big changes, and as you're doing that, because you're rescoping, you found, oh, shoot. There's a log file that we hadn't sanitized well enough, and now we had card data there from a debug process. Now we need to get rid of that or whatever. if that was in your production system, you need to send now say, now your incident response needs to be run to make sure that you understand and know how long it's been there, what the process happened
Matt: What the root cause was.
Gary: how you could fix it, do some analysis, fix it, and, lessons learned. And it also sort of implies it never says anywhere that you need to be searching for an unencrypted PAN. But this one says if you find it, then you have to do something. I guess you could keep your head in the sand and say, I never look for it, so therefore, I never find it. But I don't think that'd hold up in court or with the card brands if you ended up with that. That implies you need to be looking for unencrypted card data potentially.
Matt: Yeah. And teaching our people that if they’ve found some unencrypted card data, nobody's, don't punish them. Analyze how it got there, what process put it there. Do I need to modify my process? Like, say, oh, somebody left that system in debug mode. But then the process of, it was put into debug mode for this reason. Now you need to add a step to that process that says,
Gary: Make sure that it's undebugged.
Matt: Exactly.
Gary: That gets us to the end of all of the specific numbers, the numbers game that we've played here, and hopefully, you followed along in your copy of the PCI standard.
Matt: If you were playing IT bingo, we used a lot of words.
Gary: just some general thoughts as we've talked to our assessors over the past year doing 4.0s. It feels like there's just more documentation burden. Make sure that you're thinking that this is going to be a little bit more documentation. You need to up your game in acting like a bigger company. Sometimes the really small companies are going, you got to be kidding me. You want me to document that? Yes. Everybody has to do it. So, pony up. We talked about the TRA process…
Matt: And, hopefully, you've been working on all these. I hope they've been working on these for a while. It's not like it's new that five days from now, they come into existence.
Gary: So that's the end of that. I guess there are some questions that we can potentially do and make sure that you are continuing to submit your questions if you'd like us to address those. And, again, we may not be able to get to all of them. We have a question here about a topic that's been just a little bit controversial over the last little while, and that is…
Matt: Let me guess.
Gary: Yeah. What do you think it is?
Matt: SAQ A.
Gary: SAQ A. What do these changes in SAQA mean, and what's going on?
Matt: Yeah. What do you think about that?
Gary: I could talk about this for, like, two hours because this is all I've been doing for the last six months. We were asked to be on the EGTF, the council task force for ecommerce guidance. And, so we've been thinking about this quite a bit. Recently, as in February, I think sometime, the council made a change to the SAQA, which removed specifically 6.4.3 and 11.6.1 from the compliant requirement list.
Matt: If you meet certain requirements. Right?
Gary: Yeah. then what they replaced those two with were an eligibility statement. The idea, I guess, in industry is that people were whether it's acquirers, all kinds of different entities, we're worried about, saying forcing people, putting these on the SAQ A list, specifically.
Matt: whatever caused that event to happen, they were removed and replaced with an eligibility statement. And the eligibility statement basically said, make sure that your website is not susceptible to these scripts and that any included payment elements on your page, your referring page, which would be an iframe or something, are not susceptible to attacks from things on your side.
Matt: As an assessor, that naturally makes me go, demonstrate to me how you're not susceptible.
Gary: they removed the specific requirements and then left it with a statement that was a little confusing to people as to, now how do I meet that eligibility statement? And if I don't know how to meet that, then do I go directly into SAQ AEP, which is 70% of the PCI requirements in there rather than the twenty-nine questions. To help with that, the council published an FAQ on the SAQ.
Matt: A SAQ FAQ.
Gary: The SAQ FAQ. That's what it is. Anyway, and that helped clarify a little bit and there, they clarified that it's not your entire site because the word site was used in the eligibility statement. It really is just still referring to the same things that 6.4.3 and 11.6.1 which is the payment pages or a referring payment page. And, they basically then said, you can meet the eligibility statement in one of two ways. The first way is you could meet 6.4.3 and 11.6.1
Matt: Okay.
Gary: The second way would be to work with a third-party service provider that then says that they're going to do that for you. And, as an assessor, then what I would say is, okay. Great. Your third-party service provider, bank, big entity, whatever it is, saying that they're going to look after this. They're doing it for you.
Matt: Doing it for you.
Gary: That means, essentially, they will make sure that any script on your web page, your website cannot attack their element in there, which is difficult to do, but perhaps possible. But the thing that you have to look for as a merchant or as somebody that's using a third-party solution is you can't just say give me your AOC.
Matt: Right.
Gary: Because you don't know that AOC covers you. then you would want to say, give me your responsibility matrix or some sort of contract document or some sort of explanation how to tell me that you are meeting this eligibility statement for SAQ A for me because I'm not meeting it if I'm responding. I have to demonstrate to somebody…
Matt: To somebody or myself.
Gary: That somebody's got my back on this.
Matt: This is being addressed.
Matt: that third-party service provider is essentially taking the risk of that. Those are the two options now that they're saying to meet this eligibility statement, to do SAQ A, you either meet 6.4.3 and 11.6.1 or you find somebody who can meet them for you. And you need to look for evidence that they are actually doing that for you, and not just saying that we're PCI compliant. And they can be PCI compliant as a service provider without even doing anything for you. It’s a subtle thing, that you are doing your due diligence and looking into what your third-party service provider is telling you. I think that the council, they released that SAQ A change really quickly and then and then needed to explain a little bit the FAQ. I think the FAQ did a good job at that. You're also welcome to give us a call and talk to me about it. I could talk to you about it for two hours. So, that's SAQ A, and we may hear more as time goes on. It's a hot topic right now.
Matt: Were there other questions people submitted?
Gary: Let's see. Yes. 6.4.3 and 11.6.1, do they apply to anything other than e-commerce shopping carts? Sometimes there is an e-commerce solution where a payment solution provider would say or or you would say, hey. Look. I'm going to send you an email with a QR code that you can use to link to some emails.
Matt: Right? Seen that.
Gary: Yeah. email redirection, essentially, or maybe a button redirect going to totally somebody else's website.
Matt: Yeah. And we've seen that too. You click the button. It says, where you're going to another person's page.
Gary: Again, those ones, even from the beginning, have not been in scope for 6.4.3 and 11.6.1, those types of solutions. There hasn't really been any change that the council has put out because of the SAQ A thing that affects that process.
Matt: Yeah. That's good.
Gary: And just so you know, and because it's our webinar, the SecurityMetrics shopping cart monitor does meet the requirements for covering 6.4.3 and 11.6.1, and we do have very good and cost-effective solutions for very small merchants.
Matt: To help them meet these requirements.
Gary: Frankly, for a lot of the merchants that we are going to work with, we'll just say, do you know, to meet the eligibility statement, you can just meet 6.4.3 and 11.6.1, use our product, and they'll be good. Yeah. And you can do that with JScrambler or the other ones too. You can also just say I'm going to meet those requirements. Matt, we have another question here that came in from somebody who says, it’s my first time audit, and you guys mentioned that it's really going to be hard. The documentation might be a little bit more extensive for 4.0. I don't even know where to start. What can people do, especially if they're a smaller organization, in some of this documentation?
Matt: Yeah. Good question. And, frankly, one we get fairly often, from smaller entities like that. Most QSA firms, assessor firms have some sort of a template of policies and procedures and things that they can get to you in some way. Typically, you have to pay some amount, but sometimes they're willing to give you a single document if you need it. But that's all up to each individual QSA firm. Bottom line is they should have some documentation that can help you, get a leg up on all of the policies and things that you need to generate for 4.0. You still have to do the work to modify them for yourself. It's not just like, oh, great. It's mine. I'll put my company header at the top. You need to actually typically personalize them to your own company.
Gary: Write your process down.
Matt: Yes. Write your process down. Document what your network security control rule set is.go through and say because, the policies in requirement three talk about how long you're allowed to keep cardholder data. There's no generic policy that knows what that answer is. That's dependent on your business. You have to go in there and modify those kinds of things to match what your business processes are.
Gary: But they don't have to start with a blank piece of paper and just think, where should I start?
Matt: Yeah. Which is always daunting to look at that white screen as I don't even know where to start.
Gary: There is a lot of help available for you.
Matt: Yes. Yep. And we have some.
Gary: Matt. We have a question here from somebody about the customized approach, and that is, in what cases should an organization look into the customized approach compared to the standard requirements?
Matt: I've modified the Nike slogan slightly. It's, just don't do it.
Gary: Just don't do it.
Matt: If you read what's all what all you have to do for it is very challenging. And I have yet to see anybody who can really make a good business case for why it needs to be done.
Gary: We haven't done a customized approach since 4.0 came out. I'm sure there are a few QSAs out there, and, typically, it will be a mega organization that has a really big IT system, and they bought they spent twenty million dollars on well, a million dollars on this one software, and it doesn't exactly meet per word a defined approach, then you may say, then let's work together on creating that.
Matt: Yeah. And but, in the process of saying, it doesn't meet the requirement, you have to come up with something that meets the intent of the requirement. That means you have to spend more money and time and resources to, in some way, surround or fix that software in such a way that it still meets the intent of the original requirement, and you have to do a risk assessment on that.
Gary: You being me? No. You being the entity.
Matt: You the entity. Yeah. That's why, I appreciate you said a large entity might want to do this because they frankly would have the resources to do it. Most small entities would find it much easier just to go, I'll just meet the requirement.
Gary: Just meet the requirement. So for most of you listening, don't. Matt. We only have time for one final question, and that one really is, I'm still confused about all this stuff. Where can I go find more information about how to prepare for PCI DSS version 4.0? I mean, is there a single place that I could go?
Matt: Yeah.it's a common question. And the good news is SecurityMetrics has the PCI guide that we put out annually, and we're just updating it for 4.0. That's a good place to start. It's a nice overview of the whole standard. We have some good comments in there by different assessors. It's actually a really good document.
Gary: And I think we even cover some real-world real-world cases and comments from these guys that are actually doing the work. It's not just some sort of high-brow stuffy document. It's something that the guys that are on the front lines have helped.
Matt: It's a good document.
Gary: Look for that. You can download it, I think, as a PDF or we can, I don't know if you can get a printed copy or not, but maybe? And other than that, there's, again, all kinds of information on our learning centers, through our blogs, etcetera. There's going to be links at the bottom of this webinar. Spend your time, looking through all of that good material, and we appreciate your time here today. And, let's just say good luck as you implement 4.0.
.svg)
