PCI DSS | cside docs

PCI Shield van cside gebruikt client-side security en client-side protection controles om betaalpagina’s te beschermen tegen Magecart, e-skimming, formjacking en andere aanvallen die in de browser van de klant draaien. Deze pagina legt uit hoe cside aansluit op PCI DSS-vereisten 6.4.3 en 11.6.1 en hoe u auditklare bewijslast configureert.

Wat is PCI DSS?

De Payment Card Industry Data Security Standard (PCI DSS) is een set richtlijnen die de veiligheid van kaarttransacties wereldwijd waarborgt. Opgesteld door de PCI Security Standards Council, is het doel om bescherming te bieden tegen datadiefstal en fraude bij debet- en creditcardtransacties.

PCI DSS v4.0.1 introduceert twee eisen die bepalen hoe scripts en headers worden afgeleverd aan de browser van de kaarthouder op betaalpagina’s:

6.4.3 gaat over autorisatie, integriteit en inventarisatie van scripts.
11.6.1 gaat over het detecteren van wijzigingen en manipulatie van beveiligingsrelevante HTTP-headers en van de scriptinhoud van betaalpagina’s.

U kunt de volledige specificatie nalezen op de website van de PCI Security Standards Council.

Twee implementatiemodi, beide conform

cside biedt twee monitoringmodi. Beide voldoen aan 6.4.3 en 11.6.1. Kies op basis van uw risicotolerantie en de mogelijkheid om codewijzigingen door te voeren.

Scanmethode (geen codewijziging)

Draait volledige browsercontainers (geen losse HTTP-fetches) tweemaal per dag over de volledige website en over de user flow die leidt tot de betaalpagina.
Monitort scripts terwijl het DOM volledig wordt gerenderd, inclusief sub-requests en laat ingeladen assets die eenvoudige HTTP-scanners missen.
Bootst echt gebruikersgedrag na zodat dynamisch geïnjecteerde en via CDN geroteerde scripts worden vastgelegd.

Twee scans per dag overstijgen de eis “ten minste wekelijks” uit 11.6.1 en voldoen aan de verwachting van periodieke inventarisatie uit 6.4.3.

Scriptmethode (runtime, inline)

Wordt inline geladen in de live gebruikerssessie en logt elk script en elke scriptactie in realtime naar de backend van cside.
Biedt zichtbaarheid op requestniveau in het dashboard.
Ondersteunt granulair afdwingen: cside kan specifieke acties blokkeren of scripts volledig stoppen.
Werkt samen met CSP. cside voorkomt ook dat kwaadaardige scripts CSP-directives injecteren die het cside-script zouden uitschakelen, gedrag dat wij bij geen enkele andere oplossing op de markt hebben waargenomen.

Stapelen wordt ondersteund

Scan- en scriptmodus kunnen worden gecombineerd met CSP, SRI en uw eigen allowlists. cside vereist niet dat u bestaande controls uitschakelt.

Eis 6.4.3

Alle scripts op betaalpagina’s die in de browser van de consument worden geladen en uitgevoerd, worden als volgt beheerd…

”Er is een methode geïmplementeerd om te bevestigen dat elk script geautoriseerd is.”

PCI DSS staat zowel pre-autorisatie als post-autorisatie toe. cside ondersteunt beide:

Scanmethode: scripts die op de betaalpagina en in de user flow worden aangetroffen, verschijnen in het PCI DSS-dashboard voor review en autorisatie door een geïdentificeerde gebruiker. Het dashboard en de audit log leggen vast wie elk script heeft geautoriseerd en wanneer.
Scriptmethode: naast autorisatie via het dashboard kan cside ongeautoriseerde scripts of specifieke scriptacties technisch voorkomen dat ze runtime uitvoeren. Dit werkt naast CSP en blijft functioneren, zelfs wanneer een aanvaller probeert CSP-directives te injecteren om cside uit te schakelen.

Autorisatiebeslissingen, de identiteit van de autorisator en tijdstempels worden in de audit log vastgelegd en zijn exporteerbaar voor uw QSA.

”Er is een methode geïmplementeerd om de integriteit van elk script te waarborgen.”

cside controleert integriteit op meerdere assen in plaats van te steunen op één enkele hashcheck:

Hashing van de payload: elke scriptbody wordt gehasht. Een nieuwe hash activeert de volledige analyse-pipeline.
Pipeline voor inhoudsanalyse: nieuwe payloads worden gede-obfusceerd, geformatteerd en geëvalueerd via onze eigen Rust-gebaseerde regels-engine, Yara-regels, een lokaal gehoste LLM met kleine context, grotere modellen voor diepgaande analyse en een menselijke reviewstap door het cside-team.
Verificatie van source-metadata: elke scriptbron wordt gecontroleerd tegen de SSL-issuergeschiedenis (om hijackpogingen te betrappen), de registratie- en eigendomsgeschiedenis van het domein, wijzigingen in DNS- en NS-records, de RPKI-status van de resolvende IP-adressen (om BGP-lekken te detecteren) en reverse DNS om infrastructuuroverlap met bekende kwaadaardige domeinen te herkennen.
Historische context: cside bewaart eerdere hashes die achter dezelfde URL zijn uitgeleverd, zodat integriteitswijzigingen tussen versies auditbaar zijn. Het dashboard toont elke hashvariant en rendert de payload voor inspectie.

”Er wordt een inventaris bijgehouden van alle scripts, met een schriftelijke zakelijke of technische rechtvaardiging waarom elk script noodzakelijk is.”

Het PCI DSS-dashboard is specifiek voor deze clausule gebouwd:

Een live inventaris van elk script dat op betaalpagina’s wordt gedetecteerd, inclusief het parent object dat het heeft geladen.
Door AI gegenereerde zakelijke en technische rechtvaardigingen afgeleid van de payload en zijn gedrag (expliciet toegestaan door de PCI SSC), die een gebruiker vervolgens reviewt en bevestigt.
Per-script auditregistraties die vastleggen wie elke rechtvaardiging heeft geaccepteerd of bewerkt, met een volledige revisiegeschiedenis.
Geformatteerde payloads met gevoelige browser-APIs inline gemarkeerd, zodat reviewers geïnformeerde beslissingen kunnen nemen.

Staat een script in het DOM, dan weet cside ervan.

Dit omvat dynamisch geïnjecteerde scripts, via CDN geroteerde assets, scripts met wisselende IDs of tijdstempels en geneste sub-requests. Browserextensies vallen buiten de scope van PCI DSS omdat ze voorafgaand apparaatcompromis impliceren, maar cside toont waar mogelijk ook scripts die via extensies zijn geïnjecteerd.

Eis 11.6.1

Er is een mechanisme voor wijzigings- en tamperdetectie geïmplementeerd…

”Om personeel te waarschuwen bij ongeautoriseerde wijziging van beveiligingsrelevante HTTP-headers en de scriptinhoud van betaalpagina’s zoals ontvangen door de browser van de consument.”

cside legt headers en scriptinhoud vast zoals deze binnenkomen in een echte browser, niet zoals een server-side fetch ze zou teruggeven. Dat is belangrijk omdat veel sites verschillende headers en scripts serveren op basis van User-Agent, TLS-fingerprint, botdetectie en geografische routering.

Bewaakte beveiligingsrelevante headers:

Content Security Policy
Content Security Policy Report Only
Report To
Reporting Endpoints
Strict Transport Security
X-Frame-Options
Cross-Origin Resource Policy
Cross-Origin Opener Policy
Cross-Origin Embedder Policy
Permissions Policy
X-Content-Type-Options
X-Permitted-Cross-Domain-Policies
Referrer Policy
X-XSS-Protection

cside behandelt elke hashwijziging als een nieuw script. Telkens wanneer de payload wijzigt, wordt de nieuwe hash automatisch gede-obfusceerd en door de volledige detectie-pipeline gehaald. Alerts worden niet verstuurd bij de wijziging op zich, maar wanneer de analyse iets verkeerds vaststelt.

Concreet:

Elke hashwijziging wordt geanalyseerd als een nieuw script. Nieuwe scripts, verwijderde scripts, gewijzigde payloads en gedragsafwijkingen (nieuwe netwerkbestemmingen, nieuwe DOM-APIs, nieuw aangesproken opslagplekken) worden allemaal vastgelegd en geëvalueerd. Detectie is niet signature-based op het parent-script.
Alerts gaan af op misgedrag. Als een hashvariant zich gedraagt op een manier die niet klopt, of als iets verontrustends opduikt (bekende slechte bronnen of payloads, pogingen tot CSP-manipulatie, exfiltratie-achtig gedrag, dreigingsscores boven de drempel, nieuwe obfuscatiepatronen), alerteert cside in realtime via uw geconfigureerde notificatie-endpoints.
Reguliere inventaris wordt periodiek gerapporteerd. Het wekelijkse PDF-rapport (instelbaar op dagelijks) vermeldt elk script dat op de betaalpagina’s wordt gedetecteerd, elke betaalpagina-URL, elke wijziging van beveiligingsheaders en elke zakelijke rechtvaardiging met auteur. Dit voldoet aan de “ten minste wekelijks”-clausule van 11.6.1.

Dit overstijgt de norm. 11.6.1 vereist periodieke evaluatie; cside voert per-hash-analyse continu uit en stapelt daar onmiddellijke alerts bovenop.

”Het mechanisme is geconfigureerd om de ontvangen HTTP-headers en betaalpagina’s te evalueren.”

cside evalueert de headers en payload zoals deze in de browser worden gerenderd. Waar headers normaal niet aan een script in de pagina worden blootgesteld, gebruikt cside de browsercontext om ze op te halen. Staan uw betaalpagina’s achter een VPN of in een afgeschermde omgeving, dan levert cside een statisch IP zodat de scanner ze kan bereiken.

”De functies van het mechanisme worden ten minste wekelijks uitgevoerd, of periodiek op de frequentie gedefinieerd in de gerichte risicoanalyse van de entiteit (Eis 12.3.1).”

De scanmethode draait tweemaal per dag.
De scriptmethode draait continu, in de live gebruikerssessie.
Standaard wordt een wekelijks PDF-rapport verzonden met alle wijzigingen van beveiligingsheaders, elk script dat op de betaalpagina’s wordt gedetecteerd, elke betaalpagina-URL en elke rechtvaardiging (inclusief auteur). Deze cadans kan worden opgevoerd tot dagelijks.
Detecties van kwaadaardige scripts worden direct gealerteerd, los van het wekelijkse rapport.

Integraties voor uw eigen workflow

Alerts en rapporten kunnen worden gerouteerd naar Linear, Jira, AWS S3, Slack, Discord of elk webhook-endpoint. Grotere organisaties integreren cside doorgaans met hun bestaande change management- en SIEM-tooling.

QSA-goedkeuring

cside heeft een QSA-goedkeuringspercentage van 100%. We werken direct samen met grote banken, betaaldienstverleners en QSA-firma’s. Een whitepaper ondertekend door VikingCloud is beschikbaar via ons trust center, en de meeste QSA-firma’s hebben de oplossing ten minste eenmaal beoordeeld.

Waar cside verder gaat dan de eis

PCI DSS stelt een bodem vast, geen plafond. De volgende capaciteiten gaan verder dan de letter van 6.4.3 en 11.6.1:

Gelaagde detectie-pipeline: Yara-regels, een eigen Rust-regels-engine, LLMs met kleine context, grote LLMs en menselijke review. De meeste concurrenten leunen uitsluitend op third-party threat feeds.
Herkomstcontroles van de bron: SSL-issuerverschillen, domein- en DNS-historie, RPKI-validatie en reverse DNS op resolvende IPs.
Weerbaarheid tegen CSP-manipulatie: cside detecteert en blokkeert pogingen van kwaadaardige scripts om CSP-directives te injecteren die het cside-script zouden uitschakelen.
Zichtbaarheid op requestniveau: elke sub-request van een script wordt vastgelegd met het parent object.
De-obfuscatie en formatting: het dashboard toont de leesbare versie van elke payload met gevoelige APIs gemarkeerd.
Doorlopend onderzoek op het publieke web: cside onderzoekt sites die geen klant zijn om nieuwe aanvallen te signaleren vóór ze de betaalpagina’s van klanten raken.

Het PCI DSS-dashboard instellen

Naar PCI DSS-instellingen navigeren

Om het PCI DSS-dashboard te openen, open het dashboard en daarna:

Selecteer uw domein in de zijbalk
Selecteer PCI DSS

PCI DSS in de zijbalk

Betaalpagina’s toevoegen

Voordat u het PCI DSS-dashboard in gebruik neemt, moet u uw betaalpagina’s identificeren. Zo filtert u de data en kunt u zich richten op betaalgerelateerde scripts en headers.

PCI DSS-configuratie

Klik op Add a Payment Page of + Add Payment Page
Voer de URL van de betaalpagina in met het formaat voor scriptpatronen

Betaalpagina toevoegen

Klik op Create

Wilt u dat alle scripts worden getoond?

Wilt u dat alle scripts in uw PCI-dashboard worden opgenomen, gebruik dan een patroon dat op alles matcht.

Er zijn twee hoofdopties afhankelijk van uw betaalimplementatie:

Pagina-setup

Kies deze optie als uw betaalpagina’s:

Server-side gerenderd (SSR) zijn
Geladen worden via een herlaadactie of pagina-navigatie
Geïsoleerd zijn van scripts aanwezig tijdens client-side navigatie

Deze setup filtert de scriptlijst zodat alleen scripts worden getoond die op de aangewezen betaalpagina’s voorkomen.

Kies deze optie als uw betaalformulieren zijn geïmplementeerd als:

Modale vensters
Popup-widgets
Paywall-overlays
Elke dynamische UI waarop betalingen op meerdere pagina’s verwerkt kunnen worden

Deze setup monitort scripts in uw gehele applicatie, aangezien betaalformulieren op elke pagina kunnen verschijnen.

Configureer met een CSS-selector die uw betaalmodal of -formulier identificeert.

Voorbeeld van selector:

#pay

Het dashboard toont alle scripts die potentieel kunnen interacteren met het betaalformulier wanneer dat actief is.

Veelgestelde vragen

Wat vereisen PCI DSS-vereisten 6.4.3 en 11.6.1?

PCI DSS-vereiste 6.4.3 vereist dat scripts op betaalpagina’s geautoriseerd, op integriteit gecontroleerd, geïnventariseerd en verantwoord zijn. Vereiste 11.6.1 vereist wijzigings- en tamperdetectie voor beveiligingsrelevante HTTP-headers en scriptinhoud op betaalpagina’s zoals ontvangen door de browser van de consument.

Hoe beschermt client-side security betaalpagina’s?

Client-side security beschermt betaalpagina’s door scripts die in de browser uitvoeren te monitoren, ongeautoriseerde wijzigingen te detecteren en te waarschuwen wanneer scriptgedrag wijst op datadiefstal of manipulatie. cside voegt runtime zichtbaarheid toe, zodat teams zien welke third-party scripts laden, welke requests ze doen en of ze interageren met gevoelige checkoutflows.

Hoe pakt cside Magecart, e-skimming en formjacking aan?

cside analyseert scriptpayloads, sub-requests, bronmetadata en runtime gedrag op signalen van Magecart, e-skimming, formjacking en vergelijkbare browsergebaseerde aanvallen. Wanneer cside kwaadaardig gedrag detecteert, kan het uw team waarschuwen en, in scriptmodus, het script of specifieke scriptacties blokkeren.

Is alleen scanmodus genoeg voor PCI DSS?

Ja. De scanmethode is ontworpen om te voldoen aan de verwachtingen voor periodieke inventarisatie en wijzigingsdetectie in PCI DSS 6.4.3 en 11.6.1. De scriptmethode voegt continue runtime monitoring en blokkering toe voor teams die sterkere client-side protection willen dan de minimale compliance-eis.

Hoe helpen cside-rapporten QSAs en auditbewijslast?

cside-rapporten tonen URLs van betaalpagina’s, gedetecteerde scripts, headerwijzigingen, autorisatiebeslissingen, zakelijke rechtvaardigingen, auteurs en tijdstempels. Dit geeft QSAs bewijs dat scripts op betaalpagina’s worden gevolgd en beoordeeld, zonder afhankelijk te zijn van screenshots of handmatige spreadsheets.

Dwingt cside scriptcontroles af of monitort het alleen?

Beide, afhankelijk van de modus. De scriptmethode kan scripts en specifieke acties runtime blokkeren en blokkeert ook CSP-injectiepogingen die de monitor willen uitschakelen. De scanmethode is per ontwerp enkel monitoring. PCI DSS staat post-autorisatie scanners expliciet toe en de PCI SSC heeft dit direct bevestigd.

Hoe realtime is de detectie?

De scriptmethode draait inline in de gebruikerssessie en wrapt de meeste browser-APIs om te observeren hoe scripts het DOM muteren, waardoor analyse gebeurt terwijl scripts uitvoeren. Dezelfde payloadhash wordt niet twee keer geanalyseerd omdat dat geen beveiligingswaarde toevoegt. 11.6.1 vereist geen 100% sessiemonitoring; periodieke evaluatie volstaat, en cside voldoet aan zowel de periodieke als de continue lat.

Hoe gaat cside om met nieuwe of geobfusceerde aanvallen?

Detectie is niet signature-based op het parent-script. cside logt elke sub-request van een script, de-obfusceert payloads vóór evaluatie en draait diepgaande AI-analyse op alles dat de risicodrempel passeert. Nieuwe en zero-day payloads zijn een specifiek ontwerpdoel. Zie Dreigingsdetectie voor de volledige detectie-pipeline.

Hoe worden zakelijke rechtvaardigingen bijgehouden?

Het PCI DSS-dashboard legt elke rechtvaardiging vast in de UI en in de audit log, inclusief wie deze heeft opgesteld of bewerkt en wanneer. Door AI gegenereerde rechtvaardigingen zijn door de PCI SSC expliciet toegestaan en worden aan de reviewer aangeboden ter bevestiging, niet automatisch geaccepteerd.