AI-forensics & Incident response

Overzicht van forensisch onderzoek en incident response voor AI-systemen: waarom traditionele IR tekortschiet, de levenscyclus van een AI-incident en de unieke uitdagingen van niet-deterministische systemen.

AI-forensics & Incident response

Wanneer een AI-systeem gecompromitteerd raakt, laat het draaiboek dat je voor traditionele software-incidenten gebruikte je achter met kritieke blinde vlekken. Modelgedrag is geen binaire kwestie van "werkt" of "kapot" -- het verschuift langs een spectrum dat detectie, scoping en herstel fundamenteel anders maakt dan klassieke incident response.

Waarom traditionele IR tekortschiet

Traditionele incident response gaat uit van deterministische systemen: een gecompromitteerde server draait elke keer dezelfde exploitcode, een gestolen credential geeft bij elk gebruik dezelfde toegang en een malwarebinary produceert dezelfde hash, ongeacht wanneer je hem analyseert. AI-systemen schenden al deze aannames.

Determinisme vs. niet-determinisme

Wat traditionele frameworks missen

Het NIST Cybersecurity Framework (SP 800-61) en het SANS incident response-proces gaan er beide van uit dat je kunt:

1. Een duidelijke indicator of compromise (IoC) identificeren. In AI-systemen kan de "compromittering" een subtiele gedragsverschuiving zijn -- het model begint iets meer informatie te lekken of wordt marginaal meegaander bij schadelijke verzoeken. Er is geen equivalent van een malware-hash om naar te zoeken.

2. Het incident indammen door getroffen systemen te isoleren. Een AI-model dat in één gesprek is gejailbreaket, beïnvloedt in de meeste architecturen geen andere gesprekken. Maar als de aanval een fout in de systeemprompt of fine-tuning uitbuitte, is elk gesprek potentieel getroffen.

3. De dreiging uitroeien door kwaadaardige artefacten te verwijderen. Als het "kwaadaardige artefact" een gedragspatroon is dat tijdens de training is geleerd, kun je niet zomaar een bestand verwijderen. Je moet mogelijk hertrainen, fine-tunen met corrigerende data, of runtime-guardrails toevoegen.

4. Herstellen door terug te zetten vanaf bekende, goede back-ups. Je kunt modelgewichten terugdraaien, maar de interacties die tijdens de compromittering plaatsvonden, hebben mogelijk al schade aangericht -- er is data vrijgegeven, er zijn acties ondernomen, of downstream-systemen zijn getroffen.

De levenscyclus van een AI-incident

De levenscyclus van een AI-incident past de traditionele IR-fasen aan, maar voegt in elke fase AI-specifieke activiteiten toe.

Fase 1: Detectie

Detectie in AI-systemen steunt op andere signaaltypen dan traditionele systemen.

Fase 2: Triage en classificatie

Eenmaal gedetecteerd moeten AI-incidenten worden geclassificeerd met een AI-specifieke taxonomie. Traditionele categorieën zoals "malware", "ongeautoriseerde toegang" of "denial of service" vangen de nuances van AI-compromittering niet.

AI-incidenttaxonomie categorieën omvatten jailbreaks, prompt-injectie, data-exfiltratie via modeloutputs, modelmanipulatie, supply chain-compromittering van modelartefacten en adversariële aanvallen op modelinvoer.

Zie Incidentclassificatie voor de volledige taxonomie en Severity-framework voor de scoremethodologie.

Fase 3: Containment

AI-containmentstrategieën hangen af van het incidenttype en de systeemarchitectuur.

Fase 4: Onderzoek

AI-forensisch onderzoek bestudeert bewijstypen die niet bestaan in traditionele IR.

• Prompt- en completion-logs -- de volledige invoer-/uitvoergeschiedenis van het model, inclusief systeemprompts, gebruikersberichten en assistentantwoorden
• Inferentie-telemetrie -- waarschijnlijkheden op tokenniveau, latentiemetingen en samplingparameters voor elk verzoek
• Modelartefacten -- gewichten, adapters, tokenizerbestanden en configuratie die het gedrag van het model bepalen
• Tool call-traces -- registraties van welke externe tools of API's het model aanriep, met welke parameters en welke resultaten werden teruggegeven
• Embedding- en retrieval-logs -- welke documenten werden opgehaald voor RAG-queries, hun similariteitsscores en de chunks die in de context werden geïnjecteerd

Zie Loganalyse en Modelforensics voor gedetailleerde onderzoeksprocedures.

Fase 5: Herstel

Herstel in AI-systemen vereist vaak veranderingen die verder gaan dan het patchen van code.

1. 1

   Patch de onmiddellijke kwetsbaarheid

   Als de aanval een fout in de systeemprompt uitbuitte, werk dan de systeemprompt bij. Als het een ontbrekende guardrail uitbuitte, deploy dan de guardrail. Dit is de snelste maar minst duurzame oplossing.

2. 2

   Pak de hoofdoorzaak aan

   Bepaal of de kwetsbaarheid in het model zelf zit (trainingsdata, fine-tuning), in de applicatielaag (systeemprompt, toolconfiguratie) of in de infrastructuur (API-blootstelling, authenticatie). Pas de juiste oplossing op de juiste laag toe.

3. 3

   Verifieer de fix statistisch

   Omdat AI-systemen niet-deterministisch zijn, kun je een fix niet met een enkele test verifiëren. Voer de oorspronkelijke aanvalspayload minstens 50 keer uit en bevestig een statistisch significante daling van de slagingskans. Documenteer het betrouwbaarheidsinterval.

4. 4

   Monitor op regressie

   Deploy monitoring die specifiek let op het aanvalspatroon en gerelateerde varianten. Stel alertdrempels in op basis van baselinegedrag dat vóór het incident is vastgesteld.

Fase 6: Post-mortem

AI-incident-post-mortems moeten alle traditionele post-mortem-elementen bevatten, plus:

• Tijdlijn van modelgedrag -- hoe het gedrag van het model voor, tijdens en na het incident veranderde
• Beoordeling van overdraagbaarheid van de aanval -- of dezelfde aanval werkt op andere modellen in jouw omgeving
• Review van trainingsdata -- of de kwetsbaarheid in de trainingsdata is ontstaan
• Analyse van guardrail-gaten -- welke veiligheidsmaatregelen het incident hadden moeten opvangen en waarom ze dat niet deden

Unieke uitdagingen in AI-forensics

Niet-deterministisch bewijs

Dezelfde prompt kan bij opeenvolgende runs verschillende outputs produceren. Dit betekent:

• Je kunt het exacte incident mogelijk niet reproduceren, zelfs niet met dezelfde invoer
• "Negatieve" testresultaten bewijzen niet dat de kwetsbaarheid is verholpen
• Bewijs moet de exact waargenomen outputs bevatten, geen reconstructies
• Statistische analyse vervangt binaire pass/fail-verificatie

Prompt-logs vs. systeemlogs

Traditionele systeemlogs (syslog, applicatielogs, accesslogs) vertellen je wat er op infrastructuurniveau gebeurde. Maar AI-incidenten spelen zich af in de inhoud van de prompts en completions zelf. De "exploit" is natuurlijke taal, geen via een CVE geïdentificeerde kwetsbaarheid.

Dit betekent dat je logginginfrastructuur de volledige inhoud van elke interactie moet vastleggen, niet alleen metadata. Een logregel die zegt "gebruiker stuurde een bericht om 14:32:07, 847 tokens, respons 1.203 tokens" vertelt je niets over de vraag of er een jailbreak plaatsvond. Je hebt de daadwerkelijke tekst nodig.

Modelgedrag als bewijs

Bij sommige AI-incidenten zit het bewijs niet in logs of artefacten -- het zit in het gedrag van het model zelf. Een gefinetuned model kan zijn vergiftigd om zich in specifieke contexten anders te gedragen. De enige manier om dit te ontdekken is via systematische gedragsprobing, wat behandeld wordt in Modelforensics.

Temporele uitdagingen

AI-modellen worden vaak bijgewerkt, hertraind of vervangen. Als je een incident dagen na het optreden ervan ontdekt:

• De modelversie die op dat moment draaide is mogelijk niet meer beschikbaar
• De systeemprompt is mogelijk sinds het incident bijgewerkt
• RAG-documentindexen zijn mogelijk gewijzigd
• Toolconfiguraties zijn mogelijk aangepast

Dit maakt proactieve bewijsbewaring cruciaal. Zie Bewijsbewaring voor procedures en best practices.

Sectieoverzicht

Deze sectie is georganiseerd in vijf subsecties, die elk een kritiek aspect van AI-forensics en incident response behandelen.

Gerelateerde onderwerpen

• Agent- & Agentic-exploitatie -- begrijpen op welke aanvallen AI-IR moet reageren
• Prompt-injectie & jailbreaks -- de aanvalstechnieken die jailbreak-incidenten produceren
• Infrastructuur & Supply chain -- supply chain-compromitteringsscenario's die relevant zijn voor modelforensics
• Red team-rapportage -- het documenteren van bevindingen uit AI-forensisch onderzoek

Referenties

• "NIST SP 800-61 Rev. 3: Computer Security Incident Handling Guide" - National Institute of Standards and Technology (2024) - Foundation IR framework adapted throughout this section
• "AI Incident Database" - Partnership on AI (2025) - Catalog of real-world AI incidents used to develop the taxonomy
• "OWASP Top 10 for LLM Applications" - OWASP Foundation (2025) - Vulnerability classification relevant to incident taxonomy
• "MITRE ATLAS: Adversarial Threat Landscape for AI Systems" - MITRE Corporation (2025) - Attack taxonomy and technique catalog for AI systems