Kort samengevat: self-hosted AI voor client-side beveiliging
- Vendor-API's lekken data: De branchestandaard voor AI in security-tooling is om payloads naar de API van een externe modelaanbieder te sturen, maar dat overhandigt scriptinhoud stilletjes aan een leverancier waarvan de data-handling policies zonder overleg met je GRC-team worden herschreven.
- Self-hosted vanaf dag één: cside is in mei 2024 gelanceerd als het eerste client-side securityproduct met LLM's in de kern, dat open source-modellen draait op eigen cloud zodat scriptinhoud nooit gecontroleerde infrastructuur verlaat en er niets in een trainingsset terechtkomt.
- Op wiens infrastructuur: Bepaal vóór je volgende AI-beleidsreview of het analyseren van geobfusceerde JavaScript op betaalpagina's, samen met automatisering van PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1, een taak is die thuishoort op het gedeelde model van iemand anders of op infrastructuur die aan jou verantwoording aflegt.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
TL;DR
In mei 2024 werd cside gelanceerd als de eerste beveiligingsoplossing aan de clientzijde om AI in zijn product te integreren.
We gebruiken zelfgehoste open source-modellen op onze eigen infrastructuur om JavaScript te analyseren op kwaadaardige bedoelingen. Leg scriptgedrag uit in gewone taal, volg wijzigingen in de tijd en automatiseer PCI DSS 4.0.1-scriptcompliancebeoordelingen.
In tegenstelling tot oplossingen die gebruikmaken van AI-API's van derden, voorkomt onze architectuur het lekken van gegevens en beschermt de privacy van eindgebruikers door gebruik te maken van zelfgehoste open source LLM's. Voor organisaties met AI-beperkingen kunnen deze functies worden uitgeschakeld. AI is een overlay, geen vereiste, maar heeft zich waardevol bewezen voor GRC- en beveiligingsteams.
Beveiliging aan de clientzijde in een AI-tijdperk
Toen we cside in mei 2024 lanceerden, wilden we aanvallen opvangen die anderen niet opvingen. Daarom hebben we een beslissing genomen die ons onderscheidde van alle andere spelers op het gebied van beveiliging aan de clientzijde: we hebben vanaf dag één AI in de kern van ons product ingebouwd.
Destijds waren we de enige aanbieder die LLM's gebruikte om JavaScript-beveiliging aan de clientzijde aan te pakken. Later volgde de rest van de markt ons voorbeeld, maar hoe je AI implementeert is net zo belangrijk als de functionaliteit die het biedt.
Waarom AI belangrijk is voor JavaScript-beveiliging
JavaScript is uniek moeilijk te analyseren. Aanbieders van SAST-oplossingen gebruiken ook LLM's om code te analyseren. Maar scripts aan de clientzijde veranderen voortdurend, worden met opzet geobfusceerd en kunnen zich anders gedragen op basis van wie ze bekijkt, waar ze zich bevinden of hoe laat het is.
Traditionele patroonmatching mislukt wanneer aanvallers hun code randomiseren of zich op specifieke gebruikers richten.
In tegenstelling tot besturingssystemen zijn browsers niet gebouwd voor beveiliging. Daarom biedt cside meerdere benaderingen aan om de gaten te dichten:
- Script Methode (eenvoudigst): we controleren scriptgedrag in de browser en halen de scripts aan onze kant op, en verifiëren vervolgens of het hetzelfde script is. Het verkeer van je site loopt nooit via cside. Eenvoudig te implementeren, geen impact op de performance, en je kunt scriptacties nog steeds stoppen of blokkeren op URL, hash of domein.
- Scan Methode (snelst): als je geen script aan je site kunt toevoegen, scant cside het met behulp van threat intelligence van duizenden andere websites met miljarden gezamenlijke bezoekers. Snel op te zetten en nuttig wanneer scriptinstallatie niet mogelijk is.
De combinatie van deze modi brengt ons het dichtst bij de volledige dekking die vandaag technisch mogelijk is.
LLM's zijn erg goed in het contextualiseren van JavaScript, zelfs als het onherkenbaar is verminkt. Een LLM kan naar geobfusceerde code kijken, de bedoeling ervan begrijpen en gedrag signaleren dat statische analyse volledig zou missen. Die mogelijkheid is waardevol voor JavaScript-beveiliging, maar alleen als het verantwoord wordt geïmplementeerd.
Verantwoorde AI-architectuur: waarom we zelf hosten
cside draait open source LLM's op onze eigen cloudinfrastructuur. We behouden volledige controle over de gegevens die door onze modellen stromen.
Wanneer bedrijven functies met AI uitbrengen, grijpen ze vaak standaard naar API's van bekende AI-bedrijven. Hoewel die bedrijven functies hebben om te voorkomen dat gegevens zonder toestemming voor training worden gebruikt, worden de gegevens wel aan een derde partij verstrekt. In een ideale wereld verlaten gegevens nooit je controlegebied.
Door zelf open source-modellen te draaien, bestaat er geen risico dat scriptinhoud naar externe leveranciers lekt. Er is geen kans dat klantgegevens in een trainingsset verschijnen.
Wanneer je JavaScript naar een API van derden stuurt, vertrouw je op het gegevensverwerkingsbeleid van die leverancier, dat in de loop van de tijd actief verandert.
cside begrijpt de beveiligingsvereisten en wat er nodig is om je gegevens veilig te houden. Je kunt onze beveiligingsstatus zelf verifiëren op ons Trust Center, waar we onze SOC 2 Type II-, pentest- en PCI DSS AOC-documentatie publiceren.
Hoe cside AI gebruikt: 4 kerntoepassingen
Hier draait de AI feitelijk in ons product.
1. Scripts analyseren op kwaadaardige bedoelingen
Elk script dat op je site wordt geladen, wordt geanalyseerd in zijn oorspronkelijke vorm en na deobfuscatie. De LLM zoekt naar patronen die kwaadaardig gedrag aangeven:
- Diefstal van sessietokens
- Ongeautoriseerde onderschepping en exfiltratie van gegevens
- Verzamelen van inloggegevens
- Manipuleren van betalingsformulieren
Dit geldt net zo goed voor schoon ogende scripts als voor meer alarmerende scripts. Of het nu gaat om het primaire JavaScript-fragment of om een klein subverzoek.
De AI vangt beide. Het begrijpt de context op een manier die op regex gebaseerde detecties eenvoudigweg niet kunnen. En anders dan scanners, CSP of agent-gebaseerde producten, analyseren we de daadwerkelijke payload die je gebruikers ontvangen: we weten dat dit precies is wat de gebruiker heeft gekregen. We controleren niet alleen aan de hand van threat-feed-informatie of wachten tot valstrikken aan de clientzijde worden geactiveerd, hoewel we deze methoden natuurlijk ook gebruiken als lagen in onze detectie-engine.
De AI-laag in onze detectie-engine is slechts een van de vele lagen, maar AI kan zeer effectief zijn in het detecteren van verborgen kwaadaardig gedrag.
2. Zakelijke onderbouwing van scripts
- Moet deze chatwidget toegang hebben tot formuliergegevens?
- Waarom staat dit analytics-script op je betaalpagina?
- Moet deze marketingtool worden uitgevoerd als onderdeel van het afrekenproces?
We bieden een door de LLM gegenereerde zakelijke reden, wat voor sommige raamwerken een compliancevereiste is.
Dit bespaart teams uren aan onderzoek: in plaats van elke wijziging in de scripthash te bekijken of te proberen te achterhalen wie het script heeft toegevoegd, krijg je een uitleg in gewone taal van wat elk script doet.
3. Wijzigingen in de tijd verklaren
Scripts blijven niet statisch. Veel scripts worden voortdurend bijgewerkt. Vorige week voerde script X acties uit met betrekking tot analytics. Deze week heeft het ook toegang tot localStorage en doet het verzoeken aan een nieuw geregistreerd domein dat verwijst naar een residentieel IP-adres.
Wat is er veranderd, en maakt dat uit?
De AI van cside genereert voor mensen leesbare verklaringen voor scriptwijzigingen. Je hoeft geen beveiligingsonderzoeker te zijn om te begrijpen wat er tussen wijzigingen is gebeurd. Het platform laat je precies zien wat er anders is en of dat zorgen baart.
Dit is zeer nuttig voor compliance-audits. Wanneer een auditor vraagt naar het scriptgedrag van de afgelopen zes maanden, heb je gedocumenteerde, tijdgestempelde verklaringen klaarliggen. Onze 100% historische tracking betekent dat er niets verloren gaat.
4. AI voor automatisering van PCI DSS 4.0.1-compliance
PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1 schrijven een voortdurende beoordeling voor van scripts op betaalpagina's. De meeste teams doen dit handmatig: de pagina laden, de scripts inspecteren, alles documenteren en het proces wekelijks of maandelijks herhalen.
Met PCI Shield verwerkt de AI de beoordeling automatisch. Elke scriptwijziging op betaalpagina's wordt geanalyseerd. Als de wijziging er onschuldig uitziet, is er geen actie vereist. Als het tekenen van kwaadaardig gedrag vertoont, krijg je een melding met een volledig overzicht van wat er is gebeurd.
Deze aanpak is gevalideerd door VikingCloud, dat heeft bevestigd dat cside voldoet aan PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1 wanneer correct geïmplementeerd. Je kunt het volledige rapport lezen of downloaden via ons Trust Center.
Dat is meer dan gemak - het is het verschil tussen reactieve incidentrespons en proactieve dreigingspreventie.
Flexibiliteit is het antwoord
We begrijpen dat niet elke organisatie er klaar voor is om AI toe te passen in hun volledige techstack. Sommige hebben intern beleid tegen het gebruik van AI. Anderen willen het per geval beoordelen.
Daarom kunnen al onze AI-functies worden uitgeschakeld. De overlay is er als je die wilt, maar het is niet verplicht om cside te gebruiken.
Je krijgt nog steeds volledige zichtbaarheid van de payload, realtime blokkering, historische tracking en compliance-rapportage zonder AI.
Of je nu de Script Methode of de Scan Methode gebruikt, het platform biedt volledige scriptzichtbaarheid en een fail-open ontwerp. AI is een verbetering, en voor teams die het kunnen gebruiken, maakt de AI-laag alles sneller en nauwkeuriger.
Waarom dit er nu toe doet
Aanvallen aan de clientzijde worden steeds geavanceerder. Aanvallers weten dat de serverzijde en je statische open source-afhankelijkheden nauwlettend worden gemonitord. Daarom hebben ze hun aanvalsoppervlak aangepast en:
- Gebruiken ze dynamische client-side scripts die veranderen op basis van gebruikerscontext, waardoor ze detectie door statische scans vermijden.
- Verduisteren ze scripts zwaar om statische analyse te vermijden.
- Benutten ze de kloof tussen wat de browserspecificatie toestaat en hoe de browser daadwerkelijk is gebouwd.
Checklist-tools kunnen dit niet bijhouden. CSP-schendingen vertellen je niet wat er in een script staat en zijn moeilijk te beheren. Crawlers krijgen schone payloads te zien, terwijl echte gebruikers kwaadaardige payloads zien. Gedragsmonitoring vangt aanvallen pas op nadat ze al zijn uitgevoerd en is vatbaar voor omzeilingsmethoden.
AI-gebaseerde detectie, gecombineerd met andere methoden, heeft de beste kans: het analyseert gedrag in realtime, begrijpt geobfusceerde code zelfs wanneer deobfuscatie mislukt, en signaleert afwijkingen die patroonmatching zou missen.
Zelfgehoste modellen, geïsoleerde infrastructuur en geen gegevensdeling met derden. Zo profiteer je van de voordelen van AI zonder nieuwe risico's te introduceren of interne weerstand te ondervinden.
Klaar om cside uit te proberen? Start gratis of boek een demo voor een gesprek met ons team.
