Beveiligingsleiders discussiëren al langer of AI een compleet nieuwe generatie cyberaanvallen mogelijk maakt. De praktijk beweegt echter eerder in een andere richting: AI maakt het “middenstuk” van een aanval goedkoper en sneller. Daardoor blijven aanvallers niet buiten spel staan als een eerste poging faalt—ze leren van feedback en proberen opnieuw, vaak binnen minuten.
Voor een SOC (Security Operations Center) is dat geen theoretisch vraagstuk. Verdedigers moeten hun processen minstens net zo adaptief maken. Het kernprobleem zit niet alleen in signalen of detectieregels, maar in wat er gebeurt wanneer een incident door het team beweegt. In dit artikel staat daarom één concept centraal: stateful SOC—een manier van werken waarbij de relevante context, onzekerheden en beslisruimte meegaan met elke handoff.
Waarom AI aanvallen iteratief goedkoper maakt
In de traditionele beschrijving van een aanval staat de aanvalslijn centraal: van verkenning tot impact. Maar echte aanvallen werken vaker als een lus. Een actor kijkt rond, doet een hypothese, voert een stap uit, leest de terugkoppeling, en past de volgende poging aan.
AI versnelt precies die lus. Waar een menselijke operator na een mislukte privilege-escalatie eerst uren kwijt kon zijn aan documentatie, permissiechecks en scriptdebugging, kan een model in de loop de fout uitleggen en de volgende route voorstellen. Geen enkele afzonderlijke stap wordt daarmee “nieuw”, maar de totale doorlooptijd tot een werkende route daalt.
Het gevolg: een mislukte stap is niet langer een dure doodlopende weg. Voor verdediging betekent dat dat alleen “goed detecteren” niet genoeg is; je moet ook goed kunnen bijsturen zodra context verandert.
Wat publieke rapporten laten zien over AI in aanvallen
Publieke dreigingsrapportages tonen een verschuiving in hoe generatieve AI wordt gebruikt. In eerdere fases kwam AI vooral naar voren als productiviteitsassistent: helpen met vertalen, scripting, troubleshooting en onderzoek.
Later zien rapporten ook meer volwassen toepassingen. Denk aan aanvallers die tijdens het uitvoeren van code contact leggen met een model, of aan initiatieven waarbij AI op meerdere momenten in een criminele workflow wordt ingezet—van reconnaissance en het verzamelen van credentials tot het formuleren van losgeldeisen.
Belangrijk detail: niet elk bericht betekent dat dezelfde AI-capabiliteit 1-op-1 in de praktijk breed is uitgerold. Bovendien blijft attributie lastig en is prevalentie niet altijd goed te meten. Wat je wél mag afleiden is de richting: AI schuift steeds verder in de workflow van aanvallers, niet slechts naast hun werk.
De echte bottleneck: wat er verloren gaat bij elke handoff
De SOC wordt vaak beschreven met vijf functies: threat intelligence, threat hunting, detection engineering, investigation en remediation. Die indeling is nuttig, maar ze kan ook verbergen waar het misgaat.
In veel organisaties is niet het werk zelf het probleem, maar de overdracht. Threat intelligence kan begrijpen waarom een techniek relevant is. Threat hunting weet waar iets opvalt. Detection engineering vertaalt dat naar logica en assumptions. De investigator ziet het bewijsverloop. En de remediatieploeg weet welke acties de business het minst schaden.
Tussen die onderdelen glijdt kennis weg. Wat eerst betekenis had, eindigt later als een indicator, een alert of een ticketregel. Dat is niet per se kwaadwillend—het is een proceskenmerk. Maar het effect is groot: ieder team moet opnieuw reconstrueren wat de vorige partij al wist.
Vijf dingen die een handoff zou moeten meedragen
Een goede overdracht vraagt om meer dan alleen “de alert”. Het moet minimaal deze onderdelen bevatten:
- Entity identity: wie of wat staat centraal (gebruiker, device, workload, proces) en in welke rol.
- Evidence en provenance: welke waarnemingen ondersteunen de conclusie, waar ze vandaan komen en wanneer.
- Hypothese en confidence: de beste verklaring, de alternatieven en hoe zeker je bent.
- Telemetry sufficiency: welke claims je data wél ondersteunt, wat je niet kunt bewijzen, en welke ontbrekende bron onzekerheid veroorzaakt.
- Decision ownership en constraints: wie mag handelen, welke goedkeuringen nodig zijn en welke impact acties kunnen hebben.
Als je de eerste vier elementen mist, krijg je dubbele onderzoeken, verkeerde aannames of “bewijs” zonder herkomst. Als je de laatste twee mist, wacht een juiste aanbeveling in een queue of wordt ze vertraagd door onduidelijk eigenaarschap. In een SOC waar dit structureel gebeurt, ontstaan blijvend lawaai in regels en terugkerende blinde vlekken.
Van alert naar actie: waarom het soms een reconstructieproject wordt
Een illustratief scenario helpt het probleem scherp te krijgen. Stel: een finance-medewerker logt in vanuit een hostingprovider waar het account nog nooit eerder vandaan kwam. MFA is succesvol. Binnen tien minuten start er een nieuwe mailboxregel die doorstuurt naar een extern adres. Daarna begint het account bestanden op te halen van een finance SharePoint-site in een patroon dat afwijkt van normaal gedrag.
Op zichzelf bewijst elk van deze feiten niet “compromis”. Maar samen vormen ze een reeks die aandacht verdient.
In het echte proces beweegt een incident langs meerdere perspectieven: threat intelligence brengt een contextlaag mee vanuit eerdere observaties, de hunter vertaalt dat naar zoekvragen en ziet hiaten in dekking, detection engineering bouwt logica die alleen afgaat wanneer meerdere signalen tegelijk kloppen, en de analist probeert vervolgens in consoles de puzzel opnieuw te leggen.
Daarbij verdwijnen juist de redenen die de eerdere teams kenden. Het resultaat: de analist krijgt een alert zonder de onderliggende redenering. Twee verklaringen blijven mogelijk, maar door ontbrekende scope—bijvoorbeeld omdat er onvoldoende endpoint-telemetrie is—wordt onbekendheid onderdeel van de conclusie. De zaak sluit, maar de “waarom”-informatie die nodig is voor de volgende stap ontbreekt.
Daarna komt het echte bestuurlijke dilemma: de identity-teams krijgen een ticket met een aanbeveling zoals “disable the account”. Ze kunnen dan nét weten dat het account op dat moment midden in een payroll-run zit. Een bruuske disable kan de bedrijfscontinuïteit schaden. De containment-beslissing en de continuïteitsbeslissing moeten dus door mensen worden genomen die beide realiteiten tegelijk zien—maar die koppeling bestond niet in de overdracht.
Het werk is dus niet fout, maar de keten is fragiel: elke functie doet wat van haar verwacht wordt, terwijl het systeem de incidentcontext telkens opnieuw laat opbouwen.
Waarom je niet alleen “een unicorn analyst” moet zoeken
Wanneer organisaties dit verlies voelen, is de reflex vaak: we moeten iemand aannemen die alles kan—identity, endpoint, cloud, e-mail, malwareanalyse, detectielogica én executive communicatie. Maar die “unicorn” lost vooral een procesprobleem op, niet de oorzaak.
Wat in de praktijk gebeurt, is dat een senior analist kennis meeneemt die niet in dashboards zit. Ze weten welke logbron kan liegen, welke serviceaccounts nooit aangeraakt mogen worden en bij wie het antwoord om 2:00 uur te vinden is. Dat is waardevol—maar het maakt de organisatie afhankelijk van één hoofd.
Bovendien verdwijnt de echte leercurve na een incident vaak bij afsluiting. Als alleen de closure-reden wordt bewaard en de onderbouwing en onzekerheidscontext verdwijnt, dan blijft dezelfde regel voor jaren lawaai maken en vindt elke nieuwe analist opnieuw dezelfde blinde vlek.
Wat een stateful SOC anders maakt
De oplossing die centraal staat, is architecturaal: maak de SOC stateful. Een stateful SOC is geen organisatie die “alles onthoudt” omdat het kan, maar een systeem dat bewust kennis en besliscontext laat doorstromen.
In plaats van alleen evidence te bewaren, legt het ook vast waarom die evidence tot een hypothese leidde, welke onzekerheden bestonden en welke beperkingen er waren bij het nemen van beslissingen.
Concreet draait stateful SOC om gedeelde operationele “state”, die workflows lezen en schrijven:
- Environmental state: wie/ wat er bestaat in identity, devices, workloads en business services, plus relaties en eigenaarschap.
- Evidence state: elke observatie, met bron, tijd en terugkoppeling naar de originele gebeurtenis.
- Decision state: huidige hypothese, alternatieven, argumenten vóór/tegen, en wat nieuw bewijs zou kunnen veranderen.
- Control state: beschikbare acties, benodigde goedkeuringen, eigenaar van het systeem en wat vooraf bewaard moet worden voor containment.
- Learning state: correcties die analysts maakten, welke aannames faalden, of de fix hield, en wat dat betekent voor hunting en detectie.
Belangrijk: een stateful SOC vervangt SIEM, EDR of case management niet. Het integreert en organiseert de context zodat de ene tool de andere beter kan voeden. Denk aan het verschil tussen “een alert” en “een besluitbaar incidentdossier”.
Onbekendheid moet als data behandeld worden
Een van de strengste disciplines in deze aanpak is: “unknown” serieus nemen. Wanneer endpoint-telemetrie ontbreekt omdat een device niet beheerd is, is de conclusie niet “er is geen kwaad proces gezien”. Technisch kan dat waar zijn, maar operationeel is het misleidend.
Een stateful SOC legt vast dat de endpoint niet te controleren was, verlaagt daarmee de confidence op scope en stuurt de coverage-gap naar het team dat verantwoordelijk is voor device management. De gap wordt dan onderdeel van het dossier in plaats van een geruststellende zin.
Waar agentic AI in past (en waar niet)
Agentic AI komt in dit verhaal pas later in beeld. Dat is bewust: een agent “plakken” op een stateless SOC kan leiden tot een workflow die sneller is, maar verkeerd opereert. Bounded workflows werken beter wanneer ze bouwen op gedeelde state en niet op losse signalen.
In zo’n model kan intelligence bepalen wat lokaal relevant is, hunting kan rapporteren welke populaties wel en niet gedekt waren, detection kan alleen regels releasen wanneer de omgeving de benodigde data kan leveren, investigation kan timeline en alternatieven als één object verpakken, en remediation kan beslissingen mappen op echte acties, eigenaars en approvals.
Ook authority en confidence moeten gescheiden blijven. Een agent kan een voorstel doen en redenering bijwerken, maar uitvoering vraagt om een expliciete modus—observeren, aanbevelen aan een bevoegde, wachten op goedkeuring, of geautomatiseerd uitvoeren wanneer policy en scope exact kloppen.
Op dezelfde manier geldt voor learning: één false positive van één analist is geen stevige basis om productie-detectie te veranderen. Een stateful SOC kan daarom bewijs achter die wijziging vastleggen, vergelijkbare gevallen verzamelen en de voorgestelde aanpassing laten beoordelen door de eigenaar van de regel.
Wat je direct kunt meten in je eigen proces
Als je van dit verhaal actie wilt maken, begin dan klein maar gericht. Niet alleen met “zijn er taken afgerond”, maar met vragen die contextverlies zichtbaar maken:
- Bevat het case-object bij binnenkomst al de benodigde context?
- Noteert het dossier wat niet gezien kon worden?
- Komt een gecorrigeerd oordeel bij de rule owner aan terwijl het nog relevant is?
- Blijven geautomatiseerde acties binnen policy, met een controleerbare audit trail?
Door die meetpunten te combineren met stateful tracking van environmental, evidence, decision, control en learning state, krijg je grip op waar reconstructie ontstaat.
Daarmee wordt ook duidelijk waarom wachten op “volledige autonomie” minder verstandig is dan het iteratief dichten van contextverlies. De aanvalslus wordt sneller; je verdediging moet hetzelfde tempo van leren en beslissen benaderen.
Conclusie: sneller reageren begint bij context die blijft bestaan
AI maakt aanvallen iteratief goedkoper: een mislukte stap wordt sneller herhaald en bijgestuurd. Het SOC-probleem zit echter vaak niet in het begin van de keten, maar in de overdrachten erna. Wanneer reden, onzekerheid en beslisruimte niet meegaan, moet iemand later het incident opnieuw opbouwen—met vertraging, fouten en “vergeten lessen” als gevolg.
Een stateful SOC pakt dat structureel aan door evidence, onzekerheid, dekking en eigenaarschap als gedeelde state door te geven. Zo krijgt de volgende stap in de workflow niet alleen een alert, maar een besluitwaardig dossier. Wil je meer lezen over hoe incidentafhandeling en SOC-leerprocessen samenkomen met actuele beveiligingspraktijk? Kijk ook naar agentic remediation en de CTEM-cyclus voor een praktische brug tussen detectie, evaluatie en herstel.
Bron: https://thehackernews.com/2026/09/the-soc-doesnt-need-to-start-over-with.html
