Listen to learn more about PCI DSS version 4.0 requirements, especially about the various changes to the PCI DSS v4.0 SAQs.
"The PCI Data Security Standard is a set of about 330 security controls that are designed to protect credit card information. For most small businesses, many of the requirements don't apply in their environment. The Self-Assessment Questionnaire is a subset of the full PCI DSS standard designed to help small businesses validate their PCI compliance."
PCI DSS version 4.0 is here, and many things have changed - including the Self-Assessment Questionnaire (SAQ). If you have questions about this update, you aren't alone! Michael Simpson (Principal Security Analyst, CISSP, CISA, QSA) sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to break down all the pieces with the PCI DSS v.4.0 SAQs.
Listen to learn:
Resources:
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hello, and welcome to the SecurityMetrics podcast. I'm Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. And today, I wanna talk to you about something that I know is on a lot of people's minds because I keep getting phone calls and emails about it.
What about four point o? And specifically, if you fill out FAQs, what about the four point o? Now if you don't do PCI, all of that might have sound like kinda gobbledygook, but I have the right person here to with me today to talk about it and to help people who really, have this on their plate. Michael Simpson, principal security analyst, SecurityMetrics, also my team lead.
Welcome to the show.
Yeah. Thank you, Jim. I'm happy to be on the show.
I know that we've we've had you on before. A lot of people know you from from webinars and things, but I I just wanna take a brief moment and and offer your bio to people who don't know you yet.
Experienced security analyst with a demonstrated history of helping large enterprise and higher education entities tackle their IT security and compliance challenges.
Skilled in PCI DSS, HIPAA, networking, IPS, and NIST.
Strong information technology professional with a background in business management. I stole all of that from LinkedIn. Did I miss anything?
That sounds great.
I think one of the things that that you and I spend most of our time doing, when when we're on teams together is the higher education.
Yeah.
Yeah. Our our team focuses a lot on what I would call our multi mid companies. So our higher higher education, and also our, government. So a lot a lot of our, state and local governments, they're also, level two merchants that tend to assess using the FAQs as the baseline.
Right.
And so for people who don't know what an FAQ is, can you describe to people who maybe don't do PCI DSS or who should be doing it and just don't know that they should be doing certain things? Briefly, what is an SAQ, and how does it fit in the world of security and compliance?
Yeah. So the the PCI data security standard is a set of about three hundred and thirty security controls that are designed to protect credit card information.
For a lot of small merchants, it's a really big list to go through. And a lot of times, depending on their environment, most of those requirements don't even apply in their environment.
So what the council's done in order to help small merchants validate their PCI compliance is they they have created the self assessment questionnaires or the SAQs.
And what those are are a subset of the full PCI DSS standard that are specifically designed to protect specific types of payment flows. So if you have a a merchant that maybe they have a an analog connected terminal that their bank gave them. And all they do for processing payments is, you know, they they get the the credit card data either in person or over the phone, and they're just using that analog connected terminal to process the payment. For them, if they go through the full PCI DSS standard, a lot of it isn't gonna apply. All of the requirements surrounding network and firewall security don't apply because they have no network connection in their card environment.
Antivirus isn't gonna apply because you can't install AV on one of these bank terminals.
So what they would do is they would pick the self assessment questionnaire that fits that environment, which in this case would be in the SAQB.
And the SAQB is gonna handpick requirements from the full standard that specifically help to secure that type of a payment channel. So we'd be looking at, you know, how are they physically securing credit card data on paper, you know, if they're receiving it through the mail or how, how are they making sure that that terminal hasn't been tampered with. So it really narrows the scope of their assessment down to what really applies. So that that's how the SAQs are, work, and they're they're designed mostly for our smaller merchants, level two through four merchants to perform assessments.
You've seen literally hundreds, maybe even into the thousands now, of SAQ data flows because of of work with, the types of entities that you were talking about. These are these are groups that may have well over a hundred mids or or merchant IDs. Right?
Yes. Yeah. A lot a lot of our groups will have between one and two hundred, merchant accounts. And each of those merchant accounts may have, you know, either one one or two different payment flows that they support. So we may have, you know, one merchant group that that has both an SAQ a, payment channel for their ecommerce and an SAQ p two PE or an SAQ b for their card present environment.
So we we definitely get to look at a lot of self assessment questionnaires throughout the year.
So it feels like a a lot of people, have made real progress over the last few years towards the the version three point two point one of the SAQs.
I know in my work, I I've seen a lot of groups that really feel like they've got their arms around it, and now we have four point o coming along. So that's kind of where I would like to spend a lot of my attention right now. Now first of all, when do people have to do four point o? It's not this year. Right?
No. No. It's not.
They from the they can start doing PCI version four point o. The the FAQs have been released, but version three point two point one does not is not retired until March thirty first of twenty twenty four. So so you can continue to do a version three point two point one assessment even if you're using the self assessment questionnaires up until, you know, the end of March twenty twenty four. After that point, version four is required.
But even once version four is required, we still have a little bit of lead time for the brand new requirements that have come on in with version four.
So I did wanna talk about a point of clarity that that I think is is important for some of, of of the groups that are doing SAQs. And that is, what if a requirement existed in three point two point one, and it still exists in four point o, but maybe there's some more clarity, more more guidelines around what they mean by that. How do you think people should approach those situations?
Yeah. This is this is usually the hardest part for merchants that are doing self assessments or using the the self assessment questionnaire as the basis for their QSA validated assessment.
Whenever we have one of these big shifts and the and the SAQs are revised, if there's an existing PCI requirement that the council decides, you know, we really should have this in this particular SAQ, The merchants, they don't have that lead time that they would with a brand new version four requirement.
One example of that is that the SAQA has changed dramatically.
Some of the other FAQs from version three two one to version four really have seen little change. The FAQ b and the p two p e relatively unchanged.
But the FAQ a, there's several new requirements that have been added. Some of those are new PCI version four o requirements. And those new requirements, we have until I believe the date was twenty twenty five to have those brand new requirements fully in place and validated.
But like in the for the SAQ a ASV scans, which in PCI version three two one was a requirement eleven dot two, ASV scans were not part of the SAQA version three two one. Mhmm. But they are for version four. So as soon as a merchant does a version four assessment, those requirements that were preexisting that have been newly added to the SAQA, they have to be in place right to begin with. So if you're looking at, potentially doing a version four assessment soon or even in the future, that's kind of where to start, is looking at what are those preexisting PCID assess requirements that have been newly added to my SAQ, because those have to be in place by that March thirty first twenty twenty four deadline when SAQ when the version three point two point one SAQs are retired.
Right.
This episode is brought to you by the SecurityMetrics twenty twenty two guide to PCI compliance. I personally helped with this guide and can highly recommend it to anyone going through PCI compliance. It goes through what the the requirements are and then tells you in the real world what they mean, how to meet them, recommendations from, auditors. So, it's a great resources to get the fundamentals of PCI compliance. You can get it on our website, www.securitymetrics.com.
Well, so let's look at at some of the changes that that you found.
Existing PCI DSS requirements newly added to the SAQs with that have no grace period.
What tell me tell me about that more in detail.
Yeah. So, again, these these are requirements that, they're not new to PCI DSS.
And and I think the justification for why there is no grace period is if you look if you read through the executive summary or or or the intro to all of the FAQs in version three point two point one, And this was even prior to three point two point one. But there's a small little statement in that, in the self assessment questionnaires that say that even though we're only attesting to those requirements in the FAQ, all applicable PCI DSS controls are in place.
Right.
You know? So that's where if the PCI council now thinks, you know, ASV scans or vulnerability external vulnerability scans should be done by SAQ a merchants, they don't get that grace period because because, really, they should have been doing them in the past even though they weren't checking the box when they were filling out their SAQ.
Right. Right. So it's it it comes down to the the idea that the full PCI DSS, the full standard should apply to any card data environment. Any any card flow should be protected by the controls described in the standard. Right?
Yes. And and I think that's in my opinion, I think that's why the SAQA changed so dramatically versus some of the other SAQs because there there really were requirements that, you know, I, as a QSA, was surprised were not in the standard prior to this. And even now with version four, like, version four requires that ecommerce or these SAQA merchants, which typically tend to be, you know, an ecommerce merchant where they've outsourced all data capture and and processing to PCI DSS, compliant third party gateways.
In the past, vulnerability scans, internal or external, were not required for for these merchants, but there was a risk there. You know? If someone gained access to their ecommerce server and was able to change that redirect or the change the implementation of the iframe that was used to capture the data, then even though their server never touched credit card data, it could be used as a way to gain access unauthorized access to credit card data. So there you know, vulnerability management should have been a priority for these merchants, but it wasn't a priority in the SAQ a version three two one.
Version four, we now have external vulnerability scans required, but internal vulnerability scans are still not part of the SAQ a for version four.
Right.
Should they be done? Yes. In my opinion, you should be doing both internal and external vulnerability scans against your ecommerce server, regardless of if it's in your SAQ.
But version four right now is only requiring the external vulnerability scans.
So this comes back to your earlier statement that, they all they all are, required. You have to look at them and say if it applies to your environment, these should be in place. But you only have to attest to the the certain number that the council put in the SAQ.
And I think some people think if it's not in the SAQ, it's not import important.
But I don't think that's I think it's more that the ones that are not listed there should be done, depending on if it applies or not.
Right. And and I think it's a risk based decision that the council, you know, made to decide which ones they were going to put in each of the FAQs.
That being said, companies really should be making that risk based decision on their own. You know? And and the council has been clear all along that the PCI data security standard is is really a a baseline Yeah. For protecting card data. It it's not the, you know, the gold endpoint that we're trying to get to, but we we, at the very least, need to do these requirements.
And the self assessment questionnaires are even a lower baseline. You know? So at the very, very minimum, make sure anything listed in your self assessment questionnaire is in place, if it applies. But then the next step, you really should be going through the full standard and saying, you know, do any of these other requirements apply in my environment? Or or or any of these other security practices, would they be good to apply on my systems, to further protect my customer's payment data and my environment?
And then beyond that, you know, as part of your risk assessment, you should be looking at, you know, outside of what PCI DSS is looking for.
Are there any other, you know, risks that I face as a as a business owner that I should be reducing? You know? Are there any controls that I could put in place to further reduce the risk?
And I think that the the language that we use around it can be confusing because sometimes I'll say to an organization, like the internal vulnerability scans. Alright. Are you performing these? No.
It's not applicable in my, to me because it's not in the SAQ. But that's not what that means. You don't you don't determine applicability based on the SAQ. You term determine applicability based on what's going on in your environment.
Right?
Right. Yeah. Because there are there are some SAQA merchants, who have fully outsourced their ecommerce environment. So, you know, there there's some where their shopping cart they host their own shopping cart where people are selecting what they wanna purchase. But then at some point, they either use a third party iframe to collect the data or they redirect people out to a third party to collect the payment data.
Some merchants, they've outsourced everything. So they they don't have any servers to scan. You know, they don't have any servers to patch or to put antivirus on. So in some situations, you know, selecting not applicable is is right in that environment, and there there wouldn't be a need to do vulnerability scans.
What you know, the the ones required in PCI version four and the ones that are not part of that self assessment questionnaire. But if if your environment if you do have systems that you need to protect, then, really, you should be going through and saying, you know, based on my environment, should I put this security control in place? And and if it applies in your environment regardless of whether it's in your self assessment questionnaire, it kinda doesn't matter. You you should have it in place. And that's actually one of the key indicators to know if you maybe selected the wrong self assessment questionnaire is if you start noticing that there's a lot of security requirements that do apply in your environment that are not in your self assessment questionnaire, it might be time to revisit those qualifying criteria questions that help a merchant decide which self assessment self assessment questionnaire is right for them because maybe you've selected the wrong SAQ.
Right. And sometimes it's hard as a merchant to know what that is because they you might not have a strong familiarity with the data flows and the the related technologies.
So for some some merchants, they have p two p e. And, and I'm gonna say it again. I say it all the time. Everybody should be using P2PE.
All all everybody. Anybody who can should be using P2PE. I know it's more expensive to set up. I don't care.
It's gonna put you in a better position. So people who who have gone to the trouble to do a listed, certified, validated, I guess, is the word p two p e solution, they probably know, hey. I have p two p e. And, oh, by the way, here is my implementation manual for that, and I know all of the things about it.
A lot of merchants seem to know a lot about their p two p environment, but are a little maybe hazier and coming back to the SAQA on the ecommerce environment.
Right.
And so a lot of times, I'll ask, you know, our small merchants, where is your serve who manages your server? And they don't even know they don't even know that. They might not even know is there a server let's go back again to the higher education maybe. Is there a university server somewhere that's managing a piece of this, or does it entirely go to a third party?
Is there any stops along the way from a university server to a, third party server? And so answering those questions is not always something that the merchant knows because they might have been presented with, hey. Here's your portal. Go set it up.
And then what do they know? Right? And so that's a that's a chance for them to then say, okay.
Who chose this?
Yeah. How did it get set up? Who's in and just really start digging because if you have if it's entirely outsourced to a third party, you get to say it's in place because this third party gave me an attestation of compliance that says they do it. We can rely on that. We're golden.
But if you don't know that or if or if there's sometimes, well, I find that there is that intermediary hop from a university based server to a third party, and they were the merchant themselves were unaware of it. And so sometimes fine and if they're merchants, asking the right questions from from the people who set it up or gave it to them or or or, you know, interacted with them on it in some way, asking more questions is gonna help.
Which which reminds me that, you know, the importance of doing a an annual scope review of your environment because that it doesn't always stay the same either. You know? Like, in our higher education or government groups, you know, maybe there was a a central IT group that originally set up their ecommerce shopping cart.
But maybe that's changed. You know? Maybe a new group has taken ownership of it or they switched out the server.
Recently, I've noticed a lot of my, merchants tonight. I think this was really brought on by the the pandemic.
But even a lot of my merchants so the universities, they've been working at reducing their scope by implementing PTPE.
The last over the last couple of years that people have been working from home more, doing more remote work, sometimes they have implemented controls that kind of break their P2PE scope.
So so they're still using a p two p e device to enter the data. But now instead of having their customers come in person to make payments, they're receiving credit card payments over the phone. And if they're receiving it over, like, a a softphone or, you know, some some way that brings a network into scope or a system into scope, then as they read through that qualifying criteria, they no longer qualify for the SAQ p two p e even though they're using a p two p e terminal. So so that is something that, you know, this really should be every year as part of your scope review, read through the qualifying criteria and the SAQ, and and, you know, determine have there been any changes in my environment that would change the way I respond to these questions.
Right. And I think that scoping is something that it feels like we talk about all the time, but we don't talk about it enough because people are still unclear on scope. But scope really is, part of what helps you know what is applicable and what is not. You know, it it if something is going to secure a vulnerability in my environment, then it's applicable.
Very true.
Alright. So let's move on to new four point o requirements. Are there any new requirements that really kinda stuck out for you?
Yeah. The there there's two new requirements that I think are going to affect our SAQA merchants probably more than any. There there's a lot of, you know, new requirements and a lot of evolving requirements. One one evolving requirement, is, you know, PCI password security has based on NIST recommendations, could be considered weak in the past. You know? They they require you know, under version three two one is a seven character password.
Agree.
So as as technology has improved, you know, a lot of people feel that seven character passwords are just not sufficient, and it probably has been for a while now. So PCI version four has increased the length of that to twelve character password. So that is what we would cut, you know, what the council considers an evolving requirement. So it's it's not really a new requirement. They're just evolving based on the threats that we face today.
Right.
You know? So that's an evolving. But as far as new requirements, I think and this will affect, our SAQA, AEP, D merchants. But there there's two new requirements.
One of them is PCI requirement six four three and a similar requirement eleven six one. So and and these those numbers are version four numbers, obviously, since they're new requirements.
But how these affect our SAQA merchants really depend on how they interact with that third party provider. So if if they're using, an iframe to collect credit card data Mhmm. Then they will be looking at requirement eleven six one. And requirement eleven six ones deals with, securing the HTTP headers, making sure there's no unauthorized changes that could affect that iframe implementation.
So this is a new requirement. There's some guidance out there on it.
But this is something that may take a merchant some time to implement because it does require additional technology that might not currently be in place. Right.
For those that are doing a redirect out to the third party, so the browser you know, the, customer's browser changes from your URL over to whatever payment gateway's URL.
There's requirement six four three, and this one requires that you are maintaining an inventory of and kind of, providing verification that any third party included scripts on that page, you know, there hasn't been any unauthorized changes to the scripts that are included on the page.
So So for for third party scripts, I think that means keep scripts off the page.
That is a really good way to deal with that. Keep scripts off the page.
You know? And and some merchants are already doing that.
Mhmm.
Some merchants, unfortunately, you know, we we've adware should never be not only on the payment page, but for the SAQAs on that, the site that deals with that redirect out to the third party, you know, they're they're you shouldn't have any third party scripts that have adware or other you know?
Even you know? And and this happens a lot, and you have to kinda decide from a risk decision what's what you'd like to do. But there's a lot of third party, like, analytics, like Google Analytics or, I think Adobe has one as well.
Maybe for you, it's really important that you have those analytics on your site, and that is going to be a third party include. Well, if if that's the case, then you need to be sure that you have security controls in place that can protect that.
I I would argue that for an FAQ volume, having analytics on your page probably is just something marketing put on for out of habit or overkill or just because it was included. And and I would question whether there is real value there for for a group that that is if you're doing volume that is small enough to allow you to do an SAQ, you probably have other ways of gathering the information that you need, and and you don't need this this big old, you know, analytics engine in to tell you.
Right. And even if you do need some analytics, maybe it can be on your other pages. You know? Maybe it doesn't have to be on that critical side.
Not to dismiss the value of marketing or analytics or any of that. I understand that that's really important to a lot of people.
But I put more weight in security and that's where I stand.
So, let let's do, let before we wrap up, I know that a lot of people are probably wondering, okay.
You've told me this information. It's coming. It sounds big and complex. How do I prepare for this?
I I think the first thing is just to realize we still have some time. Yeah. Version four was just released.
We have until, you know, March twenty twenty to twenty twenty four.
I know. It's so far away. I haven't memorized when it is yet.
I know. So so we still have some time.
I even even, you know, you and I as QSAs, we cannot do a version for assessment yet because We're not allowed to until we get the official training, and the official training isn't happening yet.
So everybody can just chill a little bit.
Yeah.
We have a little time.
But the council has provided, you know, at least the the, you know, version four is out and the version four FAQs are out. So what I would do is first make sure you are compliant to version three two one.
Yeah.
And then after you're compliant to version three two one, then look at any additional three two one requirements that were added to your SAQ in version four because we have plenty of guidance on those, like the the ASV scan requirement.
For the SAQA, they've, you know, they've added, like, password age requirements and password history requirements and and and requirements to deal with how you set up new user accounts and how you reset passwords.
These are new, you know, existing requirements that we've had for years, so there's plenty of guidance out there. But they've been newly added, and those are the ones that will first need to be put in place. Right. So, you know, once you're once you're, you know, three two one compliant, look at these other controls that are going to be added to version four.
After you have those in place, then start looking at the brand new version four requirements and and try to get your head around, okay. How does this new requirement affect my environment? Does it apply? And if so, how can I make sure that, you know, once I get to twenty twenty four or twenty twenty five and and this is no longer, you know, something that's out in the future, but it's here, what can I do now to get myself into a position where when twenty twenty five rolls around, it's a piece of cake and I've got this?
Right. And and I think, I love the idea that focus on three two one and get that compliance in order first.
Yeah.
But then You don't get extra credit points for For jumping ahead.
Putting an SAQ.
It's just but it's all about securing your environment. So one of the things that I've noticed with, three point two point one is that people have not read it.
So so Mhmm. It's and it can be it can feel like a lot, but these s e q's, they're not that bad. Sitting and reading through it, and if you you get to things that you don't understand, maybe somebody in the compliance group will understand it. Maybe another merchant that maybe there are merchant groups that that help understand, you know, the FAQs in your in your organization. Maybe there's, somebody from the IT group can come over and talk about the the technically specific things. Right? So I think, for me, I I really like it when people take the time to read the words.
But even if they just read the qualifying criteria.
Yep. That is a big one. Read read the qualifying criteria and realize that, how I put it recently with the one person I was helping out. You know, the qualifying criteria are not it's not a choose your own adventure type of a scenario where you can just select one of those and go, oh, yep. This is the SAQ for me.
Every one of those qualifying criteria have to be have to be affirmatively answered for you to say, I do qualify to use this FAQ to validate my PCI compliance.
If you can't answer every one of those affirmatively, you need to look at a different FAQ to make sure that Right.
You can validate your compliance using Exactly. One of the those self assessment questionnaires.
Well, I sure appreciate you coming and talking to me today about this, and and I hope that people find it useful.
We'll have links that where people can go find additional information. But in general, where's the best place if people want to find PCI information?
Are are there documents people can go to?
Yeah. So the probably the first place to start is the PCI security standards website.
Under their document library, you can download all of the they've got several version four documents to talk about the changes, from version three two one to version four and kind of give a high level description of these new requirements.
The version four SEQs can be downloaded there. And in the SecurityMetrics blog, we're putting out content on version four to help people understand how version four applies in their environment, and we'll continue to provide more information, as it becomes available.
Terrific. Thanks very much, and I appreciate you joining us today.
Yes. Thank you, Jen. It's my pleasure.
Thanks for watching.
To watch more episodes of SecurityMetrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)
