De beste Magecart-detectietool voor PCI DSS is degene waarvan de output een QSA als bewijs accepteert. Detectie die alleen blokkeert of alleen alert is niet genoeg. Vereisten 6.4.3 en 11.6.1 vragen je in de loop der tijd vier dingen te bewijzen: dat je elk script op je betaalpagina kent, dat elk ervan geautoriseerd is, dat je wordt gealert wanneer er een zonder goedkeuring verandert, en dat je de historie kunt tonen.
Dat herkadert de aankoopbeslissing. Shop voor een systeem van registratie dat een browserlaagevent omzet in een inventarisregel, een autorisatiebeslissing, een tamperalert en een bewaard wijzigingslog, niet alleen voor het luidste skimmeralarm. De meeste "Magecart-detectie"-marketing gaat over de vangst. De audit vraagt om het papierspoor achter de vangst.
Deze post evalueert detectietooling door die PCI-bewijsbril. Hij rangschikt geen vendors bij naam en citeert geen specs. Hij vertelt welk bewijsartefact elke capaciteitscategorie produceert, welk gat elke categorie openlaat en wat je in een proef moet eisen. PCI DSS 4.0.1 maakte 6.4.3 en 11.6.1 op 2025-03-31 verplicht, dus de bewijsvraag staat nu live, niet bij de volgende vernieuwing. Als je stack bekende-slechte dreigingen al afdekt, zit het gat meestal in de documentatie, en daarom zijn Magecart-preventie en PCI-bewijs nu dezelfde klus.
Welk bewijs wil een QSA daadwerkelijk van Magecart-detectie?
Mep de requirementtekst op het artefact dat je tool moet produceren. Dit zijn de dingen die een assessor opent tijdens een 6.4.3/11.6.1-review.
| PCI-bewijsartefact | Requirement die het beantwoordt | Hoe "goed" eruitziet |
|---|---|---|
| Scriptinventaris | 6.4.3 (weten wat er draait) | Elk script op de betaalpagina, inclusief dynamisch geïnjecteerde en third-party CDN-scripts, vastgelegd zoals de browser ze ziet |
| Autorisatieregister | 6.4.3 (elk script rechtvaardigen) | Een rechtvaardiging en een goedkeuringsstatus per script, met wie besliste en wanneer |
| Integriteits-/tamperalert | 11.6.1 (wijziging detecteren) | Een alert bij ongeautoriseerde wijziging van scriptcontent en van betaalpagina-HTTP-headers, met een diff |
| Wijzigingshistorie | 6.4.3 + 11.6.1 (in de tijd bewijzen) | Een duurzaam, van timestamps voorzien log van elke script-toevoeging, -wijziging en -verwijdering, plus de afhandeling van elke alert |
De valkuil is Magecart-detectie als een securityfeature behandelen en PCI als een apart vakje. Het is dezelfde controle. Als de tool een skimmer vangt maar de assessor niet de inventarisregel kan tonen waartoe dat script behoorde, de autorisatiestatus die het schond en de gedateerde registratie van de alert en zijn afsluiting, dan ving je de aanval en faalde je de audit toch op documentatie.
Waarom een malware-signatuurvergelijking de PCI-vraag mist
De meeste "beste detectietool"-lijsten vergelijken op threatdekking: bekende-slechte handtekeningen, blocklists, feeds met kwaadaardige domeinen. Dat telt voor blokkeren. Het bevredigt 6.4.3 of 11.6.1 niet.
Supply-chain-Magecart arriveert via een script dat je al vertrouwt. De CDN van de vendor serveert een nieuwe versie, de origin staat op je allowlist en de hash verandert om een legitiem lijkende reden. Een signatuurmotor ziet niets omdat de payload nieuw is en de bron is toegestaan. De PCI-controle is precies hiervoor ontworpen: 6.4.3 dwingt je dat script vooraf te inventariseren en autoriseren, en 11.6.1 dwingt je te alerten wanneer de content zonder goedkeuring verandert. Het bewijs, niet de handtekening, is wat bewijst dat je de wissel zou hebben betrapt.
Evalueer detectie dus op of het het autorisatie- en wijzigingsrecord produceert, niet alleen op of het de vandaag bekende skimmers herkent.
Magecart-detectie evalueren op capaciteitscategorie
Detectietools vallen in een paar architecturale categorieën. Elke categorie produceert ander bewijs en laat een ander gat. Score ze op wat ze de assessor overhandigen.
| Capaciteitscategorie | Inventaris | Autorisatieregister | Tamperalert (content + headers) | Wijzigingshistorie | Belangrijkste bewijsgat |
|---|---|---|---|---|---|
| Externe scanner (crawlt vanaf cloud-IP's) | Gedeeltelijk, ziet alleen wat zijn crawler laadt | Meestal handmatig, erop geplakt | Periodiek, kan missen tussen scans | Op snapshots gebaseerd | Mist sessiespecifieke, geo-gerichte en post-interactie-scripts |
| CSP + SRI (door browser afgedwongen beleid) | Nee, het beperkt in plaats van op te sommen | Nee | Alleen headerbeleid; SRI breekt op dynamische scripts | Overtredingsrapporten, geen auditlog | Genereert controle, niet de inventaris- of autorisatiepaperwerk |
| Netwerk-/WAF-scriptzichtbaarheid | Gedeeltelijk, wat de edge passeert | Nee | Header- en bekende-slechte blokkering | Edge-logs, geen scripthistorie | Geen autorisatiestatus per script voor de QSA |
| Runtime-browsermonitoring (in-page agent) | Ja, legt scripts vast zoals de browser ze uitvoert | Ja, wanneer het platform goedkeuringsstatus modelleert | Ja, content- en headerwijziging, met diff | Ja, duurzaam, van timestamps voorzien per-script log | Vereist een tag op de betaalpagina |
Lees de tabel als een bewijschecklist, niet als een populariteitswedstrijd. Een scanner is snel uit te rollen en nuttig voor een basislijn, maar een skimmer die alleen activeert voor echte shoppers in één land kan een schone pagina aan het IP van de crawler serveren. CSP en SRI zijn echte controles die de PCI SSC noemt als geldige mechanismen, maar ze produceren beleid en overtredingsrapporten, niet de scriptinventaris en autorisatieregisters die 6.4.3 vraagt, en de hashes van SRI breken op de dynamische scripts waar de meeste checkoutflows op leunen. Diezelfde broosheid is een van de redenen waarom Content Security Policy niet werkt als zelfstandig PCI-antwoord. Runtime-browsermonitoring is de enige categorie die alle vier artefacten op zichzelf produceert, omdat hij het script observeert zoals de browser van het slachtoffer dat doet.
Een inkoopplan dat op bewijs test, niet op features
Laat een demo niet eindigen bij "kijk, hij ving het slechte script." Laat de tool het papierspoor bewijzen.
- Zet een stagingkopie van een echte betaalpagina op en koppel de tool aan.
- Push een goedaardige wijziging naar één script, zoals een commentaar toevoegen of een versie bumpen, en bevestig dat de tool hem flagt met een voor/na-diff, de betreffende pagina en een timestamp.
- Wijzig een betaalpagina-HTTP-header en bevestig dat 11.6.1-headerwijzigingsdetectie afgaat, niet alleen scriptcontentdetectie.
- Leg een autorisatiebeslissing vast (keur één script goed, wijs de wijziging af) en bevestig dat die status is opgeslagen, toegeschreven en gedateerd.
- Voeg een script toe dat alleen voor een specifieke sessie of geografie laadt en controleer of de inventaris van de tool het vastlegt. Dit is waar dekking van externe scanners faalt, en een groot deel van waarom crawlers niet kunnen helpen met PCI-compliance op zichzelf.
- Exporteer de inventaris, de autorisatieregisters en het wijzigingslog. Lees de export zoals de assessor zal doen. Als het screenshots of een ongelabelde alertfeed zijn, is het geen bewijs.
Als een tool stappen 2 tot en met 6 doorstaat, produceert hij auditklare 6.4.3/11.6.1-documentatie. Als hij stopt bij stap 2, heb je monitoring gekocht, geen compliance.
Waar cside in het bewijsmodel past
cside is een client-side securityplatform gebouwd voor de categorie runtime-browsermonitoring, en specifiek voor het bewijs dat een QSA opent. Het proxyt geen verkeer. Een tag op de betaalpagina legt scripts vast zoals de echte browser ze uitvoert, wat het gat van de scanner op sessie- en geo-gerichtheid sluit.
Voor 6.4.3 onderhoudt PCI Shield een live inventaris van elk betaalpaginascript, inclusief dynamisch geïnjecteerde en third-party CDN-scripts, met een autorisatiestatus per script. Voor 11.6.1 alert het op ongeautoriseerde wijzigingen van scriptcontent en van betaalpagina-HTTP-headers, met een diff die precies toont wat veranderde. Elke toevoeging, wijziging, verwijdering en alertafhandeling belandt in een van timestamps voorzien wijzigingslog dat je kunt exporteren. cside onderging een onafhankelijke QSA-evaluatie door VikingCloud voor 6.4.3 en 11.6.1, dus het bewijsmodel is beoordeeld, niet alleen beweerd. Voorbij het requirement voegt het platform browsergedragsmonitoring en bot-/AI-agentdetectie toe, zodat dezelfde instrumentatie die je PCI-record produceert ook de gedragsanomalies aan het licht brengt die een nieuwe skimmer creëert.
Per 2026-06-18, behandel dit als operationele richtlijn, niet als juridisch advies. Bevestig de exacte controletaal en wat je assessor als bewijs zal accepteren met je QSA, juridisch adviseur of risk owner.
