This blog will discuss changes to the PCI DSS 4.0 SAQ questionnaires and is based on our Webinar "PCI DSS 4.0: What's New and How It Affects You."
This blog will discuss the PCI DSS 4.0 SAQ questionnaires based on our Webinar "PCI DSS 4.0: What's New and How It Affects You."
We hope you are ready to learn something about PCI 4.0 and what's going to be coming up.
So let's talk about PCI version 4.0. There's a lot of discussion about PCI DSS version 4.0. People are a little nervous about it. It's been a while since we've had a new release update.
People have lots of questions about the release dates, the implementation dates, and the things that are about to affect us.
The first thing is: don't be too nervous.
Version 4.0 is out, and version 4.0 Self-Assessment Questionnaires (SAQs) are available. People can do the self-assessment using the 4.0 version of the PCI DSS, but they don't have to.
PCI DSS version 3.2.1 is still active until March 31st of 2024. So between now and March 31st of 2024, you can choose whether you want to do a 3.2.1 assessment or a version 4.0 assessment.
Once we’ve passed March 31, 2024, the 3.2.1 standard will officially be retired, and 4.0 will be the only option at that point in time.
But even when we get to that point, any of the brand new requirements that were brought in as part of this transition to PCI DSS 4.0 will be considered best practice, organizations will still have another year until March of 2025 before the new requirements need to be implemented. So you've got some time to implement PCI v. 4.0 requirements.
But it is time to start preparing now.
There should be plenty of time for organizations to take a look at the requirements and to figure out the best way to implement those in their environments before they become mandatory.
Once that hard date hits (March 2025), it's version 4.0 or non-compliance.
There really isn't much in the way of scoping changes. The scoping guideline that was put out by the Council a few years ago is still pretty much accurate.
Scope is still related to devices that are processing, storing, and transmitting credit card data, or that can affect the security of credit card information.
For example, when people are doing self-assessments, usually they're scoping their environment, but they're also going through the qualifying criteria in the SAQs to identify which SAQ applies to their environment.
There was in the SAQ, a minor modification to those qualifying criteria, but it really doesn't affect scope.
It just makes it more clear that SAQ A providers, are typically e-commerce but can be call centers.
For example, when call centers are fully outsourcing all of their collection and processing of credit card data to a third party provider, in version 3.2.1 it says that those third parties need to be PCI compliant.
In version 4.0, they've gone just a step further to say that in order to qualify to assess using the SAQ A you need to have a valid attestation of compliance (AOC) from each of those third-party providers. But other than that it really doesn't affect scoping.
There are some new requirements that have come in with PCI version 4.0, and then they've also enhanced some existing requirements.
One of them affects all of the SAQs, regardless of which one you're filling out. There is a new checkbox.
In the past, for each requirement, you would either say it's in place, which means that control is active and in your environment, or there was a no checkbox saying that that control is not in place; thus you're not PCI compliant because of that.
There was a "N/A" or not applicable checkbox, and there was an "in place with compensating control" checkbox. This basically means, “I'm meeting the intent of this requirement, but I'm doing it in a little different way.” So instead of doing it the way that was prescribed by the SAQ, I'm meeting the intent of that by doing a different control.
PCI SAQ version 4.0 has added one checkbox that says in place with remediation and this might cause some confusion for some merchants that are self-assessing.
Basically what this new checkbox means is that when you were doing your self-assessment, and you came to a control and you found out that it was not in place, and you were not PCI compliant, if you then fix that control, or implemented that control, or took care of whatever remediation where it needed to be done to be compliant, they want you to mark that in place with your remediation.
There's also a table in the appendices where you would mark which item was not in place when you first did your assessment and what work was done to bring that into compliance with the standard. So that's one change that we'll see on all of the SAQs.
One question we hear from the merchant side all the time is, how many more questions do I have to answer here?
With the exception of the SAQ A, there are fewer checkboxes in version 4.0 than in version 3.2.1.
For example, the SAQ P2PE in v. 3.2.1 had 33 checkboxes that someone would have to go through and see whether they were in place, not in place, or not applicable. In version 4.0 SAQ P2PE checkboxes have gone down to 21.
We've seen a significant reduction in the number of checkboxes, but as I've gone through those SAQs, most of the reduction is not the removal of requirements. Instead, they've combined a lot of requirements into one checkbox.
That was particularly true in part in relation to policies where PCI would say no, you must have a policy for X, Y, and Z. In the past, they would have a specific checkbox for each of those policy elements. Now, I've noticed a lot of those have been combined into one checkbox. You still need the same policy elements in place, but you're just checking in one box to say, yes, all of those policy elements are in place.
Now, the one exception to that is, like I said, the SAQ A.
In the past, the SAQ A was one of the sweet spots for merchant compliance because you're basically outsourcing all of the collection and processing to a PCI-compliant third party. So your risk level was lower.
Because most SAQ A merchants are e-commerce merchants, and they've got some websites where they're selling products or services. But before payments are taken, they're either redirecting their customer to a third party to collect that information, or they're implementing a third-party i-frame to collect it.
With the increase of eskimming attacks, the SAQ A has added both new requirements that have come in with PCI version 4.0 and some existing requirements that were not part of the SAQ A in the past (e.g., the external vulnerability scans or the ASV scans). It's not a new PCI requirement, but it is new to the SAQ A for version 4.0.
SAQ A had 24 requirements in the past. Now SAQ A has 31 requirements.
As mentioned above, quarterly external vulnerability scans are now a requirement for SAQ A merchants (requirement 11.3.2). This is one that I would recommend merchants get on right away.
Because version 4.0 has a couple of new requirements, like requirements 6.4.3 and 11.6.1, and those requirements are specifically designed to protect either the i-frame from being tampered with, or designed to prevent third-party code that's being included in your page from causing security issues on the website.
For these new requirements, you have until 2025 before they need to be in place.
But when they take an existing requirement, like the ASV scan, as soon as version 3.2.1 is retired (i.e., March 2024), you can no longer do SAQ A version 3.2.1, and this requirement needs to be in place right then. If you don't already have ASV scans, SecurityMetrics can help out with this requirement.
For example, requirement 8.3.5 in version 4.0, is another existing requirement that was pulled into SAQ A, and it addresses security when you're setting up a new user account.
Typically, you're setting up a new admin account on your e-commerce server. What's the process for setting up that first-time password? You require the user to reset their password upon first login. If someone forgets their password or gets locked out, what's your reset process?
You should ask yourself questions like: “how many passwords does my system remember so that people aren't re-using old passwords?”
In the past, for version 3.2.1, again, this requirement wasn't part of the SAQ A.
But if you are an SAQ C or a B-IP, there is a requirement that, after every 90 days, you'd have to reset your password. This 90-day requirement has been brought in. But it's a little bit different than it was in version 3.2.1.
In version 4.0, you either have to change your password every 90 days or you have to have some other form of authentication other than just a username and password.
If someone's already implemented multi-factor authentication (MFA) on their e-commerce server, they don't have to change passwords every 90 days in version 4.0.
Mostly what these requirement changes are trying to do is increase your authentication security on these e-commerce redirect servers.
Other requirements that have been added deal with how to protect any third party, either the i-frame that's being implemented or any other third-party code that you're implementing on your e-commerce site.
Really, the rest of them (e.g., SAQ B, B-IP, P2PE), they're relatively unchanged. There are some minor modifications. But if you were going through any of these SAQs prior to version 4.0, going through a version 4.0 self-assessment is really going to look similar.
The formatting looks a little bit different because there are fewer checkboxes, but what you're actually required to do is basically the same.
The CV-T, the C, and the D are more complicated ones. We do have some of these new PCI version 4.0 requirements that have made their way into those self-assessment questionnaires.
So you will see some differences in our more complex SAQs. The biggest difference for our complex SAQ is if you're a service provider. Unlike our merchants, who have many SAQs that they can choose from (e.g., A, A-EP, B, B-IP, C, C-VT, P2PE), service providers will only ever have one SAQ.
The SAQ D service provider is substantially different in version 4.0. The Council treats it almost like doing a ROC assessment, instead of just checking a box.
For example, when you're saying that a control is in place, you have to actually type in what you looked at in order to verify that the control was in place. This is similar to how someone would go through if they were doing a full ROC assessment against their environment.
Usually, their QSA comes in, performs the assessment, and when they're writing up the report, they record how they verified that a control was in place and what they tested to look at that control.
The SAQ has never asked for that level of detail before, but in version 4.0 service providers are held to a higher standard, needing to provide details as to what they looked at to verify that they are PCI compliant.
But the SAQ A-EP, which is probably one of the most common SAQs types we see out there (same with SAQ B)is still relatively unchanged in the industry. And B-IP is relatively unchanged as well.
C and C-VT have always been kind of the ones that merchants have struggled over. Even our partner banks have struggled a little bit with understanding the differences between C and C-VT SAQ. Typically, the C-VT comes into play when segmentation for merchants that use a virtual terminal. So there are not many changes for this SAQ type.
From the qualifying criteria, they’re basically the same. So if you were a C-VT in the past, you'll still be a C-VT in version 4.0. But there are some minor changes.
They have brought in some new requirements that weren't there before for version 4.0 in both the C and the C-VT.
There is some new validation that will have to be performed if you're doing a version 4.0 assessment versus 3.2.1 for either the C or the C-VT.
But it hasn't changed nearly as much as SAQ D and A-EP,. The SAQ C and the C-VT, have had some existing four requirements that were not part of their respective SAQs in the past, as well as brand new requirements that are best practice until 2025.
If you are a SAQ C or C-VT merchant, it would be worth your while to take a look at those SAQs and identify what those changes are so you can start working to prepare for a version 4.0 assessment.
The SAQ B-IP is in a kind of funny situation where you have a terminal that is connected by an IP. Is the Council still looking to make sure that merchants are segmenting that from everything else in their network?
Yes, they still are. It's still one of the qualifying criteria.
That device should be behind a firewall, be segmented, only allow traffic that's required (both inbound and outbound), and it shouldn't be on the same network segment as any of your other devices.
This is always a question that pops up when we're talking with our partners.
B-IP is an IP-enabled terminal, but also these organizations need to have this other set of security involved. The segmentation is a big piece, and if they don't have that segmentation, they would then qualify for an SAQ C. While this process can be frustrating, it's the understanding that that security is everything. That's really what we're trying to do here.
One thing that I've seen with a lot of my merchants that don't want to fill out an SAQ-C, is that they've moved to validated point-to-point (P2P) crypto terminals. This is because, with those they can connect to any network segment they want, they can even connect to their Wi-Fi network on it, and this doesn't bring that network into scope. Now, we even see some banks that are providing P2PE-validated terminals to their merchants.
If you want an IP-connected terminal, check with your bank whether they offer a validated point-to-point encryption (P2PE) solution that you can implement. It could definitely reduce the scope of your assessment and make filling out your SAQ much simpler.
B-IP 4.0 is going to have 48 questions and P2PE has 21. So you're already reducing that and there’s still no scan required for P2PE; whereas, there would be for a B-IP.
If you want to reduce those requirements, you can implement P2PE encryption for those terminals, reducing your risk and compliance burden.
The only vulnerability scan requirement change is adding this requirement to SAQ A.
Now, PCI v.4.0 will throw that scan in place. But for the rest of them, nothing has changed in that manner. SAQ P2PE, B, and C-VT do not include vulnerability scan requirements.
The following SAQ types will need to conduct a scan: A-EP, B-IP, C, D for merchants, D for service providers
One surprising thing to me is that even though they’ve added ASV scanning requirements to SAQ A, they are still not required to conduct an internal scan.
Note: With all of the SAQs, there is a statement in there that says that, even though you're only attesting to know this small subset of the full standard, you should be compliant with the full PCI standard.
So, I would recommend our SAQ A merchants do both internal and external scans, even though they only have to attest to the fact that they are conducting external scans.
Some of our merchants are quite sure what the difference is between an external scan and an internal scan. What is the importance of an internal scan and what does that mean to the merchant?
For years, the industry has recommended security in levels. So you have multiple levels or layers of security.
The external scan is a vulnerability scan conducted from the Internet, searching for potentially exploitable vulnerabilities that someone outside of your network could find.
An internal scan takes you inside of your firewall, so you're losing some of that external protection. It'll let you know if someone were to gain a foothold inside of your network. What additional vulnerabilities would there be on that server or system to exploit from that internal perspective?
With the internal scan, you get a much more in-depth look at what vulnerabilities a system actually has because the external scan is going to be blocked by that firewall or network segmentation device. Doing both an internal and external scan will get you a much clearer picture of what vulnerabilities you actually have in your environment and your systems.
Then you can address those discovered vulnerabilities to protect your systems from being compromised.
In today's world, we see that almost everybody's hackable, in some way, shape, or form, so preventing the outside entrance is wonderful, but if they do get in, it's nice to know what other systems are in place to stop them from progressing forward.
Unfortunately, we've seen so many times data breaches caused by someone gaining access to what might not be considered a critical system. But access to this system puts them inside some of those external protections. That's really why the internal vulnerability scan provides a lot of value for merchants.
They can see even if they had a failure of their external security devices that if they’ve secured properly internally, then these processes should prevent sensitive data compromise.
How often have you done audits where the damage would have been lessened if people would have secured their internal security better?
That's probably a better question for our forensic team because they actually go in after there is a breach. I'm on the team that helps prevent our customers from finding out that information because we help to protect them from ever having that data breach or that data being compromised.
The Data Security Standard (DSS) has a lot of preventative controls that would help to prevent that type of compromise from happening. And then they have detective controls designed to help you detect when something has gone wrong. You can respond to incidents quickly so that there's less damage to the organization and less data can be stolen during the window of a compromise.
So I definitely think that the more hardened your organization is both from an exterior standpoint and within all of your systems internally, the harder it's going to be for someone to continue to exploit systems within your network. This will minimize the damage that could be performed and will give you more time to respond to that type of intrusion before any critical data is taken.
At least, that's the hope and that's the whole reason for security in layers. You don't want to put all of your faith in that external firewall because someone will inevitably pass that external device, and you want to be sure you're protected on the inside as well.
Once an attacker figures out a vulnerability, they are sharing that information just as fast as we are sharing the fixes to stop vulnerabilities from happening.
Unfortunately, sometimes it's when the fixes are announced that hackers become aware that there is a hole in a layer of security. If a company doesn't have a good vulnerability management strategy in place, it really puts them in a bad situation where hackers can start creating tools to exploit known vulnerabilities.
We hope this has given you a better understanding of what is coming your way with version 4.0. For most organizations, the v. 4.0 SAQs will be going down in questions which is wonderful.
As you follow the PCI standard, you will have a much higher chance of avoiding a data breach. One of the objectives of 4.0 is to make the paperwork side a little easier and focus a little more on the security side.
Take the opportunity to really tighten up your security, but maybe not spend as much time checking boxes. Sometimes when there are so many boxes to check, it becomes an exercise of checking those boxes rather than really putting the security in place to protect your systems.
.svg)
