Watch to learn about the recently announced PCI v4.0.1 and best practices to pass your PCI v4 assessment.
In this webinar, SecurityMetrics' VP of Assessments Gary Glover and Enterprise Sales Manager Brian Cole will discuss:
Learn more about Shopping Cart Monitor here.
Learn more about Shopping Cart Inspect here.
This webinar was given on August 27, 2024.
Hi. My name is Brian Cole, and I manage our enterprise sales team here at Security Metrics. I've been here for about a little over eight years now. Here joining me today is Gary Glover. Gary is the vice president of assessments here at Security Metrics. Gary, how long have you been here at Security Metrics?
So this coming January will be twenty years. So quite a few years. A lot of experience doing this stuff over that time period.
Oh, that's awesome. That's a long time.
Gary is, was in the first group of QSAs to be certified back in o five zero six. He's actually currently, our our member of the global executive assessor roundtable for the PCI Council, so participates in the gear meetings.
And, some of the certifications that Gary holds are CISSP, CISA, and and QSA.
Today, we'd like to talk about how you can prepare for your version four dot o assessment.
As an outline, some of the things we'll cover today are the new requirements, both ones that are currently being required and future data requirements.
We'll talk about, best practices for six four three and eleven six one that are new requirements.
We'll also talk about just overall what you should be aware of and plan for when doing your first PCI four dot o assessment. So, Gary, tell us. We just heard that PCI four dot o dot one just came out. I know four dot o is fairly recent as well. So what's the difference with the new or what's with the new four dot o dot one?
Yeah. Good question. And I think that shouldn't be something that really worries people as far as a trend goes. It's not like, hey. We're gonna start doing a release every couple of months from the council.
Always when a brand new standard comes out, there'll be errors that they found, better ways of saying things, adding a little bit more guidance. And that's pretty much the difference between four o and four zero one. It's only a hundredth change.
So it's just mainly errata. You know? They've changed a couple of words, done some punctuation.
They actually made a couple of, wording changes to clarify things in in, like, eleven six one. They made some clarification changes there, that have been helpful. So nothing really that all of a sudden makes you feel like, oh, shoot. Now I have to worry about a whole new set of requirements. No. It's it's ninety nine point nine percent of the exact same things.
It is a new version, and it will become active or effective, January first of twenty twenty five. Can be used now.
You can use four o up until the end of this year, then they're requiring us to use four zero one. So most of our customers are just going right to four zero one. That's the version that we're using. It's not it's not really any difference technically.
Okay. So there's no new requirements with No. No. Perfect. And with this change, do we have to worry about version four being retired any anytime soon?
No. No. It's gonna be around for a long time. I think version threes went on for a long, you know, six, eight, ten years, I think. And so we probably got a long long period of time before big changes occur. Obviously, some of that depends on the industry. If there's all of a sudden this big new thing that occurs that affects everybody, then they will make a change to the to the standard.
I whether it needs a could it go to five? I think that's a long time away. It may go to four one or four two or four three or something like that. But Yeah.
I think it's I think you're not gonna see major changes. It's a very mature standard. The PCI DSS is a very mature standard. We're seeing not massive changes, but small kind of honing of the standard going on in the past, twenty years.
Perfect.
That's good to know. So, Gary, over the past year of the new requirements that are required starting already, what have been the most difficult? What have you seen?
The thirteen ones that are effective immediately really haven't been massively hard, and it was planned that way. All of the future data requirements were added with a lot of time for implementation because they were bigger and harder to do. So, really, the ones that are are are new and effective immediately are things like documentation, a little bit more improvement in documentation.
You're doing targeted risk analysis now. So we've we're asking for evidence of customers showing their targeted risk analysis, and that's been a little bit difficult. And so it's it's better to work with a QSA or with somebody at your corporation who knows those kind you know, knows about that stuff to to really get that documentation in in place before.
Another difficult one is that in at the beginning of every single PCI requirement, now there's a, a new requirement that's been added for somebody basically to take responsibility. They're supposed to name a group or a person that takes responsibility for the requirements in this section. So that's really just a documentation thing. A lot of people are putting that in their policy, or we need to ask them to put it in their policy.
For example, if their policies are kind of following the PCI standard, numbering system. It's easy to just add that in there. But, documentation, is probably the hardest one so far, so not really massive. No big technical challenges.
The only technical challenge we've noticed is and, again, not in as many people that that we as assessors work with, but small merchants doing SAQA are now required to do a VA scan as part of their assessment, or their self assessment.
And, sometimes that's hard for for small merchants who've never had to do that before to really go, well, why do I have to do it now, and why is it important? And I think, when we what we're really trying to do is is help that level of merchant secure the boundaries of their website.
So it really goes with it's kinda getting people prepared, and we're gonna talk about a little bit later, eleven six one, the script scanning stuff is preparing people for that requirement.
You gotta protect your boundary better so that people can't get in and start messing around with scripts on your website. And there hasn't been an emphasis for SAQA before, whereas now it's been determined security wise and compromise wise that this is an important thing. So that's probably been the hardest thing for people to do, this year has been, wow. Why do I have to do a VA scan this year?
But, for the rest of the customers, it's mainly just been documentation items that are a little bit more it's like it's the worst thing that people like to do. Right? Nobody likes to write new stuff, so that's been a hard thing. For sure.
I know additional requirements are never fun, but we've seen with our forensics team, right, that SAQAs have been an attack vector, and so it makes sense that there's additional requirements now for that.
And we'll talk a little bit more about that, I think, in in a little bit. For sure.
So, Gary, of the future data requirements, what are some of the biggest, obstacles that people should be aware of as those are quickly approaching?
Right. Now there's no time for us to go over every fifty three, each of the fifty three brand new ones. And a lot of times, some of those brand new requirements are that are that are future dated are just documentation things or small changes that that the council wanted to have everybody plenty of time to work on. They're not massive issues.
The ones that I wanted to just mention out of those are just a couple. And I think, keyed hashes, if people are using a hashing methodology right now to protect card data or to use it as a key in a database for card data or for some reason like that, lookup.
There's new requirements in PCI four dot o that requires that cash to be keyed much like an encryption algorithm is keyed, and therefore, you've gotta do key management on top of all that stuff. So that might be a issue for somebody. I had a a case recently where they thought that they had an an encryption algorithm I mean, a a hashing algorithm that was gonna be just great. And when we got down into the details of it, it really wasn't keyed.
It was it sounded keyed, but it wasn't. So working with the QSA beforehand, if you've got that situation, is gonna be real helpful to make sure that you've got that handled. The next one might be people are gonna have to do a little bit more with phishing and training their employees a little bit more with phishing. They're requiring, a mechanism to actually look at emails, for example, to make sure that they're not containing anything bad and trying to filter.
So many of the email systems nowadays are doing that kind of stuff, but that's that's gonna be one, adding some new phishing requirements.
One of the biggest ones that we'll we'll get into a little bit more detail further on is this this payment page script monitoring. You we mentioned before that we're seeing a whole our forensics team are seeing a whole lot more, compromises and attacks on iframe pages that in the past were thought to be very secure, and, you know, they were.
However, now the bad guys have figured out how to do some really interesting things just with the browser properties themselves that allows them to to sneak in and skim credit card data from from these pages. So six four three and eleven six one were added. We're gonna talk about more of that, but that's gonna be one of the more difficult ones. Another difficult one is probably gonna be, multifactor authentication for internal access to the card data environment. In the past, it's been you have to have multifactor authentication whenever you're getting remotely into the network.
Now now it's from inside the network when you access something in the CDE. So internal access to those secure areas, will need to be protected by MFA.
So that's gonna be a hard one, a new process for people. But one of the other things that for multifactor authentication is gonna be difficult is that the council has reiterated some features of these solutions that are gonna be important.
They have to be resilient to replay attacks, and you have to show in the documentation of your solution that that they've handled that, for example. There's a couple of other ones. And and all of the factors that you're validating have to be validated before you tell them whether they failed or not. So in other words, in the past, I think a lot of MFA solutions will have you type in your password and your user your username and password and then say, okay.
Good. You got past that. Now put in your multifactor authentication token. So the bad guys know, well, I know the right password then because I got to this step.
So now these solutions need to move towards putting your username, password, and MFA token, and then they'll validate all three of those at once, and they won't tell you which one was the one that failed if it fails. And so that way, the bad guys don't know, which item they have guessed right, for example.
An additional layer of security.
Yeah. So that's gonna be a a new thing, and that's gonna we're gonna depend on the MFA service providers to to really implement that correctly.
The other thing I think that will be difficult, but it's been around for a while, and that's called authenticated vulnerability assessment scanning.
Many of the tools out there have that mode already that you can access, but having to then provide that password is being stored in your in your internal scan solution. This is for internal scans, not external scans, internal scans. So you may have somebody in your department that's actually running those scans, and and they can't just do it the way they've done it in the past. There needs to be a new process where they're they're authenticating into various services, or websites, for example, to to let the the VA scanning tool do a little bit more deeper work. So that's gonna be a a difficult one.
A documentation challenge will be, scope validation and documenting your scope validation every year. Kind of in the past, in the past when we do an assessment, we say, well, has your scope changed as QSAs?
No. No. Everything's about the same. Or, no. We've changed this. Okay. Well, let's go over that.
We kinda do it verbally or or as part of the audit process. Now the audit drafts to look for a document that you've prepared as a company saying here's how our scope has changed, and here's the validation of that scope that we've conducted. And then and and we work together on making sure that we all agree on that scope validation. So I think those are probably the biggest ones that that are gonna cause the most hardship out of the fifty three.
There's, again, lots of other little ones, but not as big of a deal.
I'm curious, in addition to these changes, is this gonna cause new budget to be need to be considered, or do they already have vulnerability scans in place and they just need to authenticate them? Or is it a budget factor?
Depends on the service provider. I'm sure that there will be a budget change for that, and especially for the script scanning. That's that's a a thing that sounds easy because it has the word scan on the end of it, but that's, you know, orders of magnitude more difficult than a VA scan, if it's done right. And and so that will have a cost associated with it potentially.
So the real the real, you know, hardship for the industry is gonna be, can small merchants afford it? Big merchants are gonna be have to have to do it or big service providers will have to do it. How can we make this something that that everybody can can actually accomplish?
Good point.
So with as we talked about eleven six or six four three and eleven six one. Right? They're it's new. It's different. It's a change. Can you kind of elaborate on what those changes are and and what what merchants and service pro providers are gonna have to have in place to meet those requirements?
Yeah. Let me do just a little bit of background first. The reason why these requirements are in there is because the forensics are happening and showing that this is where compromises are occurring.
So all of this is not just based on that the council wants to add something for you to do more so that they have more things to have you do. That's not the point.
It really is something that is a a major, issue amongst, ecommerce, especially in the iframe kind of small merchants that are trying to get out of a lot of validation types of things by using SAQA.
So, six four three was put into place so that you, as a merchant or as a service provider, will know for sure all of the scripts that you have included on your page or that somebody else has included from their include. So it's a way of really kind of kind of delving into the code of a page and making sure somebody says, yes. The script is okay, and, yes, it's been authorized, and, yes, I know what it's doing. And I and I'm the one who included it, or we wanted it to be there.
Sometimes, you know, in some of our analysis, we found up to three hundred scripts on a payment page, and the provider didn't or, you know, the the merchant didn't even know what most of them were all about. And so it's really easy to have scriptflation where you're just getting all kinds of stuff, and maybe they come from the marketing department or the, counting or what you know, whatever else that they say, oh, we need this new little thing on it because we wanna track this or we wanna track their mouse movements, the developers, or whatever it may be. Those scripts may include other scripts, which may include other scripts.
Third and fourth party. Right.
Yeah. And so we found sometimes where the the fifth or sixth party script that's loaded is the one that's the bad one. Yep. So you really have to get to the bottom of all that. And so six four three is right is trying to get you to say, let's get to the bottom of this, and let's figure out, do I really need all these things? Can I reduce the number of these scripts?
And so knowing what they are, identifying them, and helping to characterize what they're doing is super important. So that's six four three.
Mhmm.
And that goes hand in hand again with with requirement eleven six one, which is, okay. Now that you know what's supposed to be there, how do you know if somebody snuck something else in, and how are you gonna tell?
Mhmm.
So that's what that one is all about because, again, like we've mentioned, these scripts can be included. Do you know where their source is? Do you trust the source?
Or a bad guy could have broken into your into your site because you have poor edge security because it never was asked for as much before. In in SAQA, for example, we didn't have you know, you don't have to validate your firewall rules.
They just assume that you have a firewall, perhaps.
So Hence, the reason for vulnerability scans for SAQA now. Right?
Exactly.
Scanning is important.
ASV scanning is important for these merchants because now you have to protect the edge so the bad guys can't get in and modify those scripts.
But if they do, you have to be able to detect when that's happening.
And let's talk a little bit of maybe about some of the features that a scanning solution would really need to have to be able to For sure. I mean to cover all that.
There's lots of solutions out there. How do you know that the solution you identify, one, meets PCI compliance, but two, ensures that your checkout page in process is secure?
Right. And that's one thing actually the council improved in eleven six one, in the guidance section of eleven six one. It used to kind of sound like you can choose any one of these bulleted items to meet this requirement, and they clarified. It's like, no.
It may your solution may be made up of these bullets or combination of these bullets or maybe some that are not here. So they were providing examples of things that could be part of a solution, but not just one of those bullets. So some people have come to me during an assessment and said, well, all we're gonna do is the sub resource integrity and, CSP, content security policy. I have to remember what those acronyms are.
And and that will satisfy six four one or eleven six one.
No. That's not true because that's kind of looks at things on load time, but not on final execute.
Six four three also mentions you have to know all the scripts all the way to the end of the checkout. Right? And that's the same thing for eleven six one. You have to understand all the scripts that are active in your page and executed all the way through the checkout process. And that really is the crux of the problem.
There's a thing in the in the web languages called the document object model, and that's where that's basically the the DOM. That's the environment that all these scripts are being executed in. That's what creates the web page. That's what you what your browser looks at and renders the web page, you know, the code. And and so there's a lot of activity going on in this document object model, this this environment, and it's very dynamic. And so a script scanning solution can't just you can't just say, oh, as it loaded, I looked at all the scripts, and there was nothing bad.
That's not enough. It has to then you have to actually go all the way through the purchase process and make your last entry of the CVV or choosing, shipping method or hitting return, you know, to say go, you know, to to make the purchase, final because it may be on that very final act that the bad guy has put a script that loads a script that loads a script that puts the bad thing in. So all of this this script scanning, the scanning of the contents of an iframe can happen at the very last microsecond.
So it's important that these are dynamic solutions that go all the way through. It's not a static scan. It's not a a quick, evaluation of the scripts that are loaded.
You also have to kinda be looking at the data that's going out, and you have to be looking for indicators of compromise.
And, what are your sources for those indicators of compromise? Are they industry accepted?
So as we've been working on a tool, that we call Monte to meet this, we detected through our forensics group this was gonna be a problem a long time ago. He visited with the council a little bit about it, and they were already thinking about it as well. So it backed up their data.
So we've been practicing, working on this for a long time, and, really, the only way to do it is by making sure that you're getting the full dynamic process. So that's super important. Then, of course, having the reporting, available to customers to look at in any kind of direction that may be helpful for them, vetting it, making sure that these are real and not just false positive. Obviously, none of us in the solution world try try to create false positive, but sometimes they're there.
So, anyway, SecurityMetrics has developed a tool called shopping cart monitor, and it can work for all the way from an enterprise down to a very small level four merchant in a cost effective way. And that's gonna be the really hard part of this solution. There's a lot of solutions out there that are kind of expensive that small merchants just wouldn't be able to afford. So we've really been focused on trying to come up with a solution for small merchants.
They may have to do a little bit more work on their side, a little DIY, but it's not coding DIY.
It's an agentless solution, so it's basically running through the purchase process, periodically, to be able to validate that there's nothing new that's been added to the site. The other thing about the script scanning vulnerability or or the script skimming vulnerabilities is that it's not necessarily a bug that can just be patched or fixed on a browser. The browser just works some ways, and the and the bad guys have learned how to exploit the normal behavior of browsers to be able to trick the document object model into reading a third party iframe hosted iframe content. So you have to continue to do this over and over. It's not just a one time, once a year annual scan or even a once a month or once a quarter. It has to be very regularly scheduled. And I think the council mentions it's it's weekly, you know, unless you can prove that you have less traffic, for example.
And that's due to the the very dynamic nature of a browser constantly changing. So it it's it's harder than than it seems to catch these you know, if you have one little line of code in three hundred lines of of code, it's very difficult to to see that and find that.
Now one thing that we suggest to people, especially that we work with during an assessment, is, you know, everybody goes, well, I don't have to to meet that requirement right now. I've got clear till, you know, March of thirty first of twenty twenty five. I don't have to do anything.
And that's true. However, don't get caught behind the eight ball there. You know, looking forward to meeting this requirement of eleven six one, you can actually start approaching it in stages. And I think that's what we recommend to our customers, as that we perform audits on is that, boy, if you wait till the very end, March thirty first twenty twenty five, you're gonna probably have a hard time meeting this requirement really quickly.
It may or may not be something that you're gonna be able to integrate into your site, you know, turnkey really easy. It's gonna take some some work, and understanding the process, that kind of stuff. So, we have SecurityMetrics has another product called shopping cart inspect, which is essentially kind of a an initial characterization by our forensics team of of your ecommerce website, the scripts that are there. If we find anything obviously malicious, we report that.
But it's kind of a characterization.
It's almost like a baseline that you could then use point in time versus a a monitor over time, but it's a point in time.
So this is essentially the same process Mhmm. That we're doing to to go through the whole payment process, look at all of the scripts that are loaded from from Timbuktu, from every source that that's coming, and then evaluating those. And at the same time, we're also looking at the scripts that are on the payment pages that are are being provided by your provider. Right? So we're actually looking at the service provider scripts.
And so one thing that we found just recently, we published a little paper was kind of the real evidence. I think there's been kind of some confusion in the industry on, well, I'm just such a small merchant. Why is this why is this the why is this my problem?
It really should be my service provider's problem. It's not my problem. Right? I wanna push this off into somebody else.
Okay. Sorry. It is your problem if you have a website, and that's because it's the referring page that's the problem, not the service provider's content of that page. So, we've proven this by doing over two thousand forensics cases.
And in one hundred percent of the cases where actual skimming was discovered out of those two thousand, the scripts were malicious scripts were on the merchant page, not on the service provider page. And we actually look at the scripts on the service provider page as part of the process.
So It's a crazy stat.
Right. So there is you know, some people are saying, boy, we shouldn't do this, on put this on merchants. It's not their problem. Well, it's not the service provider's problem.
It is the merchant problem. That's who's being attacked. The bad guys are attacking the merchant sites, not the service provider site. That's what our evidence shows so so far.
So truly important, are these two comply these two requirements, and complying with them should really help the the loss of ecommerce credit cards.
Yeah.
So we have options now, and then the the requirement is March thirty first, but we we recommend highly recommend Starting working on it now.
Yeah. When it doesn't when it doesn't matter for your compliance, start figuring out that solution, and don't be caught behind the eight ball.
Hundred percent. So, Gary, tell us, what are some things that we should consider between your twenty twenty four and twenty twenty five assessments?
You know, that's a great question. And I think there's a lot that you can do now to start getting yourselves ready. And I think, it's important to make these these things. I think a lot of people have come to us, and one thing we're noticing is they're going like, well, we're just gonna push off all these requirements that are future dated to twenty twenty five.
We're not gonna worry about them this year. Some of those, that makes a whole lot of sense, because you've gotta come up with a solution and test it. Other ones, you could just go ahead and do. So look for all of the four o requirements that you can do now, even if it takes a little more documentation or maybe a little teeny bit more process, a little more risk analysis, a little more, risk ranking process, whatever it wherever it is.
You know? Develop those procedures now and get them in place, but don't just think I'm just gonna put everything off. So that's one of the the biggest things that you ought to consider. And the other thing I think that people think about is, oh, well, if I finish my four o audit, March fifteenth, then I'm good for another year.
Right? And, well, granted, these assessments that are being done, either it's an SAQ or a or a PCI report on compliance, is a point in time assessment. And so, yes, on March fifteenth, you were meeting all of the requirements.
However, you've got to start thinking about, those requirements that are period have have a curiosity, and you have to show that you've got a history of doing that. So after March thirty first, if you just ignore all of the requirements that have kind of a time based periodic requirement, like scanning, like script scanning, like firewall reviews, those kinds of things. If you just ignore those period curiosity things, you're gonna not be compliant the next time March fifteenth comes around, twenty twenty six. So you can't just you know, you're not off the hook if you pass just before the thirty first.
Still have to work on those solutions, and you still have to be able to prove, on your SAQ or to your assessor that you have completed these these tasks that needed to be done over time.
So you're saying that you'd fail your twenty twenty six assessment unless you can show that you've been doing those scans throughout the the calendar year twenty twenty five when they're Right.
But that's a that's a potential potential finding. Okay. Sure.
So you're not off the hook. So don't just think, oh, great. We're gonna be awesome because our due date is is March fifteenth, so then we don't have to think about it for another year. Don't think about it that way. And some people have actually asked us as QSAs, my my assessment is due on April fifteenth. Can we just move it back to March fifteenth one month so that we don't have to do any of the four o stuff?
Well, technically, yes, for that one point in time assessment. Again, you go and get into the same problem. So it's a bad idea. Right.
But try not to get into these these, oh, I can get through this loophole by by getting done before March thirty first. There really isn't a loophole. No. You still have to do it.
So I think that's one of the things that be that I would say, don't don't get caught in that trap between twenty twenty four and twenty twenty five. The other thing is that there's a number of these requirements that you may want to consult with a QSA before you implement that solution or as you're implementing the solution, especially eleven six one six four three, your MFA stuff, maybe even a a hash function. You know, we may wanna touch bases with somebody, a QSA to make sure that you're implementing something correctly. So go through some of those big ones that we talked about earlier and make sure that you, you know, have an opportunity to get a little consulting or a little help before you get to twenty twenty five, so that you're for sure gonna be ready.
Yeah. Please reach out. We'd be happy to fill any questions about any of these requirements. We'd be happy to help. It's way easier to plan ahead than it is to try to figure it out in the in the point in time.
Right. You don't wanna be in the compensating control. I've gotta figure out a way to convince them that that the dog ate my homework kind of a situation. It's just hard.
And I think the other thing too to keep in mind, I've been having lots of conversations on the sales side as is people wondering what requirements are coming up and what they need to plan for budgetarily because budgets are getting approved for the calendar year. So we're doing lots of fielding lots of calls and answering lots of questions so people can plan to fit these in their twenty twenty five budget so that that's already planned and taken care of.
You don't wanna wait until it's due next month, and you have no budget to Right.
To get the scanning in place.
So talk to your MFA vendor. Yeah. Find a script scanning vendor. Make sure that if you're a level four, a, you know, SAQA merchant that you're thinking about those things. Make sure you're getting scanning done this year. For sure.
So, Gary, tell me a little bit more about how you perform assessments. How do you communicate with the client during the assessment?
Right. This really hasn't changed a whole lot, since for the last twenty years. Right? And so it's it's a process that we've been working on and and continue to develop.
So four o really hasn't changed that. I mean, there is more documentation on our side. We have to do a little bit more work in making sure our working papers are aligned correctly and and, ready for any kind of review that the council may do. So there are some things that are that we change on our side, but as far as the customer is concerned, there is no change in the way we work.
We always, try to really have good communication, with our customers. We have a kind of not really project managers, but project coordination staff that you can always talk to. So SecurityMetrics, we pride ourselves on being the people you can actually get a hold of on the phone. And if if you can't get a hold of your QSA via email or on the phone, you can always talk to a project coordinator.
They can tell you what the situation is and even get somebody somebody else to help if it's an emergency question, something like that. So, I think that's one thing that that we like to think as a differentiator in our business here at Security Metrics is that, we're we're easy to work with.
We're also very thorough, and we're not gonna be validating something that isn't really in place. So we're gonna be looking very carefully at your systems and and, doing a real thorough job there.
Apart from good communication and thoroughness, is there anything else that sets you apart?
Most of our employees have been here a long time. Most of our QSAs have been employees for ten or more years.
So we have a high stay rate, I guess, here at SecurityMetrics. So you're gonna get the same kind of treatment year after year. You can build that relationship. We're not, you know, churning through lots of people.
Very consistent expectations. When when when from cue to cue from QSA to QSA and from year to year, you can expect a a very similar experience with Security Metrics.
One thing that helps us do that is we actually have an office location here in Utah, and everybody has an office. And, they may be out on the road quite a bit, but they often, you know, will come back to the office. We have meetings together.
If you have a problem, you go out into the hall and you ask whoever's there. What have you guys been doing? How do you do this? So easy communication, and a real good team value, here at SecurityMetrics as well. Perfect.
So kinda key takeaways to summarize what we talked about today. What would you say, like, the the most important things to remember?
Yeah. I think I think the biggest thing is don't really get freaked out. It's gonna be okay. Stay calm.
There's no real big secrets. Stay organized.
Make sure you have good, flow diagrams, good network diagrams.
Check your documentation.
It really helps if you have somebody at your organization that kinda heads up the audit process instead of just having us be the ones that have to go organize all the people. Right? It's great to have a a company, representative that will be that contact point.
You need to know and understand your service providers, what they're providing exactly for you, and that you understand their attestation of compliance. And if if it's the service that you're using, we often are still finding, you know, year after year that the AOC that somebody provides us to, it doesn't match the services that you're actually getting. And so having that organized, having that understanding, I think, is gonna be important.
Document your scoping process and plan on the rock, the report on compliance writing, taking a little longer on the QSA side because it is. It's a bigger report now. We're being we're all learning this new method.
We think there's a new rock template coming out soon that will help us a little bit, but It's good. It's still a long document. It's still something that that is very detailed.
And, so make sure that you schedule a little extra time, probably. That's a that's a probably a good takeaway.
Good. So, Gary, let's ask some some frequently asked questions here to make sure we're addressing actual questions from the audience here. So is is shopping cart monitor or shopping cart inspect a better, e com better for ecommerce security and PCI requirements?
Oh, good question. We talked about both of those. They are different products. And, just to reiterate, shopping cart inspect is a single one time very detailed dive into your current, you know, the the website state, the ecommerce website state, on the payment page and that payment page process.
So that's effective for helping you understand and and start getting ready for the regular process that needs to occur.
It's not a requirement for PCI at this point, but it is kind of the beginning of that. And so if you're really wanting to kinda dip your toe into eleven six one, that's a great way to do it, but it won't fulfill eleven six one in the long run. So Shambit card monitor or some of these other products out there that are doing this this regular scan of the the checkout process, would be required to be compliant. And so the difference there is one that can help you kind of get a good start, and the other one can help you be compliant for the long term.
Okay. That's good to know. For a first time audit customer or a merchant going through PCI for the first time, what would you say the what's the best way for that company to start preparing, the documentation for a PCI assessment?
Well, number one, select a QSA partner that that, will be able to give you good feedback and communication. And many QSA companies probably have a documents package. Our documents package that we prepared, we've actually gone through and kind of looked at the PCI four o requirements and tried to provide as much as we can that's not so custom that could be templatized. Right?
That could have at least give you a starting point. So, I think that's gonna be a real helpful thing for documentation. This is the hardest thing, frankly, to do as and the nastiest thing for people to do because they don't like to write. And if you start with a blank piece of paper and say, write me a security policy for PCI.
That's tough. Yeah. So find something to start with.
It's way easier to start with the template than from scratch for sure.
Alright. Final question here. Where can I find out more information to help me prepare for a PCI DSS version four assessment?
Great. I think there's a couple. One of them is to talk to Brian and his team. Right?
And, they can give you a lot of direction there. If you have other questions, we have a learning center. We have, blogs and podcasts and and different kinds of things that are provided by Security Metrics. You can look on our website for it's always great to go to the PCI Council website and download get into their document center and look at their FAQs, look at the downloads that you can get for the either an FAQ or the report on compliance, the PCI standard, the changes from from three two one to four o is a great document to look at.
So I think, as far as another great takeaway from from our discussion today would be, spend the time before you start the assessment and learn about it, and don't just assume that a QSA or somebody in your your organization that's in charge will just know everything. You you do have to, put in do some homework and really kind of either watch a bunch of YouTube videos, look at sort sites like Security Metrics, the PCI Council. Try to get familiar with the whole process and and understand the reasons why people are doing this.
That's great advice.
If we didn't address any of your questions, please make we'll reach out to you afterwards.
We'll make sure to send a recording of this presentation and send other helpful links as well. Thank you for joining us, and we hope to see you next time.
.svg)
