S2 E2: The Major Changes in PCI DSS v4.0

The Major Changes in PCI DSS v4.0

Transcript

Jordan Eisner: Welcome to CompliancePointers, and happy new year to our listeners. I’m your host, Jordan Eisner. Before I introduce our guest today, I did want to remind everybody listening to subscribe to our channel if you haven’t already.

Today I’m joined once again by Brandon Breslin and John Barbier, both of whom you may recall from our previous episode where we explored beginning the PCI DSS 4.0 transition.

Brandon is a senior manager from our assurance group and the leader of our PCI practice. He’s been working at PCI for the better part of a decade, and the last year around there here at CompliancePoint.

John is a senior security consultant on Brandon’s team and a fellow QSA, qualified security assessor, is a broad background in several technical areas, and has spent his recent years focused on PCI and the like.

So today we’re picking back up on PCI DSS 4.0 and what’s new with the focus on some of the prominent control families and how they could impact your existing program.

So Brandon, let’s start with you. We talked in the earlier episode around planning for 4.0 assessments, and now we’re talking more specifically about the new requirements. Can you give an overview of what’s changed with respect to the new requirements?

Brandon Breslin: Yeah, absolutely. Thank you, Jordan, and thanks for having John and I on today again.

So really 4.0 is a massive overhaul of the new standard. For those that are familiar with PCI, usually the council will refresh the requirements around every three years or so. 4.0 is definitely the largest change that they’ve had. It’s more modern now. It incorporates new technologies and processes that are available. Previously, it was very static. Now it’s very dynamic to be more inclusive of some of those modern solutions that we see out there in the industry.

As it relates to the changes, there are really four pillars or goals that the council has called out in the new standard. Continuing to meet the security needs of the payment industry. There’s the dynamic piece right there.

Promoting security as a continuous process. That’s more of that orchestration, if you will, or continuous compliance.

Adding flexibility for different methodologies and enhancing validation methods. So that’s going to come into play on more of the reporting side.

In regards to the changes, we will dive into those here, but there’s kind of a few different buckets. Changes in managing risk. Identification and authentication. Cryptography. Vulnerability management. Personnel training and handling. As well as new service provider requirements.

Jordan Eisner: Yeah, well, let’s pick one of those. Brandon, how about evaluating and managing risks in an organization? Why don’t we dive specifically in that one? Brandon, why don’t you? We’ll stay with you on that one.

Brandon Breslin: Yeah, for sure. So the biggest change that those that are familiar or maybe not as familiar with the new standard, you’ve probably heard the buzzword already of targeted risk assessment or targeted risk analysis. These are going to be around managing risk.

So we talk about one of the goals being promoting security as a continuous process. That includes frequencies of different intervals, right? So in the previous standard, in 3.2.1, there were defined frequencies that every organization had to follow, but that’s just not realistic in today’s modern society of different processes and technologies.

So companies now, for some of these requirements, can define their own frequency based on the risk to their organization for that specific control. So they can determine their own intervals, whether it’s monthly for specific anti-malware scans or weekly or daily, right, as an example.

There’s also a new customized approach option that allows, previously in the old standard, there was only a defined approach to every requirement that was cut and dry of what you had to follow. Now you have a much more generic option for being able to get to the compliance state for that requirement.

And then more specifically for one of the new requirements that are around managing risk, now organizations have to conduct a review of all hardware and software that they use on an annual basis.

Jordan Eisner: Well, let’s shift. Let’s go to John for this one. John, tell us about the identification and authentication changes.

John Barbier: So multifactor authentication into all CDE systems is required. So if you’re in an accounting department and your system is a CDE system, that employee has to use multifactor authentication to log into the systems within the CDE. So that may require additional resources and investments, so something that you need to plan for before the… and get that under your belt.

So there’s some changes to MFA and the MFA has to be resistant to replay and bypass attacks. Because additional controls around user accounts and particularly service accounts. So for service accounts, they have to be implemented using least privilege and you have to have additional monitoring on that and review those accounts, make sure that they’re still required.

And then there’s also changes around passwords, so the minimum password length now is increased to 12 characters. There are cases where that’s not required if your system is not capable of having a 12-character password, but for most entities, 12 characters is going to be the minimum.

And then if you have some kind of additional monitoring of the user authentication process, you are no longer required to change the password every 90 days. But if you don’t have that in place, then you still need to change the password every 90 days.

So overall, the identification and authentication has become a lot stronger and there’s also areas that were neglected in the past, such as the service accounts and user account reviews that were not occurring that have been tightened up.

Jordan Eisner: Was the password change every 90 days previously as well?

John Barbier: It was every 90 days, yes. But if you have additional monitoring, what comes to mind is if you have monitoring of user behavior on the password and you’re able to detect, for instance, that the user account is being used outside of normal hours or outside of geographic locations, that type of monitoring, then the requirement for the 90-day password is no longer a requirement.

Jordan Eisner: And earlier when you were talking about CD systems, you might have mentioned it earlier, but for those new to PCI or maybe not as familiar, cardholder data environment, right?

John Barbier: Correct, yes, cardholder data. So any system that holds cardholder data, particularly card numbers in RAM or transits across the network is a CDE system and part of the cardholder data environment.

Jordan Eisner: Appreciate that, John. Back to Brandon.

Cryptography, obviously a key element. They have security. What’s new with that in 4.0?

Brandon Breslin: Yeah, there are a bunch of changes regarding cryptography, kind of to hit maybe the two big ones. So now every organization that goes through compliance for PCI DSS version 4.0 has to maintain an inventory of keys and certificates.

So the one that immediately comes to mind, we’re talking about cardholder data, right? So credit card data, debit card data, having an inventory of keys and certificates that are used to protect that data specifically.

So that would be encryption algorithms as well as if you have an extra web application, for example, and you have a CA certificate of some sort protecting that transmission for the tunnel encryption as well, that would be included in there. And that would be specifically for keeping track of all the algorithms, the protocols, the key strength, right? That could include the key custodians as well as it relates to ensuring that vulnerabilities are discovered in that software.

This inventory will also help with that, knowing what the latest version of the software is, the certificates and the algorithms to make sure you’re standing up to date there.

Jordan Eisner: We’re talking physical hard keys, right?

Brandon Breslin: So this is actually in, we talked a little bit earlier about incorporating modern technology. Most of the solutions now are going to be virtual keys. So you’ve got, for example, we’re talking about both encryption and transmission as well as encryption and storage. If you’ve got a website that’s using TLS 1.2 and you’re creating new session keys on every single user that’s coming to your site, those are all going to be virtual encryption keys.

Jordan Eisner: I’d just like to picture a huge key ring with all the different keys for this.

Brandon Breslin: Yeah, I was going to say one more big one as well in the cryptography space is key cryptographic hashing. So that inventory of keys and certificates is most prevalent going to be in the transmission space.

The key cryptographic hashing is going to fall more into the storage space. So for example, if you’re storing card numbers, credit card, debit card numbers in a database, previously you could, if you were just storing the full PAN in an encrypted format, now you need to have hashes to render that PAN unreadable have to be key cryptographic hashes.

So to be more specific, that’s going to be a function that incorporates a randomly generated key. So similar to salting and passwords, you now have to do quote-unquote salting for encryption key storage.

Jordan Eisner: Moving along, so I want to ask you about vulnerability management. We’ll go to you for this one, John. And interested in what’s changing because we have a cyber team here, CompliancePoint, a lot of times they’ve engaged with our clients on PCI, even though you guys, QSAs, are working with them. So it can be independent of one another. And I know there’s a lot of back and forth about the changes when you’d be doing this more often and 4.0 is going to require this. And I’ve heard a lot of different things. Walk us through, right? What’s changing with vulnerability management with 4.0?

John Barbier: I think one of the big changes is authenticated scanning. So for vulnerability scans, if you haven’t been doing authenticated scanning in the past, it’s a best practice until 2025. I highly recommend that you don’t leave it until then to get this one under the belt. Because if you haven’t done authenticated scanning, basically you’re giving the scanning  tool the rights to identify what is on the machine. And you may get a surprise as to how much more your scanning tool discovers using authenticated scanning.

So the vulnerabilities that are identified that are low and medium in the past, you were technically required to remediate them, but most entities put them on the back burner. Your policies need to determine together with a risk analysis how often or how long those vulnerabilities need to take to be remediated.

And then you have to address the low and medium vulnerabilities. So that’s another one of those that you want to get that under your belt prior to the full implementation of PCI 4.0 next year.

A new one that hasn’t really been addressed in PCI before is payment page script and in browser tamper detection. So that is where you have an inventory of all the scripts that are authorized to run on a browser in the browser window to load into the web page and then in browser detection.

So there are different technologies or techniques that can be used. So it could be like behavioral analysis. So that’s similar to the antivirus that saw behavior that, you know, software that is running in a way that looks suspicious. Or you can also have cryptographically signed scripts so that the integrity is checked before the script executes in the browser.

So there’s a lot of new technology that needs to be implemented and addressed for that requirement.

For remote connections, similar to what you would have with Citrix where you have somebody remotely connecting to a system and they may be able to seek or work with cardholder data. You have to prevent copy of the cardholder data so the user should not be able to download a copy to their local drive and work with it locally.

Penetration testing. This is not really a new requirement. There’s just clarification on this, but entities need to be aware of it. So there’s definition of what is considered an internal and an external penetration test and where the test occurs from. So testing needs to occur both from inside the CDE as well as from outside the CDE. That would be from the out of scope or from the corporate network into the CDE.

Those changes result in a much more robust vulnerability management process in PCI 4.0.

Jordan Eisner: Something for our listeners to revisit. There was a lot there to unpack.

Brandon Breslin: I guess, Jordan, if I can add on to just one plug in the vulnerability management category here.

While we’re talking about all of these future data requirements that don’t necessarily have to be implemented until 2025, the one that I really want to call out is that John mentioned was the authenticated scanning. We would highly recommend for those organizations that are already planning out your move to 4.0 or actively building out some of these new controls and processes and procedures to really look at going to authenticated scanning as early as possible.

While we are in that grace period, you really don’t want to get to a point where you’re blindsided by a lot of critical and high vulnerabilities that come out from those scans that you may not know about until you go down the route of authenticated scanning. Then you put yourself in a position to where you can’t remediate that in time and you’re jeopardizing your compliance status. So it’s definitely something to think about of moving earlier than normal.

Jordan Eisner: Very insightful stuff. So Brandon, back to you. Talk about training with the organization. So what has changed, if anything, with training your staff?

Brandon Breslin: Yeah, absolutely. So as everyone knows in the security and compliance space, people are always the most vulnerable element as it relates to security and potential attacks out there. And it’s evident within the new standard that the council is aware of that and really trying to hammer home the objective of ensuring your staff are trained appropriately in security and compliance and handling cardholder data appropriately.

A couple of the new requirements that they’ve called out within training and security awareness is now the program has to be reviewed annually. I know this may seem like a small one, but it can have a pretty big impact just because of the consistent changes in the industry with new processes, new attacks that are out there, new ways of handling data.

I personally firsthand, and I’m sure John has as well, have seen many organizations security programs built 10, 15 years ago and are never updated. So you’re really training your personnel on old ways of handling data, old security attacks that are out there that may be either extinct or are not relevant nowadays, as well as not incorporating some of those new attacks that are out there.

And then I would call it a cascading requirement, even though it’s standalone, is the new requirement for phishing and social engineering training and controls that have to be put into place.

So phishing just in a simple form is, you know, if somebody receives, for example, a malicious link in an email and they click that link and can impart malware onto the environment or onto their workstation, that’s just one example of phishing.

So the new requirements now have to incorporate training on preventing employees from clicking on malicious links. So checking, you know, email headers and checking who the sender was and were there any other recipients copied on that, as well as incorporating controls from a technical standpoint to ensure that in case an employee does click a link on an email that’s malicious, there are protections, whether it’s browser protections or local protections, to ensure that that cannot impair the cardholder data environment.

Jordan Eisner: What about smishing?

Brandon Breslin: I would say that that’s still going to fall into that same category, right? While they didn’t call out that specific, you know, type of SMS attack, the controls would still be in play. Let’s say you have a process that includes handling of mobile devices for payments of some sort. That would definitely be included in that.

Jordan Eisner: Some of the smishing I’ve seen is, you know, I had an employee start for me, I guess about three weeks ago now, and he got a text, I think it was first or second week from the CEO, right? So, I mean, somebody had, I don’t know, either been monitoring that number. Well, I think it was his own number he brought it on and just getting reimbursed. So they would have seen somewhere there’s a compliance one. I don’t know, obviously, the background of how that’s found, but some of that’s pretty sophisticated.

Brandon Breslin: It really is. And that’s a great point about that, because we see many organizations using mobile devices for payments, whether they’re, you know, while they may be corporate owned devices, right, or store or restaurant owned devices, if somebody is logged in on that device, or if somebody receives a malicious text, even if it’s a spam text to a generic number, and they click that link, there’s still implications of that from a security standpoint. So, you know, making sure those controls trickle down all the way to mobile devices as well is critically important.

Jordan Eisner: Alright, well, let’s go back to John to round us out on the questions. Let’s talk about service providers requirements there. And I guess just for our listeners again, that’s a new PCI, right? There’s merchants, there’s service providers, right? What’s different for service providers?

John Barbier: So for service providers, you know, if we think about, for instance, the requirement to determine and document your scope for a new requirement in PCI 4.0 is that all entities have to define and document the scope for merchants, it is annually. So you need to have a process where you formally define what your CDE systems are, what you’re connected to, or security providing systems are, and that process results in documentation, such as your network diagrams and the inventory documentation and data flows and stuff like that.

For service providers, the requirement is to do that more often. So there are, there’s also requirements around cryptographic architecture for service providers. So you have to have documentation around what cryptographic algorithms and protocols and keys are in use. And for service providers, the requirements around that or what needs to be included is more stringent.

There’s also vulnerability requirements, you know, in the past, very often we saw that entities find out that an encryption algorithm has been deprecated after the event occurs, and there’s suddenly a mad rush when you’re doing your PCI assessment to come up with a plan on how you’re going to replace that.

So the approach going forward is that that needs to be built into an ongoing process where you perform reviews to determine whether the encryption that you have in use is still appropriate for its purpose.

Another requirement for service providers, which is new, is that the intrusion detection or the intrusion prevention system or technology you have in use has to detect covert communication channels. So for instance, if you had somebody, if you had a breach and somebody was exfiltrating data using a covert communication channel such as DNS, DNS queries are normally pretty small and low traffic, your intrusion detection system needs to be able to detect when it’s not DNS traffic being exfiltrated from the network.

And then service providers also have to provide support for their customers’ compliance efforts. So two documents that come to mind, firstly is that when the entity requests your AOC, you have to be responsive and provide that because that’s what the merchants require for their PCI assessments, but also the responsibility matrix where you clearly define what your responsibilities are as a service provider and how you support or meet the requirements for PCI for those merchants and provide that for them both when you engage or enter into a contract as well as an ongoing basis when they need that.

Jordan Eisner: Okay, all right, so a good bit to unpack with that one too. Any closing remarks, I guess, John or Brandon on any of those service providers we just went over, but any of the other ones? I feel like we’ve covered a lot of topics, right, or a lot of content in a short period of time here.

Brandon Breslin: I think the only other remark I was going to mention is just kind of as a recap from our previous episode, really want to, as you guys are thinking about for your organization, thinking about these new requirements, thinking about how you want to quote-unquote attack PCI 4.0, really make sure you have a plan in place, right? Don’t just dive right into the requirements and start thinking, oh, what do I need to deploy? What processes or technologies do I need to purchase and put in place?

Sometimes that can get very expensive and maybe unnecessarily expensive in some cases. So really make sure you first think about plan, get together with other personnel on your team, your executive management team, making sure that you’re incorporating all the different departments in your organization that need to be included and really determining which specific technologies or processes or controls that need to be implemented first before you go down that route.

John Barbier: I think what comes to mind to me is don’t wait until March of 2025. These new requirements are best practices until then, but in a lot of cases, these technologies and these processes are going to take time and resources and don’t leave it till the end and don’t find out what the new requirements are during your first full PCI 4.0 assessment because I think that is a recipe for failure.

Jordan Eisner: Good point. Sage wisdom from the two of you. Thanks Brandon. Thanks John once again for your time today. Thank you to our listeners as always and for our listeners.

I’d add a specific plug here today. I’d say if you find yourself seeking PCI support, a third party attestation, advisory consulting support, we’ve been doing it for the better part of two decades.

Here’s just two of our experts on our team. We’d love to chat. Don’t hesitate to reach out to us. Like most companies, we have a website. If you feel maybe better just going to the website and exploring there. A lot of good content resources there. It’s compliancepoint.com.

You can email us at connect@compliancepoint.com. That’s also listed on our website or you can please feel free to reach out to Brandon, John, myself directly on LinkedIn and hopefully we can help solve some of your PCI questions, heartburn, nervousness, you name it.

So happy 2024 to everybody. We’ll see you next time.