S2 E34: Getting Ahead of PCI DSS 4.0 Future-dated Requirements
Audio version
Getting Ahead of PCI DSS 4.0 Future-dated Requirements
Transcript
Jordan Eisner: Welcome, everybody, viewers and listeners alike. I’m Jordan Eisner, host of Compliance Pointers, and this is another podcast.
So I’ve got Brandon Breslin with me today. Brandon, this is probably what, your fifth, sixth time on?
Brandon Breslin: Yes, that sounds about right. Thanks for having me on.
Jordan Eisner: You need to stop being so good and you won’t be asked to come back so often.
Brandon Breslin: I don’t know about that. I’m just here to share some knowledge.
Jordan Eisner: For our first time, viewers and listeners, Compliance Pointers is a podcast about information security, information privacy, and some niche regulatory compliance areas, and really how organizations can mitigate risk around those. So we have different experts, mostly from our team come on, but also partners and other organizations and serving this role and capacity in the hot seat, if you will. But no, not so much.
Brandon Breslin has been on a few times. So if you’re a regular listener, he really needs no introduction. But again, for the new time listeners, Brandon’s been with CompliancePoint. What is it now, Brandon, over two years?
Brandon Breslin: Getting close to two years, so probably a year and three quarters. January will be two years.
Jordan Eisner: And prior to that, worked for a major consulting firm, I think over 10 years of experience with PCI, but now with Compliance Point, he’s a director in our assurance group. So he manages all our PCI business, SOC 2 business, and ISO 27,000 series business as well.
And he’s a UGA grad. He’d want me to point that out, especially after the recent UGA Texas game.
Brandon Breslin: Huge win against Texas. On the road at night, excellent win.
Jordan Eisner: Yes. Not super enjoyable to watch as a fan.
Brandon Breslin: For the casual fan, that game probably was not enjoyable. For me, as a biased UGA fan, it was extremely enjoyable to watch.
Jordan Eisner: Especially the first half.
Well, my dad went to Texas and my brother went to UGA. I wasn’t exactly a house-divided because I pretty much grew up in Georgia, and that’s probably what I was pulling for. But I was a casual fan, and I was hoping for a better game than that.
We’ll leave it there. We’re not here to talk about that today.
We’re here to talk about PCI DSS 4.0.1 and some critical future-dated requirements that have been introduced, and the key changes organizations need to be aware of to start prepping for those. So we’re going to break down five critical ones on this podcast today.
I would say for our listeners, if you have questions beyond that, reach out. I usually save some of this for the end of the podcast, but we can be reached via our website. There’s an email connected@compliancepoint.com. Brandon and I are both pretty active on LinkedIn. You can reach out to us that way. But reach out if you have more.
We’re going to break down what we can in a day and hopefully create some usable content for you. So let’s just talk first and foremost, what are the future dated requirements, Brandon, in 4.0.1?
Brandon Breslin: A couple things. And I was thinking as we were talking about what we want to talk today, since we did a podcast, we probably haven’t introduced to the listeners that there’s been a new supplemental update. You mentioned 4.0.1.
So about a year ago, a year and a half ago is when they released the final version of 4.0. Since then, about six months ago, they released the 4.0.1 supplemental update. No new requirements since the release of the final version of 4.0. However, they did add some more guidance in there.
They also released a new version of the scoping and segmentation guidance that calls out some more of the modern architecture is really where the focus is on. So did want to call that out.
As it relates to the future-dated requirements, Jordan, you hit the nail on the head. We’re just going to hit a couple of them here. There are a ton of new future-dated requirements.
Just so everybody’s aware, when we’re referencing future-dated requirements, we’re referring to controls that are already out there. If you’re doing an assessment right now, they are out there. You can implement them now, but they are not required to be implemented until the end of March of 2025. So March 31, 2025,
Jordan Eisner: It’s not that far off.
Brandon Breslin: It’s not that far off. So this is the right time to be talking about it. If you have not started planning or even gotten to a testing or implementation phase, you really should be looking at these that we’ll dive into here shortly to really get budget approvals, especially most organizations have budget approvals right here. Coming in, we’re in quarter four right now. We’re in late October, getting approval before January to be able to implement some of these technical and operational controls.
Jordan Eisner: That’s a good call out. And I know from the buzz that this year more so than previous years has been difficult for securing additional budget. I think when you go to the powers that be and you say a standard like PCI, which had been on 3.0, is moving to 4.0. Okay, that’s big. That’s clear. That’s simple. What do we need to do in budget for it?
But why are these future-dated requirements for 4.0.1 so critical, so important? And what information should, I guess, individuals use around the importance or risk of not making these changes to help secure budget and get some organizational momentum around this?
Brandon Breslin: That’s a great question. I will say the future-dated requirements are focused on really why they’re important to answer the question directly. They are adjusted based on common attacks out there in the industry. Right. So one that we’ll hit on is around online skimming, mage card attacks. One is around anti-phishing controls that you need to have out there. User access reviews, that aligns with other methodologies and other frameworks like SOC 2 and ISO. You mentioned those at the beginning as well.
Some of the more modern architecture around payment pages. So one of the requirements now, you have to have file integrity monitoring on the payment page. You need to evaluate the payment scripts that are generated on the consumer’s browser, making sure that those are authorized and understanding how those are protected and making sure that there’s no unauthorized scripts from another third party that could be run. That’s to prevent those online skimming attacks that I mentioned.
So I will say the core competency or the core reasoning behind the future-dated requirements is to align with modern architecture, modern attacks that are out there, especially in the e-commerce space and payments, but also in the operational side of the house as well.
Jordan Eisner: And so I was going to ask you to walk through some of the critical ones you wanted to highlight. I think you touched on some of them there, but anything additional you would add around the specific requirements?
Brandon Breslin: Let’s run through a few of these. So user access reviews, I mentioned, I think that’s a big one. Regular reviews of user accounts, system accounts, application accounts, if there’s any other hardware component accounts that may be local authentication outside of a central auth, like through Active Directory or TACAX+. So really reviewing all accounts.
I will say this one is probably not going to be as big of a hurdle for most organizations, especially for midsize or larger, because if you’re already undergoing another framework assessment like SOC, ISO, NIST, CIS, any of those common ones that are out there, they all have user access reviews as common criteria or common controls that are out there.
But that one’s important because, especially in the larger organizations, there may be accounts that fall through the cracks that you have no idea about if you’re not reviewing them.
Another one is internal authenticated scanning. I think this will be a larger endeavor, especially for bigger organizations where you have a large number of system components that need to be scanned, whether it’s servers, workstations, network devices, VMs, VM hosts, hypervisors, whatever it may be that need to be scanned.
The big piece about authenticated scanning versus traditional or unauthenticated scanning is that now that there’s actually credentials to run the scan, so it actually has the ability to do an interactive login on the backend. It’s essentially given a service account to log into the device. It can do a deeper level scan, so it can review the root files, directories, libraries, more of a deeper level or more intrusive scan than the traditional discovery scan, if you will.
A traditional vulnerability scan is more of a discovery just to identify vulnerabilities that are out there and base it on criticality of common methodologies that are out there, like CVSS or even your own internal scoring method.
The authenticated scanning has the ability to actually use a service account to log in to do a deeper level discovery of the device as an administrator.
I’d say those two are big ones.
Another one that we can think of is to go back to the Magecart. I mentioned that this is requirement 643 around the payment page script. Anything that’s loaded or executed in the consumer’s browser needs to be authorized. You need to have integrity on that script. You need to make sure that it’s operating in the intended manner.
You also need to have an inventory of all the scripts that are run. This is to make sure that there’s no… If you’re the merchant, if you’re the merchant of record, you don’t want to have other third parties, especially if you’re using third parties to execute the payment for you, to process the payment or to accept the payment data. You don’t want those third parties to have other scripts that are running in the consumer’s browser or other third parties that you may have on the site. You really want to make sure that payment page is locked down.
Scripts that are run in the browser are the number one leading cause of online skimming or Magecart attacks.
Jordan Eisner: Okay, and you alluded to some of this too, but I was thinking along the lines of… I think you do see some of this being a challenge. You just said that. What are some of the common challenges and why, I guess, for organizations in trying to implement these new requirements?
Brandon Breslin: Yeah, definitely budget approval and not having a plan.
We can get to the tools here in a second. There are definitely tactical methods, but I would say definitely not getting executive or senior management approval. Establishing, we can talk through maybe some of these individually.
For authenticated scans, maybe there’s not an approval to purchase a larger product or a more complex product that allows you to run those authenticated scans.
Or for user access reviews, maybe there’s not a consistent process that already needs to be built. You need to have coordination between different departments to get user listings, especially if you’re a larger organization and you have 10, 20, 30, 100 departments, and you need to get different listings for each application or hardware component or network set. That can be a challenge.
Jordan Eisner: Let me jump in really quick from that one just so I’m understanding correctly too. This is contingent upon scope though. Right, because I know you keep saying large organizations, but if they have a very small CDE, is that still going to be a factor for them, the size and breadth of the organization regardless of the size of the CDE?
Or when we say large organizations, are we talking about with a large CDE that’s touching a lot of different systems?
Brandon Breslin: With a larger scope, that’s a good call out. I will say most of these requirements that we’ve talked through are going to be relevant for all size organizations. Small scope, medium scope, or moderate scope, and a large scope as well.
Where you may not have to worry about some of these like authenticated scanning or even MFA for all access into the CDE was another requirement I wanted to call out. That’s a larger endeavor especially for the larger scope.
But if you have a smaller scope, it may not be as big of an overhead or may not be as large of an endeavor because you only have a couple servers, right? Or you only have one firewall and one web server and a load balancer and two workstations, right? That’s pretty simple.
Or maybe you fully outsource or if you have a zero trust architecture, or if you have everything in the cloud and you’re not managing any of the system components and you can rely on third parties for handling. Sure, network security controls are a whole separate thing and managing segmentation. But if you have no access to some of those devices or if you’re not responsible for those devices, then you may not have to do the scanning or you may not or you can rely on the third party for that or you may have another third party that’s implementing MFA for you, right?
One key piece on leveraging third parties that is very important to remember if you are evaluating especially if you’re going through an assessment, right? If you’re going through a 401 assessment and you’re relying on a third party, you need to get that AOC, that responsibility matrix from the vendor to understand, okay, are they actually relying on this requirement for me, right?
Because as an entity being assessed, you need to be comfortable with that third party, that TPSP third party service provider, that they are evaluating that requirement for you and they’re handling or they’re accepting the responsibility for you on that, right? You need to be comfortable from an organizational perspective.
Yeah, I was just going to say a couple of, you know, to go back to your other question, a couple other challenges, right, may also be just the technical expertise of the security team or the technical team that you’re working with or your IT team, right?
If you’re a one-man or one-woman IT shop, right, you may not have the technical means to be able to implement some of these things that we’re talking through. And it may make sense to go out and look at or evaluate a third party to handle some of these requirements for you, right? If you’re going to implement a jump box or if you’re going to implement some new network security controls to further segment your environment, right?
Is that something that you actually have technical ability to do or do you really need to, you know, look at some of the other options that you may have, you know, specifically for one other requirement that we haven’t touched on that I really wanted to hone in on is one of the new requirements that’s not future dated. However, it’s important to remember 12.52 accountability of your scope. You mentioned scope, right? Some of these requirements may be affected by your scope. It’s important to know that you as the entity being assessed, if you’re going through an assessment, you have to be accountable to your scope.
You identify the scope and the QSA validates it, right, if you’re working with the QSA. And having that accountability for the scope, right, you need to know what is in your environment. If you’re making any significant changes this year, these are relevant, right?
You need to be accountable to your scope. You need to update your scope if you’re a service writer every six months or if you’re a merchant every year.
Jordan Eisner: And I know we’ll break it up a little bit because you mentioned the tactical piece and I think that’s a good, maybe a place to leave our listeners, right? With some very tactical things that I can write down and go do.
But the organizations that you see getting ahead of this or doing the right or planning for 401, how are they doing that, right? How are the better organizations getting, I shouldn’t say better, but the organizations more prepared for this, getting started with it?
Brandon Breslin: Yeah, it’s being proactive, not reactive, right? It’s establishing a plan. You never want to jump right into it.
You never want to evaluate, for example, one of the new requirements that you need to have anti-phishing controls in place in the organization, right? You don’t want to just jump in and hire a third party or purchase a new product. You want to establish a plan, first get executive buy-in or even before that, put together a committee or a methodology group or whatever, whoever it makes sense in your organization to talk through, decide what makes sense, get executive buy-in, and then start to test out some of those controls, right?
If it’s a new policy or procedure that needs to be written, have multiple people review it. Go through your standard change management process, right? If you have a CAB process, a change accounting board or a change accountability board, make sure to go through that process, right?
If you have two people to review it, make sure to review that. If you need to implement technical controls, have a peer review, have somebody else review it.
Make sure you really think through. That’s the reason for this grace period that we’re in right now before the future-dated requirements come into play of March 31 so that you have the time to plan and implement and plan, test, and implement prior to that timing. So I’d say that’s the big thing, right?
And making sure that you’re also not going outside your expertise.
Jordan Eisner: Well put.
Well, then coming back to the tactical as we move to wrap this up, what are some tactical suggestions you would have that you haven’t already gotten into? I think there’s been very meaningful content for our listeners, but anything additionally or even further into the weed that you would add?
Brandon Breslin: I think really about maybe on the more tactical side, we’ve talked through on the operational side, right?
Of planning, testing, implementing. Really look at what are the technical resources you have in the organization? Do you need to go out and find a new solution?
For example, with authenticated scanning, you may be working with an approved scanning vendor in ASV for external scanning, but for internal authenticated scanning, what’s the tool you use, right? Do you need to bump up the tool? Do you need to get a Nessus product or a Tenable product, right? Or a Qualys product?
Do you need to evaluate a different product that you may have, right? Do you need to integrate that with Active Directory for credentialing, right? Or credential management? Really focus on the critical systems first, right?
Maybe another example with the user access reviews, right? Do you need to establish a roles-based matrix or some type of RBAC model, right? Or do you need to coordinate with the other departments, like the example I gave earlier, if you have multiple departments or multiple system components sets, or if you’ve got an application team and a system team, a network team, a server team, right?
Or the payment page scripts, the integrity on those, right, do you need to reach out to another company and evaluate a solution, test that on your payment page? And even before that, make sure to do an inventory of all the scripts that are running. We have some organizations that have 200 scripts running on one payment page, and we have some organizations that have two scripts running on a payment page. So really understand what everything that’s running on that payment page, start to inventory that out.
Another requirement that we haven’t talked through that’s in a similar line of this is establishing an end-of-life process, right, or an end-of-life or a product lifecycle is kind of what we look at it, right? If you have servers out there, just put a column in the inventory that says, hey, these are all the dates that this device is going to go end-of-life, or the software that’s going to go end-of-life, the firmware, right, the operating system, all the different relevant categories, right, that may go end-of-life that you’re relying on a vendor for, and then establish a plan for upgrading those in the future. If they’re going to be decommed or end-of-software lifecycle in end of 2025, start to test out a new device or a new OS in early 2025, right?
So really taking a proactive approach instead of a reactive approach.
Jordan Eisner: Good food for thought. Thank you, Brandon.
And for our listeners and viewers, thank you as always. You know where you can find us, I hope, CompliancePoint.com. But make sure you subscribe, leave reviews if you’re enjoying the content, and continue to check back for more information, security, privacy, and regulatory compliance updates and podcasts.
Until next time. Thanks, everybody.
Let us help you identify any information security risks or compliance gaps that may be threatening your business or its valued data assets. Businesses in every industry face scrutiny for how they handle sensitive data including customer and prospect information.