Preparing for PCI DSS v4.0 Assessments

Transcript

Brandon Breslin: Good morning, everybody, or good afternoon, depending on where you are. Thank you for joining our webinar. This is for preparing for PCI DSS version 4.0 assessments.

My name is Brandon Breslin. I’m overseeing our PCI practice here, PCI practice lead for our team of QSAs. And then we also have John Barbier.

I’ve been doing PCI assessments since 2014 in numerous different industries, healthcare, financial services, retail, traditional retail, e-commerce, and government space as well. So I’ll pass it off to John to let him introduce himself as well.

John Barbier: Hi, I’m John Barbier. My background is in hospitality. So I worked for many years within hospitality, hotel, and travel environment. I’ve been a QSA since 2015, done numerous assessments across different industries as a QSA and happy to be with you today.

So today we’re going to be speaking firstly on how we got to version 4.0 and why we’re moving from PCI 3.2.1. We’re covering the goals of PCI DSS version 4.0 and what the pros of the new requirements are. We’ll speak about new approaches to doing assessments and what the new requirements are briefly.

And then we’ll speak about the steps to move to version 4.0 for organizations. We’ll touch on how CompliancePoint can help you. And then we’ll have a Q&A session at the end.

Brandon Breslin: I’ll give us some background on who we are at CompliancePoint. So John and I are both in our Security Assurance group, but our company as a whole, we are a professional and consultative services firm, so a consulting firm. We are based in the Atlanta area. Our focus is privacy, security, and compliance.

We’ll talk about this more in a little bit, but our focus is security first and compliance as a byproduct of that. They go very hand in hand as a consulting partner, if you will. We’ve been out in the market since 2004, and specifically offering risk assessments, consulting and implementation of processes, and compliance assessments as well.

So this is our area of expertise. I won’t go through each of these specifically. We’re obviously talking about PCI today, but these are the other services that we offer. Outside of the PCI group, we can assist you in any of these areas as it relates to compliance, security, privacy, and risk.

John Barbier: PCI 3.2 and then PCI 3.2.1, they’ve been around since about 2015, 2016. And since then, the payment industry has undergone some significant changes. So we’ve had new technologies emerge, cloud computing become more mainstream, there have been developments in mobile payments, and also the threat landscape is also involved. So there are new, more sophisticated attacks being developed all the time.

And PCI 4.0, we really needed something that addressed the changes so that the standards still becomes effective in protecting cardholder data.

Brandon Breslin: Yeah, John, I completely agree with you on the hurdles with version 3.2.1. How would you say some of those shortcomings of 3.2.1 are addressed within 4.0?

John Barbier: So 3.2.1 tended to focus on prescriptive requirements. So they told you what you should be doing and how you need to go about meeting those requirements. And this made it difficult to adapt to new technologies.

One example of that is in passwords. So some time ago, the password requirements changed. We learned a lot about what didn’t work, made some recommendations that couldn’t be implemented to the letter if you were sticking to PCI 3.2.1. PCI 4.0 is way more flexible and allows organizations to choose the best approach to meet the requirements based on their own specific circumstances.

There was also a lack of focus on risk management. In 3.2.1, if you did an annual risk assessment and you saved the document for the auditors, that was about as much risk management that was involved. Whereas in 4.0, there is a lot more focus on risk management as opposed to prescriptive requirements.

PCI 3.2.1 was a kind of a once-a-year assessment. PCI was something that was seen as something that you do when you start an audit and then you get the report and you put it to bed for nine months until the next audit. So the lack of security, security is a continuous process and compliance is a continuous process that’s been addressed by the changes to 4.0.

PCI 3.2.1 didn’t really focus on cloud computing. So 4.0 includes requirements for organizations that use cloud computing to process and store cardholder data. And then there was a lack of focus on emerging threats. So PCI 4.0 includes requirements for organizations to implement security controls to protect against these threats.

So Brandon, what are the new goals of PCI 4.0 and how are these relevant to the industry?

Bradon Breslin: Yeah, great question, John. So as we move to the next slide here, specifically for the goals of 4.0. So you can see there’s four goals out here. Continue to meet the security needs of the payment industry, promote security as a continuous process, add flexibility for different methodologies, and enhance validation methods. So let’s go ahead and dive into each of these. Specifically for continuing to meet the security needs of the payment industry.

We all know it’s constantly evolving, PCI DSS 4.0 includes updates to new threats and technologies and assets.

There’s specifically a few requirements that are related to this area, right, to address this pillar. New requirements for multi-factor authentication, stronger password requirements and options for flexible password requirements as well, password management, encryption of sensitive data changes.

It also addresses emerging threats such as cloud computing that John mentioned earlier on the last slide, and mobile payments as well. So promoting security is a continuous process. Version 4.0 emphasizes the importance of continuous monitoring and the improvement of security controls as it relates to specifically the new requirements there, requires entities to implement now a risk-based approach to security. This is a complete mindset shift of what it was previously in other standards from the PCI council.

So that is a good change that they’re moving towards as a continuous process there. It means that entities must regularly assess their risk and implement controls to mitigate those risks, right? So we all know the risk landscape is constantly changing, need to evaluate those risks continuously. And then also requiring entities to have a plan for responding to and recovering from security incidents. We all see in the news continuously that there are new data breaches out there all the time.

Like John mentioned earlier, compliance is not a one-time thing. It’s continuous. It’s always ongoing. Maintenance is always required. So flexibility for methods to achieve security objectives. This allows entities to choose the security controls that are most effective for their environment. So John in a little bit will touch on the options of customized approach instead of the previously only defined approach or prescriptive approach. Rather than using a one-size-fits-all, right?

So every organization that’s doing PCI is going to have a different approach that they do. Whether they’re working with a different QSA or doing it themselves, based on their organization they’re going to have to look at things in different lights. So that flexibility is crucial.

As it relates to the requirements, it’s important because entities have different needs and resources as well. For example, a small business may not be able to implement the same security controls as a large enterprise.

And then the fourth pillar or goal for PCI from the council is enhanced validation methods as it relates to ensuring that entities are meeting the security standards, right? So new validation requirements to help ensure that security controls are validated by a QSA on a more frequent basis. There are other options, which kind of bleeds back into the flexibility of targeted risk assessments, targeted risk analysis. We’ll get to that in a little bit.

Now let’s talk about where we are in the transition to 4.0. So as it relates to the timeline here specifically, you can see we’re on the later side of it. So obviously 4.0 is already out there. Specifically for us at CompliancePoint, we are already undergoing 4.0 assessments as many other QSAs that may be on the phone here are doing.

3.2.1 will be retired on 3.31, so March 31st of this upcoming year in 2024. The council has provided guidance out there that any assessment by 3.31.24 has to be completed by then if they’re doing 3.2.1. So for us at CompliancePoint, we’re already moving all of our assessments over to 4.0.

And then 2025 is the other big date to think about. So that is the future data requirements. We’ll get into some of the newer requirements in a bit. But specifically for 3.31, 2025, that is when the grace period ends for all new requirements. There are a couple of requirements that are immediately needing to be implemented that we’ll get to in a bit as well. But for most of the new requirements in 4.0, 3.31, 2025 is that cutoff for when those new requirements have to be implemented. So new technical controls, new operational controls there.

So John, to send it back over to you, before we talk about these new requirements, what should organizations do first?

John Barbier: So I think, firstly, organizations need to identify and engage with key stakeholders, so both internally and externally to the organization.

One of the changes is that the assessed entities need to identify and document your scope. So in the past, you may have depended upon the assessors to determine and confirm your scope. It is clearly the assessed entity responsibility. So that needs to be addressed right up front.

Understanding the new requirements. So you need to determine what new technologies or new controls that need to be implemented and identify where your shortfalls are and where you need to spend that effort.

Establishing roles and responsibilities. So obviously, assigning the responsibility to personnel who are going to be responsible for meeting those shortfalls.

And then understanding the timing of PCI compliance and the implementation of the version 4.0 standards.

So there’s some items that need to be implemented by March 31st of next year. Even if your assessment is only occurring towards the end of the year, those requirements need to be in place or have been in place since the expiration of 3.2.1.

There are items such as assigning roles and responsibilities to all personnel for all security functions. And we’ve mentioned annual documentation of scope. So that has to be done earlier than the rest of the requirements.

There are targeted risk assessments. And that is a new subject for PCI 4.0. Targeted risk assessments, you’re going to be, instead of doing one large risk assessment annually, the targeted risk assessment targets or identifies specific controls or areas within PCI.

And then you also use targeted risk assessments to document the frequency of performing certain functions.

And then you also need to decide the new option of a customized approach for assessments. So there’s entities who are going to want to take advantage of that. And you need to know what the options are and how the customized approach works.

Brandon Breslin: I can add some more clarity into these milestones as well, just to add on to what John mentioned. So as it relates, I’m just going to hit a couple of high points in each of these.

So as it relates to stakeholder engagement, getting senior and executive management right out of the gate is critical, right? So communicating often, early and often as well, engaging with the QSA. So John and I are both QSAs, compliance point as a whole, we are a QSA company. There are many QSA companies out there. We’ll get into a little bit later what we can do to help you guys as it relates to this transition specifically. But working with a QSA throughout the process is critical also.

As John touched on roles and responsibilities, having, that is one of the new requirements that has to be implemented right out of the gate in your first 4.0 assessment. So having those roles and responsibilities for each of the areas, right? Whether it’s somebody or a team dedicated to system hardening, patching, logging and monitoring, user access, logical access, whatever it may be, defining those key areas and defining who is involved in each of those key areas.

As it relates to reporting requirements, making sure that you are working with an acquirer or your customers to understand what your reporting requirements are so that you can work with the QSA and tailor the assessment to what needs to be done for reporting.

As it relates to the next bullet down there, the next milestone, documenting your scope. Assessing your environment against that scope, against the new requirements as well. So based on, because every organization like I talked about earlier has different needs, different resources, different goals and objectives.

So based on what your organization’s risk and security posture looks like and where you’re trying to move in the future, documenting that scope and assessing it against the new requirements.

Identifying, developing and implementing a new transition plan for 4.0 that can go along with the timing requirements of the new requirements for where the grace period ends in March 31, 2025, as well as some of the new requirements of the roles and responsibilities and the documenting scope.

Those are the two that have to be done immediately. But having a transition plan for all of the new technical and operational controls that have to be implemented by 2025.

As it relates to some of the documents and configuration changes that may be done, looking at everything holistically, right? That would be our recommendation. Everything from network architecture, applications, security policies and procedures, looking at everything from the ground up of what needs to be updated, what needs to be changed, what needs to be added based on some of those 4.0 requirements.

John talked about the targeted risk analysis process. That is a huge opportunity for especially the larger organizations where you may have more of a complex or different areas of risk that you have to evaluate so that you don’t have to follow that prescriptive defined approach. And then also the big key is the ongoing maintenance and then moving into the full compliance validation process, which would be the annual assessments.

John, to throw back to you, what is the customized approach and why would I want to use one and maybe some of the differences between defined and customized here?

John Barbier: The customized approach gives you the flexibility to use innovative technologies and approaches to meet the requirements. So if we take the example of the password requirements and the NIST guidelines that were published, entities had difficulty implementing the new recommendations and still remaining compliant with the requirements. So it allows entities to tailor security controls to meet the specific needs of the organization. It is really suitable for risk-mature organizations.

So I would imagine an organization that has a risk department that understands what the risks are to the data as well as what the threats are to the organization and can build effective controls around that.

So each eligible requirement has a control objective. So there are some requirements, I think there’s around eight of them, where a customized approach is not permitted. So for example, external vulnerability scans and storage of secure authentication data, that stuff that you’re not permitted to do or that are prescribed how you go about them. So they don’t have the option of a customized approach.

But where there is the option of a customized approach, it will list what the control objective is for the requirement. So instead of using the testing controls, the organization would design the control to meet the requirement objective.

There are prescribed templates that need to be used. So there are specific requirements or processes that you have to follow. You perform targeted risk assessment around that specific requirement or that specific control and you would document that targeted risk assessment. You’d collect the control evidence and your internal testing evidence and you would provide that information to the QSA. So the QSA would assess the effectiveness of the controls that you’ve designed and then the QSA would design and document the testing procedures for how those controls are to be tested.

So one of the important factors there is the independence of the QSA. So if you have a QSA involved in designing or testing the template or the control, then that QSA can’t test that, can’t test it. Independence has to be maintained. So a different QSA would need to test it. So the entity and the QSA are expected to agree on the controls and the testing procedure and you’d be expected to have that in place prior to an assessment and you have that completed and understood before the assessment starts and when it gets to that requirement, you would use that customized approach to document your compliance with that control.

Obviously, the documentation required is in depth. So I would expect that you have three or four pages of narrative and explanation versus a standardized approach. So your assessor would document that with a few sentences or a paragraph noting how you meet the requirements.

There’s a lot more effort involved in the customized approach. Obviously, it’s going to cost more for each customized approach. And as I mentioned, it’s expected that it’s in place prior to the assessment starting.

So it’s not a compensating control. Compensating controls are still there for where you have a restraint or budgetary restraint or technical restraint, legal restraint as to why you can’t meet a requirement. Nothing changes with compensating controls.

And then finally, a customized approach is not for a SAQ. So if you’re using a customized approach, that has to be documented on a ROC report on compliance.

So Brandon, for 3.2.1 expiring in March of 2024, what requirements do I have to have in place by then?

Brandon Breslin: Yeah, great question, John. So I touched on it a little bit earlier. There are two primary requirements that have to be implemented at the time of March 31, 2024, which would be, let’s say you’re doing a new assessment or your first PCI DSS assessment. It would have to be implemented by then, assuming your ROC date is after or your as-of-compliance date for your ROC or SAQ would be after 3-31-24. All of the other requirements need to be implemented by 3-31-2025.

So like I mentioned earlier, we’re still in the grace period for most of those new requirements. So I’ll dive into those two main ones. And then we’ll talk through some of the other new requirement areas that you see listed out here on the slide.

So those two primary requirements, first and foremost, roles and responsibilities. So I know both John and I have touched on this a little bit already. Having critical areas defined for each of those roles, and then those responsibilities associated for those roles. So whether it’s networking, system hardening, data flows, web encryption, anti-malware, patching and change management, all of those requirements for PCI user access, physical access, logging and monitoring, and vulnerability management.

So each of those traditional security areas or compliance areas within PCI, there now needs to be an individual or a team that’s charged with governance in that area. So it needs to be formally assigned, understood and acknowledged by the responsible parties or personnel within those areas.

The other main requirement is the documentation of the scope. So all traditional merchants or other organizations complying with PCI outside of service providers need to do this every 12 months, having it updated. So for 4.0 assessments, it’s most likely going to be almost all merchants’ first time formally documenting this.

There is guidance that’s been put out by the council on what needs to be included within that documented scope. So right out of the gate, those who are familiar with PCI here know that would include anything that stores, processes or transmits cardholder data, as well as anything that’s connected to that CDE, the cardholder data environment, as well as anything that supports or affects the security of the CDE. So that would be everything in scope there.

And then as it relates to the organization specifically, the entity being assessed, so that organization, your organization that we’re talking about here that’s going through the assessment in the future needs to understand the scope and how it applies to your business specifically. So those that are familiar with traditional methodology of aligning business and IT, this is where that comes into play.

And then the documentation specifically needs to be required with the completion date before the assessment ends. So if it’s the ROC as of date, that needs to be completed before then, preferably in the beginning of the assessment where scoping is critical. Data flow diagrams with narratives and all connections included, network diagrams showing the scoping boundaries and segmentation, data storage inventory. So any databases or cardholder data storage repositories, hardware inventory and software inventory.

Those are the critical ones. The guidance does go into more detail within the full 4.0 standard. But those are the big key areas to think about as it relates to the documented scope. And then like I mentioned, all other new requirements that we’ll get into here in a bit are required to be implemented by 3-31-2025.

Specifically these areas that we have listed on the slide are, we grouped the new requirements into six buckets here. And we’ll just, we’re not going to spend a few hours going through all the new requirements. We’re just going to take a couple minutes in each area and just hit on the big pieces or big elements. But risk management, identification and authentication, cryptography, vulnerability management, people and service providers are kind of the common themes of these new requirements which do align to the four goals.

So specifically, John, what would you say the targeted risk analysis process within risk management is? And how does it replace these existing risk management process?

John Barbier: So the prior requirement for risk assessment, they mentioned that some examples of risk assessments that you could follow and they mentioned, I recall, I think they were Octave or NIST 853 or one of those requirements. But it was a once-a-year process and it wasn’t prescriptive as to what needs to be covered. So it was a document that was required, but the testing was not involved in any depth.

The targeted risk assessment, firstly, it’s for requirements where you are considering a customized approach. So you would have to do a targeted risk assessment targeted at the controls or the control objectives for that specific requirement.

There are also other targeted risk assessments that you need to follow. So for example, let’s say you have a point of interaction, payment card devices, credit card readers, how often do you require inspections for that?

So in the past, it would be periodic inspections and that wasn’t clearly defined. So now the responsibility lies with the entity to do an assessment and to document what the risks are and why you have determined as an entity how often that specific function should be performed.

So another area of risk assessment is that you need to do a formal review on an annual basis of all the hardware and the software technology that you have in use, whether or not it is still applicable and what the end of life is so that you’re addressing end of life issues prior to when your audit actually happens and you find out that you have an end of life system that you didn’t know about.

So I think that covers the risk management areas. Brandon, do you want to talk about the changes to authentication and identification?

Brandon Breslin: So I know we’re a little bit behind on time, so I’ll run through this a little quick, but there’s a slew of new requirements, right, for requirements seven and eight. So just going to hit the high points here.

The big one that mostly everybody, if not everybody, has heard of already is MFA is now required for all access into the CDE. So that would be all entry, not just remote, not just non-console, all access to the CDE for both users and administrators. There is a caveat though that it does not apply to application or system accounts performing automated functions as well as user accounts on point-of-sale terminals, so such as one card at a time, the guidance that’s been out there for a while from earlier versions, so such as cashiers on point-of-sale terminals. Outside of that, all access to the CDE requires MFA, so two authentication factors at least, two unique authentication factors. The MFA solution must be implemented to resist replay attacks, cannot be bypassed by any user or administrator. There must be a review of all access now every six months.

I would say most organizations are already doing this from other security frameworks that is already a pretty common security control that’s out there. Access by application and system accounts needs to be reviewed periodically with access being aligned to the function being performed, right?

So similar to the user accounts that have to be least privileged, job function only, similar to that for the application and system accounts for function. Shared or generic IDs can now be used, but approval, documentation, monitoring, limited time, everything needs to be tracked, needs to be able to account activity back to one person specifically, so being able to tie that activity to one individual is a critical piece of that. But that is a pretty big change because previously in 3.2.1, you were not allowed to use shared or generic IDs.

And then there are also a couple options now for password configuration. So there is flexibility for password requirements as it relates to how often they need to be changed. So previously passwords need to be changed every 90 days or more often. Now there is the option of dynamic analysis of real-time access that can be changed or that can be leveraged, I should say. So if somebody is accessing the environment, that can be analyzed in real-time instead of having to change every 90 days or less.

And then there’s also some stronger password requirements. So every password or passphrase now has to be at least 12 characters unless the system does not support it. If that’s the case, then it needs to have eight characters as well. So that’s just the high points of requirements, seven and eight, which relate to identification and authentication.

John, protecting cardholder data is a core pillar of PCI, right? So what are the changes around cryptography and encryption?

John Barbier: So it was the case that service providers needed to have documented cryptographic architecture documents. So that’s expanded somewhat. You need an inventory of keys and certificates that are used to transmit cardholder data. You need to do an annual assessment as to whether the cryptography in use is still robust enough so that you don’t have any surprises when older cryptography is retired. Certificates need to be valid and not expired.

So if you’re using self-signed certificates to transmit PAN across public networks, you need control over that self-signed certificate. So you need some kind of PKI to validate that the self-signed certificates you’re using are actually valid.

If you’re using hashing to hash PAN, then you need to be using keyed hashes. So that’s an additional control or security feature that’s required there.

If card verification codes, if they are being stored, they are required to be encrypted. So the controls that are used for encrypting PAN also need to be used to encrypt the card verification code.

And then disk encryption, disk encryption is, it can be used for protection of cardholder data on removable media, but it is no longer suitable as a control to meet requirement three for non-removable media.

So for example, if you can’t rely on whole drive encryption as your only protection mechanism for stored cardholder data in a data center machine, you’d have to have column encryption or additional encryption there to meet that requirement.

So Brandon, vulnerability management, it’s a critical element of strong security controls and practices. What are the changes regarding vulnerability management?

Brandon Breslin: Yeah, so the big one right out of the gate is internal authenticated scanning. So this is going to be a deeper level scanning that actually, a deeper level scan that actually grants credentials to the scanner. So it’s going to do a more extensive scan to find deeper vulnerabilities that may not have been caught from the traditional unauthenticated scan. Those don’t need to be implemented technically until 3-31-2025. But if you are mid-assessment, you need to be careful about that when you move into 2025, that some of your scans may need to be authenticated scans when you get to that point.

Our recommendation is to go ahead and move to that as early as you can so that you can get that deeper level scan to understand what true vulnerabilities are out there that may not have been caught in the past.

To run through quickly, the other ones, process to address vulnerabilities that are not high and critical.

So previously in 3.2.1, there was the frequency that was required for high and critical vulnerabilities. So now you have to be concerned with timing of the moderates and the lows, which I know every organization was already concerned about that. But that’s now a requirement for addressing those based on a frequency that you feel is necessary or appropriate for your organization.

Technical controls and operational controls for addressing phishing, so anti-phishing controls for all personnel. Inventory of code repositories, so for custom and bespoke software with patching details as well.

Inventory of payment page scripts with detection of tampering within the customer’s browser or the consumer’s browser.

Change in tamper detection mechanisms on HTTP headers of payment pages on web servers. I know that’s a big one as well that’s out there. And again, most of these are 2025 requirements.

Technical and operational controls need to be put in place to prevent the copying of cardholder data over remote connections. That is a big one for especially e-commerce merchants that may be using back-end servers for storage and copying over that can no longer be the case anymore.

Removable media must be scanned or monitored by anti-malware.

Web application firewalls need to be required for all web applications. Based on the security posture in 2023 already, what we normally see already is web applications have those web application firewalls that they’re already sitting in front of anyway. So something that’s now required but shouldn’t be too big of a challenge for most organizations especially in the e-commerce space.

Automated log reviews, we all can attest nowadays that it’s just not realistic to manually review logs. Having some type of SIM solution with automated log reviews is now a requirement. So the SIM is not required but the automated log review piece is required.

Detection failures in critical security control systems is no longer just a service provider only requirement.

And then I did want to touch on the new penetration testing clarification that they put out there. So now testing from inside the network means testing from both inside the CD and into the CD from untrusted and trusted networks, internal networks. So that’s a pretty big one.

And then testing from outside the network or external penetration testing means testing the exposed external perimeter of trusted networks and critical systems connected to or accessible to public network infrastructures. So pretty big changes within the vulnerability management space.

John, people are the biggest threat to organizations and their data. Does 4.0 address how that is changing?

John Barbier: So it does somewhat. The security awareness program in the past, it did not need to meet specific requirements. You just had to have a security awareness program in place. The security awareness program has to have the content reviewed to address changes to the environment. And it needs to include awareness of the threats like phishing or social engineering that pose a threat to the CD.

And your security awareness training also needs to include the use of all the end user technologies that are in use. So that’s basically the changes around the people.

But for many organizations, the type of training or the focus on training users has increased somewhat with the type of attacks that we’ve seen in the past.

So Brandon, we spoke about service providers and vendor management as a point of emphasis in security and compliance. We’ve seen quite an increase in third-party solutions used for payments. Are there any new considerations for service providers?

Brandon Breslin: Yeah, you’re absolutely right, John. We have continued to see service providers on the rise that need to be compliant with PCI providing new platforms out there to the merchant space as well as to the consumer space. So there is an increased scrutiny of the requirements and some big changes to the requirements specifically for service providers.

The number one out of the gate is the documented scope needs to be done every six months. So we talked about what needs to be included in the documented scope. Specifically for service providers, that needs to be updated every six months, not 12 months for other merchants. The description of cryptographic architecture with the details of all the algorithms, keys, protocols that are used is another big one.

IBS and IPS techniques that need to detect, alert and prevent covert malware channels, communication channels such as DNS tunneling is a pretty big one.

The new real-time access option for passwords and passphrases that I talked about earlier is also available for service providers now.

And a big one is just the common theme and mindset from the council that service providers need to continue to support their customers’ compliance efforts. So that would be making sure you’re providing an AOC as well as a responsibility matrix. I know sometimes that gets lost in translation, but if you’re a service provider, really focusing on that responsibility matrix, outlining each of the new requirements, the full set for 4.0 and calling out what is the responsibility of the service provider, the customer or the organization being assessed, or is there a shared responsibility there? Or are there any other third parties involved in that process?

Specifically for multi-tenant service providers, there’s also a pretty big new requirement that from our experience has already been happening in the industry, but now it’s more formalized. And that is a requirement to either provide penetration testing results to the customer or the third party that needs those, that’s using that multi-tenant service provider or allowing the customer to do a pen test on that environment specifically.

So those are the big hitters. There’s a slew of other new requirements for service providers, but those are the big ones.

John Barbier: So what are the steps that an entity would need to follow to move from 3.2.1.2 to 4.0?

Brandon Breslin: So I know we’ve hit on the big ones, right? I mean, identifying the key stakeholders, identifying roles and responsibilities, establishing those processes, communicating early and often, engaging everyone that needs to be on the team and educating the organization, your organization on those new requirements, working through a transition plan, implementing new controls, testing those controls, validating those controls, determining if you need any customized approach objectives that have to be followed.

John talked about the six requirements that cannot be used for the customized approach. So identifying which ones you want to go down the customized approach, identifying targeted risk analysis, so the frequency-based requirements. If traditionally there were specific milestone frequencies that had to be followed now, the council gives that flexible option of determining how often you want to comply with the control based on the organization risk, security posture, and risk appetite. There is some documentation to follow with that if you’re going down the targeted risk analysis route for a few of those requirements, as well as the customized approach.

There’s new documentation you have to conduct on that. And then after everything has been done there, you validated all the new controls, operational controls, technical controls, you’re ready to do the full PCI assessment, making sure you’re working with the QSA there. Working with the QSA throughout the process is critical, making sure that you’re following the guidance from the council, making sure that you’re addressing each of the requirements individually so that you’re ready to get a compliant report on compliance and AOC.

As it relates to ongoing maintenance as well, like John mentioned earlier, compliance is not a one-step, it’s a year-long process. Compliance orchestration is continuing to move in that space. It’s promoting security as a continuous process. It’s ongoing. It’s ongoing maintenance needs to happen.

John, I know we have a few organizations listening in, so I’m going to talk about how CompliancePoint also can assist them.

So for any of those that have not done a PCI assessment before, we can help you. At CompliancePoint, we are a QSA firm, like I talked about earlier. John is one of our senior QSAs on the team. We follow this three-core methodology here of identify, mitigate, and manage. So as it relates to risk, security, and compliance, we believe that security is the focus, and compliance is a byproduct of that.

So if you’re a current customer of ours, we offer the bridge assessment process that I know we’ve talked with you guys about. That is an opportunity for us to do an inquiry-only evaluation of the new requirements. Because we just completed the 3.2.1 assessment, we can leverage some of that detail and the evidence that we have to go through and evaluate those new requirements and talk through that from a consultative, hand-to-hand approach.

As it relates to customers who may not be working with us right now, we offer an option to do a readiness or a gap assessment for 4.0. So that’s going to be more evidence-driven, but still a subset of sampling that you would expect for a full compliance evaluation. So it’s going to be just a smaller process for compliance to understand where some of those gaps are, where you may have hiccups in compliance, and how can we help you in that space.

Moving forward, after we identify any issues that may arise from that, we have a full implementation team that’s organizationally independent from our PCI QSAs that can perform dynamic consulting, assist in the creation of policy and procedures development, all the way up through actually direct implementation of those controls or operational directives that need to be put into place.

As an opportunity for all clients, moving into that management space, we offer a year-round compliance orchestration process or PCI as a service for ongoing maintenance. We use a best-in-class GRC tool that we’ve partnered with that provides direct development opportunities that they’re continuing to add more features to as we are building it out for our 4.0 programs. Our customer feedback has been tremendous on that platform, and it works with other common security frameworks that are not just PCI. So NIST, CMMC, SOC, ISO, HIPAA, HITRUST, you name it, that GRC tool has it. So that’s a big process that we’re undergoing right now.

So for anybody that may be interested in that, feel free to reach out to John and myself, and we can get you slated on board for that. Overall PCI DSS, just to wrap it up, I know we’ve talked about a lot of changes here. We’re here to help you make a smooth transition. Follow these key areas and milestones and steps that we’ve talked about, and we can assure you that you’re going to have a smooth transition into 4.0.

So we appreciate your time. Thank you for your attentiveness, and we can open it up for Q&A as well. And we put some links here as well if you want to connect with us over social media too and follow us.

John Barbier: So we have some questions. Brandon I see that I’m going to let you answer the first one. I know you mentioned March 31st. Our assessment window is coming up soon, and we’re deciding if we should move ahead to 4.0 for this one or keep doing version 3.2.1. What would you recommend as we get closer?

Brandon Breslin: Yeah, since we are now in November today, we are recommending all of our customers and any other organizations that are out there to go ahead and move to 4.0, right? Today we’ve talked about some of those steps that make sense for what you should do first. And since we’re already getting close to that 3-31 timeframe by the council that we talked about earlier, it is highly recommended that you go ahead and move to 4.0. I will reiterate that most of the new requirements are future-dated.

So let’s say you’re doing an assessment for 4.0. You don’t necessarily need to have those new technical or operational controls implemented at the time of your ROC date, right? So at the time of your compliance date, you don’t necessarily need to have all of those controls that are the new requirements implemented by then.

John, to pass it over to you, another question that came in, are there any different impacts for companies using SAQD instead of a QSA?

John Barbier: So the timing of the requirements and the applicability of all of the requirements are the same, whether you’re doing a self-assessment or whether you’re doing a full assessment with a QSA and you’re doing a ROC. I think one important difference that comes to mind is that if you’re doing a customized approach or you’re considering a customized approach, that is not supported in self-assessments.

So if you wanted to go ahead with self-assessment, you would not be able to use any of the customized approaches. Otherwise, the rest of the requirements are equally applicable.

So Brandon, we’ve never done a PCI assessment before. Is it okay to go ahead and start with version 4.0 instead of version 3.2.1?

Brandon Breslin: I would say similar to the previous question that was asked earlier, whether you’re doing a new assessment for the first time or you’re doing an assessment coming off of 3.2.1, we recommend moving to 4.0.

For those that we don’t work with, I touched on earlier the option to do a gap or a readiness assessment. So if you’ve never done a PCI assessment before, we highly recommend doing a gap assessment or a readiness assessment.

Like I mentioned, it’s a subset of sampling evidence, but it gives you a good holistic picture of where you are from a compliance perspective. So before you get everyone involved, all the stakeholders involved, you do the full assessment. Before you get into that, getting a gut check or quick snapshot of where you are from a compliance perspective will give you a better idea of where to spend your time, where to focus the priorities internally to understand what needs to happen to move to 4.0.

And full disk encryption, only good for removable media?

I’ll take that one. So it doesn’t mean you can’t use full disk encryption. Of course, you can go ahead and use that. You just can’t use full disk encryption to meet the requirement to render stored cardholder data unreadable. So you can’t use that to meet the requirements in requirement three. So if you’re using full disk encryption on the drives in your data center, you can continue to use them, but you’re also going to have to implement column or file encryption to protect the stored cardholder data to meet that requirement.

And then final question, Brandon, we’ve relied on third parties for our PCI assessments. Do we still need to get AOCs from those third parties in version 4.0?

Brandon Breslin: So as it relates to the requirements for obtaining an AOC or some type of compliance validation documentation, that has not changed. So if you’re an organization that’s going down the compliance route or if you’re mid-assessment or even before your assessment and you have a standard process for requesting those AOCs, requesting those validation documents, definitely continue to do that.

As it relates to service provider management overall, all of the previous requirements in 3.2.1 that you have come to know, due diligence process, getting contracts in place, ensuring again, ensuring the AOCs are up to date, making sure that you have either a responsibility matrix or some type of mapping of what areas are managed for each service provider that you rely on. All of those are still out there. So making sure you’re still requesting those AOCs as a reminder, the requirement is not that you have to have an AOC.

It’s at least that you are doing your due diligence to request it, right? So if the service provider that you’re reaching out to doesn’t necessarily have an AOC, that’s okay. You’re doing your due diligence to at least check to see if they have one.

I think that was all of our questions that we received so far. And I know we’ve gone a minute over, but we really appreciate everyone’s time today.

We threw the email out there for if you guys have any inquiries or if you want to reach out for any questions or feel free to reach out to John or I over LinkedIn as well. We are happy to assist with any questions you guys have.

Thank you, everybody.