De afgelopen maand is er een nieuwe AI-categorie razendsnel opgekomen: AI decision models. In plaats van tekst te genereren krijgen ze een stukje “state” en een set vooraf gedefinieerde vragen. Vervolgens leveren ze geen verhaal, maar een keuze, een score of een ja/nee met bijbehorende waarschijnlijkheid. Voor een Security Operations Center (SOC) is dat geen hype, maar vooral een praktisch voordeel: je kunt triage automatiseren op een manier die auditeerbaar blijft.
Toch zit de valkuil niet in het model. Het echte verschil zit in de laag die eraan voorafgaat: het verzamelen van het juiste bewijs en het begrijpen van wat in jouw omgeving “normaal” is.
Waarom SOC’s enthousiast mogen zijn over AI decision models
Er zijn drie eigenschappen waardoor AI decision models logisch passen bij alert triage.
1) Een score die je direct kunt automatiseren
Wanneer het model een gekalibreerde waarschijnlijkheid geeft, kun je daar thresholds op zetten. Denk aan: een kans boven 0,97 betekent “waarschijnlijk veilig, sluit automatisch”. Onder 0,6 betekent “waarschijnlijk incident, escaleer”. Alles ertussen schuift door naar een analist voor een extra check.
Belangrijk: dit sluit ook aan op het soort acties dat je wilt beperken. Niet elke stap in je workflow is gelijkwaardig. Een modeluitspraak kan bijvoorbeeld wél geschikt zijn om een ticket bij te werken, maar niet om meteen een account te blokkeren. Met aparte drempels voor “irreversible acties” voorkom je onnodig risico.
2) Lage kosten per alert maken brede dekking haalbaar
In de bron wordt een economisch argument genoemd dat veel organisaties aanspreekt: modellen als Jev worden aangeboden tegen een relatief lage prijs per hoeveelheid input, met snelle responstijden. In zo’n scenario verdwijnt het dwingende kostenargument om alleen “high severity” alerts te onderzoeken. Je kunt juist meer signalen laten beoordelen.
Voor SOC-teams betekent dit: je kunt triage democratischer maken—niet alleen de alarmsituaties met de grootste impact krijgen aandacht, maar ook de vele randgevallen die anders tussen wal en schip vallen.
3) Elke uitspraak wordt een record
Een ander voordeel is dat het outputformaat vast en voorspelbaar is. Als je vooraf definieert welke antwoorden mogelijk zijn, kun je elke beslissing loggen, later terugkijken, en zelfs vergelijken met de uiteindelijke uitkomst. Dat is doorgaans eenvoudiger te auditen dan een aanpak waarbij je vooral “redeneringen” of vrije tekst opslaat.
Let wel: wanneer leveranciers zeggen dat hun modellen “niet hallucinate”, bedoelen ze vaak vooral dat de output altijd aan het schema voldoet. Een goed gevormde uitspraak kan nog steeds inhoudelijk onjuist zijn.
Waarom gekalibreerde waarschijnlijkheid toch geen garantie is
De kernregel blijft: garbage in, garbage out. Gekalibreerde waarschijnlijkheid betekent dat de kansverdeling klopt over vergelijkbare inputs. Dus: wanneer het model bij 90% komt, is dat 90% van de tijd correct voor voorbeelden die lijken op wat jij aanlevert.
Maar “lijken op wat jij aanlevert” is precies waar het vaak misgaat in security. Een model ziet bijvoorbeeld alertmetadata (zoals titels en severity), maar kent geen automatische diepere kennis van de betreffende host of organisatie. Daardoor is de waarschijnlijkheid niet magisch; hij is afhankelijk van wat er in de input zit.
Wat gebeurt er als de alertinput misleidend is?
In de bron worden cijfers genoemd uit een AI SOC-rapport met miljoenen alerts. Daaruit komt naar voren dat veel alerts uiteindelijk geen daadwerkelijke bedreiging blijken te zijn, zelfs als er endpoint-activiteit is geweest en EDR’s al hebben gemitigeerd.
Voor AI decision models betekent dit: als een alert een verkeerde claim bevat (bijvoorbeeld de verkeerde interpretatie van severity of context), kan het model met hoge zekerheid “sluiten” omdat het patroon in de data overeenkomt met “meestal veilig”. Het model doet dan wat het hoort te doen—maar de input leidde af.
Ook severity kan een verkeerde voorspeller zijn
De bron benoemt dat een deel van de echte incidenten terug te voeren is op alerts met de laagste severity. Bij grootschalige aantallen kan dat nog steeds een betekenisvolle hoeveelheid echte dreigingen opleveren. Daardoor is severity als “poortwachter” niet voldoende—zeker niet wanneer je wilt automatiseren op basis van kansen en bewijs.
Ook hier geldt: het model kan overconfident zijn en gevoelig voor hoe prompts of kandidaten worden geformuleerd. Die eerlijkheid komt vaak terug in modeldocumentatie, en het is een reminder om je pipeline te testen op jouw eigen datatypes en workflows.
Wat “bewijs” in security echt betekent (en waarom het zo moeilijk is)
Om te begrijpen waarom AI decision models niet het hele verhaal zijn, helpt een vergelijking met forensisch onderzoek. Je kunt een vrij algemene hypothese laten maken, maar je krijgt de juiste verdachte pas met DNA, vingerafdrukken, en getuigenverklaringen. Security is vergelijkbaar: de juiste context bepaalt of je een goede beslissing kunt nemen.
De bron legt de nadruk op Security Context Engineering: het omzetten van een alert in een set feiten voordat een model of analist een oordeel velt. Daarbij is het meest waardevol dat je bewijs verzamelt dat niet alleen “metadata” is, maar technisch verifieerbaar.
Code-level evidence: wat draait er echt in geheugen?
Een voorbeeld in de bron is codeanalyse van binaire onderdelen die in het geheugen draaien. Het idee: vergelijk code in runtime met bekende betrouwbare en schadelijke patronen, en detecteer zowel bekende malware als nieuw gedrag dat dezelfde bouwstenen hergebruikt.
Live memory forensics: vooral relevant bij fileless aanvallen
Een tweede categorie bewijs richt zich op live memory. Juist bij aanvallen die “fileless” zijn of waarbij code-injectie speelt, is alleen een bestandsstatus “gequarantineerd” vaak te weinig. In de bron wordt beschreven dat een endpointscanner automatisch procesbomen, in-memory geladen executables, memory dumps bij vermoedelijke injectie, en bestanden achter scheduled tasks en autoruns verzamelt.
Detonation en netwerkforensics: gedrag boven veronderstellingen
Verder is er het idee van sandboxing: verdachte bestanden worden uitgevoerd in een gecontroleerde omgeving. Tegelijk worden URLs, domeinen en IP’s onderzocht zodat een verdict niet alleen op statische signalen rust, maar op zichtbaar gedrag.
Het lastigste deel: wat “normaal” is voor jouw organisatie
Forensisch bewijs vertelt wat er gebeurd is. Het vertelt zelden of het ook verwacht is binnen jouw bedrijf.
In de bron komt dit duidelijk naar voren bij identity-gerelateerde alerts. Een groot deel blijkt waarschijnlijk benign. Onmogelijke reis-achtige signalen worden pas zelden bevestigd als echte compromissen. Tegelijk kunnen specifieke use-cases (zoals VPN-gebruik) een sterke invloed hebben op uitkomsten.
Het probleem: een model kan niet automatisch weten dat “Dave uit finance altijd vanaf Portugal inlogt” of dat een bepaalde alert elke release op build servers triggert.
Daarom is “organisatorische context” nodig. Volgens de bron zijn er twee uitdagingen:
- Het is niet te kopen als kant-en-klare data—het is specifiek voor jouw omgeving.
- Het decayeert snel, omdat assets, gebruikers en tooling veranderen. Een snapshot bij onboarding is na verloop van tijd achterhaald.
De oplossing die in de bron wordt beschreven is een gesloten leerlus: leer van eerdere cases, haal live context op wanneer geheugen nog niet genoeg is, en schrijf de les terug zodra een onderzoek is afgerond. Zo controleer je ook of een model in jouw praktijk nog steeds zo “90% klopt” als je aanvankelijk verwachtte.
Een forensische aanpak voor alert triage: eerst bewijs, dan beslissen
De bron beschrijft een concrete structuur die je kunt vertalen naar je eigen pipeline. Het uitgangspunt is: verzamel eerst bewijs en beslis daarna.
1) Evidence-first: wat je weet moet je kunnen meten
In de bron wordt bijvoorbeeld code-level evidence genoemd (vergelijking van binaire code in geheugen) en live memory forensics wanneer de alert niet genoeg materiaal bevat voor een verdict. Dit is vooral nuttig wanneer er aanwijzingen zijn voor fileless gedrag of code-injectie.
2) Detonation en netwerkanalyse ondersteunen het oordeel
Wanneer er verdachte bestanden zijn, helpt sandboxing om gedrag te bevestigen. Daarmee verschuift het zwaartepunt van interpretatie naar observatie.
3) Organizational memory als antwoord op “wat is normaal hier?”
De bron noemt een “Org Brain” concept met twee soorten geheugen: procedureel (hoe jouw team onderzoekt en welke detecties je direct afhandelt) en declaratief (assets, gebruikers, normaal gedrag en ook hoe je SIEM-schema is ingericht). Door case history te koppelen aan live context tijdens een onderzoek, worden beslissingen beter en blijven ze actueel.
Waar je inspanning het meeste oplevert
Nieuwe modellen verbeteren doorgaans cyclisch: wat een voordeel is deze kwartaalperiode, komt later ook bij concurrenten en attackers. De bron benadrukt daarom dat je echte voorsprong vooral zit in de contextlaag.
Als je dit jaar een pipeline voor AI decision models bouwt of bijstuurt, dan zijn dit volgens de bron de beste bestedingspunten:
- Verzamel bewijs vóór je beslist: procesbomen, sandboxresultaten en in-memory data wegen zwaarder dan alleen alertmetadata.
- Laat severity niet alles bepalen: als decision models goedkoop zijn, is het niet logisch om enkel lage severity links te negeren—laat het bewijs en je drempels het werk doen.
- Behandel organisatiekennis als een systeem: assets, gebruikers en normaal gedrag moeten continu worden aangevuld en ververst.
- Meet kalibratie in jouw omgeving: koppel elke geautomatiseerde verdict aan de uitkomst en volg drift.
Conclusie: AI decision models versnellen triage, maar context beslist
AI decision models zijn een stap vooruit voor SOC’s omdat ze snelle, gestructureerde beslissingen leveren met een score die je kunt vertalen naar thresholds. Daardoor kun je triage sneller, goedkoper en beter auditeerbaar maken.
Maar de kwaliteit van je uitkomst hangt vooral af van de laag ervoor: evidence-first forensics en een continu bijgewerkte organisatorische context. Wanneer je die basis goed inricht, wordt automatisering niet alleen sneller—maar ook betrouwbaarder.
Gerelateerd lezen: Contextuele cybersecurity: van losse alerts naar actie.
Gerelateerd lezen: Fake AI-aanvallen: zo beperk je incidenten vroeg.
Gerelateerd lezen: NGINX en Juniper patches: kritieke RCE’s verholpen.
Bron: https://thehackernews.com/2026/10/ai-decision-models-and-their-impact-on.html
