Triageprocedures voor AI-incidenten (Ai Forensics Ir)

Eerste-responsprocedures voor AI-beveiligingsincidenten: wat onmiddellijk te behouden, wat te isoleren, checklists voor initiële beoordeling, en escalatiecriteria voor AI-specifieke incidenten.

Triageprocedures voor AI-incidenten

De eerste 30 minuten van een AI-incident bepalen of je kritiek bewijs behoudt of verliest, de schade inperkt of laat verspreiden, en de juiste responders identificeert of tijd verspilt met het verkeerde team. Deze pagina definieert de eerste-responsprocedures die specifiek zijn voor AI-systemen.

De eerste 30 minuten

AI-incidenten hebben een smal venster voor bewijsbehoud. In tegenstelling tot traditionele systemen, waar schijfimages en netwerkcaptures behouden blijven, is AI-bewijs vaak vluchtig: inferentielogs kunnen roteren, modelversies kunnen worden bijgewerkt, en contextvensters van conversaties worden gewist wanneer sessies eindigen.

Triageworkflow

1. 1

   Bevestig en zet een tijdstempel

   Registreer de exacte tijd (UTC) van detectie, de bron van de waarschuwing (geautomatiseerd systeem, gebruikersmelding, interne ontdekking), en je identiteit als triage-responder. Dit start de incidenttijdlijn.

   Incident ID: AI-IR-2026-0042
   Detected: 2026-03-15T14:32:07Z
   Source: Safety classifier alert (Llama Guard)
   Triage Responder: [Name]
   

2. 2

   Behoud vluchtig bewijs

   Voordat je enige andere actie onderneemt, leg je bewijs vast dat verloren kan gaan. In volgorde van vluchtigheid:

   1. Actieve conversatietoestand -- als het incident een lopende conversatie betreft, leg dan de volledige conversatiegeschiedenis vast, inclusief de systeemprompt, alle gebruikersberichten, alle assistent-reacties, en eventuele registraties van tool-aanroepen
   2. Huidige modelconfiguratie -- registreer de exacte modelversie, de hash van de systeemprompt, temperature, samplingparameters, en eventuele actieve adapters of plugins
   3. Inferentielogs -- zorg ervoor dat de inferentielogging niet op het punt staat te roteren; verleng de bewaartermijn indien mogelijk
   4. Toestand van de RAG-index -- als ophalen betrokken is, maak dan een momentopname van de huidige documentindex en recente ophaallogs
   5. Toestand van tool-aanroepen -- leg eventuele aanstaande of recente tool-invocaties, hun parameters en resultaten vast

   Zie Bewijsbehoud voor gedetailleerde behoudprocedures.

3. 3

   Beoordeel de omvang en inperkingsbehoefte

   Bepaal of het incident geïsoleerd is (enkele conversatie, enkele gebruiker) of systemisch (treft alle gebruikers, misbruikt een fout in het model of de systeemprompt).

   Vraag	Bij ja → Implicatie
   Kan elke gebruiker dit triggeren?	Systemisch -- overweeg onmiddellijke inperking
   Vereist het specifieke voorafgaande context?	Mogelijk geïsoleerd -- ga door met beoordelen
   Wordt het model actief geëxploiteerd?	Dringende inperking nodig
   Ondernam het model acties in de echte wereld (tool-aanroepen, API-verzoeken)?	Beoordeel de downstream-impact onmiddellijk
   Wordt er gevoelige data blootgesteld?	Datalekprocedures kunnen van toepassing zijn

4. 4

   Implementeer initiële inperking

   Neem op basis van de omvangsbeoordeling de minimale inperkingsactie die de bloeding stelpt zonder bewijs te vernietigen.

   Inperkingsactie	Wanneer te gebruiken	Bewijsimpact
   Beëindig specifieke sessie	Geïsoleerd tot één conversatie	Behoudt alle andere sessies
   Voeg invoerfilter toe voor bekende payload	Specifiek aanvalspatroon geïdentificeerd	Lage impact; aanvaller kan zich aanpassen
   Schakel uitgebreide logging in	Meer data nodig om de omvang te beoordelen	Geen negatieve impact
   Verminder modelcapaciteiten	Toolmisbruik gedetecteerd	Beperkt de functionaliteit maar behoudt het model
   Schakel over naar fallback-model	Systemische kwetsbaarheid in het primaire model	Behoudt het primaire model voor analyse
   Haal endpoint offline	Actieve data-exfiltratie of schadelijke uitvoer	Maximale verstoring, maximale inperking

5. 5

   Voer een initiële ernstbeoordeling uit

   Pas het Ernstkader toe met de beschikbare informatie. Een initiële score op basis van gedeeltelijke informatie is beter dan geen score -- het stuurt escalatiebeslissingen aan.

   Registreer je initiële beoordeling, zelfs als deze onvolledig is:

   ## Initial Severity Assessment (Preliminary)
   - Model Integrity: [score] - [brief justification]
   - Data Exposure: [score or "Unknown - assessing"]
   - Blast Radius: [score] - [brief justification]
   - Reversibility: [score or "Unknown - assessing"]
   - Exploitability: [score] - [brief justification]
   - Preliminary Severity: [level]

6. 6

   Classificeer en escaleer

   Pas de Incidentclassificatie-taxonomie toe en volg de Escalatiepaden op basis van ernst en categorie.

Wat onmiddellijk te behouden

AI-systemen produceren bewijstypen die niet bestaan in traditionele IR. Het missen van een van deze tijdens de triage kan een incident onmogelijk te onderzoeken maken.

Checklist voor kritiek bewijs

Commando's voor bewijsbehoud

Voor veelvoorkomende AI-deploymentpatronen leggen deze commando's kritieke vluchtige toestand vast:

# Capture current model deployment state
kubectl get deployment ai-model-service -o yaml > evidence/deployment_state.yaml
kubectl logs ai-model-service --since=1h > evidence/inference_logs.txt
 
# Snapshot the system prompt from config
kubectl get configmap ai-system-prompt -o jsonpath='{.data}' > evidence/system_prompt.json
 
# Export recent conversation logs (application-specific)
# Adjust the query to your conversation storage
psql -c "COPY (SELECT * FROM conversations
  WHERE created_at > NOW() - INTERVAL '2 hours')
  TO STDOUT WITH CSV HEADER" > evidence/recent_conversations.csv
 
# Capture model version info
curl -s http://model-service:8080/health | jq '.model_version' > evidence/model_version.json

Veelvoorkomende triagefouten

Fout 1: Proberen te reproduceren voordat je behoudt

Het sturen van prompts naar het model om de kwetsbaarheid te "testen" voordat het bewijs is behouden, kan:

• De conversatietoestand in stateful systemen wijzigen
• Logrotatie triggeren als het systeem op volume gebaseerde rotatie heeft
• De aanvaller waarschuwen als deze het systeem monitort
• Het gedrag van het model veranderen in few-shot- of in-context-learning-opstellingen

Fout 2: De systeemprompt onmiddellijk bijwerken

Het instinct om de systeemprompt onmiddellijk te "repareren" is begrijpelijk maar voorbarig:

• Je verliest de versie die werd geëxploiteerd
• Je kunt niet beoordelen of de fix daadwerkelijk werkt zonder het origineel
• Er kunnen andere aanvalspaden bestaan die de promptupdate niet aanpakt
• De bijgewerkte prompt kan nieuwe kwetsbaarheden introduceren

Fout 3: Een systemisch probleem als geïsoleerd behandelen

Een enkele gebruikersmelding van een jailbreak kan wijzen op een kwetsbaarheid die alle gebruikers kunnen misbruiken. Voordat je een incident als geïsoleerd classificeert:

• Doorzoek logs op vergelijkbare patronen van andere gebruikers
• Test of de aanval conversatiespecifieke context vereist
• Controleer of de kwetsbaarheid in de systeemprompt zit (systemisch) of in de conversatiestroom (mogelijk geïsoleerd)

Fout 4: Downstream-effecten negeren

Als het AI-model externe tools aanriep, naar databases schreef, e-mails verstuurde, of API-verzoeken deed tijdens het incident, strekt de blast radius zich uit voorbij het model zelf. Triage moet omvatten:

• Het identificeren van alle tool-aanroepen die tijdens het incidentvenster zijn gedaan
• Het beoordelen of downstream-systemen hebben gehandeld op basis van gecompromitteerde modeluitvoer
• Het bepalen of downstream-uitvoer moet worden teruggeroepen of teruggedraaid

Vragenlijst voor initiële beoordeling

Gebruik deze vragenlijst om het initiële triagegesprek met de persoon die het incident meldt te structureren.

Triage-beslismatrix

Gebruik na de initiële beoordeling deze matrix om het juiste responsniveau te bepalen.

Gerelateerde onderwerpen

• Ernstkader -- gedetailleerde scoring voor de initiële ernstbeoordeling
• Escalatiepaden -- waar te routeren na triage
• Bewijsbehoud -- gedetailleerde procedures voor bewijsbehoud
• Loganalyse -- onderzoekstechnieken na de triage

Referenties

• "NIST SP 800-61 Rev. 3: Computer Security Incident Handling Guide" - NIST (2024) - Triage procedures adapted for AI context
• "SANS Incident Handler's Handbook" - SANS Institute (2024) - First-responder procedures for security incidents
• "Incident Response in the Age of AI" - Microsoft Security (2025) - AI-specific triage considerations