Watch to learn about the new and evolving requirements of PCI DSS 4.0 and how to prepare for PCI DSS 4.0 implementation.
SecurityMetrics VP of Assessments Gary Glover (CISSP, CISA, QSA, PA-QSA) and Audit Director Matt Halbleib (CISSP, CISA, QSA (P2PE), PA-QSA (P2PE)) will discuss:
Check out the Shopping Cart Monitor Demo
Learn more about Ecommerce Security Solutions
This webinar was given on April 1, 2022.
Hello. Welcome.
Thanks for tuning in today. I am Gary Glover.
I am the, vice president of our audit team here at Security Metrics, and we have I have with me Matt Halbleythe, the Adonis of audit.
And, he's gonna be, helping me as we discuss, PCI four o. Matt, exactly what do you do for Security Metrics?
I'm the audit director. So been a p c QSA for about well, fourteen and a half years.
Fourteen and a half years. Exactly. So we have, between us, probably over thirty years of experience, let's say, right, and, in PCI. So, hopefully, we'll have a few things that we can say. And, by the way, we know it's April Fools' Day, but it is no joke, folks. PCI DSS four dot o is here.
And now what? What are we gonna do now? What what does what does the community do? So today, we're gonna go through some highlights of some of those biggest changes, that have happened in PCI DSS four dot o.
This is not going to be an exhaustive review of of the all the exact changes, the wording changes, and everything from three two one to four dot o. We just really wanna focus on some of the things that are gonna be the the biggest things, the ones that you could, would, should be doing now maybe as Ford Auto comes out.
And as a reminder, during this webinar, if you have any questions, be sure to send them through the, the webinar interface there, and we'll be doing some questions at the very end of our Mhmm. Of our discussion today. One thing I wanna point out before we get going here is a couple of things. Note, all of the changes in PCI four o are are are not all immediate.
There's different kinds of changes that are coming out in in four point o. There's things called so I'm gonna go through some of those. There's new or evolving requirements. Some of these new requirements or evolving requirements will be effective right away as soon as four point o comes out.
So in other words When you start doing Ford Auto doing a Ford Auto assessment, then you gotta fulfill that.
Now many of those are gonna be future dated till March, thirty first of twenty twenty five as as being something that's a best practice until March of twenty twenty five.
There will be some clarifications or guidance changes in the standard Yep. That are very helpful. Always as we get to have get to go the council gets to go over this the standard wording and stuff. They they are, you know, using all of our comments in the industry to make sure there are clarifications, adding new guides, etcetera. There is some structure and some format changes in the standard itself. We'll be talking about that and showing you that as we go on here today.
You know, the changes update the standard, and all of them are good. None of them are really far out. We're gonna talk a little bit more about that and give you kind of our opinions on some of these things. But, you know, don't panic. Keep calm.
Keep focused on three dot two dot one for now and, the tasks that you have. Don't don't lose focus. Make sure that you're still working on your security, controls. And as four dot o gets more and more familiar to you, then you can start rolling in some of those things that'll be coming. There's plenty of transition, time, and we're actually gonna be showing you a timeline, on a slide at this point. And, you can see there that in March of thirty March thirty first, you know, just yesterday, the standard was released.
And what was released is, summary of changes document, the standard itself, the report on compliance template. So the things that that Matt and I and all our assessors will be using to actually conduct the audits and filling out and making the report, that's gonna be released. So that's gonna be helpful for us. We're excited about that. Absolutely.
As well as the AOC, the attestation and compliance documents, they're gonna be out. They they were out too as well. So, what about the SAQs? The SAQs, as we heard from a member of the council, Lauren Holloway, posted something a couple weeks ago saying that they will be coming out soon, and they will be reflecting the four dot o changes.
So SAQs updated to four o will be coming out soon, and, we'll probably be doing another another webinar, maybe a a blog or something on that as those come out. Yeah. So now when we talk about the future, when is PCI DSS three dot two dot one gonna be done? As you can see here on the chart, that's March thirty first twenty twenty four.
How many years is that, Matt?
So you get two years?
That'd be two big years to work on, three two, you know Your transition.
Your transition to four dot o. The one thing that you probably shouldn't do is just say, well, I'm gonna stay in three dot two dot one for two years until I'm forced to go to four dot o. That's probably always a a little bit difficult, more of a transition there.
But, Well, you know, I do appreciate that on those future data requirements, they always put it's a best practice until.
Right. Exactly. So they're there. They're there for you to start looking at, and you should be doing them.
Starting on the requirement.
Actually, it says, as you can see on the chart here, March thirty first twenty twenty five. So that's three years until all of the future dated ones, which are gonna be the ones with the biggest change.
Yeah.
Some of the ones that are a little bit harder.
So plenty of transition time going on there.
More than they've given in the past, actually.
A lot more. A lot more. This has been they recognize this is gonna be a big transition. It's a big number.
It's from three, two, one to four. Right? It's a big number. So, so when can someone actually get a PCI DSS four dot o assessment, man?
Yeah. Great question.
You know, really, you need to start working on it, anytime you want. Now you don't have to transition immediately from three two one to four dot o as soon as as soon as possible.
As a matter of fact, I wouldn't even recommend that. I would recommend you read all the documents, talk to your QSA about what the transition means to you and your environment. Hopefully, they know what your environment looks like and can help inform your decisions. So, you know, as QSA's, I like to say, I can tell you the implications of your change, but you're the one who has to actually, of course, make the change. So, you know, you might want to wait a little bit before you just dive in and start saying, oh, we're going all in for four dot o.
But, you know, now's the time to start thinking about it, but make it an orderly transition from three two one to four dot o. And even in the end, really, QSAs aren't going to be able to do four dot o until we've completed the training that all QSAs have to go through and until they've released, you know, maybe all the Q or the SAQs and things too. So it'll be what June, July time frame before we could even really consider doing the first one.
That's what we hear.
And and that means every QSA who needs to conduct or wants to conduct, QSA being an individual, not a company Right.
An individual has to take some training. I think it'll be an online set of training, for us. Council says that's coming out in June.
So, we won't be even authorized to do it until we've completed the training.
Well.
So don't be thinking that you've gotta start today working on your four point zero assessment if your if your due date is just in a few months or half a year or something like that.
It's not an immediate thing. No.
So what then can you start doing today is a question I think that we'd like to kinda talk about. First, I think the first thing you should probably do is to just breathe. If you have one of those apps on your iPhone, on your iWatch, go through that, breathe a little bit, relax.
It's gonna be okay.
You know, it's really, keep calm and carry on.
And carry on. Exactly. So I think, you know, what I'd first do, initially, I think if I were in charge of, my own company's assessment and worried about four dot o, I'd probably just start by spending some time reading. Maybe get a fire started, get some snacks, whatever, you know, and and sit down and start reading some of these documents.
Where do you think is a good place to start for them, Matt?
You know, honestly, just sounds kinda simple, but, start at the beginning.
And I mean I mean that in all seriousness. The executive summary has a lot of good information in it. And people really need to go through, you know, start with the summary of changes document because it just gives a nice overview, but then move into the executive summary. So that's where I'd start.
Exactly. Before so the full standard is broken up into various areas. The thing that we deal with mostly, I think, in as QSAs and most of you out there are is the big matrix of all the requirements. But there is a ton of really good information at the beginning of the PCI standard that is gonna give you a little direction about, you know, some changes in four o, some enhancements to sections like the scoping guidelines. So don't just jump right into the requirements matrix. Make sure that you're actually taking your time going through those sections.
The the scoping guidelines was a good one.
What other ones did you like?
So they have a nice section on, making PCI part of your business as usual. That's a really good one. They give details on, so they've always defined certain requirements have a time period associated with them, you know, daily, weekly, monthly, quarterly, whatever.
And then there were always some of those requirements that were called periodically.
And but they never really gave a great definition of what Yeah.
Periodically of our existence.
What is the period?
Exactly. It was kinda left to the entity to determine that, but not a lot of great guidance on that. But in four point zero, they actually added a definition, if you will, that says, you know, the periodicity of that review is determined by a risk assessment. Mhmm. And we'll talk more about risk assessments a little bit later, but you need to become more familiar with conducting risk assessments that, targeted, you know, changes and things.
Right. Right.
That'll be a big deal.
And I I think, you know, another phrase that is used often is significant change. Right? You know? And I think they've done a good job of of, you know, defining what a what a significant change is. It's always been it was one of those hard ones.
Yeah. That's true too. They added a lot better information into, here's what we mean when we say significant change, you know. Oh, you're changing out a firewall or a server or whatever. That's a significant change.
And one of the biggest areas, I think, in the introduction that's gonna be important, for you to understand, perhaps if you're a larger organization, a large enterprise with their own risk assessment team and and all kinds of stuff would be data, and just details on the defined approach and the customized approach and understanding the differences between those. We'll talk a little bit more about that as we go on here. Yeah. You've all heard about the customized approach in previous podcasts and releases by the council, etcetera. And so, we'll continue to learn more about that and and increase our understanding of that thing, as we come along here.
You know, one thing I'd like to talk about, so we went back, talked about reading the executive summary and things, but there's also a change a little bit anyways in the format of the standard itself. It's always That's a requirement matrix section. Yes. Yeah.
So we have a slide on that we're gonna probably put up.
So there's always been the three columns, but they've actually taken even column one and broken it down a little further. There's the requirement itself, then there's a little section about the defined approach and it says here's what the intent of the requirement is. And so you know if first column is the requirement, middle column are the testing procedures, which is really instructions to us as QSAs on what we're supposed to look at when we say is this in place or not? Oh, I interviewed this person. I saw this system, this setting, whatever.
So it's important for that. The third column is just basic guidance on, you know, good information about here's what we're trying to do in this requirement. But if you in reading that testing procedures in the middle there, sometimes there's there's quite a few of them and it can get you can kind of get lost in the weeds if you're not careful. You can always go back and look at that defined approach.
Customize. There's a customized approach. Yes. Sorry. The customized approach.
Section. Right? Yeah. You can see that on the slide here. There's a section that's just said the intent of this requirement is the cusp for the customized approach.
Yeah. So it gives a nice overview of what they're trying to accomplish with that particular control objective.
So, so yeah.
And I noticed even in the guidance section, they've actually kind of put there's always some kind of here's a a point, here's a point, here's a point, and they kind of follow that, pattern throughout. They'll talk, here's the purpose, here's the guidance, here's, you know, things like that. So we've we've I think they've done a good job at getting that standard ready a little easier to read.
Yeah. And in addition, in the summary document, they're saying which ones are future dated, but also as you're reading the actual standard Right. In that first column at the sometimes, yeah, you don't have to break over to the next page or whatever. It'll say when it's a future dated requirement.
Exactly. It'll be down at the bottom there. So now make sure that while you're reading then, you you know, doing and you're staying awake, of course Yes. Yes. While you're reading. But as you're reading, make sure that you're noting any requirement changes that may affect you and your current controls.
It's you know, highlight whatever. Start looking for things. Start thinking about what you're doing and how it might be changing. We're gonna be pointing out some more of those during the as we continue on this webinar. So, just to get a little bit more on the customized approach, I wanted to make sure that we're clear we've probably said it before. You may have heard it before, many people out there. But, the customized approach is a way of satisfying a PCI requirement that that may not exactly match what you're doing in your system, but you have maybe a unique set of controls that you think is just as good or better than the requirement.
You know, a lot of times, I think people think, well, I'm gonna use a customized approach because I think it's easy, and I think it's cool. And I don't think that's gonna be very hard. Now let me say, make sure you read a lot of the details about the customized approach that are coming out in four dot o. It's not gonna be easy. It's not for the faint of heart. It's for large organizations mainly that have spent maybe a whole lot of money on a on a on a solution that doesn't quite match the word of a requirement, yet it may match the intent. Hence, that section that says, you know, the customized approach intent or the customized approach kind of objective, in the requirement.
Yeah. I I would just reiterate what you were saying about it. It's it's not for the average person. It's it's really, to meet the intent of the requirement and everything and do it in the customized approach way, requires a lot of work and effort to define what the actual requirements are, to define how to actually measure that they're in place and functioning.
It's actually a pretty significant effort just to do one requirement.
Yeah. And and just to be clear, it's not on Matt and I to do that. Right. Yeah.
There's a lot of work that needs to be done. Main the main chunk of work is done by the entity being assessed. It's not being done by the QSA. So you think, well, no.
I wanna just tell my QSA to make this customized approach. Go. Right? That's not gonna be something that's gonna happen.
There's a big lot of there's gonna be some forms. There's gonna be guidance. There's direction. There's all kinds of stuff.
So it's not for everybody.
No. And I you know, we mentioned the risk assessment earlier. And we'll talk more about it later. But the risk assessment, or performing a risk assessment customized approach is part of defining A pretty big part.
Yeah, exactly. A big part. Yeah. And not just a simple back of the napkin kind of thing that you did in fifteen minutes.
It's it's a, you know, a very structured formalized risk assessment. Exactly.
So here's the question maybe a lot of people are having out there, Matt. Why do we need a PCI DSS four dot o? Isn't it hard enough already? What what are your thoughts and feelings after reading the standard?
You know, actually, I like the standard. So remember that I think it's important to remember that there's no real changes to the basic security principles involved. But technologies are always evolving.
The tactics of our adversaries are always evolving.
And so sometimes we need to update things to come in line with modern technologies and things.
You know, containerization and stuff just didn't exist a few years ago, really. I mean, to speak of, you know.
And so, yeah, there's things that have to be modified in the standard to help it going. The basic security principle is the same in terms of, you know, whether you go with the CIA triad if you're a CISSP type person.
They're not just trying to make it harder.
So the council's not out to get everybody out there just to make this make them feel like they're getting their money's worth? No.
No. Definitely not. You know, it's not one of those that we're just changing it because we wanna freshen it and get new eyes on it and stuff. It's trying to update it and, make it more in line with what's where the industry is going right now.
Exactly. And as security professionals, I think we could probably say seal of approval. It's all the changes have been really good.
Some of them are gonna be, you know, maybe a little hard, but nothing is just out there. It's all good stuff.
And so feel good about that Yeah.
As you learn about PCI four o. Feel good that it's moving forward. Don't get, balled up into why is it changing at all. Right?
Right. Yeah. Exactly. And and you have time. I mean, three years before other things ever give us. Yeah.
So, there's these, you know, we talked about risk assessments a little bit. We're gonna talk a little bit more about that right now because it will kind of apply to a lot of things coming in, in four o. And let me I'm gonna explain kinda what the expectation was in the past in three dot three dot two dot one and before, you know, as an assessor, you know, early on in the cowboy days of PCI, you know, it just says conduct a risk assessment, and people kinda go, well, what really is that? And we know, you know, as professionals that there are rules, there's guidelines about risk assessments, but there was never really a whole lot of guidance given to, PCI DSS entities who are who are actually getting compliance.
And so in the old days, you know, we'd say, well, have you had a meeting or have you sat around a table or have you written a document or have you done something that shows that you've thought about the risks in your system? How did you do that? Explain to us. Right?
So we kinda basically go through and have them explain to it. And they say, well, we had a meeting, and here's the date we had it, and here's the presentation we used, or here's the result of that, and we think that things haven't changed or have changed or whatever. So it was kinda loosey goosey as far as whether it was being done in a in a in a real formal way or or not. And I think now the expectation is a little bit more.
What is the expectation now, Matt, in four dot o?
Yeah. Well, that's a good point because, like I say, you know, they always said you should use some sort of standard by which to to base your risk assessment on, but they didn't really, you know, other than saying you should you should do that. Right. They didn't force a lot of, formalization on it and stuff. But four dot o, you know, they've they actually expect instead of just, as you say, in the old one, in three two one, specifically, it was requirement twelve dot two, required you to perform an annual risk assessment.
Now, though, they're expecting, like, oh, you're making a change in the environment. You need to do a risk assessment on that. Oh, you're, you know, you're adding in a new firewall or whatever. You should do a risk assessment on that. So they're expecting you to do risk assessments on a lot more items. We mentioned on items that were, where it was periodical.
You have to define that periodicity in the risk assessment.
So looking at threats, vulnerabilities, impacts, likelihoods, all that, you know, to do a more formalized risk assessment maybe based on NIST or something, you know, eight hundred hundred dash or a year or one of the other. There are other, risk assessment standards out there too. But just make sure that you start to become familiar with those.
Figure out what your, you know, all your assets, IDs, and what your threats are and things. You know, you're gonna have to do it at least annually, probably for the whole environment, if you would, but also very targeted risk assessments. So, you know, make sure that whatever process you implement that, you can actually perform it on a broader scale or a narrower one if you're making an individual change or something.
Yeah. Exactly. And and I wanna make the point that this really does sound a whole lot more formal than it ever has been before. And it's not just quick annual meeting as I discussed, you know, kinda described earlier.
If you're not a large organization and you're working on, gonna start working on four dot o or thinking about in the future, you know, making that transition, if you have not had a whole lot of experience with a formal risk assessment or don't have a risk department as part of your entity, you may wanna get some help from a third party initially as you get going and learning how to do these things.
They'll help design and inform kind of your process and and make sure that you have a good handle on it until your own methods are developed enough to kinda continuously apply them. And as Matt mentioned, you know, and as we probably will mention over and over again here in our presentation, this risk assessment process is going to be needed for many of the new future data requirements, in PCI. And anytime you see the word period or curiosity or whatever, as we mentioned before, you're gonna have to say, well, what informs that period? It's gonna be my risk assessment, and here it is.
Yep. Here's the document. Here's the reasons why. And your assessor's gonna have to look at that and say, yeah.
Okay. That's reasonable.
Right? Yeah. You know, we'll talk about some later too about the changes in password requirements and things. But that's another one. If you're if you're gonna do a different, you know, password length for some reason, that's different maybe than the defined approach, that's one where you'd have to have a risk assessment. Right?
Exactly.
So I really think this is one of the biggest requirements, the biggest things that have changed in four dot o that really needs to be something to get a handle on early on in the process. So if I can talk directly to all you people out there, don't forget this one. This might be a big one. Start working on it now, and start learning about formal risk assessments because it will be a big part of your process going forward. So with that, that's kind of kind of our intro stuff. I'd like to spend some time now getting directly into the going in through the requirements. So now we're kind of into the matrix kinda section.
And, Matt's gonna start off kind of a a change that's on everyone, on every single one requirement.
Right. So you mentioned earlier there are some requirements that are future dated, some of them that take effect as soon as you start doing four dot o, because there are a few of those. This is one that I'd like to point out. In three dot two dot one, PCI DSS three two one, Ironically, there's a requirement 3.2.1.
So anyways, at the end of every section, there used to be a statement that says that the policies and operational procedures for this section are documented in use and known to all affected parties.
So one of the changes in four point zero is they pulled that specific requirement up to the very beginning of every section. And then they added one that says the roles and responsibilities for performing the activities are documented, assigned, and understood.
So that's a requirement that's in every section and it takes effect immediately when you start doing four point zero.
And it's not a future date.
And are documents generally easy for people to do?
No. Usually, documentation is one of the harder things for everybody to kinda get their handle on. And so when when we say things like you're gonna have a new document that needs to be, you know, reviewed and and set up and thought about, It it is something I think that will be new to people.
It will. But it'll also be helpful because when it comes time to actually perform the assessment, if you sit down with your assessor and go, let's go over section three, you could look at this document and you go, oh, these are the people that are responsible for it.
You would know right away.
Yeah.
Who's if you've got the right people in the meeting.
So we'll help you plan your assessment, will help us in an assessment. Or if you're doing a self assessment, you're gonna know which people to talk about.
Yeah. Exactly.
Yep. Good. So let's go on to then section three. And, you know, when we look through the PCI, the changes document, section one and section two of four dot o, thankfully, didn't have a lot of changes that really we thought were big.
So we're giving you one and two. Don't worry about them. They're gonna be okay. Right?
Yeah.
So section three has a a couple of changes we wanna highlight really quickly.
The one zero one one of them was, in the past, there's always been kind of this loosey goosey thing. Hey. If you store sensitive authentication data before authentication, authorization, I guess, is the right word. Authorization is the right word.
It's always been, well, you should try to encrypt it or protect it, but it wasn't required.
And talk to the card brand.
Talk to the brand. Talk to the card brands and see what they want you to do. Now it's required. Now it's gonna be part of four point o.
It is a future data requirement for till twenty twenty five. However, if you have sensitive authentication data stored in your system before an authorization a did I say that right? Authentication. Authorization. Authorization. Authorization. They both start with auth.
Then, it has to be encrypted if it's stored for a period of time. You know, like, if the network goes down or whatever, you have to store that.
Yeah. And we're not saying you can store it long term. No. This is still no no storage post auth post authorization unless you're involved with, issuing or supporting issuing services.
Right.
So it's just in that weird period where they didn't use to define much.
Have anything. So now they've they've decided to add something. And they've also added and saying that issuers now have to encrypt the sensitive authentication data that they may be storing.
I'm guessing that maybe it's not a big deal for most issuers at this point. Sometimes it's a little harder if you've got, mainframes or whatever that may not have some of those capabilities or you're really worried about their processing capability or whatever.
Yeah.
So it may be a change for some processors. Hopefully not too many.
Yeah. I I hope not. But, you know, if you're doing millions of transactions or something, the crypto can actually add latency into the system. And so you're gonna have to look at, you know, either modifying your business process or adding equipment or something.
Right? So Perhaps. Yeah. The other one in section three that was interesting was, remote access technologies. If you're using a remote access technology to access the CDE, the card data environment, then you have to prevent the copy and relocation of PAN data, which is the count you know, the credit card number from those systems that you know, from systems that have access. So this is kind of like it's been mentioned, I think, and thought about before, but now it will be a requirement to get in twenty twenty five.
Well, it was a procedural control. Right. You could just have a policy that says, yeah. Don't do this.
Right. Now they're they want it to be enforced by some technology. And, there may be in your remote access software, there may be settings in that technology.
You know, things like Citrix, etcetera, have ways of preventing access to certain functions.
So that one, you know, it's it's gonna be maybe not hard, but it might be. It just depends on your current processes. Zip may be easier, which is something that we talk to people about a lot. It may be easier to change your process.
So you just don't have the ability to do or see the full card number in most cases or never remotely.
You know, it's just something that that we often talk to people about in lots of different areas of the standard.
Yeah, exactly. I mean, this is not the first time there's been a requirement that people went, what? You know? So like you say, really first thing I would recommend to anybody is look at your business process and see if you can re engineer it in some way. You know, way back when I first started, insecure protocols were not allowed to be used like FTP and things like that because, you know, they're clear text credentials and stuff. But yet I go to clients and they're like, yeah, but my bank, the only way you know, they require me to FTP stuff.
Exactly. So Those were the days.
But in the end, you know, the businesses or the banks and the businesses and everything started to modify their processes and use SFTP or whatever to send data. So it's a change, but it's something that, you know, it can be handled.
If seeing if if seeing all full data remotely is something that has just been the way you've done it forever, maybe think of another way to do it. Yeah. Absolutely. It might work. May not.
But And and in many cases, the banks are supporting alternate things like that now.
Right.
So So the other the last one in section three that we thought was big enough to mention was disk level encryption.
Used to be something that could be used to protect stored PAN, and now that is being removed and only allowed to apply to removable media. So like a USB drive or an external hard, SSD or something. You can't use it anymore on your computer's hard drive or any kind of nonremovable media. That's a twenty twenty five requirement. May hit some people, hopefully, not many. Right? I don't know that it'll be that big, but if you're using disk level encryption for protection, you may need to be to make some changes there.
One I'd like to talk about for a second though, section four, it it seems like a small requirement. They talk about, like SSL, TLS, certain things. You have to actually track them now. So you have to document and inventory them, determine their their periods of validity and, you know, when they when they're expired or whatever.
There's always been a revocation list and things, but you need to start tracking those now. And once again, this is that documentation thing. It's, you know, to go out and make the list, of what it is today is kind of the easy part. You could go through and look at all your websites and things and document them or if you're using TLS internally, you know, make sure you document all that.
But what's really implied by the requirement is that you have to have a process to keep those current and make sure that the items, you know, haven't expired. You didn't forget about one of them. So I think that's the more slightly more difficult piece.
Processed copies of it.
Yeah.
Yeah. Yep. Implement a process to go along with that inventory list.
And that's Section four. Section five had some stuff around malware and stuff.
It's now a requirement that it scan removable media, starting in twenty twenty five.
That would be a future dated one, but Right.
I think most antivirus probably did this or had the capability. It's just maybe it wasn't turned on for one reason or another or maybe on your server or something where you don't, you know, if you're sneaker netting things into your servers.
So that was one. Oh, yeah, probably the big one in five. It's a twenty twenty five. It's a future one, but you have to have processes and automatic mechanisms in place to detect and protect personnel against email phishing attacks.
Right, right. This is a new one.
It is a new one. Yep. And so it's kind of a big one. If you're doing your email in house or something, you may or may not have have all the controls in place for this yet.
If you've outsourced it, then you better start talking to your provider and see what sort of protections they have. You know, they're automated mechanisms for protecting against phishing attacks and stuff. So if you're if you're using one of the big, big providers, then, you know, they probably already have some things in place, But you need to you need to ask the right questions.
So it'd be something to start doing some research on and making sure you have the right tools in place Yep. To doing that. It's not you can't just say anymore, well, I've trained people not to click on a on a phishing email. Right?
No.
Our experience with that in in kind of running those kinds of attacks against some really good ones.
We've made some really good ones.
So Yeah.
They're not very They're not very People are not very good at recognizing. Right.
Okay. So moving on, section six. Boy, we're just screaming through the standard at this point. It sounds easy, doesn't it?
New to section six, in the old days, they said you need a web app firewall web application firewall, or you can have a process to kind of do code reviews as an option. Now that option is going away, and they will have a requirement for the web app firewall solution has to be required. And that's a March twenty twenty five requirement.
You know, in the old days, I think when when this requirement first was mentioned and came out in section six, people you know, WAFs were kinda new and and kind of funky and and There weren't even many of them.
Many of them, and and it kinda maybe impacted performance. I think we're a long ways past that now. So this one is probably a long time is incoming. It should have been it shouldn't be something that's surprising.
Now there are cloud based solutions that are available Oh, absolutely. That don't take up your processing power, etcetera. So it's something that's just gonna be coming new. Yeah. And you just have to have a WAF now.
All the major cloud providers provide options. Even even DDoS protection services have, Anyways yeah.
And, you know, in section six is kind of the development and development processes. Another thing that, needs to be is that you may have some code or some scripting on payment pages, and these payment pages are being used by ecommerce, skimming and all kinds of things like that, stuff going on there, page cards. So those there's no new requirement to review all those payment page scripts to confirm they're inventoried and authorized and that the integrity has been validated. This is a twenty twenty five standard as well or twenty twenty five future data requirement.
There's some really good guidance. We don't wanna get deep into it, but there's some good guidance given in the standard actually in the column talking about this one. So make sure you, mark that as something to review and think about. But that's gonna be a new process, that has to be instrumented Yeah. In your system.
And it'll be a pretty big one if you're It'll be a big one. Not doing it.
Yeah. Section seven, not much there. They're really just kinda tightening some out, account reviews, processes around reviews for systems and users and applications.
It is a a twenty twenty five thing. I don't think it's that big of a deal, so we're not gonna spend a whole lot of time on that.
It's it's the basic, role based access control stuff and, like you say, just tightening some things down. Exactly.
What about section eight?
Oh, yeah. There are some changes in section eight.
Minimum password length is moving from seven to twelve here.
Seven to twelve.
And that's that could be hard if you've got code that makes it, you know, seven only, right?
Yeah. And even there are some older systems if people are still using them where, you know, I have a max password length.
Exactly.
This is gonna be a problem for them. But it's a good thing, right? So alphanumerics still required minimum length of twelve.
But you know, it's it's honestly even at a personal level, I've increased the length of all my passwords.
Passwords are starting to become a thing of the past. We're gonna have to move into other controls as the future goes on.
We've we've talked about it for quite a while. Right? In the industry where there's always that talk about how to move past passwords, but haven't quite figured out how to do it.
So we're we're taking the next step, which is again, you know, baby steps.
But, yeah, because rainbow tables are out there that are publicly available that, you know, go out to eight, nine, ten characters even. So it makes you wonder what's privately available on that kind of stuff.
Another change in Section eight around passwords and stuff is service provider customers of service providers will now have to change their password every ninety days.
Mhmm.
If you're not using like, say, a multi factor auth or something. So if if it's a single factor authentication just as the password, then they'll have to to change the password every ninety days. That's a change. So if I'm logging into my service provider to see, you know, all the transactions I did or something.
Yeah, that sort of thing. So they're gonna have to change passwords on that. Now there is a caveat in there and I think it's kind of a nod. They don't state it this way, but it's a bit of a nod to the Zero Trust architecture type thing where if you're dynamically analyzing the security posture of the device that's connecting to your environment and you can guarantee the security configuration of that device and the individual and things, then then you wouldn't necessarily have to change the password every ninety days.
Right. Those things are that does happen. But it is a new new process, new systems.
Yep. Yep. And another big one.
Oh, yeah.
Which is a good deal overall.
But, multifactor authentication for all access to the CDE is coming. Twenty twenty five.
Twenty twenty five.
That's gonna be a big one.
It's gonna be a big one. Yeah. So if you read it, you'll notice it talks about servers, firewalls, workstations, web pages, all these different things, multi factor authentication.
Not just safe enough to be inside your network sometimes maybe.
Right. Exactly.
That access your firewall.
Yep. So there's big implications for that, depending on how people, you know, whether it's a work from home kind of thing or like you say, even inside the office, maybe people didn't used to require multifactor inside the office to access the CDE. It's gonna be required now. Right. Twenty twenty five.
Right. And with work from home coming to be kind of a pretty standard way of doing business, this is something people have to think about how they handle.
Yeah.
A little bit more than in section eight on multifactor authentication.
I remember reading that, again, in twenty twenty five, they've added some functional rules for MFA implementations.
So you can't just kinda say, well, I threw something out there. Now you have to say that it's not susceptible to replay attacks, can't be bypassed. Make sure that you have two different kinds of factors, no two passwords. That's kinda standard.
Yeah. That's They're just documenting that. And then, the one that's gonna be a little harder is the success of all the factors, has to be you have to have success of all the factors before access is given. So you can't know which one of those caused a failure.
If you type in a password and a code, you don't you can't be informed. Okay. Well, you got the wrong password. I'm not gonna send you the code.
Right. Right.
Like like some systems do. Is it maybe some people use you put in username and password, and then it asks on a separate page, you know, for the the token it sent you in in your SMS or whatever. That wouldn't be allowed under the new environment.
Or or else you can't get full access and known.
Know, another way to do it well, yeah, I mean, they might they might do it that way, but they can't tell you Right.
Like, did did your username password were either good or bad or whatever.
Yeah.
So So that's gonna be a procedural change for some of those solutions, I think.
And I think providers will have to handle that for the most part.
There may be some some things that you've done for your own systems that you have to mess with, but probably mainly handled by your providers. Yep. Also, in section eight, they've kind of added something on the better protection of passwords for application and systems accounts. Now this one might be again, it's a twenty twenty five requirement, but anything that could be used for interactive login that an application or a system may use, you can't put that in a file or in a script or something.
So there's some requirements around there that you need to review. So that's kind of a different process. They're wanting to protect those a little bit better.
Yeah. The key there was interactive.
Interactive login is the key there. And then, also, those system and account, application passwords, have to change periodically based on your risk assessment. Right. And that, again, you know, maybe you've got a really long password and maybe it's different. You you have to identify the risks and base it on something. Right. Can't just say, I don't believe the risk is there.
Yeah. It kinda goes back to my point about very targeted risk assessments for certain things.
So that one may be a a little bit of a hard one, especially if you're dealing with a lot of kind of code and, application system account access to in your processes.
Anyway, wow. We're almost, we're almost done here. We got section ten coming up. Matt, what do you think about section ten?
Yeah. Some interesting changes in ten.
One of them that I think most of us have been a big fan of for quite a while is it used to say that, you just had to review your logs daily. Right? System logs. System logs.
It didn't say they had to be automated, though. Right. Any sort of, you know, SIM or whatever. So in other words, you could do it manually.
They're not gonna allow that anymore as of twenty twenty four.
Frankly, if you are doing that, grow up. Right? So it most people haven't been doing that for many years. Early on, I remember in, you know, the two thousand fives and tens and whatever, people might have been doing some of that stuff.
Yeah. But it's yeah. Oh, my goodness. It's, to do it properly takes a lot of time.
Right. Just not effective either. You'd easily miss stuff. So that's that's one that is a good change.
And the council has formalized that for twenty twenty five. Yeah.
Twenty twenty five.
So another one, this failure of it was a requirement in three two one for service providers. The failure of critical security controls, systems, and so on are detected, alerted, and responded to. So that was a requirement for service providers. But in twenty twenty five, they're gonna make it a requirement for everybody.
For everybody. So if any, you know, if your, IDS system went down or whatever, you have to detect that it went down in a timely manner, you have to, of course, alert on it and respond to it and everything. So that may require some reinstrumentation of some of your processes in the sense of having some things that, you know, it's not enough just to get the logs. Now you have to actually monitor that your devices are up and stuff and alert on them.
Collecting them.
So yeah. So that might be a a pretty big change for some smaller entities that are that are kinda squeaking by on on log systems. Yeah. Yep. Absolutely.
Okay. Section eleven. We're almost done here. But, some pretty big changes in section eleven that I thought were some good ones.
One of the ones initially was there's gonna be internal VA scanning has to now be authenticated.
And, that's a change. Before it was, you know, you could get Nessus or whatever and just kinda run it internally, or you can have a a device or a a OpenVAS. OpenVAS. You know, something running on your systems inside your network that's testing those applications and and network, access ports.
Now you're gonna have to have credentials involved, and you're gonna have to make sure you protect those credentials carefully. And I think that's, frankly, the biggest part of this. A lot of tools have this authenticated scanning going. Right. But, you know, making sure that you're you're protecting where it's keeping those credentials. Yeah.
That's that's as you as you said, that's the real I mean, it's a good thing, right, to do the authenticated scan. You'll get better details back on what's running on the system, vulnerable packages, that sort of stuff, what needs to be fixed. But as you've identified, the the protection of the credentials is critical because typically this this scanner is going to have full access into that system authenticated.
Right.
So you need to protect those credentials because it's not just one system that it's accessing. It's it's all the systems in your CDE. So a big deal for that.
Another one in that, in eleven that I kinda liked, was a change on IDSIPS, you know, IDSI, if that's what you're using, Snort, whatever, you know, kind of signature based and whatnot, might, it can attempt to detect certain covert malware channels and things. But now it's gonna be a requirement in twenty twenty five that you actually, you know, that IDSIPS system be able to detect those. So whether it's DNS tunneling or whatever it is, you know, for some command and control stuff, it looks like port fifty three going out DNS traffic or whatever. If you're not really analyzing the traffic using some heuristics and things to and pattern analysis because it can actually encrypt the packages and or the payloads and stuff. So, you know, you have to do some enhanced analysis to actually determine that. So that'll be a big change coming for IDS, IPS, right, in twenty twenty five.
That might be a thing for service providers of those solutions. They're gonna be implementing those in your system. So, probably one of the biggest thing in section eleven, I think, that's that's coming out is, adding a change in tamper detection mechanisms for deployment on payment pages. I mean, this is, again, a kind of a shout out or or a reference to things like MageCart and some of the scripting problems skimming on ecommerce.
Starting to be a big deal, has been a big deal. You have to be able to catch those include scripts, header changes.
It's really something that is absolutely needed for ecommerce. This is one of those requirements that I I know is gonna be a little hard, but this is something that we need right now. And, interestingly, Security Metrics just released a new product that fulfills this requirement. So it's called Shopee Carte Monitor, Shopee Carte Expect.
You may wanna look for some demos coming up on our website. Sure. There's other companies out there that have solutions that will be coming, but this is one of those things that you're gonna have to engage a a new service provider to to actually handle for you. It's not something you can just sort of say you do on your own.
No. It's yeah. Exactly. I mean, and, you know, our new products, I really like. We have some FADDIP technology in it. It's pretty cool. It is.
And we're finding a lot of compromises out there by malicious scripts right now. Yes. So Alrighty. The last section, section twelve, Matt, what do you think?
Okay. There's some, obviously, some changes. We talked about the risk assessment and things, but there's quite a few changes.
You know, I don't want to keep belaboring the point, but risk assessments have changed. So that was normally a section twelve.
Was it risk assessments, did you say, is gonna be important? I think so.
One that was really just put up in the kind of in the executive summary of the PCI DSS was about, you know, scoping your environment every year and confirming the scope with your QSA and that sort of thing. They actually have the moved that into the requirements in section twelve now. So you're going to have to prove at a minimum if you're a merchant on an annual basis that you've confirmed the scope of your environment. And and once again, you know, you have to have some proof.
You can't just say to the QS, I I did.
Yeah. I did. Trust me.
Of course we did.
You have to have some proof. So that'll involve some documentation and things. Exactly.
On top of that, then if you're a service provider, they're moving that to every six months. Six months. So that's a change.
You might have to do, you know, some data discovery stuff occasionally to make sure that your environment is really what you think it is.
It applies a standard process, right?
Yeah, exactly. Yep. And the results of it.
And so that also goes to, you know, one of those significant changes we mentioned earlier. If a significant change has happened, you need to evaluate if the scope of the environment has changed. So specifically, you know, it could be it could be everything from changing systems to changing people.
Large organizations sometimes have reorgs and, that group's no longer responsible for whatever.
That's a potential impact to the scope of your PCI assessment. You need to make sure that the assignment for managing PCI goes to a particular department. Somebody's given that role Right. And has responsibility for it. And that's that's kind of a big deal, right?
Yeah. There's been audits and stuff I've done in the past where somebody says, well, no. This group used to be in charge of our scans, and, oh, shoot. Now they're not or they're gone.
The dog ate my homework.
I don't have any scans. So Yeah. The dog ate your organization. Change. So this is again, the council is noticing this stuff actually happening. That's why it's being added to the standard again for twenty twenty five.
Yeah. And this even has implications kind of at the end user level. If somebody moves roles between, you know, all their PCI today in some way involved with PCI, right, and they move to a different department or whatever, they don't still need those permissions into the CDE. Right. So that's something that needs to be modified.
Another another change, which I don't think is, you know, gonna be difficult or whatever, was to the security awareness program.
Before, you could kind of get away with a little bit of a generic security awareness program. Right. But now they're expecting that you talk about specific, you know, to your users and generate awareness on specific threats and vulnerabilities in your environment.
So if phishing is a big deal for your environment, then you need to address phishing in your training and everything. So oh, one big change too, with the incident response plan.
So now if you detect pan anywhere where it doesn't belong, then you have to they have a very defined set of activities that you have to do if you detect the pan somewhere where it doesn't belong. Right? And they you can look in in there in four point zero, it'll give you, oh, you must do the following there's like four or five steps to it. So pretty big deal on that. Incident response procedures, right? Yeah. And what it actually implies though, is that number one, you've modified the process so people know how to engage the incident response process even when they're not involved with PCI.
So that's one potential change for you.
And the other is kind of hidden in that is the, well, you have to be looking for it then, don't you?
Exactly. It implies regular vigilance.
Yes. Of of finding card numbers where they don't belong.
Kind of business as usual, which is, again, something that is being emphasized. So kind of to wrap up here.
We're done.
We went over a little bit, I think, on what we thought.
It's a it's, you know, fun to talk about. It's a good discussion. We've got lots of things, that are coming.
What again, let's wrap up. What do I do now? What are the most important things to focus on? First, read. Get familiar with any of these big changes. Start formulating your plans right now for compliance.
You may want to think about engaging with the QSA at a heart to start answering some of your questions and planning for four dot o. That's up to you. Yep. Again, we can't conduct an assessment right away, but we're happy to start consulting and thinking with you about these things as QSAs all throughout the industry.
The risk assessment process, once again did we say anything about risk assessment? Risk assessment process, gonna be a big thing. One of the bigger things you can do right now to get ready for four o, start learning about risk assessment formal processes. NIST eight hundred dash you know, today's dash thirty is a good place to start.
If you wanna move to four dot o, like I said, just realize that we can't actually conduct the audit. Said that before till till after about the July time frame. Plenty of time for transition.
However, don't just leave it till twenty twenty four. Yeah. It's just not gonna be a good thing to do. There's enough stuff here that will catch you and make it really difficult and cost a lot of money. So spread the money out.
And the and the work effort. And the work effort. Exactly. So, anyway, thanks for joining us, for this, and thanks for listening. We're gonna go right now into QA for a bit, and, we'll talk to you there.
Look forward to hearing what your questions are for sure.
Okay. So thank you for joining us today. We'd like to hand the time over to Matt and Gary.
Are you gentlemen ready to answer some questions for our audience?
Yes. We do have some time for questions, and we've gotten a couple of them, number of them. So we're gonna try to get those, answered here before we need to sign off. We do appreciate everybody listening in today and thinking about this and got some great questions.
So let's just jump right in. The first question we had was somebody was saying, hey. They manage a really small trade association, only take credit card payments for, like, a few dues and payments, meaning registration fees, things like that. Is PCI something I need to worry about and take action on, or is this something my credit card service provider takes care of for me? And what about my web hosting service?
So good question. Not not an uncommon one.
You can't really just ignore PCI if you take credit cards. Depending on how you take them, it may mean more or less work. However, right now, you're already subject to PCI DSS three two one. So, yes, you would be subject to four dot o in the future as well.
If your volume is really low, perhaps, then maybe, you're gonna be filling out an SAQ, a self assessment questionnaire.
That may depend on how you're taking which one you use would depend on how you're taking cards, and, which one is there. There is no four dot o FAQs yet as we mentioned earlier. They're coming out, as I heard in in a meeting I was in, two days ago in April sometime.
So, if you have any trouble scoping yourself, you can work with a company like SecurityMetrics, to help out, and and that's about the best I can do on that question.
I'll take question two.
It said, is there such a thing as doing a hybrid with some customized approach controls and the rest as traditional, or is it all or nothing? Either a company does a customized approach or they don't.
So the simple answer is, yes. You can mix both approaches in the same wrong.
Some, you know, some requirements using the defined approach or even the majority of them or whatever, that's the the more standard version of it. And then some using the custom.
But just remember that if you're gonna use the customized approach, it adds a lot of complexity and difficulty to the process. Something you would need to start way early if you're even gonna think about it, work with your QSA, but there's a lot of work involved for the organization to actually do the customized approach. Probably work well for large organizations who have defined teams that can, help all this.
Is this gonna be an SAQ thing, Matt? No. No. So if you're a small merchant or or somebody using an SAQ customized approach, it won't be something that you can really, right, make use of as far as we understand right now.
Alright. So the next question was, if we're currently working maybe Matt and I both talk about this one. If we're currently working to get our company up to compliance with the standard, that's three two one, do you recommend we focus on meeting these standards for now and focusing on four dot o in twenty twenty three or skip, you know, and skip three two one altogether?
That's gonna be a real interesting question, I think, Matt, for a lot of people, in this transition period. As we said earlier, there's a lot of time for you that these are both gonna be concurrent, and I think it kinda matters of how far along you really are. If you're a long ways towards three two one compliance, then I'd probably stick with that route if you're almost there. Yeah. If you're just now starting and kinda reading, what do you think they ought to do, Matt?
If you're just starting it right now, I'd start off with four dot o. Yeah. Go for it. I mean, there's all those future data requirements are future dated even for four o. Right. So those you don't have to meet until twenty twenty five.
And that's pretty much the same other than that.
Right? I mean, they're they're the future data ones are the ones that are really changing stuff. There hasn't been, like, this massive rewrite and massive change.
You know, if you if you kind of said, well, I'm gonna work on the the stuff that's not future data first, then you're pretty much working on three two one.
So, if you're if you're well along in the process, stick with what you're doing.
If you're just beginning, jump over to four o.
And if you're an SAQ, you're gonna have to wait for a bit to know whether you should. So because four o.
For the four o FAQs. Yep.
Alright. Well, I'm gonna handle this next question because it came from somebody that I know. Hi, Robin.
Will Security Metrics provide a risk assessment template, form, or process?
Excellent question. I think risk assessment, as we mentioned in the webinar, is gonna be one of the more heavier lift type of efforts as we move forward.
We we have you know, we kinda talked about it. It's based on lots of different standards, NIST eight hundred dash thirty.
I think there's another question about it a little bit later too. There's some other standards.
We currently don't have kind of a template per se, but it's not a bad idea. We may look into doing something like that or trying to have a recipe, a little bit better recipe that's quicker to follow or some sort of web thing. I don't know if it will be incorporated into our small medium business portal for for merchants. Maybe that's a good idea.
We still have lots of time for this, so just stay tuned and, watch for us. But, anyway, thanks, Robin, for the question.
Alright. Let's see. I'll read the next question. You might wanna answer it. Alright. Says, I wanted to understand the use case of cloud components.
Cloud components.
And that's a it's kind of a it's a question that could be interpreted a lot of different ways, and and Matt may jump in here too.
But but if you're saying, can you get PCI compliant using systems or networks or applications hosted in the cloud, I think we can both confidently say yes. Absolutely. Matt, we have assessors out all the time that are actually working with customers using the cloud almost, you know, exclusively, some doing hybrid and mixed situations.
If you're asking about a real specific technology, that that I'm I'm not maybe understanding, you know, that's probably handled on a one on one basis. We can learn more about your specific question. Talk to a QSA. Talk to a QSA.
But but to say, Matt, can you say that we routinely work with customers who are working in the cloud?
Yeah. All the time. For many, many years, and it's getting more and more prevalent. So the other nice documented.
Everything else. Documented. And four dot o is really trying to handle, you know, making some cloud statements in it if you read in some of their guidance and stuff. So, the council has really understands the importance of cloud services and cloud.
So they are, you know, making more of a notice of it than they did in three two one. In three two one, you just kinda had to say, well, how would I do this if I did the cloud? And that's how we've been working for years. Now they're actually trying to do it.
I think they're they partnered with the Cloud Security Alliance and some things you may see some more stuff coming out from them as well.
That's always been one of the tricks. Right? Is I think you stuff. Applying applying the security principles of PCI to a cloud environment. You can do it. It becomes difficult with that interplay between the cloud provider and what they're doing and what the end user's doing, but that's where the old requirement twelve eight, came in or twelve eight five's about having a responsibility matrix and stuff.
I'll look at question six here. It says, any recommendation on where is a good place to start to learn, and then in parentheses, documentation, playbook, etcetera, about doing formal risk assessments as you mentioned?
Absolutely. You could start, of course, NIST or National Institutes of Standards and Technology.
Eight hundred dash thirty is one of them. And in inside that document are, many appendices and things with good information.
Octave is one that's been out there for quite a long time, and you can find stuff about them.
CIS RAM, so Center for Information Security, Risk Assessment Methodology, CIS RAM. They have some documentation out there that's free for people and also, it has good information about just, how to, architect and target your risk assessments.
So, you know, you could do one company wide versus one maybe at a group level versus one at a very specific level for technology or systems and things.
So it's not a new topic.
It's something that's been around and people have written a lot about. Yeah. So Google is your friend here. Absolutely.
And and, you know, it's just sort of being emphasized more Yeah.
Here now. Yeah. It's not like it's a new total new technology.
No. My biggest advice on it right now is a good friend of mine told me a long time ago is don't try and boil the ocean. So make sure you pay attention to what the scope of the risk assessment is. Too large, you'll just get bogged down, so be very tight about what it is you're assessing.
Let's see. What's the next one here? It says for SAD or sensitive authentication data, one vendor requested to to store SAD and in their terms and conditions explicitly requires the user to accept all liability for the vendor storage of the CVV.
Is that PCI DSS four o compliant?
No. It's not PCI DSS three dot two dot one compliant either.
You're not supposed to store that information post authorization unless you're involved with issuing or supporting issuing services.
So, no, the vendor shouldn't be doing that.
I'm gonna guess they're probably doing it because they wanna do some sort of a recurring transaction, in which case then they really need to talk to their bank or their acquirer.
There are ways for them to do recurring transactions that don't require them to store the CVV and things. So just yeah. Don't store the SAD if you don't need it. I mean, it's yeah. Well, you're not allowed to even, you know, post authorization. So no.
Alright.
We're getting a few more questions. We're we've been told we got three minutes left here, so we'll get to as many as we can. And if we can't we didn't answer one of your question. We'll, work with our marketing folks and see if we can get, some some addressing addressing of those questions.
One question was, could you elaborate on disk encryption for nonremovable storage for storage solutions that hold databases with cardholder data?
So in short, if it's a nonremovable storage in a database of card data, disk level encryption will not be allowed anymore. You need column level encryption of the data. Yeah. End of story. Right?
So there's not a or or some other method.
You could use an HSM to encrypt the data and then store it in the database.
There's lots lots of ways, but, no, there's no longer full disk encryption kind of a thing. You're gonna have to go for more data encryption traditional data encryption in a database. Yep. And, that's a twenty twenty five thing.
So you got a couple years there to work on that. Now we're gonna hit a few questions here in the last two minutes that that we haven't seen yet. So we're just gonna gonna see them. Wing it.
We're gonna wing it here. One question. Are are mobile apps going to be in scope for PCI requirements?
And I love the this question because the answer is it depends.
Yeah.
And, if your mobile app is customer only facing, if it's something that I download as a customer, as a person, and type in my credit card number, then it's really not a PCI, thing.
If it's a web application that you have written as a merchant or bought as a merchant and deploy to your people for taking credit cards, at a restaurant or something, then, yes, it would be in scope for PCI, and there's many different ways to And they address the compliance.
Yeah. And they have requirements around that. If it's part of your point of sale system or whatever, there's very strict requirements around using that.
Yeah.
Yeah. And by the way, they they've mentioned for a long time, if you're developing that app for the end user, like you mentioned at the first step, you should do it using good security practices. So Yeah.
I hear While it might not be assessed, it's still good to develop it properly.
I'll do a couple of real quick ones here in the last thirty seconds. We had one section. How come you didn't have any changes in section nine? There really wasn't anything worth mentioning. Yeah. There may have been some clarifications or whatever, but nothing new. So you'll have to just kinda check the changes document for that.
Let's see. There's is there a deadline to move, from SAQs to some other validation method? Right now, the council has said that there will be there currently is not a another small business validation method that will be released soon. SAQs will be will be remaining for four dot o. I don't know if they'll change to another validation method or form in the future.
So that gets us right to eleven o five, which we told what we're told was kind of our end date. We really appreciate you guys, listening in today. Again, we couldn't get to all your questions, but we'll see how we can do that.
Let's see. We're supposed to mention at the end, thanks for joining us. And we will be sending out a link to the recording shortly so you'll be able to see all of this and and review all of the things that Matt has said because they are just awesome.
Thanks for listening, and, hang in there. It's gonna be okay.
.svg)
