Practical Cybersecurity with Jen Stone · 2026-08-04 · 39 min
Key moments - from our scoring
Substance score
65 / 100
Five dimensions, 20 points each
Jen Stone from Security Metrics hosts a panel webinar with Aaron Willis (forensics) and Hef (SOC/threat hunting) examining how AI has changed the threat landscape in 2026. Rather than introducing novel attack vectors, AI is functioning as a force multiplier for existing threats - credential compromise, session hijacking, MFA fatigue, and especially e-commerce skimming attacks. Aaron reports investigating thousands of cases annually, with over 2,000 e-commerce focused breaches, finding one new skimmer per week across monitored sites. A standout case involved attackers bypassing agent-based security by exploiting Next.js framework rendering and using keystroke logging stored in local storage. Jen clarifies widespread confusion around PCI DSS 4.0.1 compliance with AI: the standard doesn't mention AI explicitly because existing requirements already cover it - access controls (Requirements 7-8), secure development (Requirement 6), and risk analysis all apply to AI systems. Critical confusion exists around Requirements 6.4.3 and 11.6.1 regarding script protection in e-commerce, with FAQ 1588 creating ambiguity around iframe vs. redirect approaches. Aaron reveals a 300% increase in merchants choosing payment redirects to avoid compliance overhead, unknowingly adopting a weaker security posture that attackers heavily exploit. The panel stresses that compliance is a floor, not ceiling security strategy, requiring continuous monitoring and real-time threat response.
PCI DSS 4.0.1 covers AI implicitly through existing requirements: access control and authorization (Requirements 7-8) apply to who can access cardholder data including AI systems, secure development (Requirement 6) applies to AI-generated code, and risk analysis applies to AI implementation decisions. Organizations must justify AI's business need and apply the same controls as to human systems.
FAQ 1588 clarifies that script protection (Requirements 6.4.3 and 11.6.1) applies to all e-commerce payment processes. It originally seemed to waive script protection requirements, but it actually requires merchants to either obtain written confirmation from their payment provider that the embedded solution is protected, or implement their own script management and tamper detection.
Full payment redirects are exempt from script protection requirements (6.4.3 and 11.6.1) under FAQ 1588, but are technically easier for attackers to compromise than iframes. While iframes create a security boundary around payment data, redirects are just links with no protective wrapper, making it simple for attackers to change the URL to a fake payment page mimicking the real checkout.
Spectre AI enhances the original Spectre tool by using artificial intelligence to analyze website pages at scale and detect malicious activity invisible to human review. While original Spectre identified known malicious IOCs, Spectre AI intelligently identifies hidden attack vectors, malware, and compromised code embedded in third-party scripts and databases that were previously undetectable.
Attackers exploited the Next.js framework's server-side rendering by infecting a JSON object called NextData, then used keystroke logging (old-fashioned key logging) instead of direct credit card theft. They stored captured keystrokes in local storage and slowly exfiltrated them one at a time, evading agent-based detection that looks for immediate credit card data extraction patterns.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers moderate insight density with concrete operational advice on PCI DSS 4.0.1 compliance and AI-related security controls, but significant portions consist of panel banter, question-answer repetition, and familiar framings (defense in depth, compliance as floor). The speakers provide useful specifics on script skimming and requirements mapping, but also engage in confirmatory agreement and filler exchanges that dilute the content.
We're monitoring tens of thousands of live, active e commerce sites. Um, we're finding over one skimmer a week right now. As our average.
You have to immediately notify. That's part of 1161 immediately. So whatever you're using for your tools to find out that it needs to give a notification right then.
The episode repackages well-known compliance frameworks (defense in depth, compliance as security floor, risk analysis) and PCI DSS guidance without substantial contrarian insight. The main original contribution - connecting AI-acceleration to existing compliance requirements rather than new requirements - is sound but relatively straightforward. Most perspectives align with conventional compliance thinking; minimal first-principles thinking or counterintuitive claims.
AI didn't change the rules, it just raised the stakes.
PCI DSS is reactive to risk related to cardholder data. And uh, it's not that AI necessarily is creating different risks, it's accelerating the risks that exist.
The three panelists (Jen Stone, Aaron Willis, and Hef) are active practitioners with clear operational roles: Jen is a principal security analyst doing compliance audits; Aaron leads forensic investigations and monitors e-commerce sites at scale (2,000+ cases/year); Hef runs SOC and threat-hunting teams. All three have hands-on experience with the problems discussed. However, they are primarily internal Security Metrics employees rather than independent external operators, which limits external validation of their claims.
I'm one of the principal security analysts here at Security Metrics.
half my day is spent building, uh, AI assisted forensic tools.
The episode provides strong specific evidence on e-commerce attacks (2,000+ cases/year, 1 skimmer per week discovery rate, 3-400 scripts on single checkout pages) and concrete PCI DSS requirement numbers (6.4.3, 11.6.1, FAQ 1588). Detailed case study of Next.js JSON object exploitation with keystroke logging demonstrates technical specificity. However, some claims lack supporting data (e.g., 300% increase in redirects, 5,000 exploits found by Claude - stated as "if I remember"), and vulnerability counts (500/200 per week) are mentioned without sourcing.
We're monitoring tens of thousands of live, active e commerce sites. Um, we're finding over one skimmer a week right now. As our average.
We've recently, uh, found hundreds of different, uh, attack vectors and malicious actors moving in ways that we've never been able to see before.
Hef demonstrates some follow-up instincts (probing on agent-based tool limitations, asking for case studies), but the conversation often defaults to confirmatory agreement ("Yeah, that was insane, man") and surface-level Q&A exchanges without deep pushback or productive tension. When disagreement surfaces (e.g., iframe vs. redirect debate), it reinforces existing consensus rather than testing assumptions. Missing are hard questions about whether compliance frameworks adequately address AI risks or whether the speakers' own products create blind spots.
That's where the confusion hit.
They are not bulletproof.
Computed from the transcript - who did the talking, and the words that came up most.
You can pass your PCI assessment and still be leaking cardholder data. In e-commerce, compliant and secure are not the same thing - and AI just made the gap between them a lot harder to ignore. In this episode, SecurityMetrics Principal Security Analyst Jen Stone is joined by forensic investigator Aaron Willis and [HOST NAME] for a practitioner panel on how AI is reshaping attacks on cardholder data - and why passing PCI DSS 4.0.1 isn't the same as being safe. It's a repurposed webinar built around what auditors and forensic investigators are seeing in the field right now.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Hello, and welcome back to Practical Cybersecurity. My name is Jen Stone. I'm one of the principal security analysts here at Security Metrics. I have a very special and exciting thing for you here today. I got to be part of a panel on a webinar all about artificial intelligence. And I thought, you know what, it's so great. Let's present it to you as part of this podcast. I hope you enjoy it as much as I do.
Speaker B: On today's webinar, we have some very special guest. We have Jen Stone, needs no introduction. Right. You're probably familiar with her. And if you've ever watched any of our forensic prediction webinars that we do, along with a lot of other stuff, we have Aaron Willis here from the forensic side of the house. I'm Hef. I'm your, your host. I'm on the cybersecurity side running our SOC and our threat hunting teams. I know we spend a lot of time together, Aaron, talking about those forensic predictions. It's a pretty good webinar. Right?
Speaker A: And I want to hear more about that. How are the results? Uh, your top four forensic and cyber predictions for 2026. How accurate are you so far?
Speaker C: We talked about AI as a force multiplier.
Speaker B: Yeah, that was insane, man.
Speaker C: Have we seen, uh, an increase in the amount of AI assisted attacks going on Heav?
Speaker B: Yeah. The good thing is, though, us good guys are fighting back. We are absolutely deploying AI in the field to try to stay ahead of the speed at which these attacks are happening.
Speaker C: Half my day is spent building, uh, AI assisted forensic tools. It's a lot of work. Yeah. That's how much time we have to spend, uh, battling this AI stuff and staying ahead of all these attacks that we're seeing.
Speaker B: I love that we've got these four predictions, Jen. And we were so right on the money with all four of our top predictions this year.
Speaker C: Yeah, we've got, uh, agentic AI that we're seeing now, uh, bots that are going out, smart bots, things we've never seen in the past that can go out and drill holes through websites and E commerce sites like we've never seen before.
Speaker B: I know the primary battleground, it seems like it's the E commerce, it's the healthcare. Uh, we're still seeing that.
Speaker C: We're still seeing a lot of credential compromises, uh, happening. Uh, some of the basic stuff, session hijacking is still around, but all these things are being assisted by AI.
Speaker B: One of our other predictions that we got right was about the session hijacking and the credential compromise. Stolen credentials are still the thing that bad guys are going after. Session, uh, token theft is part of it. I know we've all seen a lot of the automated, uh, MFA attack. We call it attack fatigue because it really is.
Speaker C: MFA fatigue is a very real thing.
Speaker B: But one thing that I did want to call out is I'm blown away, guys. About. In the news, the velocity of vulnerabilities being found and the number of zero days wasn't like, just like a month ago or not even a month ago. The Microsoft, like, 500 vulnerabilities announced in one week, that was insane. And then like a week before that was 200 vulnerabilities.
Speaker C: There's also the humorous case of Claude M. Mythos.
Speaker B: Claude. Yes. Yeah.
Speaker C: Where, you know, it was too dangerous for the public to get their hands on. Um, and of course, that just made us all want it more. Right. Um, but, uh, it found supposedly half. What was it? How many exploits did it find?
Speaker B: Yeah, it's like. I thought it was like 5,000 if I remember. There was some insane number. But, Aaron, in your world, before we get to Jen, inside your world, you're doing a lot of e commerce, a lot of forensic data investigations, Something like how many cases this year alone?
Speaker C: Thousands, uh, of cases. So disheartening, specifically E commerce cases are really what we've been focusing on. Um, uh, over 2,000 of those in a year. And, uh, what we're seeing is that almost 100%, maybe even 100% of all the attacks that are happening, all the successful breaches are still happening on the merchant side. M. Even when they've moved over to iframes or things like that, the attackers are getting in on those websites that maybe they have a little bit less security because the merchant is depending on the security of that iframe, they're getting in and defeating those iframes through various clever techniques, uh, that are allowing them to pull the credit card data right out of the iframe.
Speaker B: Oh, so. So damaging. I know you guys have a lot of findings. There's a lot of things that you're seeing from the shopping cart monitor that, that product that we have is phenomenal how it's evolved from my perspective. Outsider looking in, can you kind of share some of the findings that you're seeing from that in 2020?
Speaker C: Yeah. With our shopping cart monitor, we're. We're monitoring tens of thousands of live, active e commerce sites. Um, we're finding over one skimmer a week right now. As our average.
Speaker B: And where is that skimmer being found? Is it in the browser? Is it somewhere else?
Speaker C: It's being found specifically in the browser, um, often on the checkout page itself, really hidden in third party code quite often, or in merchant scripts, uh, that they've included there. Um, but we're finding them so often now, uh, in third party plugins, uh, code included from the database. You know, if you think about what that database is, it sits out on the server and it's not being scanned by anything really. And so scripts in the database can sit there for a long time and you can scan the server. You never see them until they're included on the checkout page in that rendered HTML page. Uh, and so if you don't have eyes in the browser at the moment of checkout, that script may come in at the very last second. It may be triggered just by somebody entering the credit card field. And then that script gets pulled from the database, runs for just a split second and then vanishes into the ether.
Speaker A: I'm glad we're going to dive into that a little more later because there are so many people who don't recognize how easy it is to, for this attack to execute. But you're seeing it all the time.
Speaker C: Yeah, uh, we're seeing stuff even in local storage on the browser, um, credit cards being stored there, malware being stored there.
Speaker B: Really, uh, crazy. I know at security metrics. One of the really cool new pieces of tech that we introduced was Spectre AI. I've heard from a lot of folks say, what is Spectre? What does it do? Can you just take a super brief moment to kind of explain what that tool is and what it's doing?
Speaker C: Well, Spectre AI is kind of derivative or an enhancement over our original Spectre tool, which went out to millions of websites, would grab anything it could see on the landing page and do a quick analysis and send back any, uh, IOCs or things that we found that were uh, 100% associated with data breaches. Spectre AI is an enhancement on that where we actually use AI to determine, uh, if we're seeing anything malicious on that page. Um, it's really making those static looks a lot more intelligent. Uh, we can pick out things now that we just didn't have the time or the bandwidth to see. We can feed that data to AI and pick out things that are hidden in code that a human eye just wouldn't be able to see.
Speaker B: At volume and at scale.
Speaker C: Yeah, at volume and at scale. And so, uh, we're going to Share some of those findings too. And just fascinating what Spectre AI can pick up. We've recently, uh, found hundreds of different, uh, attack vectors and malicious actors moving in ways that we've never been able to see before.
Speaker B: Before we get off this topic, I am, um, dying to know. And we don't get a chance to always to talk and share some of the really amazing stuff that we find. But I know you've had a bunch of case studies just in the first six months of 2026. Can you take a brief moment to share maybe one or two of uh, something that just blew you out of the water that maybe our audience would love to hear about?
Speaker C: Uh, one of the craziest things we saw this year, and this is just recent, in the last few weeks, we found a skimmer running on a page that had all the security in place, including an agent running specifically defined JavaScript skimmers on the checkout process. Um, and so, and this is not a low budget skimmer, this is one of the premier agents that, that are.
Speaker B: That missed it.
Speaker C: Yeah, that flat out missed it. And it had to do with uh, the way the uh, merchant was processing, how they were rendering HTML on the page. They were infecting a JSON object called Next Data from the Next JS framework. And uh, so in that framework everything gets, uh, put together server side, and then as it gets pushed to the, to the client side, it hydrates and it adds in all the little elements that uh, the customer needs to check out. And so they were able to bypass all of that. And they did the most crazy thing. Instead of stealing a credit card, they logged the keystrokes. Old fashioned key logging, huh? And the security software that was running the agent missed it because they were just capturing it, putting it over in local storage. And then they didn't pull it out right away. Whoa. Uh, they didn't go grab it and reassemble and say, oh, hey, we've got the credit card. They just, every once in a while they just reach into local storage and pull out a keystroke, pull out another one, just a little bit at a time. And so the software that was there, the agent completely missed it.
Speaker B: Uh, so, you know, if we had to summarize here, because I'm, I know we have a lot of folks in the audience that are on different sides of the business. Some folks are, you know, you're on the compliance side of the house, some of you are on the cyber. You're really deep in the audit world. Kind of summarize for us how that threat landscape has changed. It seems like compliance auditing does not stop at all mixed with this new tech that we're rolling out. What's that like? If you had to sum up.
Speaker C: Well, it's real time is really what is happening. You know, the threat landscape is active, it's dynamic, it's changing. You know, we have agents on pages that we think are picking things up, but that agent got defeated and we found it because we have an agentless solution. Um, we were able to watch things happen sort of after the fact. That and the neat thing about an agentless solution, hef, is the attackers don't know we're there. That's really what allowed us to find that breach we were talking about is they didn't know we were there watching. The moment they can see that an agent is there, that gives them a whole lot of information to work around. Right. They can find the holes, uh, or the chinks in the armor.
Speaker B: Yeah, yeah. Your team has done a phenomenal job of, of just finding these threat actors in the browser, in the shopping cart area. And I just say kudos, hats off to what you've guys been able to do for the previous six months. And what's left here going towards 2027. I know in Jen's world. Jen, the auditing world. Right. What's going on? I'm hearing rumors about confusion around PCI DSS 4.0.
Speaker A: There is, um, because here we have this big artificial intelligence thing happening and people are saying, well, 4.0.1 doesn't say artificial intelligence and address it, but it doesn't have to. Right. So instead of saying we need to address artificial intelligence, instead we say, in what ways are we using artificial intelligence? That's already covered by PCI dss. And it is. Let me give you a few examples and then you'll totally start getting the pattern. For example, data, who's allowed to see full pan, who is allowed full access to cardholder data. And so who are you sharing that with? Well, if you're sharing it with AI, then you've got to have a business justification for that. Typically we're not going to want to share that. It better be internal, private, fully locked down. If you are in some way having AI interact with it. So you'll think of it that way. So who's getting my data? AI is another. Uh, we've got applications and systems and human beings that need to be justified and protected in certain ways. AI falls right into that. And that leads right into requirements 7 and 8, access and authorization. Right. So the access and authorization, it still has to run with least privilege, and it still has to be fully justified and authorized. Right. So all of the requirements there fully apply to AI. Um, let's look at, uh, secure AI workflows in code. A lot of people are using code or AI to help develop code. Right. Well, you still have to apply the secure software development life cycle, all of the requirements in requirement 6 to whatever your AI is doing to help develop code. So I'm not going to dive into every single one of them, but I just wanted to show you a pattern of if AI is doing a thing and it falls into a certain bucket, you have to apply those requirements to that bucket. And I really think where people got confused was it didn't explicitly start using the words artificial intelligence, but it doesn't have to.
Speaker C: Yeah.
Speaker B: Um, there seems to be a lot of confusion around two requirements. In particular, I want to take a brief moment to kind of dive in what you are seeing out in the battlefield.
Speaker A: Yeah.
Speaker B: Requirement 643 and requirement 1161. Script security and FAQ 1588.
Speaker A: Yes.
Speaker B: What is going on in this world? Can you decipher and clarify?
Speaker A: I'm so glad you brought up FAQ 1588, because there is, and my heart goes out to any merchants that have E commerce because this was implemented in a confusing way. And it's critical because this is where we're seeing data actually being lost. So let me run you through it. So we care about protecting scripts on a page, because the scripts on a page are what's stealing cardholder data. Right. So, uh, 4.0.1 came out and originally in the SAQA said, hey, you have to now protect scripts on a page. And then they said, oh, no, you don't. Or it seemed like they said, oh, no, you don't.
Speaker B: That's where the confusion hit.
Speaker A: They didn't actually say that because as we can see from FAQ 1588, this is still a problem and it's still something that you need to address. And it's. That's kind of hidden. If you don't read the entire thing, you should read the entire thing. Go and read the SAQA eligibility requirements. So, uh, criteria, the eligibility criteria, and the eligibility criteria say that you need to protect the scripts on a page as if it were 6, 4 3, and 1161. But it does it in a very lightweight. Oh, and by the way, you got to do this. 1588 really locks this down for us. And the Council tells us you can protect your, um, SAQA environments In one of two ways. M. Excuse me. They didn't say protect. You can meet the compliance requirements in one of two ways. Either get your service provider to say that your environment is not susceptible to these kinds of attacks, which is insane. Although, I mean, they're impossible. A couple of them did it very, very early and then they suddenly went, o, we cannot because they can't. Right. So, um, that also confused people. Well, last year they said they would do this for me. Why aren't they doing it this year? Because they learned. So you either have to get a very, uh, well documented written confirmation from your payment provider, um, saying that the embedded solution protects the merchant page, or you have to implement script management and tamper detection. And that is what every. Here's why you should do it. That's why we're seeing the breaches. Ah, I have kind of a love hate relationship with 643 and 1161 because it's so important to protect your data. And, um, at the same time, it's really hard for a lot of merchants to understand. They felt a little bit whiplashed over how do I accomplish this? So I get it and it's frustrating, but it's real and you should be doing it. There's another little aspect of it too, and that is, is this. Only if I. Most of the time people are like, well, I have an iframe. It makes it an saqa. Yes. That's a real clear use, um, case for having 643 and 1161 in place. But then there's. Well, what if I do a full redirect? Yeah. Okay. I'm going to tell you what the council says so that you can pass your, um, audit. And then Erin's going to tell you why you shouldn't skip this. So pay attention. Uh, under, uh, FAQ 1588, full URL redirects completing the SAQA are exempt from requirements 643 and 1161, however, that. So that you can pass your PCI. Here's what you do if you actually want to be secure.
Speaker C: We've seen a 300% increase in merchants using payment redirects because it's, it's an easy way to get around all this.
Speaker A: Absolutely easy. Yeah.
Speaker C: And the hackers and attackers are all cheerleading it.
Speaker A: Yeah.
Speaker C: Why? It's so much easier to defeat a payment redirect than it is an iframe.
Speaker A: Yep.
Speaker C: And we are seeing, uh, a corresponding, uh, increase in the number of attacks against payment redirects. If you think about it, an iframe is a security box around, uh, that payment data. And an attacker has to know what they're doing to get in and defeat that. Iframe, what's a payment redirect?
Speaker A: Click, click.
Speaker C: It's a link.
Speaker A: That's all it is.
Speaker C: Is there anything around that link protecting it? No. The hacker just literally goes in, changes the link, and now it stays. Uh, your customer doesn't go out where they should. It stays right on your site, usually, or to an attacker's site that's duplicating, mimicking the real payment checkout. That's far, far easier. And we're seeing some pretty sophisticated attacks where the payment still completes.
Speaker B: Yep, that's wild.
Speaker C: So everybody's happy.
Speaker A: That's the argument that I get from my merchants is, well, everything's fine. We're still getting payments. That does not mean you have not been breached. You're not saying that just because, Just because the bad guys got your cardholder data doesn't mean you also didn't get it. Right? That can be used for two purposes, the intended and the not so intended.
Speaker B: Uh, there are so many questions that have come into us at the very end today. We're going to take some time to try our best to answer all the questions, but if we don't get to your question, you can always send it to us. You pick up the phone and call us, and we'll do our best to try to make sense of the insanity that's going on right now in the last six months. Uh, Jen, help, help me out and understand the requirements that are impacted by AI. The PCI requirements impacted by AI. There's quite a few. I was actually kind of blown away that there's this many. Uh, if we could kindly start with maybe 12, 3, 12, 3 1, 12, 3 4. Uh, target risk analysis is a big buzzword right now.
Speaker A: It is. Well, a targeted risk analysis is intended to look at a, ah, specific thing that you're trying to make decisions on. How often do we, for example, um, test, uh, for skimmers out in the wild, you know, um, how frequently are we scanning a certain thing? So it's usually around the frequency of scanning that type of thing. Well, if you haven't gone and looked at what you said before and then asked yourself, how does AI and the acceleration of the bad guy's activities affect this decision, then you haven't got your bases covered. So really, every targeted risk analysis should have you stop and say, does AI affect this? If it does, let's redo it.
Speaker B: So if I adopt a new AI tool in my business, should I do a tra?
Speaker A: Oh, you know what? If you adopt a new tool, uh, in your business, not only should you do a new TRA for all of the ones that apply, you should also say to yourself, hey, this is a major change to my environment. And then you review all of the things that a, um, change to your environment would trigger. So new ASV scannings, um, and potentially looking at your scope, AI could expand your scope. Probably does. Um, and so making sure, where is my AI live and where is my PCI network? And are those in any way related? So making sure that you have updated all of the ways in which anything can interact with cardholder data, including AI, could trigger new network diagrams, new data flow diagrams. Right.
Speaker B: So sounds like so much work, but it's worth it. It really is.
Speaker A: But also, if you have AI help you, it can help.
Speaker B: Requirement eight is mfa. Uh, you know, it's not just about knowing these new tools and having a risk analysis done, but mfa, the access to it, how has that been impacted?
Speaker A: Multifactor authentication is one of the most important things that we see in helping people keep the bad guys out. And yes, we all kind of get tired of having to put in a code or whatever it is that we're doing for the mfa, but it's critical for us to be able to in some way lock down our environment. So MFA has to be everywhere across administrative and remote pathways. I recommend people do it everywhere. So anytime that you can access cardholder, um, data, that's a place that you need to apply.
Speaker B: MFA, requirement 1263 is something that is near and dear to my heart. Especially here at Security Metrics, where you're talking about updating your phishing training. There is so many different types of AI generated phishing examples that are out there from the news that you could pull and share with your team, share with your employees. Could we spend just a quick moment though on requirement 12 8? How has that impacted? Because I'm hearing a lot from my, huh, friends and business owners that that
Speaker A: is a big deal to them, third party service providers. And a lot of people aren't even thinking, oh, this AI that I'm now using is another third party service provider. It is, yeah, it absolutely is. And so you have to make sure that you are, um, taking that into account as you do all of the 12.8 sub requirements.
Speaker B: Okay, uh, Jen, summarize for us. Give us a key takeaway. What would that be about? The changes that you're seeing on the battlefield right now.
Speaker A: So PCI DSS is reactive to risk related to cardholder data. And uh, it's not that AI necessarily is creating different risks, it's accelerating the risks that exist because AI can do all of the current and previous threats faster. So, uh, it has to be taken into account when you consider not just what are the threats, but, but are the threats accelerated and then apply the right security controls that way.
Speaker B: We're going to switch gears for a moment. We're going to get to your questions here in just a moment at the end. But I think it's really important we address this concept of compliance as a security floor framework. It is not something new, folks. This has been around for a very long time. But, uh, from an understanding, from a practical cybersecurity strategy, it's really more important than ever when you talk about the persistency of these AI threats and how do you stay compliant? And just because you're compliant doesn't mean you're secure. So let's dive into this. There's three tiers on this framework. What is tier one all about here? Continuous compliance, is that right?
Speaker C: Uh, it really involves real time monitoring. Watch when it's going. Compliance is not an event, it's a moving iceberg. Yeah, you've got to be on top of it all the time.
Speaker B: Now, uh, tier two is about extending the controls coverage for AI. AI usage policies. Do you have a lot of conversations with clients about that at all?
Speaker A: Uh, you know, it's surprising to me how many people haven't updated their acceptable use policies to include whether AI is acceptable or not. You know, they haven't. It's a lot of people are kind of afraid of AI and they don't want to consider it. And so they don't. Which is that's not a good way to think about a risk. And so being willing to dive into something that's uncomfortable and say, how do I look at all of my policies and procedures? How do I look at all of my targeted risk analyses? How do I look at all of my training and then modify it for the reality, which is AI?
Speaker B: Three to four years ago, all the rage of conversation was about do you have a US or uh, do you have an AI usage policy? Do you have that place? Now it seems like the conversation shifted more towards are you doing deep fake simulations? Are you testing for that kind of stuff?
Speaker A: Should be.
Speaker B: So Tier one, continuous compliance. Tier two, we're talking about extending controls for AI Tier three. It shifts the conversation to getting a really nice baseline around PCI DSS 4.01
Speaker C: really about knowing what's in your browser.
Speaker B: So inventory. Yeah, script inventory.
Speaker C: Script inventory. Know what's on that checkout page? Uh, in the old POS environments, we knew what was on that on the checkout server, and it was hard to get something in there. You had to go through all kinds of hoops to get something approved. Now we have found hundreds, 3, 400 scripts on a checkout page. That is a massive surface area on a single checkout page. And if you think about that, that could be hundreds of thousands, if not millions of lines of code that all have access to the credit card data on that page.
Speaker B: Wow. I mean, if you are not doing targeted risk analysis, scenario planning and simulations and I mean, I know it's sometimes a struggle when you're trying to run the business day to day, but knowing what the potentials are, what could, what are the potential doorways in your business, it's, uh, such a challenge. Oh, my goodness. All right, uh, let's talk about. Before we start to wrap this up, I know we've had some really good questions. They come in all the time here, and I feel like this is the perfect venue to cover some of these questions. Let's talk about question number one. This one came in about redirecting customers, and we kind of briefly touched on it. Maybe there's some good takeaways here. Redirecting, um, customers to a hosted payment page. We're talking about SAQA. Are we legally required to comply with 643 or 1161?
Speaker A: I love this question. It's so juicy because it has so much in it because it used the word legally. And, um, a lot of people think that PCI DSS is a law. It's not. It's not a law. It is a standard that is required by the payment card industry. However, if you are an saqa, um, merchant, and you're not fulfilling your obligations, um, by meeting that, a lot of things can happen that, including they'll take away your ability to accept credit cards. You don't want that as a merchant, you want the ability to accept credit cards.
Speaker B: Right.
Speaker A: I'm not saying that that's like their first thing that happens. I'm saying that if you, if you don't become compliant, eventually there is an end stop and that's it. Right. So setting aside the legal thing, do you need to comply with 643 and 1161? If you redirect according to PCI DSS, uh, FAQ 1588, you are not required to. You can pass your PCI compliance, uh, without doing anything about 643 and 1161. But I'm here to tell you it's a bad choice. Don't do this because you don't want to lose card data. You want to be secure. Please use your judgment in this and implement these things.
Speaker B: This is a good segue too. If, uh, our merchant site uses an iframe, how do we satisfy the script protection rule in FAQ 1588?
Speaker A: Same kind of a, same realm. Just do it. So either get from your payment, um, service, uh, provider that you are not susceptible. Here's the other thing. I want to do a little bit of nuance. I got a customer that said, my payment provider said, uh, I am an saqa, so I don't have to do this. And I'm like, that's not what this says at all. Just because they told you that you're an saqa, which they were, doesn't mean you don't have to do this. They have to tell you formally in a written statement that you are not susceptible to the risks that are covered by 643 and 1161. Nobody's doing that anymore. So you need to put in, uh, 643 and 1161.
Speaker B: Next question that came in. I thought this was a pretty good one too. Does an agent based protection tool fully satisfy requirements of 643 and 116 1? What are your thoughts around that?
Speaker C: I mean agent based tools are absolutely better than nothing. Hef. Yeah, um, in our example we showed how an attacker knew the agent was there. It could monitor that agent's behavior, find its weaknesses and make an exploit for it.
Speaker B: They're not bulletproof.
Speaker C: They are not bulletproof. And so absolutely you want something in place. And an agent is better than nothing. But something like uh, an agentless solution where the attacker doesn't know what's happening, it gives them nothing to, no behavior to see, uh, to get around.
Speaker B: I like the concept. You know, we've talked about this for decades. Defense in depth. When you're pairing a client side control with external agentless monitoring like shopping cart monitor, I think that's a winning combination for this. Answering this question. All right, another question that came in. What qualifies as a payment page script under PCI DSS401? What is the anyscript? So, uh, payment fields, would you include that? Analytic tools, marketing pixels, tag managers. I mean the list goes on and on. Uh, wow. We had another question that came in here and that is around the notification obligations. What am I required to do under 116 1. If an unauthorized script change is detected, what's the step? What's the process? Is there one?
Speaker A: I mean, you have to immediately notify. That's part of 1161 immediately. So whatever you're using for your tools to find out that it needs to give a notification right then. And then people need to dig into it, find out what's going on. So that's also kind of tied to other notifications, like who else needs to know besides the people who are digging into it. Right.
Speaker B: Wow.
Speaker A: Is there follow on notifications? Well, yes, there's merchant agreements on who they're supposed to tell and under what, um, timelines, um, to let other people know that either that there was an incident that's being investigated or that there was a known, um, breach of data. So it really depends on your, um, agreements. So knowing those contractual agreements is pretty important in this case.
Speaker B: It seems like it could get really messy really quickly depending on what state you're operating in or what country you're operating in.
Speaker C: And this is so important too, because oftentimes when we go into a forensic investigation, we find out that there were tools running that caught things that would have ended it early. Um, and we find out nobody was paying any attention. It went to an email account that nobody's reading or they read it once a month. You have to read that.
Speaker A: It has to be a full conversation for it to be an immediate notification. Right. Uh, not just a shout in the dark.
Speaker C: And you have to be watching every day, reviewing those alerts. Every single day.
Speaker B: Yeah. Okay. We had a couple of AI questions that came in and some regulatory questions. We have to get to these. I think they're so important for the audience. If I adopt an AI powered chatbot or a search tool, I'm putting in it embedding in my website or there's a website trigger or, uh, um, sorry, Will that trigger a risk assessment if I start embedding those chat bots or search tools?
Speaker A: Absolutely. Because it changes your environment in significant ways that you have not gone through any kind of a risk analysis for previously. So definitely it triggers risk.
Speaker B: Doing that TRA before you deploy is so critical. All right, uh, you got to know the boundaries, the data boundaries. Let's talk about. Also this question came in. What specific evidence will PCI assessors look for to verify that your security training covers AI threats? What kind of evidence are you looking at?
Speaker A: Yeah, so a lot of times we'll say, can you give us, ah, a summary of what's being taught? What are the modules we want to know what are those modules and then a little bit of detail in them to make sure that it's really covering AI related things. Um, and especially if we can, we'll say is this training applicable in ways that the person getting it can, uh, apply it in their job? Right. So we try to look at not just are you throwing information at people, but is it something that's immediately applicable to the people who are receiving it? And then did they actually do the training? Did they complete this training? So the best training out there has, um, modules that are modifiable and then there is usually, um, some sort of a test associated with it. Not just I pushed play through all of these things, but something that tells us that people are intaking the information that is necessary. And then hopefully some sorts of, um, phishing, uh, uh, simulators. Yeah, simulators for any kinds of AI attacks.
Speaker B: Really good. Great question, by the way. We're going to end it with one final question here, and this is a tuffy, so you might need some time here to think about it for the audience and for us to answer it. Is there an operational risk difference between employees using public AI tools versus private enterprise level AI tools? Is there a difference? I think there is.
Speaker C: There's a massive difference.
Speaker A: You mean it's not all just Claude? What I'm using Claude. My company says I can use Claude. What are you talking about?
Speaker C: Well, there's so many, there's so many options out there right now, um, from free ChatGPT things you can just go to a browser and start using AI now. But if you think about what's happening to the data that you're entering in, that you are training, that chatbot that you're interacting with, um, and so you can inadvertently share private data publicly. Uh, not necessarily directly, but things can leak out in indirect ways. Uh, we've seen cases of intellectual property leaking out through these public AI chatbots, um, where you're entering things that nobody should know about and that AI is trained on it. And then somebody else in a different country can be asking that chat bot the same thing and says, oh yeah, I know a solution for this. And there goes your, uh, intellectual property.
Speaker B: I think that's so hard for a business owner to understand how critical it is that you give people the tools they need that are approved, that are within your boundaries of what risk you're willing to tolerate for your business success.
Speaker A: And I don't think it's that a rational response is, well, we will not use any AI in our business because if you don't give your people the tools that are locked down and controlled by the enterprise, they're going to go use public tools. They're going to use what they can because they want that boost in productivity or that ease of understanding. And so give them the tools that are locked down and then that you're going to reduce your risk of them going to a, uh, public non lockdown.
Speaker B: So there you have it folks. We have Jen Stone from the audit side of the house at Security Metrics. We have Aaron Willis from the forensic side. Got me Hef here from the cyber side. As we wrap it up today, it's fascinating the world that we're in right the there's no brand new compliance laws as of the recording of this video.
Speaker C: AI didn't change the rules, it just raised the stakes.
Speaker A: Absolutely.
Speaker B: All right, well, there you have it folks. Thanks for joining us. Uh, as always, share your questions, give us a call or, or email us, let us know. Stay compliant. That's what we do here at Security Metrics.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Can responsible AI beat hallucinations?The ITPro Podcast · on Agentic AI95 / 100
Why your research needs a “thinking cave” with Sarah KlingThe Curiosity Current: A Market Research Podcast · on Agentic AI89 / 100
Media Briefs: Terrapinn’s Sharon Roessen on boosting event registration and attendance with agentic AIThe Publisher Podcast by Media Voices · on Agentic AI82 / 100
Elizabeth Wooliston, Chief of Markets: Artificial: Why the London Market is ready for intelligent automation (413)InsTech · on Agentic AI81 / 100
The Judgment Void: How AI Is Dismantling the One Human Capability It Cannot Replace, with Larry DurhamHuman Capital Leadership · on Agentic AI80 / 100
Navigating AI Risks with Trevor Horwitz from TrustNetB2B Automation Spotlight · on Agentic AI79 / 100Which PCI SAQ Do You Actually Need? (ep. 10)81 / 100The Expert Guide to Defeating eSkimmers (ep. 8)86 / 100Your PCI Scope is Too Big (and how to fix it) Ep.12You're Probably Behind on CMMC. Here’s What To Do Next. (ep 11)Passkeys: An Upgrade You Didn't Know You Needed (ep. 9)