Listen to learn about updates relating to universities for PCI v4.0 requirements and security tips for universities.
PCI DSS Version 4.0 includes several large changes and updates to the compliance space, especially for universities. Michael Simpson (Principal Security Analyst, CISSP, CISA, QSA) sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to do a deep dive on what universities need to know for PCI DSS v.4.0.
Listen to learn:
Resources:
Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide
[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 back to the SecurityMetrics podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. Very excited to bring you the topic today, which is all about how PCI version four point o will impact university payment processing.
If you are a new, listener or follower, welcome. Very excited to have you here. We have a lot of topics that that really run the gamut of compliance, security, risk. And so there should be a little something here for you regardless of of what role you hold in your company.
We have a lot of universities that come to us with questions about PCI, and I have with me today Michael Simpson, who is he's kind of the king of university audits. So very I don't even know. Do you wanna introduce yourself a little bit, Michael?
Oh, yeah. Yeah. I'm Michael Simpson. I've been with SecurityMetrics for, I don't know, over eleven years now doing PCI assessments.
Before that, I came from the university world. So I was a a database engineer, network engineer for for a university for about ten, eleven years. So kind of understand how that university space works, and then I moved into mostly PCI assessments, but security assessments in general, and and it's been great. I love I love working with universities right now.
I, I'm the director of our enterprise audit or enterprise assessment team. And we focus on our university clients, our large enterprise clients, and our, government clients. So pretty much any anytime we're doing an assessment where we're sending out multiple assessors and the universities tend to be that route, it usually ends up on my team's plate.
Yeah. And I'm excited to be part of that team.
It's actually some of the most fun and interesting work that we do is some of these large, more complex audits.
And universities are their own special thing. A lot of people don't understand why why universities are harder, but, I think part of it is, because they're, like, an a a conglomeration of a lot of little merchants.
Yeah. Yeah. It I I call it you know, it's it's a multi mid assessment. So they have all of these merchant accounts, sometimes hundreds of merchant accounts.
It acts a lot like a little city. Yeah. Or a big city. You know?
And a lot of times there's, distributed decision making too. So you don't have, like, one person saying or one group saying, here's the processes we're all going to follow. And so there that adds a little bit of, spice to what we're looking at. But, so let's talk about before we really dive into how it affects universities, maybe kind of talk about the four point o timeline because people are wondering when do I have to care about this?
Yeah. No. That's a great question. That four point o, you should have started caring about it probably about a year ago.
But it's not too late. It's good to start, you know, thinking about it now.
We have until March of next year. Before March of twenty twenty four, that's when version three two one will be retired.
And at that point, you will have to do version four assessments.
There's another time line, which is a year after that, March thirty first of twenty twenty five, and that's when all of these brand new future dated requirements will need to be put in place. Up until that point, they're considered a best practice. So from a scheduling standpoint, those are the two dates to really worry about is next March and the March after that.
Right. And so, in, in PCI, the there's kind of two different ways to report on it, And that is the SAQ, the self assessment questionnaire versus the ROC or the report on compliance typically.
And self assessment questionnaire might even be a little confusing because you can have a QSA come and evaluate you. You do and fill out your SAQs and sign that you have to have a QSA do the rock. But then there's, like, self assessment as it infers if you're small enough or maybe, low risk enough, your bank will allow you to to do a self signed SAQ. So how do those different ways of assessing, how does that apply to the university environment?
Yeah. So that's a good question. And this this is something that maybe is not universally adopted.
But in my opinion, the best way to review a university environment from a compliance standpoint is to look at each of your merchant accounts and identify which self assessment questionnaire fits that ROC or an AOC from a ROC, it helps to really identify which PCI requirements apply to specific payment flows so that you can work with those merchants on campus and say, you know, because you have an ecommerce payment flow and you're using an iframe from your third party provider, you know, this payment flow would be if you were using an SAQ to assess it, it'd be the SAQ AEP. So these are the security controls from the standard Mhmm.
That we should really focus in on, instead of throwing the whole standard at them and saying, okay. You guys need to meet everything here. Sometimes, you know, a lot of those aren't going to apply. So if if you could look at each of your merchant accounts, look at each payment flow and say, okay.
This payment flow, this is an SAQ b type payment flow. Mhmm. So I don't need to worry about network security controls, and I don't need to worry about unauthorized wireless devices. You know, this is an analog connected terminal.
I mostly need to worry about physical security and staff training. So the FAQs, even if you're not turning in an FAQ at the end of your assessment process, it really helps you to define your merchant environment as a whole and to really understand which ECI requirements need to be put in place to protect each of those payment flows.
I think it's a really good way to do it too because you're not overwhelming the individual merchants or individual departments with with questions they don't know how to answer.
You know, if you have let's say you have a let's say the marching band takes payments using point to point encrypted, terminals.
And then you go and ask them, well, what how how do you deal with, rogue wireless? And they're like, what?
We don't even what does that even mean? That doesn't have anything to do with it. Right? And so it helps support the And not overwhelm the merchants while gathering the actually applicable things that you need to know. So I think I just think it's a really smart way to do it. So then, a lot of, organizations, the universities have been doing this way, Especially the ones that we work with have been doing it this way. And so they actually care about the SAQs.
So at this point, they're probably saying, all right, we've been We know how to answer an SAQ, but there's changes that are happening. What are the, what are these changes to the SAQs that they need to know about?
Yeah. So any anytime the standard changes, and it's been a few years since we've had a major change to the standard.
But the the PCI council, not only will they decide, you know, which of these new PCI requirements that are brand new to version four should we put into which SAQ. Mhmm. They'll also say, you know, we probably should also add this existing PCI requirement that's been part of version three two one that hasn't been in this FAQ. It really makes sense to bring that in.
So when when you're going through an FAQ based approach, and you and we're going through these standard changes, there's, you know, two types of requirements we need to keep an eye out. One is for brand new requirements, and those like I said, usually, we have until March thirty first of twenty twenty five for most of those new requirements, before those have to be put in place. But if they take an existing requirement, one example of this is with the SAQA's, the external vulnerability scan used to not be a requirement that SAQA merchants had to do. But the council, when they were making this four point zero change, they're like, you know, really these ecommerce websites should have an ASV scanned on them every every quarter.
So they're gonna they grabbed that requirement. They added it to the SAQA.
Assessment to version four, if next year you're doing your first version four assessment, even though that's a newly added requirement to the SAQA, it's not seen as a new requirement and it needs to be put in place on day one.
Right. Because it was always a requirement. And I've heard you say this over and over again.
This is it's not that you don't have to meet requirements if you're an SAQA or if you're if you're if you're filling out the SAQs.
It's not that you don't have to meet a requirement. If it's applicable in your environment, you just don't have to attest to it. And so I think that makes a lot of sense where people, well, it is a new requirement. It's not. You just now have to attest to it in in places where you didn't have to attest to it before.
Yeah. And and unfortunately, I mean, it's it's the way of compliance. If usually, if people are not attesting to it, it's easy just to ignore it. Yeah.
But but there is a little CYA statement that's been in the SAQs forever that just says, you know, even though I'm only attesting to these requirements, I need to be rolls from here, guys.
I know. I know. I know. It's like, what are you talking about? It feels kind of like a sophistry, but it it really is.
That's the way it goes. And and, try trying to help people understand that things are applicable. But there are a lot of people that we work with, a lot of groups that we work with who already get this, who've already been doing it, and who have actually gone that extra step of, look, we know that this is a security concern in our environment even though we haven't been testing to it. We've been doing these things.
And so, for some groups, this is gonna be a super easy transition. But other groups, if they haven't been doing things like, external vulnerability scans, it takes some ramp up to do that. And so people need to be aware of it now so they can be prepared for it. I mean, I'm glad you talked about the SAQA.
Let's talk about maybe some other changes to the SAQA because I feel like the SAQA used to be kind of one of the easiest ones. Because a lot of SAQAs, they were relying on iframes, for example.
But there are changes that we have to be aware of because this is where the breaches are happening now.
This is where we're seeing Yeah.
Actual malicious activity is in, groups that are using the SAQA. And so they need to know what these changes are, because they're addressing real problems, not just, oh, we think this might be a problem in the future. Nope. It's happening now. So what are some of the other changes to the SAQA that people really need to be aware of?
Yeah. So one of one of the biggest changes to the SAQA, there's two new security requirements that are designed to prevent an ecommerce skimming attack or, you know, a man in the middle type of attack.
Requirement, six four three and eleven six one, and these kind of interplay. They got they kinda relate to each other.
Both of these new requirements, they only apply if you're using a third party iframe to capture payment data. So if if you're an SAQA, which which basically an SAQA merchant, they've outsourced all collection processing and transmission to a third party provider.
If you've done that, if you're ecommerce and you've done that by fully redirecting a browser, you know, so the customers on your website, they're selecting what they wanna purchase, and then you redirect them out to that third party to make the payment. And then after the payment's done, they get redirected back to your site. Mhmm.
If that happens, these requirements don't apply to you Right.
Because you're not really the target of these types of attacks.
But for ecommerce merchants who have outsourced the collection by implementing a third party iframe, which is a little piece of code they put on their site, then when I'm a customer on your site, your your web server is saying, hey. You know, this is what I want you to display to the user. I want you to go out to this, you know, website and pull some code here and go out to this other website, pull some code. Go out here and pull in this iframe that's coming from the payment gateway.
These controls are to look at all of that code that you're telling my browser what to load. Mhmm. Because if if one of those third parties gets compromised or those code repositories and you tell me my browser, hey. Go over here and pull this compromised code in. Some of that code might, you know, might be also skimming or scraping the same information. My my payment data that I'm putting into that iframe on your site, another another piece of code might also be taking that same information.
So as a result, there's some security controls where we need to really understand what are all of these pieces of code that we're asking our customer's browser to pull in.
Yeah.
And we need to have a way to check to make sure that there's no unauthorized changes or malicious code that's being introduced into that environment. And that is a weekly check that or at least weekly, check that'll have to be done. So a big change for an SAQA, customers tend to not they went to SAQA because they didn't want to have to deal with a lot of compliance, and maybe they don't have a lot of technical expertise there. So for some of these merchants, you know, this is gonna be a very heavy, very technical lift for them to to deal with.
Right. And, you know, I think there's another gotcha in there where some universities are creating that web page that hosts the iframe and so, of course, they're gonna be responsible.
There are some who have a third party create that web page that hosts the iframe.
And and here's what I'm seeing a lot is that third party that creates the web page that hosts the iframe will tell universities they're not in scope for PCI.
Yep.
They'll they'll tell them there's nothing there that they need to be doing and it's absolutely not true because if they're unaware of this protection of that page, the issues that we're seeing there, they're gonna put the university at risk. And also, the university might say, well, is this really that big a deal? Can we just take a self signed service provider SAQ from them? And I'm gonna say you shouldn't.
It's a big risk. So this is one of those things that I would like to see when we start talking about targeted risks analysis which is part of four point o. You need to do an analysis of risk. If you have a third party that's hosting that webpage and they're gonna give you, a self signed SAQ, I don't think in a lot of cases, they have enough expertise either in cybersecurity or in PCI for you to be able to to successfully take that and say, yes, this meets the the the risk appetite of the university.
And and that's gonna be another difficult thing because a lot of these little departments have been working with, you know, this small, mom and pop shop that does that, pay that hosting for them. And so, that's going to have to be a conversation where groups are going to have to recognize this is an actual risk to the university because that's where we're seeing breaches happen.
Which that actually reminds me of another SAQA change that really doesn't hit any of the list that the council says, oh, here's the changes.
Because it's not a new requirement and it's not even a requirement in per se, but every every self assessment questionnaire has an eligibility to complete list Yeah. Where it says, you know, to be eligible for the SAQA, have to you know, and there's, like, four or five statements where you have to be able to check a box saying, yes, this applies to me. Yes, this applies to me. One of those statements that changed just a little bit, in version three two one, it says, you know, my third party providers who I am outsourcing the collection and processing of payment data to, they're PCI compliant.
In SAQA version four o, it says that not only are they compliant, but I've received, you know, their attestation of compliance. So we can't just, you know, take their word that they're PCI compliant. We can't just we can't even look at, you know, like the Visa Global Registry. We actually need to see some type of validation that they are PCI compliant.
Technically, like you were saying, we we can accept a self validated SAQ from a third party provider, but merchants really should realize that there is risk there.
If, you know, if if they're allowing a self validated service provider, some of them are more conscientious than others. Some of them might be trying their best and maybe just not understanding the requirements. But too often in the SAQA world, we do get those instances where the third party says, hey. I don't store process or transmit. I don't I'm not in scope at all even though they're the ones hosting, you know, this website that has the payment iframe attached to to it.
One of the red flags there is if you ask your hosting, provider to give you an SAQ and they give you an SAQ a, and they don't they don't give you something from a service provider perspective, that's a big red flag. It tells you they really don't understand, enough to be able to give you a self signed SAQ. So, I think we're kind of focusing on on the SAQA a lot right now because this is where I think we're going to see some real challenges to universities, and it needs to be thought through carefully at this point.
And it is the FAQ that has seen the most changes Mhmm. With the version four change. You know, the SAQ B, the P2PE, the B-IP, fairly unchanged.
Right.
You know, there there are some other ones like the SAQ C-VT, the C, and the A-EP that have seen some changes, but most of the changes for most of our university clients is that the aids that are really going to be their big lift in CPI 4.0.
This episode is brought to you by our SecurityMetrics penetration testing team. They do a lot of pen tests. They do a lot, like, network layer, application layer, segmentation checks. They're very, very knowledgeable.
And, some of them have even won, like, competitions at Defcon. So you can rely on these guys to know what they're doing. Head over to www.securitymetrics.com/penetration-testing, learn more about pen testing. And maybe we should talk about, now some of the changes to the SAQ C-VT that they'll need to be aware of.
So these are people who are using the virtual terminal to enter in credit card, data from a system that's owned by the university personnel.
So what what there do you think people need to be aware of?
So the the biggest thing that I've seen there, you know, so I I guess first off, the the biggest problem at university that I see with virtual terminals is the fact that most CVTs on campus tend to be accidental. You know, they they've got staff that Yes. It should be an SAQA environment, but they're being overly helpful and they're using their computers to enter it. So first, we need to realize that, you know, if you're using a staff workstation to enter data or if you set up a kiosk, you know, that should be a CBT type environment.
But as far as the changes to version four o, there's with with PCI version four, they've made some policy enhancement changes. So so for each sub requirement, you know, requirement one deals with network security.
They they wanna know that you have identified who's in charge of your firewalls or who are who's in charge of your network security controls for that environment and what policies or procedures do they have to follow to help them to do that in a PCI compliant manner. Right. So that's a a new slight change that we're seeing in the SAQ CBT for version four.
We do also have some future dated requirements that have been on there. One is that, you know, we we've always had a requirement where antivirus solution needs to be installed on a CBT workstation.
We that antivirus solution now, there's a separate sub requirement that says, you know, if if you allow for, like, USB or any removable electronic media to connect to that CVT workstation, your antivirus needs to be configured to protect that as well. So you plug something in, it's gonna scan it and make sure that it's safe.
Phishing prevention. And this is a weird one for a lot of people that have been doing PCI for a while.
Usually, in the the PCI world, we're used to saying, okay. What are the systems that are in scope, and then what controls do we need to validate on those?
In PCI version four, phishing prevention has been brought in. And, usually, you know, the way that we prevent phishing attacks is by looking at the email server. You know, how can we prevent these emails to get to from getting to our staff, or how can we, protect the staff if they click on one of these links that are in their email?
Yeah.
But, usually, you know, we've been trying for years. Hey. Keep your email system out of scope. You know? You don't want that in your PCI environment. But even though, you know, you can have your email system out of scope, we still need to help staff to, you know, be protected from these phishing attacks both through training and through technical controls. So that's one technical control that will be brought into the the CBT.
Yeah. And I think it's important because phishing social engineering in general is just exploding. You know, that's Yeah. That's one of the the other places where we're seeing successful attacks executed.
So Surprisingly enough, ten years ago when I started, people would complain about, I can't we have to train our staff every year.
We we trained them last year. Why do we have to do it again this year?
But now that people at their homes are getting these attacks all the time Yeah.
It's more understandable. I think that, yes, we we do need to make sure we're training our staff to know what's out there and how to protect themselves and how to protect us as an institution.
And do you know if it's done if it's done in a way that's applicable to the people, not just for their jobs, but also, hey, this is how it translates into at your home for your family, I think training becomes something that is valuable and people appreciate knowing more how to protect themselves from from being phished, from these social engineering attacks.
Mhmm.
So future what does future dated mean?
So so future dated whenever there's one of these standard changes and the council comes up with brand new security requirements that we haven't seen in the standard before, they wanna be sure that companies have plenty of lead time to get these in place. Because sometimes, this is going to require, you know, substantial expenditures depending on the environment and what type of equipment would need to be purchased and installed, or substantial changes to how, you know, you manage processes.
You know, like, you hopefully, your your phishing prevention has been part of your security awareness training for a while. But, you know, for companies that have a big training program, maybe it's gonna take them a little bit of time to get some of these things in place. So the council gives them a bit of lead time to get that in place. So it's kind of a, hey.
This is something we're seeing problems with. We need to address it. By March thirty first twenty twenty five, we need something to be put in place to protect against this. So it gives companies time to really research and figure out what is the best way for us to address this new security requirement, and put it in place.
So, hopefully, they're already in place or something that you can get in place pretty quickly. So I I would future dated requirements, I don't think should ever just be put off. Oh, we can worry about that next year. You know?
Get it in place if you can, but they do give you until March of twenty twenty five in case it takes you some time to get that in place.
Right. So let's shift gears a little bit and focus more on changes to The Rock. You know, one of the misconceptions I've seen is that people think the SAQs are different from The Rock in some way, but they're not. They're just specific subsets that the council has carved out based on risk associated to specific data flows.
But but the rock is the full set of things. Right? So understanding the rock can help people who are have multiple SAQs like a university environment. Right?
So I think it's worth definitely worth talking about. So, big picture changes, in the ROC. What are what are some of the kind of overarching changes we need to know about?
Yeah. So one of them we talked about a little bit with the CVT, and and it's just making well, you know, defining who's responsible to make sure security requirements are in place and those. So so we're in the rock. We see at the beginning of every section, you know, what what group is responsible for your firewall controls, or what group is responsible for hardening systems, or for for log monitoring and review. You know, we need to be sure the merchants or service providers are defining who's responsible to make sure these controls are in place and that we have policies and procedures that guide them. So that's one thing that you'll see throughout the full standard in in PCI version four. We kind of saw it in in version three two one, but it's much more formalized in version four.
It can't just be you have somebody responsible, but they're responsible for everything. Instead, there might be teams or individuals that are more responsible for passwords and others that are more responsible for encryption of data. Right? So Yeah. So it kind of refines that understanding a little bit, I think.
Yes. Yep. No. That that is a great one.
Another one that I've seen, and you mentioned, you know, the targeted risk assessment in PCI version three two one. And this is something, you know, both of those requirements are you know, the first time you do a version four assessment, they're not future data. They're they they just need to be put in place. But the risk assessment prior to version four in in PCI, there was a requirement that some type of risk assessment was being performed on an annual basis.
The standard did give some suggestions on different frameworks that could be used, but it's pretty much up to the merchant to decide what they wanted to do for the risk assessment. And it didn't necessarily say it needed to be PCI focused or, you know, they their risk assessment could mostly be, you know, what are we gonna do if there's an earthquake, or what are we gonna do if there's a fire? You know? So the in version four, they changed that overall, you know, risk assessment to targeted risk assessments where we're looking at specific items Mhmm.
Throughout the standard.
And most of them are items in the standard where they've asked you to do something on a periodic basis, but they didn't tell you how quick how you know, what periodic means.
Yes.
In version four, you decide what periodic means based on your risk. Right. You know? So for for terminal inspections, if you're a service station and you've got terminals that are out in the public space and there's not a lot of supervision, you probably have much more risk than a university environment where there's, you know, a small analog device on on Janet's desk, you know, in a locked office area. Okay. So based on your risk, you decide, you know, maybe, you know, maybe for Janet, a quarterly inspection of that device is totally fine.
Inspection would be negligent.
Exactly. Yeah. Their risk assessment needs to define that.
So that's something that we see that we'll see in PCI version four is those targeted risk And I know as an assessor, I'm going to want to see that documented.
I'm going to want to see, the why are you doing this at this frequency and and, hopefully, some sort of sign off. Like, this is what we who are closest to the idea of risk believe is is the actual risk for this. So like you said, you know, there's a there's a, locked drawer device. Right?
So there's some sort of a risk analysis performed and written up. And then somebody who is in in responsibility level, somebody in authority looks at that assessment of risk and says, Yeah, I can get behind that idea. I think that that's makes perfect sense for what you've decided to do. And then some sort of a signature, right?
So even though PCI doesn't define these things, as rational humans, we'd wanna look at why are we doing this and what gives us the, you know, the the uplift from doing targeted risk analysis, and and having it documented in that way. It also makes it so, okay, we've decided to do this. Somebody else over here says, well, why did you do it like that? Look, here's our decision.
And then on an annual basis, you can reevaluate it and say, here's what we decided last year. Does this still make sense based on how we do things? Oh, no. We've changed it in this and this and this way.
We think we need to do to to modify it in this way. And so you have kind of a of a of a visual aid for the decision making process regarding risk. Mhmm.
So Yeah.
And and those are really the two like, if if I were preparing for a PCI version for Iraq, you know, to to happen soon, those are the two, policy process changes that I would really focus in on first Yeah. Because they need to be put in place initially when we do that assessment. Some of the requirements that we've talked about, like preventing ecommerce skimming, there there's new requirements over, using how we deal with caching. You know?
We we need to have key cryptographic hashing in inversion four. You know? Some a lot of these new technical requirements we have until twenty twenty five. You know?
If if they're not in place right when we first do our our initial assessment, those are considered best practice. So so the first thing I would suggest though is looking at those things that we know, you know, what do we have to validate when we do our first PCI version four? Let's make sure those are in tight, and then let's start looking at these future data requirements and see what we could get in place.
For sure. Well, why don't we wrap up with a if it kind of a quick hit of the top changes by section.
So I'll give you a section. You tell me that the top changes for it.
Okay.
So starting with section three, which is all about protecting stored cardholder data, what what is what are the biggest changes there?
Yeah. So so the there's really two big changes that I've seen there. One of them in PCI version three two one, there was a requirement that said that if we're if we have stored credit card data in our environment and people can remote into the environment Mhmm. We needed to have controls to show, you know, who could remote into to that environment.
And but they the the controls that were there before, it said that, you know, people shouldn't be copying data, locally to their drive if if they're remoting. And PCI version four has kind of put a little more emphasis on that. We now it's not just a policy thing. We need to have technical controls that prevent someone if they're remoting into the environment to be able to download or copy pan data on their on their local systems.
Right. So one that's one requirement. The other one is that hashing, the the hashing algorithm. If if you are storing hashed pan data in version four, and we we don't have to go through your old hashed data and and rehash stuff, but, once we get to, you know, March thirty first of twenty twenty five, that hashing algorithm that you're using, if you're storing a hash of the pan, it needs to be a a cryptographically secure or a keyed crypto hashing algorithm.
But, also, if you're a university, why are you storing? Don't store.
Yes. That is not the expertise of a university.
Have somebody who has expertise in storing. If you need to store, use a third party. Yes. So I know. Not to get sassy.
I do have an opinion on that one.
Okay. Section four, which is all about transmitting cardholder data. What is the big changes we need to know about there?
Yeah. Really, the the biggest change there and there's a few areas throughout the report or throughout the rock where we'll see there's more of an emphasis in our inventories.
One place we see that is in section four.
We need to have an inventory of all of the encrypting algorithms that we're using, all of the certificates that we're using. So all of that, we need to have an inventory so we know what certificates we have, when those certificates expire, who gave us those certificate.
So that that type of information needs to be documented.
Right.
And we should be looking at that periodically.
And similar to that, but this is probably more of a section two item, in PCI version three two one, we had to have an inventory of our devices and our payment applications or applications in general. So it's hardware, software inventory. In PCI version four, that needs to be much more detailed. You know? We we need to have, like, end of life date for all of the software that we have in our environment, all the hardware environment. So, you know, if we have, you know, a Cisco ASA firewall, we should know exactly when that firewall is not going to be supported anymore so that we can plan for the future.
Yeah.
I I love the idea of more detailed, inventory because as an assessor, if I try to evaluate security controls in an environment but I don't know exactly what versions and what flavors of things, then there's different ways to to properly protect from us from a technical security standpoint. So having those inventories, it's gonna be very helpful. And also, I get how from the security team's standpoint, if they don't know, how are they properly protecting it? So Yeah.
It should be helpful. I know it sounds like a lot of work and it probably is. So Yes. Section five.
Section five, is all about, malware protections.
So what's what are the big changes there?
Yeah. So the biggest changes in five, we've talked about some of them, you know, like the scanning removable drive that's new to PCI version four.
The biggest one though, and we we talked a bit about this, is the phishing prevention. So phishing prevention, it's addressed in two different places in section five. One of it's from a training aspect. So your security awareness training needs to have, you know, social engineering and phishing prevention included in the training, but it's not just gonna be, hey. You know, we've trained you now. It's your responsibility as a employee to protect us from phishing. There needs to be some technical control also put in place where, you know, you're trying to help protect your employees from phishing attacks as well.
Right. So I came from the IT operations side of the house and and I have been as guilty of this as any, IT group. And that is sometimes the IT group will throw changes in and then the users are like, Oh, they changed another thing. But without properly socializing it. And so, it's almost like you're training your people to expect, oh, well, there's an unexpected thing that IT probably did when it's actually some sort of phishing or some sort of, an issue that they should report but they don't know that they should report it. And so part of that training is anytime you get something that looks a little suspect, then there should be a mechanism or a pathway or process that they can turn around and say to the IT group, did you guys do this? Is this legitimate?
And that also helps the the, the technology group turn around and say, all right, we we wanna not get six million emails asking us if this is legitimate. Maybe we should inform people first. So it kind of creates a positive cycle of of communication that makes it easier for employees to know when they're getting phished.
Yeah. I've seen I've seen a funny implementation of one of these teaching controls where, you know, they they send out these test emails to see if their staff are gonna click on the links. But the ones that do click on the link, they send them another email saying, hey. You know, you failed this phishing test by clicking on a link that you didn't know.
Click on this link and take this training. So you're asking them to click on another link that they don't know that's supposed to be there.
So Exactly. So maybe you have to kinda think of, you know, what is the best way to help my people learn about fishing?
What am I actually teaching them to do? And the people that that click on the fishing links, unfortunately, tend to be the people who are most conscientious and most helpful and are trying to do good work and are trying to do it quickly. And so then we turn around and punish them with more training.
So It's that or the people that like cat videos.
You know? Oh.
They're a good Yeah.
I do fall for a good cat video for sure.
Okay. PCI DSS section six which is all about well, it's a section six is a weird one because it combines patching with software development, which I've never thought that those two go together. But, you know, here they are in PCI bumping along together. So Yeah. What are the top changes for section six?
Yeah. So this is another area where we're seeing inventory changes or enhancements. And one of them is what we talked about with the SAQA.
In addition to having, you know, that detailed inventory of all of our hardware, software in the environment, we also need to have an inventory of any third party code that we're including on our sites.
So that's probably the the biggest change that I've seen in section six. One of the another change I, noticed in section six, when it came to patch management, PCI version three two one really focused in on those high and critical patches, making sure that those are patched within thirty days of the of a a patch release.
And and then everything else, you know, should be patched at some future date. You know? But it it didn't really dive into that. ECI version four, and and this is another one of those targeted risk assessment things.
We need to know okay. So high end criticals, we do need to address those within thirty days. How quickly should we be addressing our medium and lows? And that's really your risk assessment that should be defining that, following your policies and processes.
Right.
That's that's the biggest changes that I've noticed in in section six. Agreed.
So, section let's jump to section eight. So, authorization.
Yeah. So section eight, one of the big ones that will that universities definitely will come across, anyone that's using a password to log in. For a long time, the the PCI standard may have been a little bit behind from a security standpoint in the length of a password.
So it used to be seven characters by twenty twenty five, so we still have quite a bit of time, but we'll need to increase to twelve characters on those passwords.
The other change that we're seeing is multifactor authentication.
In PCI version three two one, there was a requirement to have you know, if you're remoting into a CDE environment or a CDE system, somewhere along that authentication change, we would need to have multifactor authentication in place. So, you know, if if you first connected to a VPN and, you know, the VPN enforced multifactor, then you can, you know, remote desktop onto a system, and you wouldn't have to do another multifactor.
In PCI version four, we need to have multifactor authentication in place anytime you're remoting into a network. So if, you know, if that VPN is putting you on the CDE, multifactor is needed there. And then even in the CDE, if we then remote onto one of the servers in the CDE, we need to have multifactor in place for that as well. So in some places, we may need to have add a multifactor authentication where maybe it wasn't in place under version three.
Right. Right. And so a lot of people get confused about what what multifactor actually is, and I know this isn't a multifactor podcast, but I just I think it's worth just saying. It's it's it's very simple. It's something you have, something you know, something you are. And so, something you have infers something physical, but sometimes we allow the digital token.
Right.
Something you know is usually username password and something you are is typically some kind of biometric. So, a facial scan or a fingerprint, something like that.
And so, it's not like you can't have Multifactor is not, oh, I'm gonna do a password here and then I'm gonna do another password at the next step. No, that's something you know and something you know.
And Yeah. The reason that we want different types of things is somebody, you know, just kind of calling back to that phishing idea. Somebody can get out of you something you know and something you know.
They can, you know, you get in the right situation and then you're spilling all, yes, this is my password and this is my username and oh, and here's You need the SMS code? Here, let me read that off to you, right? And so Right. So if you kind of think about, where multifactor authentication is applicable, you're gonna wanna do a little bit of a threat assessment, threat analysis there, and kind of put into place what type of MFA is really going to be secure for for that access to the CDE. So that's for what it's worth.
The other the other big change I'm seeing in version four assessments when it comes to section eight is they're putting a focus not just on user accounts, but also system and application accounts.
Which is great.
So, you know, the the passwords that are used for for those system accounts and even the permissions that are assigned to the system account, there needs to be a process place where you're periodically reviewing, you know, what system accounts do I have in place that should be inventoried? What permissions are assigned to each of those accounts? And are those permissions appropriate for the level of access that that account really needs?
Mhmm.
And how am I handling authentication for those application or system accounts.
And I think that's a valid, addition or or, kind of bulking up on that one because, system and software passwords are kind of invisible to a lot a lot of people. They don't really look at them. So that's a good addition.
Once they put them in, they kinda forget they're in the air. Forget in my program.
Mhmm. Alright. Okay. Moving on to let's go to section ten.
Section ten is all about logging, monitoring, and alerting. And so it's a super important section.
What are you seeing there for big changes?
Yeah. So the biggest one and this shouldn't be this this is one of those, requirements that maybe, you know, we shouldn't have been doing for a long time. But in in PCI version three two one for log review, it could either be an automated process or a manual process, review process that does any good.
That's insane.
By twenty twenty five, you can't say, oh, yes, I'm manually looking at all of my logs, and that's my log review process.
Uh-huh.
There needs to be an automated solution, some type of SIM solution or, you know, where where AI or whatever. Some some solution is looking through the logs for you and saying, hey. This is something you should look at as the human. You know? So we're having the computer help us to find the problems that we should be looking at instead of us reading through all of this stuff.
Otherwise, it's just too hard to find indicators or compromise. When you're doing it manually, it's just almost impossible.
Yeah. So that's a big one. The other one and this is also for for merchants. It is a new requirement. For service providers, it's not.
In version three two one, there was a service provider only requirement. We were we were looking for critical security control failures. You know? So like our our ACLs or our firewalls, our, our our logs, review solution or our FIM, you know, all of these critical security controls, our antivirus.
If if all of a sudden our our antivirus agents are no longer updating, we should get alerted to say, hey. There's a problem here. Look into that. If if we're you know, somehow our firewall gets stuck on a open any any and just any traffic is going through. You know? There there needs to be some way that we identify when one of these critical security controls fails, and then we need to have a process where we go in and not only fix it, but we identify, okay, how did that fail? Is there anything I can do to prevent that from failing in the future?
I think that's a a a valuable, control, especially the what went wrong and how do we fix it in the future?
Right. That root cause analysis. You know, something that comes into play there.
Alright. We have only two sections left. This this, section, section eleven, I think is is one of the most important sections because it's all about the running reports, running scans, doing test testing and proving that your configurations, your your policies, your procedures, your your, you know, everything that we've talked about up until now proving that it's actually working. So, section eleven, what are the big changes there?
So one of the the big change I think the biggest change that people will run across in section eleven is our internal vulnerability scans. You know, they have been a quarterly process. It still is quarterly, but now we're looking for authenticated scans.
And the the biggest difference there is, you know, unauthenticated scan is basically one computer kind of looking at another computer from afar off and saying, okay. What what ports and services do you have open? You know, is there anything that I can see without being led onto that system where I can say, oh, you know, here's a vulnerability that needs needs to be identified, which is a needs to be identified, which is a valuable thing. You know?
They and they've been great. Authenticated scans just takes it one step further where that scanning engine is either authenticating to the device and scanning as an authorized user on the device So it sees everything. It knows exactly what software is installed on that thing. It knows what patches have been installed.
So it nothing's hidden from that point. Or so it's either logging in or there's an agent sitting on the device that's scanning from inside of the computer itself and saying, here's all of my badness. You know? Come and pick me.
So so that's that's gonna be a new one.
And this is one area, like with the ASV scans being added to the the SAQA's.
Right. If I was in SAQA, it's in the SAQA, I would still do it. You know, the vulnerability scan is probably one of your it's a great way to protect your ecommerce servers.
Even though it's not an SAQA thing, do it. Yeah. So that that's one big thing. And then the other big thing, and we talked a little bit about this with the SAQAs, is that periodically scanning or checking all of the changes for any if you have an ecommerce website, any third party code that's included, that needs to be scanned. And and this is different than, like, file integrity scans because code does not reside on your server. This is code that your server is telling my browser to load. So so this needs to be really scanned from the endpoint standpoint where you're pulling that in just like your customer's browser would, scanning it, looking for any changes, looking for anything malicious, and that needs to be done on a weekly basis.
Right.
Okay then. That leaves us with section twelve. And section twelve is always about a lot of documentation and training and that type of thing. So what are what are the big changes there? The first one is my favorite one.
Yeah. So the first one and this again, it it shouldn't be new to anybody because it was part of the executive summary in version three two one, but scoping.
Yes.
Performing a scoping exercise, annual scoping exercise for merchants, semiannual for service providers. But having an exercise where you're looking at your whole environment saying what are the ways that we're receiving credit card data, what systems does it touch, where are we storing data, where are we sending data out, you know, going through that whole process. So you know, you know, the the people and the systems that are involved in your payment environment and you know what controls need to be put in place. Because of the fact that that wasn't a requirement, too many merchants and service providers were relying on their QSA or their assessor to do their scoping for them. This really is something that the merchant or the service provider should be doing internally, and then their assessor should be validating that they did a good job.
Exactly. And I love this one because, again, it gets back to knowing what to protect. So, if you have a good understanding of scope, then you have a good understanding of actual threats and vulnerabilities and what controls should be in place to provide security. So it it for me, that's just the juice of the whole thing.
What are we what are we protecting? What's your scope? Yeah. Love the scoping exercise. I know that sounded super nerd to you guys.
I also like me a good Excel spreadsheet. So Yeah.
Alright. So what's the give us our last big top change.
Yeah. So there there's another new requirement that deals with what do I do if I find credit card numbers being stored somewhere where I don't expect them to be stored.
So so this is very similar to in requirement eleven, there's a a requirement where we're looking for unauthorized wireless devices.
And it says we should have an instant response plan that says, what do we do if we find an unauthorized wireless device plugged into our network? For this requirement, there should be some type of process where we're looking for this data.
Uh-huh.
So we're scanning our our logs to see if we're for whatever reason, our ecommerce server's popping full payment data into our logs or we're we're, you know, we're scanning our CVT workstations or, you know, scanning places where we really shouldn't be seeing stored credit card data. But if we do find data, there should be a defined response where we say, okay. You know, it's and it's kind of that root cause analysis. How did that data get there?
What can we do to prevent that from happening in the future? How long has that data been there? Has anyone had access to it? So you we kind of you know, there there needs to be an instant response process, a type Right.
Tied to this as well.
I think it's a great addition for four point o.
And I know we've had a really long conversation. It's been pretty in-depth. If you stuck with it so far, gold stars all around.
But I don't I think we need one more topic before we close because it's it's it's new and it's different. And people are saying, how is this help me understand this. And it's the customized approach validation method. I don't wanna dive super deep into it, but I do wanna give people a little bit understanding of what that is.
If you're a university, don't do it. Just kidding.
There we go. Alright. No. I actually agree with that statement, but maybe we'll tell people why.
Yeah. So so customized approach, it's this is different than a compensating control. A compensating control is where for whatever reason, you know, whether it's financial reasons or or technical reasons, we cannot meet a specific PCI requirement the way it's written. So we we find out, okay, well, this requirement was defined to help prevent what, you know. So we define what it was designed to prevent, and we put in our own controls that help us to achieve the same status.
Right.
The difference here with with the customized approach, maybe we have something that is better than what the standard is asking for.
Yeah.
You know, it's cutting edge technology.
We have we have a better way of dealing with the same re the same vulnerability or or the or the same threat.
We can go through and say, this is what we're doing. So so we're looking at the original control. We're understanding what it's trying to prevent.
And then we we are writing, you know, this is what we have in place that that helps us to prevent that, and we think it's better than what the PCI standard is asking us to do. And then we're gonna work with our QSA. The QSA is gonna look at it and say, yeah. I think that makes sense. This is how I'm going to test to make sure that you're actually doing what you say you're doing. So they need to come up with some some testing requirements, and then all of that kind of needs to be packaged up together.
So this is something where the the merchant or service provider is working in conjunction with their QSA Mhmm.
Or with AQSA to define this customized approach and to define the testing process.
Right.
The reason why I said with AQSA and not their QSA is if your QSA helped you to define that customized approach, they should not be the QSA that's testing it to make sure you're actually you know, that it's that it's valid. Yeah. So as that you know, a different QSA should be doing the testing so that the QSA is not testing their own work.
Agreed. Agreed. So it can't be used for SAQs. You it can only be used for rocks. And let me give people a specific example where they're saying, well, what do you mean by another way of doing things? This is not just best practices.
This is there are organizations out there that have very, carefully defined they're following NIST CSF, for example, or ISO one two zero zero seven. Right? So, no, one two seven zero zero one, sorry.
You guys know what I'm talking about if you're using it. But so there's a very specific defined, way that they have developed their security program.
And they want to follow that. And in a lot of these cases, their PCI is very, very gentle with people. It's like the minimum bar for protecting information. Right? So there are a lot of places where they're they don't wanna meet the minimum bar. They have a very, compelling reason to meet a much stronger security standard.
And so we don't wanna come in and say, well, you have to do PCI.
This is what the customized approach is, kind of respecting that understanding that yes, there are other very secure ways and we don't wanna have you have to carve out your PCI environment and make it less secure than your the standard way of doing things.
Yep.
Alright. Anything, we've missed for today before we wrap up the the whole conversation?
Well, PCI version four is here, and it's coming. You know? So version three two one is gonna be retired.
I don't I don't think for most merchants, this is not going to be all that big of a hurdle to to get PCI version four compliance if you're already compliant to version three two one. So so don't be afraid of it. Start looking at it. Start preparing for it.
For for most especially our university merchants, if you've already done a good job of descoping and simplifying your environments, moving to SAQ P2PEs and A's, you know, trying to not store credit card data locally, Really, the the shift to version four, there there will be some work involved in getting there, but it doesn't have to be, an onerous undertaking. It's something that you can do. So so don't don't put it off too long, but but you can get there.
Great. Thank you so much for spending the time today to talk about it, and, hope I get to talk to you again soon.
Yeah. Thank you, Jen.
Alright.
Bye. 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)
