PCI DSS v3.2.1 expired on March 31, 2024. Organizations should have planned for the transition to PCI DSS v4.0. With 64 new requirements within PCI DSS v4.0, there is much to prepare for in the impending deadline. Through our PCI Webinar Series, discover the overall changes to 4.0, new requirements, best practices, and how greater focus on risk assessments in the new version will be the catalyst for security and compliance.
Join Viviana Wesley, CISM, PCI QSA, ISO 27001 Auditor and HALOCK Principal Consultant to review key updates and next steps to support your transition to PCI DSS v4.0.
TRANSCRIPT
Hello. Thank you for joining us today.
This is the first of HALOCK’s PCI DSS 4.0 overview webinar sessions. Today, we’re gonna cover the changes comp that have come out in 4.0 DSS.
My name is Viviana Wesley. I’m a principal consultant on HALOCK’s governance, compliance, and engineering team. I’m a CISM, PCI QSA, and also an ISO twenty seven thousand one auditor.
I’ve been working with HALOCK for about thirteen years and have been a subject matter expert for the organization for several years. I also serve as an expert witness for state offices of attorney generals and multidistrict litigation cases.
I started in information security before I transitioned into information security.
In our presentation today, we will first cover a quick introduction about the PCI data security standard. We’ll talk about what changed in v4.0. Then we’ll actually get into some of the detailed 4.0 requirement changes section by section and also cover reporting changes that have come out for for DSS 4.0 validation.
To start off, we need to talk always talk about the PCI Security Standards Council. The Security Standards Council is an independent industry standards body that provides oversights and development of all of the management of payment card industry standards globally.
The founding multinational acceptance brand members include American Express, Visa, Mastercard, Discover, as well as Japanese card credit bureau and union pay that was added this past year.
The PCI security standards council has been quite busy. We now have fifteen PCI security standards. The one we’re gonna be talking about today is called the PCI data security standard.
The PCI data security standard is a collaboration of the card brands that started in the early two thousands. The current version that we are on is v3.2.1, but v4 was published last year in March of last year. So we’re now one almost one year into that being published and version 3.2.1 will be retired in March of next year. So as of March of twenty twenty four, all organizations will have to comply with v4 of the DSS.
When we go through transitionators with the PCI security standards council and they introduce new requirements, they typically give organizations additional time to implement those new requirements. So fifty one of the new 4.0requirements are actually best practices until we reach March of twenty twenty five.
As always, the PCI DSS is seen as a security low bar. This is the bottom least amount of security we should be implementing for any credit card data security efforts we do.
And, anytime organizations are wondering if it applies to them, they should be considering any potential payment channel. So it’s gonna apply to any cardholder data of one of those brands that we mentioned upfront, and it’s gonna depend on if the organization is either a PCI merchant or service provider.
So when we’re talking about the PCI DSS, there’s typically two categories of organizations that applies to the organizations that the standard applies to. Merchants being an organization that actually accept one of those payment brand cards for goods or services they provide, and service providers are organizations that are directly involved in storing, processing, processing, or transmitting cardholder data on behalf of another entity or can impact the security of another entity’s environment because they’re actually providing some managed security services or can somehow impact that environment security or handling data on their behalf.
Now the reason we always try to get in front of the PCI DSS and try to make sure organizations are compliant and the people are doing what they need to is because if an organization is breached and that data is stolen, there’s a lot of negative impacts that that organization will be faced with. Not only fines and penalties from the card brands, but also any disruption to the organization’s business as a whole, reputation loss, and then all of the additional costs that can come out of a breach investigation and potential litigations.
So it’s very important to stay on top of this and be vigilant and try to address this before organizations lose that information.
So let’s talk a little bit more specifically about the timeline I mentioned. We’re currently in Q2 of twenty twenty three. So we still have until Q1 of next year to make sure that we’re ready for any brand new four point o requirements that are applicable right away. And then we have that additional year to make sure that any of those new fifty one requirements are addressed before March of twenty twenty five.
So we’re very much still in a transition period.
The PCI Security Standards Council always releases a summary of changes document when they go from version to version. So there is a summary of changes document on the council’s website from version 3.2.1 to 4.0. In that document, they summarize all of the changes they’ve made in the standard, and they classify the different requirement changes into three different categories.
Evolving requirements will include those requirements that are brand new. Also, updated requirements or testing procedures got lumped into that category, and also some deleted requirements, what we called evolving requirements.
For clarification and guidance, which we did see quite a bit of in the new version of the DSS, there’s a lot of changes between requirements and testing procedures, agreements, clarifications, clear language, and a lot more information in their applicability notes.
And then we have a change classification of structure or format.
So that’s when the council combined or renumbered requirements.
And one of the things that I really like about what they did with the four point o standard is they added so much additional information and guidance about scope and applicability.
You’ll notice that every section heading for each of the DSS sections now has additional guidance around what that section applies to, how it applies, and additional applicability notes throughout the DSS.
So there’s also great additional guidance in the appendices of the DSS.
One of the things that was introduced in version 4.0 is called the customized approach.
So what we’ve been doing in the past, the way we’ve been validating the compliance in the past is now called the defined approach. So you have the requirement, you have defined testing procedures, and you can use compensating controls if you cannot meet the intent of that control because of a business or a technical constraint.
Now there’s an additional approach that organizations can use for a lot of the DSS requirements, but not all.
What that approach is called is the customized approach. The intent is to provide flexibility to the entity. So if they’re do if they are meeting that intent, the objective of that requirement, but they’re doing it in a way that’s a little different than what the DSS states, but they can still show that they’re meeting that objective.
This is what the customized approach is intended for. It’s not a replacement of compensating controls.
It can’t be used for compensating controls.
It’s actually a more robust more robust way to explain that you’re meeting that objective.
Though it adds flexibility, it also comes with additional documentation and evidence and and data that needs to be collected, right? So when an organization wants to use that customized approach, there’s an appendix in the DSS now that provides all the templates and information necessary there.
The organization has to document and maintain evidence about each customized control they use. They need to perform a targeted risk analysis (TRA) for any customized control, and then they need to test and monitor that control.
That information from the assessed entity then has to be provided to the QSA assessor, and that QSA assessor reviews that in evidence, that targeted risk analysis controls matrix, and then we have to develop custom testing procedures to validate that control meets the intent. And then we actually test that control. So there’s there’s a different approach for that, but there’s additional documentation needed as well.
So what exactly is this targeted risk analysis I mentioned?
A targeted risk analysis is something that’s also been introduced in version four point o. There’s also a template for that in one of the appendices.
On the right hand side, you’ll see all of the different information that is required to be included in a targeted risk analysis template.
One of the things that also got introduced is the term mischief. So mischief in PCI DSS 4.0 refers to the occurrence of event that negatively affects the security posture of entity.
So in the PCI DSS, you will see that there are now control objectives with the control objective that explains what that control is intending to prevent. The mischief essentially is if that control, it does not prevent what is intending to prevent, what’s gonna occur. Right? What happens if that objective is not being met? And so when organizations are documenting their targeted risk analysis for 4.0, they’re going to have to think about that mischief. They’re gonna have to include how the control is designed to prevent it, how it would prevent the mischief, what would the likelihood of the mischief occurring change to.
And we’ll all we will also see an a new addition to an analyze changes of the impact of unauthorized access to cardholder data. So they actually want us to think about if this mischief occurred, how much credit card data could be impacted by that. Right? So that’s something very new in the DSS.
And all of the targeted risk analysis that’s done for an organization has to be approved and reviewed by executive management. So they wanna make sure people have this oversight with the targeted risk analysis that’s being documented.
One of the other changes we saw with the PCI security standards council this past couple years is that PA-DSS, the payment application data security standard, was retired in October of twenty twenty two.
That standard is actually being replaced with two additional standards related to secure software framework. So there’s a secure software life cycle standard and a secure software standard.
Similarly to the PA DSS validation and those applications, it doesn’t the PCI DSS does not require you to use one of those, but if you do, it can help with your compliance objectives. Right? So secure software standards can actually help with three specific requirements in section six to show that you are in compliance with those already because you’re using that validated solution.
So the they’ve replaced one standard, introduced two others, and then tied it back to the PCI DSS in a in a similar way. It’s not required to be used, but it can help with your compliance if you are using a validated solution.
For before we jump into each section by section requirement changes, let’s give you an overview of what we’re looking at.
So there were sixty four new requirements added in PCI DSS v4. Fifty three of those apply to all entities. It doesn’t matter if you’re a service provider or a merchant.
Eleven of those are only applicable to service providers.
Thirteen of the sixty four are applicable immediately.
So that’s actually gonna be one of our next, sessions in this webinar series is looking at a deep dive of those thirteen requirements.
And then fifty one requirements are the ones that are effective March twenty twenty five. So that will also be one of our webinar sessions looking at those requirements.
Just about almost every PCI DSS requirement was impacted somehow with this change. It was either updated, moved, adjusted, clarified, removed.
There was a lot of verbiage changes in the DSS, so people definitely need to look at the details in there.
One of the things that we also saw consistently throughout is that each section one through eleven has a new roles and responsibility requirement.
So similarly to how we had operational security peep procedures required for each of those session sections, now we have roles and responsibilities also required for each of those sections. So not only do we need to know the documentation, but who’s responsible for that. That actually makes up of eleven of those thirteen new effective immediately requirements.
Alright. So let’s dive in.
Section one had significant verbiage changes. So, if you remember, section one previously said firewalls and routers for most of the controls.
They’ve replaced that term with network security controls.
They added some explanation of what those security controls may include to expand on what we’re seeing in the industry and in the in in use cases today. Right? It’s not just firewalls and routers anymore.
Then like I mentioned, section one has a new roles and responsibility requirement.
After that, they expanded some of the configuration and review requirements to ensure that we’re looking at everything we should be looking at, not a narrowed view. Right?
So the first change there is making sure that our network security control changes tie back into our change management process in section six. So now there’s alignment between those two those two areas of, the DSS when it comes to change management.
Next, they expanded on the rule set review requirement on a biannual basis to say that not just rule sets, but all network security control configurations need to be reviewed on a biannual basis.
Configuration files for network security controls also need to be secured and kept consistent with active configurations.
So this replaced the synchronized and secure router configuration files with all network security control configurations.
Pretty significant wording changes there.
In requirement two, we see that some additional clarification and wording changes like we saw in requirement one.
One of the major changes there is that this doesn’t just apply to vendor defaults. Right? So the the title of the whole section got changed to make sure it’s secure configurations for all system components. Of course, we have the new roles and responsibility requirement.
And then we also now have a distinct call out to make sure that configuration standards account for new vulnerabilities that are identified.
So tying it back into your risk ranking process in section six.
And now they have, some explanations, some additional guidance that if there is a need to have multiple multiple primary functions on the same component, you can do that if those security levels are at that highest security need. Right? So you can combine functions as long as you’re at the highest security level rather than having just the one primary function per component.
The other thing to note about section two is there was some movement of requirements. So the inventory of system component inventories for what’s in scope for PCI got moved into section twelve and taken out of section two.
For section three of the DSS, we see that we’ve expanded on the term of cardholder data to account data to cover not only cardholder data, but sensitive authentication data as well.
I did mention that not every requirement can be used with a customized approach.
There are seven requirements in version four that you cannot use the customized approach with, six of which are in section three. So and the majority of those requirements around protecting account data and protecting sensitive authentication data cannot be approached through a customized approach method. They have to be validated through the defined approach method.
If something cannot be validated through the customized approach, it actually says that in the customized approach field for that requirement, so you can easily tell.
Also, in section three, of course, we have a roles and responsibility requirement.
Then we have some additional new requirements that are best practices and until March of twenty twenty five. So there’s quite a few of those actually.
They want to they added a requirement to make sure that any sensitive authentication data that is stored pre authorization is also encrypted.
So that is something that will have to be addressed. It’s pre it’s, again, a best practice until March of twenty twenty five.
But we have some additional requirements to consider here too. If hashing is used to render pan unreadable, they now must be keyed cryptographic hashes.
And with technical control, now we’re gonna need to actually have a technical control that prevents moving or copying of cardholder data via remote access technology. So this actually used to be in the acceptable use requirement, but now we’re gonna actually have to have technical controls to prevent that move.
Then they explained that disk encryption is not sufficient for nonremovable media that is storing cardholder data. So if you’re storing cardholder data on something that is nonremovable media, this encryption will have to be augmented with another type of encryption to protect that cardholder data as well.
Then they go on to explain that service providers cannot use the same encryption keys in production and test environments.
One of the things I’ve noticed with all of the changes in the different versions of the DSS I’ve seen is anytime that they add a new requirement that’s only applicable to service providers, there’s a good chance that might become a requirement that’s applicable to everybody in the future. So take note of that.
The other thing to know about version or not only version four, but also section three is the truncation rules have changed.
So a couple years ago, it was, it became known that bank identification numbers, that’s what the BIN stands for. It’s the beginning portion of the credit card. Those started running out, so they had to expand BIN numbers, and so they had to change the trunking rules. So the PCI security standards council actually released a new FAQ on this topic, and then the masking rules have changed as well to say no more than the BIN and the last four digits.
The whole masking truncation rules got a little confusing because each card ran had their own rules. So I believe that’s why the council came out with a frequently asked question article on it. So if you have additional questions on there, that’s a really great great reference to look at.
The other thing to keep a note is anytime you see one of these green dollar sign, highlights, it’s because we anticipate that there might be some additional cost that organizations are gonna be looking at. When we’re talking about new technical controls, that might be something that we’re not currently budgeting for or currently have in our toolset, right? So we need to be able to plan for those items. So please take note for anything that has that green highlight that might indicate that there’s gonna be an additional cost to implement that control for you.
For version four, we did see some updates in here as well.
Of course, new roles and responsibility requirement.
But then we also saw some additions around certificates and trusted keys and certificates. So first, they wanted to make sure that any cardholder data transmission that’s over open public networks, it’s still open public networks, must be valid certificates and must be trusted and issued from a trusted source cannot be expired. So now this is all being explicitly called out.
Also, in in line with that, they want to make sure organizations have a good inventory of the trusted keys and certificates that they use to protect credit card information over transmission.
If we don’t know who all of the trusted keys and certificates we’re using, it’s hard for us to keep track of when they are gonna expire or if we need to replace them.
Four two one also added some additional guidance around receiving cardholder data that’s not expected and how you would deal with that as a one off basis and potentially have an incident, a small incident response process to eliminate that or pull that into scope, as well as providing some additional guidance around self signed certificates and when those could potentially be used if they were secured properly.
For requirement five, we also saw some new March twenty twenty five requirements coming there too. So, of course, we start off with our new roles and responsibility requirement.
But in requirement five, we also have our first targeted risk analysis requirement.
Remember how I mentioned the targeted risk analysis had to be used for any control that you’re doing the customized approach for? Well, there’s another use case for it in version four.
Targeted risk analysis will now be required for any PCI DSS requirement that has a periodic cadence that is applicable to the organization.
So one of the things in requirement five says if if we do if we have previously, it said, if we have systems that were not commonly affected by malicious software, that’s been replaced with not at risk. So if we have components that are not at risk for malicious software, then we can determine if those components still can be okay and secured without anti malware.
Whenever we see a periodic cadence requirement in version four, we now need to create a targeted risk analysis to justify that cadence.
So that is the first time that we’re seeing that come up in DSS 4.0’s in section five related to the not at risk components.
If you are using some anti malware software already for all of your components, even if they are at risk or not, then you wouldn’t need to do that targeted risk analysis because you’re you’re addressing that requirement with the previous requirement. So it just depends on the applicability for each organization.
They’ve also introduced an option for continuous behavioral analysis. So they haven’t said that you have to use continuous behavioral analysis, but it’s now an option to do that rather than, you know, weekly scans.
They’re also requiring anti malware for removable electronic media and anti phishing mechanisms. So not training around anti phishing, but anti phishing mechanisms to actually prevent phishing.
As you can imagine, the anti malware for removable electronic media or the anti phishing mechanisms could potentially come with an additional cost to the organization.
As you probably noticed as I was speaking about this section, antivirus was replaced with anti malware.
The requirement six, we also see some additional best practice requirements until March of twenty twenty five and some potentially significant ones.
So first and foremost, roles and responsibility requirement.
Then we have to now create a bespoke and custom software inventory.
So any software the organization uses as part of their cardholder data environment now needs to be part of our inventory.
We also see that there is a change coming with the existing six point six requirement.
Currently, if you have a web application that is, being used and in scope for PCI compliance, it can either have a web application firewall in front of it preventing malicious attacks, or you can use web application penetration testing.
In March of twenty twenty five, all organizations will be required to use a web application firewall in front of those public facing web applications.
The an additional new requirement in section six is related to payment page scripts.
Now by March of twenty twenty five, organizations will have to be using something to monitor, authorize, manage, and inventory all of the payment page scripts they use. So that is something that is gonna be introduced new for any organization that has a payment page script. Think an ecommerce site. Right? Those are payment pages.
Those scripts have to now be authorized, managed, and inventoried.
A lot of the section six requirements were reorganized.
There was additional guidance and clarification around separation of rules.
They also explained that people can actually test with live credit card numbers if that preproduction environment is in scope. You notice I said preproduction rather than development and test. That is a verbiage change they also made in section six.
Section seven, we saw some interesting new additions in as well. So, of course, new roles and responsibilities.
But then we’re also getting some account reviews on a certain cadence.
First and foremost, user accounts and privileges will have to be reviewed on a biannual basis for any in scope components.
Now we’re also seeing the the addition of application and system account management in the PCI DSS.
Previously, most of the PCI DSS only applied to employee accounts, user accounts for that environment rather than system or application level accounts. That will be changing. You’re gonna see a couple requirements in here as well as in section section eight related to how those application and system accounts are going to have to be managed and reviewed periodically.
They also did a nice job of adding additional guidance around explaining what types of user accounts, these controls apply to and which types they don’t apply to. Something they made very clear is the difference between consumer facing accounts and customer accounts. There’s always some confusion for third party service providers if their clients are customers.
Right? In this case, they would be considered customers, not consumers. And so when those requirements talk specifically about those types of accounts Hello.
Now there’s some guidance related to that.
Yeah.
Now I’ll just let you know.
For section eight, we’ve had quite a few additional March twenty twenty five new requirements coming. Honestly, the only one that’s applicable right now that’s new is the roles responsibilities requirement that’s in every section one through eleven. But the other requirements are all March twenty twenty five requirements because a lot of them are brand new.
We’re finally seeing a password length increase in the PCI DSS 4.0. It’s going to go to twelve characters unless that is not supported, and then it will be increased by one to eight characters.
And then service providers with nonconsumer customer accounts will have to start doing a ninety day expiration on those or use something like, dynamic analysis of access like zero trust.
Then we’re seeing an increase of multifactor authentication for all access into the cardholder data environment, so not just non console or administrative access.
So, of course, we anticipate organizations might have to do a lot more multifactor licenses than they might have now.
We’re also seeing some new requirements around how organizations should be protecting their multifactor implementations to ensure that those controls are not being bypassed.
Remember I mentioned additional controls around system and application accounts? Here they are.
System and application accounts with interactive logins have to be managed now. We can now hard code those passwords into for system and application accounts into code, and we need to have some way to, manage those accounts and rotate those passwords.
Right? So there’s quite a bit coming with the system application accounts.
When we get to requirement nine, we see that a lot of requirement nine had changes related to guidance around physical security and where physical security had to be applied. So one of the biggest things is they made a very clear distinction between facilities, the cardholder data environment, or a sensitive area.
A sensitive area now has a definition in the glossary. Another thing I love about version four is that the glossary is now an appendices in the actual DSS. So it’s not a separate document anymore, which is great and very handy if you’re trying to look something up.
The facility is actually defined in that overview section of the top of section nine, so where they have that additional guidance.
So besides those wording changes around the physical spaces, the biggest other change we see in requirement nine besides roles and responsibilities being added is that now we need a targeted risk analysis for our point of interaction device inspections.
That’s another periodic cadence requirement. So now there’ll be a targeted risk analysis needed for that by March of twenty twenty five.
Requirement ten also introduced some new, best practice controls until March of twenty twenty five. Of course, our roles and responsibilities to start, and then we see some changes. So first, they’re now actually requiring an automated mechanism to perform audit log reviews. So previously, for daily log reviews, they said you could use log harvesting, parsing, or alerting tools. Now they’re saying you need some automated mechanism to do this. And, honestly, it’s almost impossible to do it without some sort of automated mechanism. There’s so much log information out there that if you don’t know how to find those anomalies or suspicious events, it’s very, very difficult to miss it if you’re looking at all those logs manually.
And then if you have components that are not part of your daily log review, remember there was another requirement that said all other components do a log review on a periodic basis. So if there are components in your environment that fit into that category, that periodic basis is now gonna have to be defined by your targeted risk analysis.
Remember how I mentioned when they, you know, add a requirement in there for service providers, sometimes they you we see that that gets added for every organization?
That’s what happened with ten seven two and ten seven three.
So PCI service providers for several years now have been required to have a process to identify critical security control failures. If a critical critical security control failure happens, there needs to be a timely response process, a process that people go through after to document what happened and the root cause and what they need to do to prevent reoccurrence.
Previously, just just service providers had to do that. Now everybody will have to do that by March of twenty twenty five. So this new requirement is being added to expand that requirement to all PCI organizations, not just third party service providers.
Requirement eleven will be an interesting one for some. Roles and responsibilities, of course, were added.
There’s also a new requirement in here for internal vulnerability scanning. So internal vulnerability scanning currently says, use your risk ranking process, determine what are your highest risks, address those to achieve a passing vulnerability scan report.
Now they’re saying all other vulnerabilities will have to be addressed based on a targeted risk analysis for internal vulnerability scanning.
So that is something that will be required by March of twenty twenty five.
And the next one might be a bit of a doozy for some.
Internal authenticated vulnerability scanning will be required by March of twenty twenty five. If organizations are not aware of this, please be aware that when you authenticate your internal vulnerability scans, that means you’re essentially giving that vulnerability scanner credentials to those components. It typically finds more vulnerabilities than it previously had. This is a March twenty twenty five best practice requirement, but since it’s related to vulnerability scanning as the previous one, if the validation is three, six months after that, you would be expected to have that control in place by March of twenty twenty five and be able to show recurring evidence of that. So please be aware.
Shared hosting providers in the PCI DSS were renamed to multi tenant service providers. So that next requirement in section eleven talks about those multi tenant service providers supporting their customers’ external pen testing needs. So if you’ve ever had a an issue with that with one of your shared hosting providers, this requirement should help alleviate some of that that concern moving forward.
In line with that, third party service providers (TPSPs) are getting another new requirement.
So they are going to have to have some sort of intrusion detection, intrusion prevention, or other alert and preventing mechanism to address covert malware communication channels.
Again, I suspect this is something we will see that gets expanded to all organizations in the future.
So something to be aware of that third party service providers will have to have this in place by March of twenty twenty five, but that may mean that it’s coming down the road for everybody else as well.
And then the last new requirement in section eleven relates again to payment pages. So based on the PCI security standards council’s best practice eCommerce guidance from twenty seventeen, they were explaining back then that organizations that are using a third party service provider for outsourcing ecommerce need to make sure that that integration does not change without authorization.
Instead of just having that be guidance in a best practice document, it’s now gonna be a PCI DSS requirement once we get to March of twenty twenty five. Organizations will have to be able to detect and report changes to payment pages, have those controls in place to prevent those things from changing without authorization.
That is another one that we might anticipate seeing some additional cost with. Right?
And requirement twelve.
As you can see, there were a lot of changes to requirement twelve.
To start, there’s no rules and responsibility requirement in requirement twelve. Those are just in requirements one through eleven.
But the first thing we deal with in requirement twelve is targeted risk analysis. So as we’ve talked about, the periodic cadence requirements will all require you to maintain a targeted risk analysis (TRA) for justification of that cadence.
Then organizations are gonna have to actually have a cryptographic agility process.
What that means is organizations should know what they’re using for cryptographic cipher suites, should understand what protocols are in use and should be monitoring industry trends for changes to those, to make sure that they are ready to address those. Remember the whole, we need to get off of us to sell an early TLS and how that took years. This is where I see this coming in, right?
They’re trying to get organizations to think more proactively of these upcoming changes.
Along the same lines, they’re wanting organizations to do a better job of making sure that we’re monitoring the hardware and software that we’re using and how long our vendors are gonna support that, right?
A lot of organizations end up in situations where their software or their hardware has reached end of life and they haven’t had an opportunity to, to replace it yet. And now it can potentially become a compliance issue if there’s a vulnerability associated with that. So they’re trying to get organizations to be more proactive, be tracking this information so they can plan ahead to make those changes. That is something that if an organization is not currently planning to have a maintenance plan to replace equipment and software, this might come at an additional cost. So something to be aware of.
Then again, if you ever use the targeted or the customized approach to address any individual requirement, you have to have a targeted risk analysis for that as well. But that’s not a March twenty twenty five requirement. That’s a new right now requirement.
12.5.2 is probably one of my favorite new requirements.
Every organization is now going to be required to document and confirm their PCI DSS scope at least annually before somebody like myself walks in to validate that environment.
I think this is so important because organizations go through changes on a regular basis. And if we’re not keeping track of how those changes impact us, or if they’ve changed scope or if we’re now doing something that we didn’t account for before, when it comes validation time, we’re often scrambling, right?
How organizations determine this practice for them and how they’re gonna best do this, I think is something that it’s gonna probably come as part of that transition and probably mature over time.
There’s organizations we work with now that survey different departments on a regular basis to see if anything’s changed. That might be a good option as a starting point, But they they the PCI DSS does a really nice job of giving you some guidance around the things you should be considering or things you should be looking at when you’re confirming your scope and documenting that scope.
In line with that, third party service providers are gonna actually have to do that twice a year starting March of twenty twenty five. Not only do they have to do that annually, but it will become a biannual process for them.
They will also have to, make sure that if there are any significant changes to their organizational structure, that actually initiates an additional scope review.
Okay? So I I think that’s a a key factor there too. We’ve all seen a lot of change over the last couple years. And when when people don’t know in their new role that they have new responsibilities that they’re accountable for, sometimes processes break down. Right? So having a check on that scope review or making sure that people are involved and aware of the piece that they need to be, I think is is gonna be really helpful there.
They also want organizations to actually review their security awareness training materials on an annual basis and update those. As, you know, the industry changes daily, I think that’s a great idea to keep that up to date.
One of the things that, they’re also we’re gonna require organizations to do is make sure that their security awareness training deals with social engineering threats and phishing attempts. So that’s also a great practice to have our employees be continuously being trained on that information as it’s changing constantly.
And then they wanna make sure that your security organized training includes acceptable uses for that end user technology.
Pretty straightforward, but they’d have they never actually tied those two things together previously.
12.9.2 is also a new nice new addition. So organizations that have potentially struggled in the past to get compliance information from their third party service providers, your complaints have been heard by the council.
They added a requirement in here to ensure that customers’ request for PCI compliance status and responsibility is something that third party service providers actually have a requirement for. So they are actually required to help facilitate that information and that conversation.
Then we see some additions and some changes to the incident response plan. So if for the for the incident response plan, there is a requirement in there for periodic training of your incident response team. Of course, periodic means targeted risk analysis. So we’ll need to have a targeted risk analysis for that cadence.
And then because we’re adding additional controls around tampering around payment pages, they also wanna make sure that if there’s an event associated with that, that will trigger the incident response plan. So just tying those things together. And then they also provided some additional guidance for organizations that receive unexpected credit card data to make sure that they have some sort of process to deal with that. Right? Typically, if you see receive something that you don’t expect, if you can clean that up, you don’t necessarily have to pull that into scope, but you need to make sure that that gets fully addressed and is documented and is confirmed and approved and overseen.
Alright. The other one that we anticipate might be a little costly for people, not only the hardware software review, but the security awareness training being reviewed annually and potentially including phishing and social engineering as well if that’s not something that is currently part of your training.
There are also some changes to appendix one for multi tenant service providers. So they did include some logical separation between the provider and the customers.
They also confirmed some logical controls between customers as a new requirement, and then they also added some additional reporting to address suspected or confirmed incidents.
So let’s talk a bit about the overview of changes to reporting in general.
The report on compliance and attestation of compliance sections are now aligned.
So if if you ever notice, they’re they were similar but not exactly titled the same, not numbered the same. They’ve aligned all of those sections now, so it’s gonna be easier to align that information for yourself.
They’ve also done the same thing with the self assessment questionnaires (SAQs). So the self assessment questionnaires and the attestations of compliance sections have also been aligned.
And now one of the things I absolutely love is that self assessment questionnaires actually use actually use the data security standard text. Previously, self assessment questionnaires had a question that was supposed to represent what the DSS was asking.
Typically, the question was a bit of a more high level question, didn’t have all the details. So it can be very confusing if you’re looking at the DSS and then the self assessment questionnaire.
They also added a new section for remote assessments. I think they realized that those probably weren’t gonna go away.
And then they expanded the executive summary section significantly.
So in the raw reporting template, there’s a lot more detail being asked for upfront, more ways to track documentation, evidence that’s collected, all the samples that people review, all the interviews and observations that are conducted.
And so what they’ve really done is pushed a lot more information to the executive summary of that report. And then the intent is when you go to actually report on the requirement itself, there’s one write up for each requirement. And then the rest of what you’re doing in that write up is just referencing sections from those above tables.
So the reporting has shifted considerably.
There are no new self assessment questionnaire types. The types remained the same. So we have the same types that we had in three two one, same exact letters, type, numbers, all of that.
Now the self assessment questionnaires also expanded their executive summary sections, but not to the degree the report on compliance did.
One one of the things to be aware of is as a cell as as a third party service provider for PCI, even if you are self assessing, you are now gonna be required to do a write up for each requirement to explain how you got to that finding.
During the development of 4.0, at one point, the PCI security standards council had floated the idea of removing self assessment questionnaires for service providers and requiring them all to get on-site assessments and reports on compliance.
There was quite a bit of pushback on in the industry, and so they backed away from that a little bit.
So they are lending service providers and still validate with the self assessment questionnaire if they’re a level two, but there’s quite a bit more that will be required of those third party service providers to explain how they determine that that compliance or that that requirement is in compliance.
Like I mentioned before, when you are using a self assessment questionnaire, you do not have the option of the customized approach. So the self assessment questionnaires will not even include the customized approach objective. You will only see the customized approach objective in the DSS or the rock itself.
Some other updates related to 4.0.
Remember how I said v4.0 was published in March of twenty twenty two? Well, it was. And then this year they published new versions in 4.0. Initially they came out with a new status called in place with remediation that has been removed. There was again quite a bit of pushback in the industry.
The PCI security standards council has explained that for QSAs doing on-site assessments with organizations, they would like to have an in place for remediation worksheet that QSAs filled out and provided to that organization.
The intent of that in place for remediation status is if a process broke down, think one of those cadence requirements we talked about. If that process broke down and when somebody came in to do the validation, somebody wasn’t able to show that it that process was working the whole year, but they were able to fix it.
That’s when you would use in place for remediation.
Right? So it’s not, you know, a small, oh, you forgot to update the date on a a document. It’s intended for process breakdown. It’s intended for best practice active or business as usual activities that were not conduct conducted at conducted as expected.
We haven’t actually seen the release of that in place for remediation worksheet. They were expected to release it, I believe, in Q1, but we haven’t seen that come out. So I would anticipate that would come out fairly quick. And the intent is that it’s not shared with third parties, but it’s shared with the organization being assessed. So their upper management, their executive management, the people accountable for PCI compliance know that there was a process breakdown and can be aware that something might need to be adjusted to prevent that from happening again.
The 4.0 transition training is now available to PCI QSAs.
If a PCI QSA has not completed the 4.0 transition training and taken their test, they cannot work on any four point o assessments. So So if you’re working on a PCI with a PCI QSA and you want to do a four point o assessment, you need to confirm that they have validated that they have completed their 4.0 transition training.
There will there is some additional 4.0 training available to ISAs and PCIPs, but I’ve heard from some of my clients it’s not as extensive as what we’ve received.
So if if you ever have questions, please don’t hesitate to reach out to a QSA. They have quite a bit more training on on this stuff than than we’re seeing in some of the, more high level details that are being provided.
We thought that requalification training would be available this year against 4.0, but it and from from conversations with the council, it looks like it’s gonna be in twenty twenty four that requalification training will start to be against four point o. So if you are still requalifying as an ISA, QSA, or PCIP this year, you can still do it under 3.2.1. It’s probably gonna be a good idea to go through one of those transition, education presentations from the council before you sit for your requalification in twenty twenty four. Otherwise, you will be looking at a brand new training brand new training material.
One of the things to, be aware of, if you are a PCI merchant that validates their compliance through a portal that maybe your financial institution gave you access to or suggested or uses to manage their PCI DSS compliance, that we have seen some of those portal providers switch to the new versions of the data security standard that’s been released prior to the deadline.
So like I said, I’ve been doing this a while. I’ve I’ve been through a few PCI DSS, transitions over my years. And I’d say, typically, about seventy five percent of the time, some of those portal providers transition to that new version prior to that deadline being reached. So keep an eye out. If you are in touch with that vendor, you can always reach out to them and see if they have a timeline in mind. I would expect that you would receive your communication from them when that is going to occur as they try to communicate that with their users.
And then one of the things to be aware of, if you are using a third party service provider for PCI compliance right now, whether that’s for outsourced ecommerce or cloud infrastructure or platform as a service or even a software vendor that could potentially have software that’s part of, you know, PCI certified secure software framework or secure CLC.
You need to make sure that when you’re planning your four point o transition efforts, you’re taking into consideration what those third party service providers are doing and what their responsibility might be.
A lot of organizations are still transitioning to 4.0. Some organizations are still figuring out how that impacts them.
If you’re currently heavily reliant on a third party service provider, you want to understand what they’re gonna see as their responsibilities and what you’re going to see as yours.
Some of that information you might not be able to determine until your third party service provider does their own determination.
Right? So something to keep in mind for any outsourced clients out there that you’re gonna wanna get new information from your third party service provider about what responsibilities you have as their customer if you’re using their outsourced services.
Okay, folks. Does anybody have any questions they’d like to ask?
Everybody is muted. So if you have a question, you can just go ahead and unmute your unmute your mic.
Hi, Viviana. This is Justin Evans from the University of Iowa. Got a quick question for you here.
How can something like a targeted risk assessment be used to identify scope reduction opportunities and make, you know, the transition to four point o more efficient for your organization.
Yeah. And, you know, the interesting thing is the the way that the council adjusted risk analysis for the PCI DSS 4.0 public publication is they’re really focused on what what’s a justification and a defensible stance for when you determine a periodic cadence and if you’re using the customized approach.
The PCI security standards council kind of removed the enterprise level risk assessment in doing that. And so organizations when they’re looking at, potentially outsourcing or looking at PCI scope reductions, essentially they have to think about what is that scope production going to do? Is that really gonna benefit me? Is it gonna reduce my risk? Is it gonna potentially reduce how much cardholder data would be exposed?
Is that too burdensome? Is it gonna be too expensive for what I will gain? Right? So that that actually takes us back to kind of a Duty of Care Risk Analysis (DoCRA) method that we always like to use for everything.
We like to make sure that when we’re thinking about risk, we’re considering not only the impact to us, but the impact that that risk would have to our obligations, the organizations that we work with, the people whose information we have. Right? And so anytime we’re thinking about, should I do this? Is it gonna benefit me and benefit my users by reducing the risk to their information?
We always like to do a balance test. We like to make sure that whatever control you’re looking at is not too burdensome, but it’s also gonna appropriately reduce the risk you’re trying to reduce.
Thanks, Justin. That was a great question.
Yeah. Thank you.
Any others, folks?
I just wanna add, in the interim here that, under the Q&A section, I went ahead and added the link for session two, which goes into the DSS requirements applicable immediately. So if anybody wants to sign up for that who hasn’t already, it’s available there.
Thank you, Rachel.
Hey, Viv. It’s Fran Spinoso here from LSI. I sorry. I’m just jumping in. How are you?
Can you expound a little bit on twelve nine two where it’s saying that we’re required to facilitate the status updates of our PCI compliance to our clients. Is what, like, would be the expectation here?
So, unfortunately, I’ve had the the fun experience of working with clients that when they have reached out to third party service providers to ask them for compliance information, they just get no response or it’s it’s very difficult to engage in that conversation or get the right people on the line to have that discussion.
Essentially, what they’re looking for here is making sure that as a third party service provider, your organization has awareness that when customers customers make that request, you should respond in a in some sort of timely fashion. You should help provide whatever information’s necessary.
You should explain what responsibilities you agree to or be willing to look at that responsibility matricy and and ensure that it covers both organizations.
In all honesty, they they didn’t give any very direct specifics of how they expect organizations to do this. I think the intent here is that people are cooperating and working together and trying to do their best to come together to make sure that payment data is secure. Right? It’s, it’s really just being willing to work with each other on it.
Okay. So maybe a good idea to kind of, track or log any requests coming in and just keeping any documentation that you’ve shared, is sort of a good way to meet the spirit of that control.
I believe that that would be above and beyond, but I think that would be a great way to meet the spirit of that. Because if you’re ever asked to show proof of that, you absolutely can. It’s easy to say, yes. We do that. But if you’re not tracking it and you don’t have those metrics and measures, it’s it’s hard to be able to confirm that that’s being done. So I love that idea.
Great. Thanks, Viv.
Of course.
Hey, Viv. This is Justin again. That last question just, sort of sparked a thought. Do you happen to have any, suggestions for, like, risk tracking tools or applications that can help organizations, you know, identify those areas that they need to, you know, communicate with, other organizations with or just track their risks overall.
Yeah. And and, Justin, when when you mentioned that, I mean, I I think of two different things. Right? Because I unfortunately, I think we’re in the day that everybody has seen that third party vendor management has become a very difficult thing for organizations to do in an easy way, right? No matter what, a lot of organizations have a lot of different business partners and vendors. And I think part of this is managing your third parties in a way where somebody can track that communication.
And if you’re not receiving the information you expect from those third parties or from their security questionnaires or however you are doing that vendor management, then also having a way to track those risks. And so I actually do think that those might end up being two separate types of tools, right, in the sense that you might be using something for risk management tracking or risk identification, but that might not necessarily be tied into your third party vendor management solution, and that’s okay. As long as you have a way to identify that risk and then, have a way to follow-up on that risk.
And, of course, yes. I mean, HALOCK uses a Reasonable Risk tool that we, of course, would recommend for something like that.
Thanks, Ken.
Of course.
Hi, Viv. Quick quest actually, probably two questions. This is Joe Espinosa from Orrick Sutcliffe and Harrington.
In in turn well, first off, have the, the new SACS been released and published yet?
Yes, sir.
Okay. And do they do they require targeted risk assessments, for the applicable requirements as well?
They do. So if if that self assessment questionnaire includes requirements that have a periodic cadence, then those requirements would have to have a targeted risk analysis.
However, since those self assessment questionnaires do not allow you to do any customized approach validation for requirements, that targeted risk analysis requirement will not be in there.
Okay. And then so follow-up with these with these targeted risk assessments that that need to be done.
Are these are the is the acceptance of these should they should they be accepted in the same way that, like, a privacy based risk is assessed? Like, should our general counsel be reviewing these to make sure that they are designed and written out in a way that that puts the the organization into a defensible position?
That’s a great question. From a PCI DSS perspective, they didn’t specifically call out general counsel. But what they do call out is there is a requirement to have oversight and accountability for PCI compliance at the executive management level, and those targeted risk analysis are required to be reviewed and approved by executive management.
Now, I mean, as as Joe can probably tell you since he works for a law firm, it’s always a good idea to involve general counsel and anything like that. Right? Especially when you’re talking about risk analysis or a defensible stance when it comes to compliance. So I I agree there.
Okay. Thank you. Of course.
I guess, you know, another quick follow-up then too. In terms of of scoping and applicability of the DSS, there hasn’t been any changes in terms of what they’ve defined as cardholder data or what would be in scope in terms of what’s defined as a connected system or connected process.
I love that you brought this up, Joe, and I think it’s because you and I had a chance to work together and you know how important scoping is for PCI compliance.
So Just a little.
Yeah.
So the scoping rules have not changed.
What they did do though, is they absolutely added more guidance, more examples, more, you know, lists of what that potentially could mean. So they’ve always said that, you know, system components means this list of computing type devices. They expanded on that what that system component list meant. Then the rules of anything that stores, processes, transmits, cardholder data still comes into scope.
Any connected systems. They did explain the connected systems or systems that have unrestricted network traffic. So they did expand on that verbiage a bit, and then any systems that manage the security of the environment. So that section of the DSS definitely had a lot of guidance added to it. But if you’re looking at what they say comes into scope and if that’s changed, it really hasn’t. They’ve just added more clarification and guidance around what that should mean.
Okay. Great. Thank you.
Of course. Okay. Well, if there are no more questions today, we thank you so much for oh, yeah.
Go ahead.
Yeah. I’ll throw one more. I have because I haven’t seen the template yet for, what is it? E two in the, in the rack. But, I mean so in terms of the targeted risk assessments, can we just leverage our own I mean, inputs or put some of our own inputs into the template from our firms, or the organization’s risk assessment framework? Are these things that need to be, reassessed in in the context that the DSS wants us to, or is this something that we can leverage DoCRA for as well?
So it’s definitely something you can leverage DoCRA for. Absolutely. We are actually working on a targeted risk analysis template that is in line with DoCRA.
Because Joe brought this up and because I just happen to have 4.0 on my desktop, I decided to pull it up. So it like he mentioned, this is section e two of the PCI DSS 4.0. And here’s the thing, You absolutely can do this in a way that it is using your existing risk assessment methodology, but you need to make sure that when you do that, you are also including the fields that they’re specifically asking for.
So we can’t just ignore the PCI security standards council’s template and use our own methodology. We essentially have to combine what they’re looking for with your our existing methodology, and that’s their approach we’re gonna be using as well. So we are working on a target targeted risk analysis template using DoCRA, and that’s actually gonna be one of the webinar series we have coming up in May.
So it does talk about identifying the requirement, describing the proposed solution, and then it gets into the analysis of any changes to the likelihood of the mischief occurring leading to a breach in confidentiality of cardholder data.
So this is their sample template, goes on to have an analysis of any changes to the impact.
And then as you mentioned, Joe, the risk approval and review.
So all of this is in here, and how you how you include that information, they didn’t say you have to use this template and you can only do use this template, but these fields that they’re asking for have to be in any targeted risk analysis that you do for four point o.
Okay.
And I assume that mischief would just be equivalent to the threat or the intent that the requirement is trying to, the the threat that the intent of the requirement is trying to prevent. Right?
Depending on the day, I think it’s the threat. I think it’s the vulnerability. I think it’s the risk.
Essentially, the when when I when I think about the term that they are now using as mischief, I I see the easiest way to kinda think about it is the opposite of the control objective.
So if the control objective is malware can’t be run on a you know, can’t be installed, now malware is installed.
Okay.
It’s the simplest way to explain it, I would say.
That works. Thanks.
Of course.
Any other questions?
Okay. Well, thank you all for attending our first 4.0 webinar series. We look forward to sharing additional information with you on 4.0 in the coming weeks.
And please never hesitate to reach out if you have additional questions. We are always happy to help.
We hope everybody has a great day.
