Hoe bouw je een incident response plan dat werkt?

De meeste organisaties falen niet bij incident response omdat ze geen tools hebben. Ze falen omdat niemand vooraf heeft afgesproken wie wat doet, en het eerste echte incident wordt een vergadering in plaats van een respons.

Begin met de fases, niet het playbook

NIST SP 800-61 legt vier fases uit: preparation, detection and analysis, containment/eradication/recovery, en post-incident activity. Die volgorde is belangrijk. Teams willen meteen naar containment springen omdat het productief aanvoelt, maar als je het preparation werk niet hebt gedaan, ken je je eigen netwerk niet goed genoeg om iets schoon in te dammen.

Preparation betekent asset inventories die actueel zijn, niet het spreadsheet van 2022. Het betekent dat je je log retention window kent (als het 7 dagen is en de aanvaller had 30 dagen dwell time, ben je de timeline al kwijt). Het betekent pre-staged forensic tooling — Velociraptor, KAPE, of zelfs een gedocumenteerde tar/dd procedure voor disk images — zodat niemand tools downloadt op een gecompromitteerde host tijdens een actief incident.

Definieer severity levels voordat je ze nodig hebt

Een SEV1 (actieve data exfiltration, ransomware detonation, domain admin compromise) vereist een ander respons dan een SEV3 (geïsoleerde malware op één unprivileged workstation). Schrijf dit op als een matrix: impact vs. scope vs. confidence. Wijs elke severity een vereiste response time en een escalation path toe. Als je incident commander voor een SEV1 dezelfde persoon is die elke $500 inkooporder moet goedkeuren, heb je een bottleneck in je eigen noodproces ingebouwd.

De incident commander rol is niet optioneel

Één persoon leidt het incident. Niet standaard de meest senior engineer — de persoon het best geschikt om te coördineren, te delegeren, en containment keuzes onder druk te maken. Deze persoon raakt niet per se een toetsenbord aan tijdens de respons; ze volgen de timeline, beheren communicatie met legal en leadership, en bepalen wanneer het moment aanbreekt om een segment af te sluiten of een systeem offline te halen.

Zonder deze rol krijg je vijf mensen SSH'd in dezelfde box, geen van hen praat met elkaar, en niemand legt volatile memory vast voordat iemand de machine opnieuw opstart om "te zien of het het oplost".

Containment keuzes die echt uitmaken

De moeilijkste beslissing in de meeste incidents is: nu isoleren, of nog even observeren om het bereik te begrijpen? Network access te snel afsnijden waarschuwt een aanvaller die nog lateraal beweegt en vernietigt je kans hun volgende stap te zien. Te lang wachten laat ransomware shares afmaken versleutelen.

Een redelijk midden: gebruik network segmentation en EDR isolation (CrowdStrike, Defender for Endpoint, SentinelOne ondersteunen dit allemaal) om een host af te snijden van lateral movement terwijl het aanstaat voor memory capture. Volledig afsluiten moet een laatste redmiddel zijn — het doodt volatile evidence en kan voor ransomware cases anti-forensic behavior triggeren die in enkele payloads ingebakken is.

Logging gaps die je spijt zullen doen tijdens, niet daarvoor

Windows Event Log defaults zijn niet genoeg. Als je Sysmon niet gedeployed hebt met een fatsoenlijke config (SwiftOnSecurity's of Olaf Hartong's baseline configs zijn een solide startpunt), zul je process trees uit fragmenten reconstrueren. Aan de network kant hebben NetFlow of Zeek logs meer gewicht dan de meeste orgs beseffen totdat ze moeten antwoord geven