With the deadline for PCI 4.0 rapidly approaching, understanding the new requirements for e-commerce is crucial.
Join us on this extra long episode as SecurityMetrics experts Jen Stone, Gary Glover, Aaron Willis, and Chad Horton dive deep into the evolving landscape of PCI compliance for ecommerce businesses. With the deadline for PCI 4.0 rapidly approaching, understanding the new requirements for ecommerce is crucial.
In this episode, our panelists discuss:
Whether you're a seasoned PCI professional or just starting your compliance journey, this episode provides valuable insights to help you safeguard your ecommerce business and protect your customers' sensitive information.
Resources:
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hello, and welcome back to the SecurityMetrics podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. And if you are in the PCI world, you're probably deep into what do I have to do for PCI v4 for March of twenty twenty five.
Right? Especially if you have ecommerce. So there are a lot of people who are dealing with what are these new requirements for ecommerce? I'm gonna say a couple numbers, and if you're in the middle of it, you will know, and this is the show for you.
6.4.3 and 11.6.1: These topics are so big that I'm not dealing with just one person. I have three people here to help me, and I want them to introduce themselves. I think you've seen all of these people in previous podcasts, but I just want for the people who are new, let's do a quick introduction. Let's start with Aaron.
My name is Aaron Willis. I'm the vice president of forensic investigations here at SecurityMetrics. I've been in the industry for almost thirty years, fifteen of those here at SecurityMetrics.
Also been a professor of digital forensics at Utah Valley University and around several businesses technology related.
Great. Gary.
Hi. I'm Gary Glover. I'm the vice president of our assessment team here at SecurityMetrics. So we do the IT audit and help people do compliance assessments.
And I've been here working at SecurityMetrics for about twenty years now.
Before that, doing other things like software development and aerospace engineering.
And Chad?
Hi. My name is Chad Horton. So I'm the VP of technology here at SecurityMetrics. I've been performing penetration tests for about eighteen years. And about six years ago, Aaron and I got super interested into ecommerce skimmers.
And ever since there, it's then it's become my passion. And with 11.6.1 coming out, I was the guy for the job. So I've been able to work on our technology here at SecurityMetrics.
Thank you all for joining me. I'm really glad that you're here. And so just to kind of give some background, before we jump into what we have to do for 6.4.3 and 11.6.1, maybe we should back it up and say, what is this problem that we're talking about?
And I'd like to start because I think one of the PCI requirements years and years ago was on software development. And if people are doing software development, they have to be in charge of making sure that things on their website is secure like, securely coded. There's always those requirements for secure coding. And years ago, we started and I think maybe even before Aaron and Chad started thinking about it, we were telling people, well, you gotta at least know what you're including on your pages and compare them or do something.
And so we were talking to him about it. There were no tools in the industry. There was nothing that we could really enforce there, but it was mainly, like, mainly how are you looking at those tools? So for years, we've known that people have to look at these include files.
And I think then Aaron and Chad started seeing people actually mess with those.
Yeah. We started getting forensic investigations coming in, you know, full PFI investigations.
And our typical method was to download a snapshot of the server, tear it apart in the lab, and kinda go through that checkout process line by line in the code if needed, and find out where the bad guys had inserted some PHP or something to steal those credit cards. We started getting cases where, you know, we were the third PFI to look at it, but we didn't find anything. There was nothing on the server that indicated there was a problem or, you know, no traditional PHP skimmers or any other, server side skimmers.
And so we started looking in the browser and noticed that malware was appearing right when the customer was typing in their credit card data. There was nothing on the server that would ever lead us to find that skimmer that was running or executing just in the browser itself.
And Chad was instrumental in helping us find that as well.
As a penetration tester, we actually started playing around with skimmers, a few about two thousand seventeen when one of our developers built a test environment for my analyst and he'd practice against, and they threw in a skimmer that would hijack the credit card information just to see if any penetration tester would find it.
Sure enough, I didn't find it. And rather, that became a passion of mine because I now had to figure out how that worked, how I would detect it. And so, as Aaron mentioned, I got the opportunity to work with him when the time came up, and it was super cool to see these things in action.
So this is something that this team has been really interested in and has seen it as a problem for years, not just not just recently.
Not since PCI DSS v4. Yeah. Not just a PCI v4 issue. Right?
Yep.
This is going back a number of years now.
And it's something that we're actually seeing, have in the wild. Like, peep people are actually being breached because of of this issue.
It's it's kind of a natural progression.
When when the shift went to ecommerce, the attackers followed. Right? They they they just went where the low hanging fruit is. And so, as ecommerce, became more prevalent, that's where the attackers went to start grabbing those credit cards. And so we did everything to lock down the server side environment. We had the file integrity monitoring, and the antivirus and your IDS, IPS, your firewalls, your WAFs, all these things that we put in place to try to lock that down.
And so the attackers went where we didn't have any eyes, and that was in the browser. There was that security gap where nobody really had eyes on what was happening at that critical moment of checkout when customers typing in the credit card data. And so, you know, we try to solve that by throwing iframes in there and trying to separate that piece of it away from the merchant's side, and that worked great for a while. Of course, you know, if the the hackers get into the website and they've got long enough, they're gonna figure out how to get around that iframe.
And I think that's a good point. I mean, we saw the big hit to ecommerce as soon as, the chips on the cards the AMD chips on the cards here in the United States got to be more I think it happened earlier in Europe. They were actually seeing more ecommerce. So the shift over to ecommerce was caused by more security in stores.
Those card present environments, when they got more secure than they went to ecommerce. And, you know, I remember when SAQA, you know, kinda started changing and morphing, and they said, well, now there's these iframe things. And everybody's really excited about iframes, and there was this big push to move from any other SAQ to SAQ a. So we had all kinds of universities and other people that were, you know, online people moving to an iframe, as a way of saying, now we're secure, now we only have to do very few things, now we're awesome.
And so I think the industry for a long time, and frankly, I think even now, I was on a website yesterday for a web development environment, and they are saying we use Stripe so that way we don't have to do PCI. I go, no. Wait a minute. You do ecommerce.
Untrue.
And you're just so in other words, I think it's still a pretty big misconception amongst many people in the industry that this really is a deal for them. They still think iframes are protecting them. So I think over the next few years, the whole industry has to learn and understand these attack vectors. And that's what we're trying to help you understand today or or, you know, that's what the council is trying to have you understand with the addition of these requirements.
Now the example that I like to use, and and I've mentioned this in many times, but it's like putting a safe in your house. You can have the best safe in the world. That doesn't mean you don't lock your doors and windows. Right. You've got to do that perimeter security around those iframes. If an attacker gets into your house and they're in there for long enough, they will figure out how to get into that safe.
If they're in your website, even though you've got that iframe and and you've outsourced a lot of the responsibility to your payment provider, given enough time, the attacker is gonna figure out how to get data out of that iframe.
So, and I think this is why a lot of people, as merchants especially, are kind of frustrated right now because they thought, I'm using iframes. I'm doing the SAQA. I'm good. I have very little I have to do.
I'm outsourcing this. And all of a sudden, this feels like this feels like a big deal, and it and it kind of is a heavy lift in some ways. But I try to explain to my customers, this is something we're actually seeing. As a matter of fact, you, I think, took a report to the PCI Council.
Right.
Right. So and that's one thing I think that's helping the industry really kind of understand where the problem is. There's two programs here that we've had at SecurityMetrics to do some research.
One of those, our CEO really kinda loves to do, and that's something he calls risk checks. So he has downloaded, you know, got a database of ninety six million websites throughout the world.
And we checked those and found out of those, you know, fifty six million, you know, ecommerce sites that we know are ecommerce.
And we can run through those ecommerce sites with just a quick set of we things we know will be, not a false positive. In other words, it will it's like a VA scan, a very small vulnerability scan. And because we're an ASV scan vendor, we kinda know what things really are not false positive, what things turn up as false positive. So we picked a number, you know, handful of things that we knew were gonna result in compromises potentially, to their websites.
So check the Internet, a number of times. It takes a day or two to do the whole fifty six million and found the results found that basically twenty nine point nine percent of the websites ecommerce websites out there throughout the world were vulnerable to one of these big major attacks. So that means thirty percent of the ecommerce websites might be vulnerable.
And if they're an SAQ A merchant, that means they're vulnerable. That means somebody can get in. So out of fifty six million it is basically fifteen point five million or something like that, websites that could be, available for attack, which is a pretty big number, for the bad guys to go after. So that's the first piece of data that was important for us to understand that there's a big chunk of people out there that just aren't protecting the their edge very well, which then resulted in, an or can result in the reason for the ASV scans for SAQA merchants.
So SAQ A merchants now have to do vulnerability assessment scan where they didn't before. Yeah. There's a reason why. Thirty percent of them were bad.
So that's the first piece, which is frustrating probably as a QA merchants, is that they've gotta do a vulnerability scan. Mhmm. That's right away. And then future data is the script scanning stuff that we've been talking about.
Script analysis is not really a scan.
It's not like an ASV scan at all. I don't wanna make that distinction. But then Aaron has done a lot of research. We've got, a lot of kind of forensics we've done on level four merchants over the past number of years.
I think over two thousand. Yeah. Well, over two thousand. Two thousand on those.
Three.
Yeah. Coming up on three thousand. And so it's not a small sample. It's a pretty large statistical sample Mhmm.
During that investigation, Aaron's team is looking not only at the scripts that are present on the referring page, which is the page that holds the iframe Mhmm.
You know, the thing that you look through to see the third party site.
But we're also looking at the scripts that are loaded into the browser dynamically from their service provider. So we're seeing the whole process from soup to nuts.
Mhmm.
And, correct me if I'm wrong, Aaron, but at the time when we did this analysis, one hundred percent of all the cases where data was being compromised, it was being compromised on the merchant side, the small SQA merchant side, not on the service provider side.
That's correct. The malware, one hundred percent of the time, always came in on the merchant side of the iframe.
Right. So to me, that completely illustrates. And that was the kind of the gist of this little paper, this report we provided to the council first and now to the industry. You can download it.
Maybe there'll be a link under this podcast somewhere, that shows where this, problem is occurring. It's not occurring on the service provider side. Service providers are usually better at writing code. They're usually better at protecting sites.
And not to say that there isn't one or two or five or something that have this problem, but it's overwhelmingly a small merchant problem. So it's not a requirement that you can just say, oh, let's just ignore this one for now. We'll have the service providers fix it. And I think that comes from the whole feeling of, no.
I've outsourced to a service provider. Yeah. They should handle this for me. Yeah. I have a website that uses Stripe.
I just outsourced to them. Why is it my problem? What we're illustrating here today and these reports is that it really is the small merchant problem. It's the referring page problem.
And the confusion is understandable because a merchant that implements an iframe, they really don't get the credit card. Right? Right. The customer types it in, and it gets sent back to the payment provider gateway.
Mhmm. It gets authorized. The token gets sent back. The merchant ideally doesn't store that card data.
So a merchant is really feeling justified when they say, hey. Why are you looking at me? I never even saw the credit card. You know, go talk to somebody else.
Right.
And so, you know, that's how the merchant is feeling. Yeah. Like, I paid for somebody else to deal with this problem. Right.
And I'm also hearing this one. It's happening in the browser. Shouldn't the browsers be fixing this problem?
It goes all the way back. I mean, you could look at it as a browser issue. It's, you know, these latest attacks that we're seeing with iframe circumvention, it's based on the way that the browsers handle the rendering of the iframes.
Yeah. At at the end of the day, it's just another HTML element.
Yeah.
And you can use JavaScript to mess with HTML elements.
Program.
So you can address something like that.
You can go hit those attributes and properties of an iframe and mess with them, and attackers have gotten really clever. Yeah.
And figured out that, hey. Iframes have a source attribute.
Let's go play with it.
But that's working as designed. Right? The browsers are actually working the way they're designed. And so to say it's a browser problem, the browser needs to fix it. Let's wait till the browsers fix it. I think that's the wrong solution.
Yeah. It it yeah. It's not gonna happen. Sometimes.
It's not the that is not the correct solution.
Take a fundamental rewrite of the technology to fix that problem.
And that's and that's simply not going to happen. That's what I told him was, look. If if you have, an issue on your page, you're responsible for that. And it doesn't matter how angry you are at the browser.
Yeah. It's the the solution is really, let's look at how to how to fix the the vulnerability in the merchant page.
Yeah. The safe is still in your house. You still have to lock your doors when it does. You're not gonna get out of that responsibility.
Which then leads us to why the changes have been made in four o four. Specifically, the ones that are gonna affect people most, I think, is the SAQA merchants. They're not used to Yeah. These, you know, weekly things, daily things, whatever that they need to be, these these scans and these analysis of the scripts.
And it these are big and sometimes confusing language, especially if you're a merchant and you're outsourcing all of your technology, and all of a sudden you get hit with a requirement that has language in it that you don't understand. That can be, that can be difficult. And so I wanted to go over what the language is first and then talk about what it means, and then maybe see if we can talk about, from a technical perspective, what solves this. So starting with 6.4.3, all payment page scripts that are loaded and executed in the consumer's browser are managed as follows.
A method is implemented to confirm that each script is authorized.
A method is implemented to assure the integrity of each script, and an inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
So this is gonna be required in March March thirty first twenty twenty five. And but, honestly, everything that we're seeing says you should be doing this now because the problem is out there. And just because it's not required until March thirty first doesn't mean you're not gonna have a breach before then. Right?
Yeah. And 6.4.3 is really telling the merchants you have to know what is going on under the hood.
You know, behind the scenes, what are you loading on your checkout page when that credit card is present?
You have to know what's there.
I would take it a step further and say the merchant needs to know what is loaded on the page, why they're loading it on the page, and when it changes. And whether that's the merchant or who they've hired out to, the third party provider, someone needs to be aware and keeping track of that.
And I think that's the point of having it. The council, I think, when they wrote 6.4.3, they're thinking, yeah. This will be great. This will fix them. If we make a list of all the scripts they've gotta have, then clearly, they'll want to reduce that number.
So far, that really hasn't No.
That I haven't seen it either.
That control will be it. So it is about awareness.
Maybe it will affect some people saying, wow. We got fifty or sixty or a hundred or whatever scripts on here. I don't really wanna know what they all are. Do we really need these marketing? Do we need these?
Yeah. Well, alright. You don't have to have them if you don't want to. So that's a process that could happen, which would be a good effect of 6.4.3. It may reduce the number of scripts just because people say, why are we doing this? So it's an awareness thing.
And we do see a large number of scripts that are present. Sometimes we've seen over three hundred individual JavaScripts and libraries that get loaded on the checkout page when the card data is there.
If you think about that, that's a massive surface area Mhmm.
That is potentially open to attack.
Right.
You know, in a point of sale environment, if you wanted to introduce something on the back house server or or, you know, something in the payment process, that thing had to be vetted and looked at and approved. And now we're kinda just in the wild, wild west with ecommerce. You know, everybody wants us to throw a business analytics script in there because it's profitable. Right? You know, if you can throw a script in there that tells you when your customer is abandoning that cart, that's valuable information.
Mhmm.
So I wanted to ask Chad. I just made a point. You said up to three hundred. So Chad and both of you maybe, is that or that means three hundred different URLs, or do they come from one URL sometimes?
Well, that's kind of the top level URL.
You know, that's a URL loading in scripts.
There could be thousands of other scripts coming in from those. You know, some of these libraries open up into just massive amounts of code.
What's your take, Chad?
Yeah. It definitely is. It's, you've got multiple layers. So one script may load and that may load two more scripts, and then one of those scripts may load three more. So you've got this natural loading of additional content on it.
Kind of a daisy chain. I I think our record is finding malware seven layers deep.
Oh my goodness.
And the thing is is once you get past that for like, merchants today don't even know what the first layer looks like. And so talking about seven layers deep is just stuff that they're not even aware of. Right. But towards your point, Gary, of, like, what are the outcomes could be that people say, hey.
We didn't even know we needed to have all this stuff on there. Maybe we should remove one. We have already seen instances where we're reporting to merchants saying, hey. Look.
You're putting ad networks on the same page that you're receiving, credit card data. And we've had merchants within hours respond to us and say, didn't realize I was doing that. We fixed it.
Test this again. We need to make sure that that's gone.
And to your point, Chad, I think that I think that that's absolutely going to spur some behaviors with some, especially, small merchants. Because what I see when I talk to people is you've got your IT team typically responding to the audit. And they're saying, we get told to put these scripts on. We don't know where they're from. We don't know who the owner is. And so they don't have a good way to continue to manage those scripts because they're not even sure if the original reason they were put on is a valid reason still. I got asked this a couple weeks ago.
Should I just delete any scripts that I can't identify?
And I said, I think you should talk to your leadership about how they wanna handle it before you go deleting things. But that, I mean, that is the kind of the final solution. You have scripts on your page that nobody is taking ownership of. Nobody knows where they came from.
Well, pretty sure that's, tag for deletion. Right?
To your point, Jen, we had a recent forensic case where they were using just an off the shelf shopping cart solution, But they had published the code, and it included all of the payment scripts necessary for a number of different payment vendors that they weren't even using.
That code was out there.
Attackers were able to get in. They manipulated some of that external code to offer an occasional customer a payment option that the merchant wasn't even accepting.
And so they were just using code that was already there that wasn't in use. They just made a few little changes, and they were able to get a fake checkout process put in place using code that was already there. Not malicious code.
Mhmm.
They just made it malicious by injecting a few lines of JavaScript.
Let's also talk about 11.6.1 because 6.4.3 and 11.6.1 really go hand in hand. So allow me to read through this one, and then we can maybe dig into how we solve this problem with what kind of solutions will address these things. So 11.6.1 says, a change in tamper detection mechanism is deployed as follows, to alert personnel to unauthorized modification, including indicators of compromise, changes, additions, and deletions to the security impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
The mechanism is configured to evaluate the received HTTP headers and payment pages.
The mechanism of functions are performed at least once weekly or periodically as determined by a targeted risk assessment.
So this brings another view into what we're trying to do, the reducing the the changes or the potential compromise of the scripts on the page, not just knowing about it, but knowing, as Chad was saying earlier, have they changed?
Yeah. Going into that, it's not only, like, have they changed, but looking for indicators of compromise associated with those. If you are IT, for example, going back to what you said earlier, and you're like, hey. We're just told to add JavaScript onto the web pie web page, and you get notified another one got added. How do you know whether that was normal, expected, or not? So many organizations, especially smaller merchants, are not set up to even respond to those or know how to. And so I think one of the key things that we've really focused on and felt like is important in this requirement is identifying indicators of compromise.
Is that JavaScript that was added there, is it accessing card data? Are there new HTTP requests sending off malicious or potentially malicious data? And so being able to identify when something is suspicious going on in that page, Something that wasn't happening before, it's happening now, something someone needs to take a look at it.
Right.
So then I run into people that say, well, this doesn't seem too complicated. We'll have a spreadsheet of our of our scripts that are on our page, and then we'll do, CSP headers. We should be good.
And and and I've had to answer probably not. That's probably insufficient.
So I think this is gonna be one of the hardest things over the next year or two, not only for the small merchant service providers, but also for QSAs, and I represent that community.
I'm excited to have both of these other guys here with us today because they're the real guts behind this. And, frankly, you know, I think we might be in a good position here at SecurityMetrics to help people understand why these are happening, why these requirements are here, and then how to really know what they mean. You know, we spent, you know, Chad and everybody on the team have spent months looking and trying to read and figure out what the best things are. And I was talking to somebody, couple weeks ago, and they were reading it too, and they can read it in a totally different way than we read it.
Right? And they and I had one person say to me, they read it and said, well, this doesn't really apply to me. And I'm going, no. Wait.
It does. So I don't think that we can just assume that the Council was perfect in their language. I think they did their best at the time. It's a good requirement.
They did it. They wrote it based on what was really happening, the forensics. And so in other words, what we have here are people that are actually knowing why this requirement was written. Yeah. And so we have a unique perspective in being able to say, well, now I understand what they're trying to say in the requirement because we see it happening.
And, absolutely, I'm so glad that you that you framed it that way because I want to know how what needs to be in place to solve this problem, not against the the, pedantic reading of the requirement, but in a way that's going to actually solve this problem and prevent or even or make us aware of breaches, in this situation because these were written for a very specific challenge. And I think you are aware of the challenge and how to address it, and that's what I'd like to dive into next is what does it take from a technical perspective to address this challenge?
Yeah. And I'd like to hear discussion between these guys. At what level does this analysis has to take place at? And so we can help people understand that.
Well, if you think about what 6.4.3 and 11.6.1 are asking, you know, it's asking merchants to to know what's on your checkout page. As Chad said, know why it's there.
11.6.1, monitor it.
Mhmm.
Make sure that what is there is what's supposed to be there, and it's not getting changed in malicious ways.
And so, technically, to do that, that presents a number of unique challenges.
We've had Chad working on those solutions.
But, 6.4.3, we talked about the sheer number of scripts, right, that a merchant could have on their site.
Expecting a small merchant to go in and really inventory what could be potentially be thousands of JavaScripts, you know, once they once they all get unbundled, that's a huge ask. That's a technical requirement that is very challenging to know.
I mean, I think, Chad, you found a whole bunch of JavaScripts just recently, right, that we didn't even know were there? They were getting injected into another iframe?
Yeah. It's it's all about, what you determine is the scope of how you're gonna evaluate what JavaScript is running on the page.
It can really get confusing even on determining well, what is running on my page? That requires some technical knowledge and technical analysis to even figure out what's in scope.
Yeah. And for those technical nerds, I'll talk a little bit more about that because you've got, like, event handlers. That's JavaScript that's in line with the HTML element as it's defined. You've got inline scripts.
You've got scripts that are sourced from third parties. You've got scripts that are sourced inside a JavaScript or inside a or inside a sub iframes that post messages back and forward with the mainframe. And you'll have iframes that are sometimes nested two or three layers deep. And so when you start talking about the technical implementation of wrapping your mind around what it says in 6.4.3 of inventory all scripts that run on the page, that becomes a monumental task.
And so for anyone like me who understands how the browser works, you step back and you're like, how is any mom and pop shop ever supposed to find success here?
When you get really technical, you can even argue about what the page is.
No. Oh, I'm glad you said that because I was going to ask that question because I'll get this. Well, we have FIM on our payment page. But a payment page isn't a static thing. Right?
Can you maybe describe a little bit about how the final form, how we get to the final form, like and how you go from what is maybe the ASV scan is seeing what is just out there at the beginning of a payment page. Yeah.
I would love Evolution.
Right? Can you talk about what I'm trying to say?
Oh, yeah. Definitely. I'm super passionate about this one. So when you look at, like, a a payment page, for example, like a website, the biggest thing that you need to know is the payment page or the referring page, depending on which type of checkout you're doing, is the page that either embeds a third party iframe where the credit card number is gonna be typed in or it accepts the actual credit card number. If you were to look in the URL for that, path of how you navigate to that, if you open a new browser, you cannot navigate directly to that page because the application itself requires you to have state. You have to have an item in your checkout in your shopping cart.
In some websites, you have to be logged in and authenticated, and then you have to go to the checkout page. And so from a high level, you can start by saying, well, the page is gonna be the page that either embeds the third party iframe, which is a referring page, or it's gonna be the page that accepts the credit card number.
But then it gets even more complicated because if you're looking at it from a developer's perspective, it's all about what the DOM is doing, the document object model. Now web developers most web developers are actually oblivious to this, and I can speak from experience. As a pen tester, I've assessed probably close to a thousand different websites, web applications. So I've spoken to my fair share of developers, and I've developed some myself as well.
But the document object model is what loads in the browser when you go to a website.
Well, in some websites, that document object model is created once at the very beginning.
And even though you click on the login button and then you log in and the page looks like it's refreshing, it's actually just modifying that DOM, the whole DOM.
The views.
Right.
It's just changing the views. And this is called a single page application.
And so the question becomes, is the payment page the where that DOM was originated, where it first was created? Because if I load a JavaScript on that first view and then ten views later, I'm entering the card data, that JavaScript from the first view can impact that card data. And so for single page applications, your payment page or referring page may be your whole website.
And that can be used. Right?
This is such a complicated, topic for anybody to understand, let alone merchants who don't have technical experience.
And we do see malware scammers that get loaded in those single page applications all the way at the beginning. And then, you know, thirty minutes later after the customer's done shopping and they type in that credit card, that script was just waiting there the whole time, just waiting for that number to get typed in.
So you can't look just at the script on that initial page.
You can't look just at the scripts on the page that loaded the first time. Then when it's loaded the first time. You can't look just at the page that accepts the payment. You have to look at the full evolution of the DOM in that single page application because it could exist anywhere, and wherever it exists could affect the security of the credit card information. Did I get that right?
Yeah. And if you're traditional app. If I'm a nontechnical merchant at this point, I'm ready to give up.
Yeah. Yeah.
Yes. If you're in a traditional application, it's a little bit simpler because it does refresh that DOM on every single page. And so it can be just the URL, but you have to have the state.
But, ultimately, yeah, it's a complex. Even for some merchants to identify where do I need to be looking. They don't even know where to start.
Hey, Chad. You and I talked a while ago about this concept of generated scripts and dynamic scripts, and we have to think of this document object model that you're talking about, this web. Basically, it's kind of the browser environment, the development environment even or whatever. But but in in a totally dynamic way, it's not something that you can just say I think file integrity monitoring, you know, I'm used to in the old days just saying, well, let's just look at the contents of the HTML as it's loaded, and then we'll know what's on the page. This that's not really the way things work anymore.
No.
No. No. You've got so much dynamic content. As Erin alluded to earlier, we've got, tracking scripts that are literally changing what they're sending each time based on how you interact with the page. You've got ads, unfortunately, still today on the, you know, the checkout page that are changing what type of JavaScript is being pulled in.
And even marketing modules, when you're dealing with, like, Magento or, standard applications, they'll have marketing based on how where you're from geographically and what you've looked at on the page. They're gonna load different modules on that page, as well. Different HTML will come up. And so there are so many different factors that can play a part into this DOM changing that it's hard to get a firm grasp of how we are even gonna measure it.
Yeah. And some checkout pages are just so dynamic. You know, there's the funnel marketing that can produce a dynamic checkout page for any number of different products depending on how people came in.
And so those we've seen checkout pages being served from different domains, you know, being shared among different merchants.
And so it can get really complicated to figure out what is my checkout page.
Right. So from Jen and I's perspective as QSAs, some of this stuff is really interesting, but I'm not sure that everybody every QSA in the world is an expert on the DOM, an expert on all of this stuff.
I can guarantee you this is a hard conversation.
Hard conversation, and it's a hard topic to really grasp. So if we jump back up higher a little bit for Gemini's purpose for Gemini's view, what are some things that you two guys could teach, our audience about, this analysis process. What does 11.6.1 it has to happen in the Dom. What does that really mean?
And and how can we help as QSAs help our customers understand that, or what things can we do as a company to help communicate what this analysis really needs to be and what it needs to look at? I mean, I have been working on it. You guys have been working on it.
So you can really think of the browser environment as a virtual machine, a virtual computer that's running, on your customer's computer that is processing all of those JavaScripts and doing all of these dynamic things.
And that piece is really what we're looking to protect with eleven dot six dot one and6.4.3. And so it gets really complicated as Chad was explaining, but, really, we're just trying with with these two things, we're trying to to get merchants to get measures in place so that they know what's running on the checkout process in eleven dot six dot one to monitor those things for indicators of compromise so that if something does happen, it gets detected right away, and it's not six months of of card data loss.
And so that at a simplified level, that's all we're trying to do. And it does get complicated under the hood, but we're working on tools that are really gonna make it a whole lot easier for merchants, especially the small merchants.
Chad Woods, do you have anything you wanna add?
Yeah. I was just gonna build on what he said. If I were to approach this and I was talking to a small merchant, my first advice would be to identify how you're processing the card data today.
Like I said, you can't know where to apply any sort of solution or what type of solution. You had briefly brought up, like, CSP, and I hope we come back to that because I do have some comments on that. But, start by identifying what type of, processing of cards you're doing. Are you hosting it yourself, or have you outsourced this in an embedded iframe, or do you have a hard redirect?
Because once you have that knowledge, then that's gonna change what type of solutions you're gonna look for. The type of what looks like an indicator of compromise for a hard redirect is completely different than if it's a hosted page. The types of restrictions I'm gonna talk about with my QSA or whether that just be internally of how we're gonna monitor this, whether or not, you know, certain JavaScript should be on that page or not. It's gonna change based on whether we redirect to someone else or whether we take the card data itself.
So first off and foremost, I would say, start by identifying how you process credit cards.
I know this is gonna be scary, but ask your developers if you're a single page application or not. If you are and you're not technical, I would say that probably is a sign that you need to go and talk to someone who is an expert on it or work with those developers to try and find it. If you're not a single page application, then maybe there's some solutions that you can come and you can look at trying to implement yourself.
So, back to my one I guess my original comment on, the spreadsheet of, scripts and the CSP header. How come that's not sufficient?
And let me start with this discussion. I wanna let you guys go off on it here in a minute. But as an experience thing, this is Jen and I, we get these experiences talking to people. I had a customer say to me, well, I read in PCI v4, and this was the first version of 4.0, in 11.6.1, the guidance basically said it sounded like it could be interpreted as being said, you can use any one of the following solutions.
And it had a list of a number of bullets. CSP was one of them, SRI, you know, all these different things. And when I talked to the people at the council who actually kinda wrote this, I said, is that your intent? And they said, no.
No. Really. It was just examples of things that could be put together to create a solution to this problem. So I had a customer say to me, well, no.
CSP is one of those bullets. Yeah. That's all I wanna do. And I'm going, no.
They rewrote that in 4.0.1 and actually made it say could be made up of one of the of a number of the following. So that's kind of a preview to what people are so careful about reading these requirements and trying to think, I gotta do the minimal amount.
Yeah.
Because they wanna do.
Because they wanna get out of the work rather than addressing what the real problem is.
So why is CSP itself not enough? Is that a Chad? Start off. Yeah.
I'll dive into that one. I was the one who asked it to come back up. So, CSP was a browser solution to try and solve the problem of how do we prevent JavaScript from executing in the page that we don't wanna execute. It's funny because this ties directly back to we what we talked about before is, isn't this a browser problem? Yeah. They became just the solution.
Ironically, CSP came out years before even the PCI was talking about what what could we do as a solution.
To to paint a picture here, in twenty twenty during COVID, during the lockdown for the remote PCI North North America community meeting, I actually gave a presentation on using CSP and SRI to identify skimmers in the wild. So this solution has been talked about and thrown around, and there's a lot of great advantages that you get with CSP.
Ironically, even four years ago, my conclusion was CSP is great and it has opportunities where it can identify skimmers. However, from experience, I can tell you, they're false positive prone. Many browser extensions to this day can still cause false negative false positives, where the browser extension triggers traffic that gets interpreted as a potential skimmer. Number two is that, CSP itself is extremely difficult for the average developer to be able to configure properly.
We just talked about before that JavaScript gets loaded in as like a daisy chain, and you can have layers and layers and layers deep. Developers and I've seen this on a pen test site again, that developers will go and write a CSP, and they'll lock it down, and they're like, We got it. And then they load up the page in production because they just pushed it, and nothing will load. Because they didn't realize that this JavaScript over here depended on this JavaScript way down here that came from a third party.
Yeah.
So CSP is hard to get right. Out of close to a thousand different websites that I've assessed, and I've probably seen CSP on around fifteen to twenty percent of those, I've probably seen one or two that were actually written correctly where I wasn't able to bypass it. Mhmm. Like, in less than a one to two percent.
There are so many common ways that people make mistakes when writing the CSP. They don't consider the exceptions. They don't consider how they're white listing them. And so there's so many pitfalls with it.
It literally is a foot gun. You use it, but it's at your own risk.
And so I think that we solution in and of itself.
Right?
Yeah. And that goes to what Gary is saying there, which is even if you get it all right and you put it into place, the problem is the third bullet point, Jen, that you had mentioned was you have to make sure that it's running correctly weekly. And the CSP, there's no way to check whether that CSP has been modified automatically. So someone would have to be going into the website and looking for that.
So it's not a set and forget solution.
Oh, definitely not. I mean, it's the exact opposite. Because if I'm an attacker, you know, going back to what Aaron said earlier, and I've got access to your to your ecommerce environment, I can change what's on the page, but I can also change the headers. So if you have CSP, it's just one more step for me to go in and change the header before I change the page. It's not that big of an obstacle for an attacker to get around.
Right.
And so many times in our forensic cases where merchants have lost credit card data, we found that CSP was implemented Mhmm. But either wasn't implemented correctly or the malware was whitelisted, or it was coming in from malvertising where the ad network was whitelisted.
Come through. Right.
And so, yeah, the malware got in and CSP was essentially defeated.
Right. So that so CSP would protect something as it was being loaded or as it was coming from a place you didn't recognize.
And that's why, this analysis has to happen. You know, you just said, well, I whitelisted the malware. I wanted that ad to come through, and that's where it came from. So there's one of the reasons why just that solution itself won't work because the guys that designed your website, the marketing people said, no. We need to whitelist that area. And that's where the bad stuff came from, so CSP would never find it. Right?
Well, yeah. And I'd change your statement there, Gary, a little bit from I white listed the malware to I white listed the CDN that we get all of our JavaScripts from. I mean, we've seen this on even CDNs that have this. So you whitelist your CDN, that CDN gets compromised, and now that malicious JavaScript can come in. So it can be a trustworthy host, a trustworthy source.
That's a better way to do that. Yeah.
Yeah. Yep. For sure.
And building and building on CSP, SRI, again, another browser solution that they gave us to equip developers to proactively protect against this. The problem is the vast majority of JavaScript that's loaded today in the browser is dynamic.
It changes every time. And so SRI was great ten years ago when it first came out. Like, yes, there's everything that we can do to lock down and make sure these JavaScript files don't change. But is web two dot o has turned into web three dot o, which has turned into web, I don't know.
But whenever it's complex Whatever. Yeah.
We we're no longer static. Everything is dynamic. And because everything is so dynamic anymore, even SRI, what the developers years ago from these browser companies and I wanna give them compliments and and call outs here because they're great developers. They see this as a problem, and they're trying to help, but it's not a problem that even they are equipped or positioned to solve.
So solutions.
Well and and that's that's, I guess, the crux of this. I'll bet a lot of people are listening going, tell me what to do. What is the solution I should use? Right? And there are a lot of organizations out there that are working hard to come up with solutions.
I think, when an organization is trying to decide what solution do I use, how do they how do they choose?
Right. I I think this is a good opportunity for talk about kind of the two major categories of those solutions, and I'll let these guys pontificate more about them. But in my mind, I see it as, an agent based where somebody has to actually take a piece of JavaScript and add it to your page as a developer. So you have to be savvy enough to say, okay. I I get this JavaScript that's from a provider that says that they can meet 6.4.3 and 11.6.1, but it requires me to put this thing into my page.
And, you know, it's not that hard. It's a cut and paste, but some people, small merchants, may not even really know how to do that. So then there might be a reason why we need an agentless solution, something that doesn't require software development. Maybe they don't even have access to the development environment sometimes, these people that are trying to get compliance.
So Well, and then there's this two solutions.
There's also the discomfort of of adding any kind of a script on your page. Like, exactly. I mean, we're here we are going, yeah. Do you know your are your scripts authorized? And you're like, oh, one more script. Yeah. What is You have too many scripts.
You add another one.
But I'm not saying we're not we're not trying to diss those those solutions. I think a script based solution for 11.6.1 and 6.4.3 is a viable solution, but it's just one more thing you have to think about. Make sure that you're covering that. So why don't you guys Yeah. Talk more about about that?
Oh, there are some advantages to a script based solution, and we've certainly explored those.
Agent. Agent based. Right?
Agent based solution.
Number one, you can monitor every single transaction. So every single transaction that's going through, you're right there.
And if anything goes wrong, you've got a front row seat.
Let's go back a second. And, you know, you guys you two guys already kind of understand your minds. Like, well, it just happens. I don't even know how that happens. So when you say that a script I can add a script that monitors everything.
How does it do that? Does it put itself in front of everything? Is it become like a proxy and all the traffic has to go through it? What is why does that script become all powerful?
Yeah. That script ultimately become it is the first thing that you load into that DOM. We're gonna step back into the technical. I apologize, but that's what they brought me here for is the technical.
It's the boss.
It's the boss.
So when you load the JavaScript, it's gonna be the first thing that's loaded into the DOM. And what that JavaScript does is ultimately it wraps everything that the browser can do and everything that you can do inside the browser so that it can profile any other JavaScript and determine what it's doing. So think of it like a sandbox. It's gonna build like a a firewall.
It's gonna build a firewall between every JavaScript and any action that it's gonna try and take. And then they can use heuristics to try and determine, hey. This JavaScript's doing something new, or this JavaScript actually grabbed a credit card number, or it's sending off a request to a new web page. But that means because it's the first thing loaded into the DOM, any visitor that comes to your web page, they're gonna have that sandbox there.
They're gonna have that script that is loaded that's ultimately listening to what they're doing on the page.
Is that a processing hit?
Is that something that It can be.
Yes.
And you say it wraps and determines does it does it just be aware of every type of transaction or every type of script that gets loaded, or does it prevent them?
It can do both. Like, it it ultimately, they're putting themselves in a position almost like antivirus. If you think of antivirus on your computer, you know, Aaron had made the comparison that these browsers today are basically operating systems is how they work. So these inline scripts are basically like an antivirus running on your computer. An antivirus can just report you and notify you. It can quarantine that JavaScript and just put it to the side or quarantine a virus, something that it sees malicious, or some antivirus will actually just delete it immediately and shut down any processes that had were associated with it. So you've got different actions that can take, and these JavaScript can do the same thing.
So, because I know that my merchants are gonna be asking me, well, what happens if it's, like, false? So so in other words, if they're gonna choose an agent based solution, that's one of the questions I think that people need to ask is, can this potentially stop a transaction from going through? Because that could potentially, raise some issues if they're not aware that that is something that that could happen.
Yeah. It could happen. If you, make a change that they weren't expecting on their web page, then they may determine that you are a threat, and you're trying to get to that credit card data and you weren't approved. So, yes, being blocked is a potential, so you'll wanna work with ever whichever provider you end up going to with and make sure that you're aware of what to do to prevent that from ever happening.
Right.
I can't speak to the hows because it's so vendor.
It's gonna be different from vendor to vendor, but it's I think it's a valid question for merchants to ask as they're as they're implementing this.
And I wanna make one quick point here.
A point of compliance order, I suppose, is that I think a lot of people that I've talked to, say that prevention that we've talked about here, that Chen talked about, is a requirement in PCI DSS, that when you see one of these scripts happening or doing some indicator of compromise or whatever, that you must prevent it. And I think that's not the interpretation of the standard. The standard just says alert.
I'm not saying the prevention is bad. It's a it's going kind of the extra mile, and the standard is the low part of security. Yeah. You know? So prevention could be possible.
But just to be clear, the standard says alert, not alert and block or alert and block.
So potentially a business decision based on a risk analysis. And another thing to think about as they're because people are implementing something brand new, and there are a lot of questions that might not even have occurred to a lot of merchants yet. So I'm trying to get ahead of people asking me these questions because I know they will. That this is a this is a new thing that we're all trying to to get into place.
There's kind of a a an innate fear in in the back of some people's mind that if we put a systemic solution in like like an agent that we embed on the page, could there be a catastrophic failure where it shuts down every single transaction and our website is down and and it's labeling everybody? What do you think, Chad? Is that could something like that happen?
Oh, yeah. I mentioned earlier. I've seen it happen with CSP, and and and I don't wanna this is not me guessing that it's gonna happen in the future, but we saw what happened with CrowdStrike with a bad update. Yeah. And CrowdStrike was an endpoint like antivirus, and I just compared an agency to antivirus.
That they make a bad update.
So it's a potential risk that people need to be aware of.
Yeah. You ultimately, I would say, you wanna make sure that you vet your vendor, whoever you're going with, to make sure that you trust them, but know that even that isn't a foolproof solution. So there is no guarantee there.
How does the agentless solution get around that?
Well, the agentless solution does not run inside the browser. So its visibility is much reduced, dramatically reduced. An agentless solution is something that is going to go through the checkout experience, and then it's gonna get from a browser. Right? Because that's one of the requirements. But it's gonna be a browser that that vendor controls, and then they're gonna do an evaluation from inside of that controlled environment.
So it's completely independent. It isn't a vulnerability scan. I wanna be very clear of it, but you can look at it being performed much in the same way as an external vulnerability scan that's required in PCI today.
That infrastructure is completely independent from your infrastructure, and that has some major advantages that come with it. Because if you're gonna embed JavaScript, they do the agent solution, That JavaScript becomes a part of your code commits that you're doing. There could be some configuration changes that you're gonna have to make. So your development process is gonna have to adapt to that vendor.
And you have to bet their security as well, right, potentially.
Yes. But an agentless solution because just like a VA scan, they're completely independent of you. There is no way that that agent, agentless solution could ever impact the security of any of your transactions that are happening, and it happens entirely independent of all your configuration changes, your code changes. It's completely separate from all of your processes.
So is an agentless like, you can almost think of it as a virtual person making a transaction and then allowing, you know, a company to look at all of these things that happened during that transaction.
It's like the secret shopper concept where you hire somebody to come in and and vet your store, you know, check out your store, see how see how the customer service is, see how the checkout Mhmm.
Process is. It's kind of that concept where we would come in and we would simulate a a real world transaction.
It doesn't look any different in the logs. The attackers never know that we're there, which is another downfall of of an agent based one.
Sometimes the attackers know, you know, your code is right there on the page for anybody to see the Yeah.
With an agentless one, there's no way to shut us down because there's nothing on that page for anybody to mess with.
I wanna dive into this for YouTube just for a second. Sorry, Jen.
I No.
You're good. Yeah.
Because I'm thinking about, if look. We talked earlier. I said earlier that thirty percent of the websites might be vulnerable to compromise. So in other words, many of these compromises we're talking about assumes that or or all of them maybe assume that the bad guy has control and is inside your web server, right, in some ways. Maybe not, but some of them do. So if the guy is on your web server and he's looking at the code and he can see you've just loaded an agent based solution, can he change that code? Just remove the agent based solution?
If he's got access, he can And, again, this isn't where the place where all the compromises are occurring, but some of them are that the guy actually has the bad guy has access, root access to your systems.
The other compromises are happening because they're being loaded from malicious sites or sites that have been compromised by somebody else.
But anyway Yeah.
Well, going along with what you're saying, Gary, they actually don't even have to remove it.
The premise of an agent based solution is it's the first thing loaded into the DOM. All they have to do is insert their JavaScript above that. Oh.
Because now they can no longer wrap it in time before these guys already have access to what they need to have access to.
Interesting.
So there are ways that they because they can now wrap the wrapper. And so, they don't have to remove it because removing it, you know, an agent based solution may say, well, we'll notice the moment that that goes down.
So this brings another so here's my compliance brain thinking again, Jen, and Jen probably thinking the same thing. So we know that SAQ A doesn't have a whole lot of controls around edge security. Mhmm. Right? I mean, they're adding ASV scans because that's one attempt. But I mean, as an auditor, we don't go through section one.
We don't look at their firewalls. We don't look at their hard names.
Through anything for edge security. So what we're assuming and what we what SAQA has assumed for years and years is that, well, they can't attack the website that you know, you can't get the credit card data because it's a third party payment script and all I mean, a payment page and all this kind of stuff. But what we're seeing now, and I I want to make sure our audience understands this, is that you can be doing an SAQ a and have one of the solutions for 11.6.1 and not worry about your firewall, somebody breaks in and does exactly what Chad said, puts their stuff in front of your script. So we're asking people in SAQA to do these things, which help reduce the risk a little bit, but it's still we still may be saying thirty percent of the world is vulnerable, and we're not addressing that problem necessarily.
Maybe. And it's a conversation. So I always try to have that conversation with the people that I work with is, you know, let's talk about security. Let's talk about what we're seeing in the real world, and then we'll talk about what PCI says.
Are you going to pass your PCI assessment by doing only these things? Yes. Are you still vulnerable? Yes.
And that's something that not to scare people or anything, but it's important to have a security program beyond PCI because of some of these things we're talking about. Risks that you may, you know, and understand what those risks are.
Yeah. And one thing I would just hurry and interject here is that no solution is ever gonna be foolproof. So, like, vulnerability scanning. We have a standard that we have to go and adhere to to be an ASV.
But even ASVs miss aren't foolproof. We will miss vulnerabilities on occasion.
And so the agentless or agent based solution, we talked about some shortcomings there, but there are also shortcomings of an agentless solution as well. So I just wanna make sure, especially to make sure our viewers are educated.
An agentless solution like what we talked about, the, Phantom sharper shopper, I think is what Aaron called it. They may only be coming from one geographical region. And if you're a global company, then you may have regional CDNs, and those compromises could be a regional thing. Right. And so when it comes to choosing between an agent and an agent list, it's important to know that there are pros and there are cons to either side.
And some solutions, like, some companies want an agent list, but because of how their website processes, they really need to get an agent based solution Right. Vice versa.
And it may even be a combination of both solutions that you want to implement in your in your corporate plan.
And there are ways we can adapt an agentless one. You know, we can simulate shopping experiences from different geographic regions. We can use different browsers and mobile browsers.
It just depends on what what SLA you you really wanna do for that type of solution.
I wanted to ask follow-up on that a little bit, Chad. I think earlier you said, and perhaps I I misunderstood you, but I think you said, that agent agentless has less visibility than agent based. Is that is that what I heard you say, or was that incorrect?
Oh, by definition, much less. And and for some companies, that's desired. Okay. Sorry.
Alright. So I just was wondering it. Does that mean they're going to miss something if it's agentless?
I wanna expand a little bit on that. So I've done pen test in environments where they are processing over a thousand transactions every second.
And in those environments, because they have thousands coming in, they don't want to assess the security of all thousand of those.
They don't want every single one of their customers because they know their customers are running legacy hardware.
Mhmm.
And agent solution can impact that processing time as, Gary had alluded to.
It can create a huge footprint.
And so for companies like that, they may choose and say, do you want to know what? We just want it tested daily.
We one of the things we haven't even touched come back to yet is that you can choose how frequently based on a risk assessment to run this. If you're processing two credit card numbers a year through your website, then do you does it make sense from a risk assessment to run it weekly? Or maybe you run it even less frequently than weekly. Right. And so, again, like, it comes back to what is their goals, like, what best fits how they process cards and their environment.
That's why both solutions are important, I think. Right?
Right. Yes.
I I just don't want customers, like, listeners walking away thinking SecurityMetrics is saying agent list Right. Is this shining silver bullet. Because both of them are silver bullets, and they both have values.
Right. Great.
They both have Kinda where you're going after.
What market? And I think here at SecurityMetrics, we're really have always been focused on small merchants in a big way. I mean, kind of Jen and I is part of the company and and Aaron and Chad, we all kinda work with maybe enterprise level people.
But there's a whole another group of SAQ A people, smaller merchants that are having to deal with this. And Yeah. You say to them, all you have to do is install the software or, you know, put the software in your script, in your payment page, and they go payment what, where, and how, and what exactly where is it? So you need to go so how do I know you know, so that can be difficult for really small merchants. So is there a solution that may be more effective, in actually protecting the problem that we have detect that we see that there is? It's a small merchant problem.
Right.
It's not a big service provider problem. It's a small merchant problem. So how do we address that small merchant problem? And how does an agent less solution help that problem?
Right. And I think we have so far been extremely cautious about saying, and therefore, SecurityMetrics does this thing. Right? But we do.
We do have this thing, and it's called shopping cart monitor. And I think it's okay that we talk about our product a little bit. Now that we've really weighed, you know, what are the pros and cons of of various ways of doing things. I think there's value in talking about how we do it now, if if that's okay.
Yeah.
Well, one of the most awesome things about shopping cart monitor is there is nothing to install.
Mhmm.
If we've got the URL, we can point our tools at the shopping cart, and it'll go into its thing. And with the configuration, the setup is so much more streamlined and easy than having to go insert something to make sure it's compatible, make sure it doesn't break your shopping cart.
So that is one of the main benefits for a smaller merchant that may not have the technical expertise.
And the money. Yeah. Yeah. To be able to spend on some of these.
There are some pricey solutions out there for sure.
Yeah. There's some really pricey solutions that are just, frankly, really impossible for a small merchant to to meet those fee levels.
Right. Yeah. When we started working on our solution our first solution, we started in two thousand nineteen trying to bring a product to the market. And, we ran that with that product for the past five years, and we have version two that's come out. And it's been released for a limited release so far.
But when we started even five years ago and every other time that we've talked about the solution, we have always started from the perspective of how do we help the most merchants, as possible, especially small to medium sized merchants because that's where we help the majority of our customers are those. And secondly, how do we make it as streamless and and stress free as possible for these environments?
So for us, that's where agentless became a no brainer. It was like that is the only option if you're trying to accomplish both of those things. And so for our solution, as Aaron said before, is customers will come to us. They'll provide us the website that they have a a shopping cart on.
And then right now, that is all that they have to do. And we go through during the limited release, and we will actually do this for them weekly so that they can get familiar with it. Now when we do our full release, which should be coming in the next month or so, so pay attention to our news feeds. But when we do the full release, we'll actually have the tool on the website that merchants will be able to go into the website.
They'll be able to have a embedded what looks like a mini browser open to their website, go through the checkout process. And once they're done shopping, once they've completed that shopping step, then they that data goes over to our analysis. Well, we'll break it down and look for those indicators of compromise. We'll identify all the JavaScript that was loaded on that payment page, and we'll be able to give them a simplified view into that.
It'll be an interface that can it is an interface that can both manage the JavaScript and allow you to do your inventory right there in our website so that you're accomplishing 6.4.3, as well as it'll report any IOCs that are detected or changes, updates to security headers in order to accomplish 11.6.1 as well.
So, ultimately, that's the solution that we've tried to develop over the past five years. Right.
And and and like you said, we've been doing this for quite a while. And, it's really cool that these two techie nerds are with Jen and and I as QSA's today because I think they really have you know, I go to these guys and say, please explain to me why this is happening because I really can't do it. I can't understand it. And it's a deep part thing. And part of our job as QSAs and, basically, as a company, SecurityMetrics, is to help people understand at the level they can understand what these tools are needed to do and what and and how to do it. There's, I think, another product I'd like to mention too that Aaron's group runs, and that's called shopping cart inspect. So if you don't wanna jump into a monitor solution and you just want let's say it's between now and the end of this year or between now and March, well, don't make it all the way to March.
No. Do not wait till March.
Until now and December, now and January.
You just wanna get an experience with, well, what really is on my site? And how can I jump in not jump into the pool, but dip my toe into the pool and find out how my website is faring?
Yeah.
You know?
And that's kind of a one time analysis, for a pretty cost effective inspect service that we do in forensics.
Yeah. That's kind of a a little mini forensic that we do, where we review your public facing code, you know, exactly what the customer sees in the browser.
We go through. We look at all the JavaScripts, inventory those JavaScripts.
And it also works really well in tandem with shopping cart monitor because if you do a shopping cart inspect first, we go through and look at it and make sure that those scripts are behaving properly so that you're not white listing any of those potentially malicious scripts that that could then, you know, potentially be, let by by any type of monitoring tool.
So shopping on respect is something that somebody could do today. Mhmm. Yes. Right? And really get a good start, a good understanding of 11.6.1 and 6.4.3 without committing to a solution. And we're not saying, you know, you if you use Shopping Cart Inspect, you don't have to use Shopping Cart Monitor, but it's a great way to probably get started. And if you don't know where to start and you're not and you're worried about March thirty first coming up, here's a place to start.
So I'm sure we'll have a link somewhere in, you know, with amazing how many times we get shopping carts inspect inspects, in where we go through and and do the analysis and find malware when there was no suspicion that there was even anything wrong.
I I think the last statistics I looked at were something like seven percent of our cases that came in Oh, wow.
Where they just did it to do it. They're they didn't have a CPP report or nobody was reporting fraud. We went in and found some malicious activity happening on their website.
Almost a one in ten chance that you might have something going on there.
So Always better to find it before you get a report.
Yes. And this won't affect your compliance at all statements right now. Even if you're in the middle of anything, you can do one these. So Yeah.
We've talked a lot. There's been a lot of stuff probably to remember. If we were to summarize, what are some of the necessary features of a tool that needs to do this. So if I were to try to summarize, and you guys can correct me if I'm wrong here or add to it, the first thing needs to be during this discovery phase, right, when we're looking at a website to see how many scripts there are, what's going on, that has to occur at what Chad calls the DOM level, the document object model.
So this all has to be doing happening there. So if you have a if you're looking at a tool that that you know, there's gonna be a lot of people, I think, that come out in the next six months, year saying, we do 6.4.3. We do 11.6.1. You go with us, and we're gonna do it.
I worry about QSAs out there just saying, well, it says they did 6.4.3 and 11.6.1. What's my you know, I don't know enough to go test that. And I don't have a tool to go test that. Because, you know, we just basically trust whoever does that.
And the same with consumers out there who are buying this service. There are a lot of really great solutions out there. There's gonna be more.
Will there be different quality levels? I assume so. Probably. Right? Because that's how the world works.
Right? So what are some questions that you need to be aware of that you can say to your solution provider when they say, no. We've got your back. We do 11.6.1.
We do 6.4.3. And you say, okay. Well, do you do a dynamic analysis in the Dom? Does it cover from the very beginning of the load all the way to the very last typing of the CVV data?
Right?
Is there anything else in that data gathering? Are there good questions that they could ask in that data gathering?
Yeah. The next thing I would look at is, what does your interface look like for me to be able to manage my scripts? Because if they're gonna be doing that, like we said, there's daisy chain six, eight, nine layers deep. How, where do you wanna manage that? Does their interface provide you a place that you feel that your organization and your processes will be successful?
K. So there's a good one. Show me your interface for looking at the script.
Show me my JavaScript. Show me my JavaScripts and show me my alerts.
So the discovery phase, dynamic dom, super important.
Show me what you know, that I can see what's going on. How can I justify them? So then the next part that Chad called basically our analysis part after we do the Phantom shopping, we send it, you know, we anyone would have to send it to some sort of analysis, portion. What are some of the features of this analysis that need to be, asked about?
Right? Are you looking at dynamic scripts? Are you looking at generated scripts? Are you, I'm just making up some of these things.
Are you, what is an indicator of compromise? And how many indicators of compromise are you looking for? And where did you get those indicators of compromise? Do you guys have anything to say about this analysis thing that would help people know whether they're getting a good solution?
Yeah. I, I I'm gonna throw out, you're gonna see a lot of my background come here because I spend a lot of my background come here because I spend a lot of time helping our ASV team over the past few years, our vulnerability scan product. And one of the things that I'm hugely passionate about is don't go after the number of IOCs, or don't go after the number of plug ins specifically for vulnerability scans. Because just because they look for more things, that could also mean that you're gonna get more alert fatigue.
Most organizations are not ready to take on five, six, ten alerts in a week that are gonna cost their employees thirty minutes to an hour or an hour and a half to go and investigate.
So knowing more about what type of things do you, report, how frequently are you reporting them, what can I expect for time investment that we need to invest to support this product?
Those would probably be the questions I would ask. I think there definitely is an element of how do I know that they're an authority or not? Like, is this a college graduate who has no real world experience, or do they have a forensics organization like SecurityMetrics does in Aaron's team that's actually providing research, and evidence to build a product around. And so, I would ask some questions about, like, how do you determine what you're gonna flag for? What does that process look like?
But I would be sure or be wary of just looking at what are the numbers, what type of alerts am I gonna see.
Okay. And that kinda gets to the third phase, which is reporting.
So is there some kind of minimum, you know, required reporting or or things that you would look for a solution? How do I know when something is sent to me? How do I know how bad it is and what I'm supposed to do about it?
That's where, support would come in. Right? It's like, what type of support will you guys offer us? If we need consultation, can we get consultation from you? Or are you just gonna give me it and expect me and my team to be able to research and understand it? So Okay. Understanding more of what the contract is.
I've been alluding to it, but one thing if you read under all the comments I've made throughout this section here, it's all about what type of organization am I and what type of investment am I ready to make in this tool and in this process.
If you're a company that looks at PCI as a bunch of checkboxes, then going with the best solution that requires, you know, three to four hours a week of your time probably isn't gonna give you your money's return. And if you're in a small organization that needs to be nimble and quick and you need efficient reporting, then you wanna make sure again that you're going with a solution that doesn't that frowns upon false positives.
And so when it comes to reporting, it's gonna be under that same tone of what type of organization are you and what are you looking Okay.
And here's my or do you have something else you wanna add?
Oh, I was just gonna make a quip.
You know, if you really wanted to test them out, go change your URL to your iframe and see if it's See if it catches it.
Alright.
Ironically, Aaron actually, ironically, I had a pen test customer, call me last year, and we were talking about a solution they had just bought. This was before, it was officially released. He's like, I bought these guys. We went and changed the iframe. We changed who we process with. We changed everything.
And they didn't notice for a month until I Oh, no.
And so he's like, I quit that contract in a second.
He's like, I Maybe test it out. Right?
So that might be Well, I mean, I was saying that tongue in cheek, but Yeah. But it might not be a bad idea to test it out.
And now here's the last question I had because I had this in an audit this summer. Somebody talked to me. And this organization, very sharp. Really good development team, thirty developers. It's a great company. They're really sharp.
And their first question was and the developers, when I was up on the phone with them, well, we can write this our own. We can do our own.
You know, how hard can it be? So I guess with your two guys' experience over the last five years, how would you address that to a developer saying, well, it can't be that hard. I can just write it myself. How hard can it be?
My response would be good luck. You know, it gets complicated. And you may be able to pull off a simple solution, but, you know, I I would have my doubts if you're really getting down to the to the nitty gritty of what's going on in the browser. Are you checking local storage to see if scripts are being written into local storage?
Are you checking for scripts inside of cookies?
All these methods the attackers use to hide their malware in places you would not even dream of Mhmm. As a normal developer. You know, hackers are very good at hiding their their stuff in in places that aren't being observed. So you could write some quick little, program to to monitor what's there, but are you really checking all of that dynamic scripts? If a script changes, do you have the ability to determine how what type of a change it was?
So all those type of issues come into play, and we've been doing this for years now. Chad and I have met fairly regularly over the years, looking at at all the different ways that attackers are getting in and exploiting things.
And so it can get really complicated. I'm not saying you couldn't do it. If you have the skills, by all means.
But then as an assessor I mean, not to overburden PCI further, but how do I know that the solution that they're using meets all these things?
I mean, this seems technical enough that and it's taught me if I'm wrong. It seems like it would be a good candidate for something like the ASV program.
Yeah. And I I frankly have brought this up with the PCI Council. I don't know where in the long run it'll go, but I think they recognize, that this is harder than ASV. And there are some movements starting now at the council to try to get their arms around how do we really is it does it make sense to validate some of these solutions?
I don't know. And I'm not gonna say that they're gonna do one thing or other. All I can say is they have an ASV program, and it's way harder than that. So is it a candidate for something in the future potentially?
Yeah.
It would make my job easier. So if you could make that happen. Yeah. Thanks.
Chad, did you have anything that you wanted to add about could somebody write this on their own? He's kind of been doing a lot of the writing of this.
Yeah. I've talked to developers, from customers and from other organizations both. And I I think that you could do this on your own if you wanted to.
But the thing I would bring it back to is, the last time that you developed something that was not within your, subject matter experience, like, where where you're an expert in, how long did it take you to notice that it wasn't running properly, and how much time did you invest both the building and then fix the problems that inevitably came.
And we laughed and laughed.
And we laughed because we've all done that.
We've all been there. And so what I would what I always respond with is, okay. Then I would take those hours. I would add fifty percent just like you would if you were estimating it for your management.
Right.
And then ask them what is your what is your time worth? And then compare that against what solutions are out there. Maybe you don't go with a pro version. Maybe you choose a basic version, because of who you are and where your priorities are.
But it would allow them to allow to at least start to say, okay. Do I wanna build it? If we're gonna build it, what's a metric look like? And then how do I compare That's how I would recommend they go about making that.
Nice. Good advice.
So it's not just CSP.
Nope.
It's gonna be more. We've already addressed that. So I think if people are out there thinking about developing their own, just realize we think it's hard.
Yeah.
And we've been doing it for a long time.
Yeah. And it's so important to emphasize that you can't outsource all the responsibility.
If you're using iframes, great. We want you using iframes. They do so much to protect that card data, but you still have to lock your doors and windows. Yeah.
Well, thank you very much. It was a delight speaking with all of you, especially altogether. I think this was, this was the cross functional conversation that that really needed to happen, and I appreciate your time.
Been great. Thanks, Jen. Thanks, Chad. Thank you, Jen.
Thanks for watching. To watch more episodes of SecurityMetrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)
