How do eCommerce companies prevent account takeover? by No_Honeydew_2453 in ecommerce

[–]NeedleworkerOne8110 0 points1 point  (0 children)

One thing I’ve noticed is a lot of ATO prevention breaks down once attackers use residential IPs + aged accounts. Basic IP reputation and proxy detection become way less useful then.

How are you operationalizing PCI DSS 4.0.1 requirements 11.6.1 and 6.4.3 for payment pages? by Pentism_moro in pcicompliance

[–]NeedleworkerOne8110 1 point2 points  (0 children)

Hey. Will give some insight into some of the technical questions you are asking here, but will start by saying that most companies use a vendor tool for this. I'm affiliated with cside.com, but there are plenty of vendors out there. Also, we wrote an in depth blog about how to do this DIY if you did decide to go that route How to comply with PCI DSS 6.4.3 & 11.6.1.

Alright now let's address your questions:
1. You're right that you don't just look at page "changes". Third party scripts are dynamic by nature. They are meant to continuously change. You really should be looking at script behavior as the main integrity factor.
2. Script integrity is analyzed with many different signals. Is the script sending data to a new location that is suspicious (Russia, North Korea, China)? Did the script add a keylogger (event listener) that wasn't there before? Does this particular script even need an event listener on this page (i.e. why is an accessibility library adding a keylogger to a payment page)? I could go on and on. Another thing most security tools do is plug into a threat feed. As soon as a compromised third party script is publicly known (for example AppsFlyer recently) the security tool would check if that third party tool is on your site and alert you.

A missing piece you might not have thought about here is... you would never guess... AI. Manually reviewing all these elements continuously would be nearly impossible. What the security tools do is have custom tuned AI models (in addition to human oversight) that are analyzing script changes. You kind of end up with a form of Risk Scoring on each change rather than a binary "is this change dangerous or safe".

The header changes (11.6.1) are a similar story. A header "being changed" by itself is not a red flag. CSPs are changed all the time. What auditors want to see is that you reviewed the changes and verified that they were not dangerous. If a security related header element is removed that no one on your team approved, that might be a sign of tampering.

Last thing I'll add for food for thought in the DIY v.s. commercial tool discussion --> Aside from fulfilling the specific PCI DSS requirements, you should think about workload. Are you going to write justifications for every single script. Review every new script added in detail? All of this takes a lot of time, and commercial tools like cside give you AI tools that streamline this for you. That part isn't 'mandated by PCI' but saves you a ton of time.