Incident response draaiboek afgestemd op NIST SP 800-61r3 en NIS2

Een praktisch incidentresponsedraaiboek gebaseerd op NIST SP 800-61r3 en NIS2, met rollen, een ernstniveaumatrix, bewijsregels en een duidelijk pad van detectie tot naincidentbeoordeling.

Dit draaiboek is voor organisaties die een werkbaar incidentresponseproces nodig hebben. Dit omvat NIS2-entiteiten, bedrijven die zich voorbereiden op ISO/IEC 27001-certificering en MSP's die de respons voor hun klanten uitvoeren. Het volgt de structuur van NIST SP 800-61r3 en houdt de NIS2-vereisten in het oog. Aan het einde heb je de schets van een incidentresponseplan, een ernstmatrix, een rollenlijst en de bewijsregels die je responders nodig hebben. Regelgevingsrapportage heeft een eigen draaiboek, waarnaar we op de besluitvormingspunten linken.

Voordat je begint

NIST's derde revisie kijkt anders tegen incidentrespons aan. Het is niet langer een zelfstandige cyclus. Het maakt deel uit van het algehele beheer van cyberbeveiligingsrisico's. In de CSF 2.0 Functions ondersteunen Govern, Identify en Protect de voorbereiding. Detect, Respond en Recover vormen de respons zelf. De Improvement-categorie (ID.IM) verzamelt lessen uit elke Function op elk moment, niet alleen nadat een incident is afgerond^[1]. Als je al NIST CSF 2.0 gebruikt, moet je incidentresponsplan naar die outcomes verwijzen.

Noem de kernrollen en een vervanger voor elk:

Rol	Verantwoordelijkheid	Typische houder
Incidentmanager	Verklaart het incident, stelt de ernst vast, leidt de bridge call, beheert de tijdlijn en het besluitenlogboek	Security lead, SOC-manager of MSP-lead
Technisch verantwoordelijke	Voert analyse, inperking en uitroeiing uit en stuurt de IT- en cloudteams aan	Senior engineer of externe DFIR-provider
Juridisch adviseur	Adviseert over aansprakelijkheid, contracten, wetshandhaving en privilege, en beoordeelt externe verklaringen	Interne juridisch adviseur of ingehuurde firma
DPO	Beoordeelt de impact op persoonsgegevens en leidt de AVG-inbreukbeslissing	Functionaris voor gegevensbescherming
Communicatielead	Verzorgt interne updates, klantberichten en mediaverzoeken	Communicatie- of marketingmanager
Uitvoerende sponsor	Keurt beslissingen met grote impact goed (services uitschakelen, externe partijen inschakelen, uitgaven)	Lid van het bestuursorgaan

NIST noemt ook HR, facilities, asset owners en derde partijen zoals MSSPs en cloud providers. Hun rollen moeten in contracten worden vastgelegd^[1].

Fase 1: De voorbereiding

Voorbereiding bepaalt hoe de andere fasen verlopen. NIS2 artikel 21, lid 2, onder b) noemt incident handling als een vereiste maatregel^[3]. Voor digitale infrastructuur en digitale dienstverleners gaat de bijlage bij Uitvoeringsverordening (EU) 2024/2690 in detail. Deze behandelt een incident handling-beleid, monitoring en logging, event reporting, event assessment en classificatie, incident response en post-incident reviews^[4]. Entiteiten in andere sectoren kunnen dit als een goed onderbouwde benchmark gebruiken.

• Keur een incident response-beleid en plan op managementniveau goed.
• Houd een actuele asset inventory en netwerkdiagrammen bij, met de kritieke services gerangschikt.
• Zorg ervoor dat logs gecentraliseerd, tijdsgesynchroniseerd en lang genoeg bewaard zijn voor onderzoek (minstens 90 dagen online is een verstandige baseline).
• Regel out-of-band communicatie, zoals een aparte chat of telefoonbrug, voor het geval e-mail en je identity provider zijn gecompromitteerd.
• Sluit een retainerovereenkomst met een DFIR-provider, controleer wat je cyberverzekering vereist, en bewaar de contactlijst offline.

Fase 2: Detectie en triage

Events komen uit veel bronnen: EDR-waarschuwingen, SIEM-regels, gebruikersrapporten, leveranciers, de nationale CSIRT en soms de aanvaller. Triage bepaalt snel of een event een incident is en hoe ernstig het is.

• Open een ticket voor elk event en noteer het moment van eerste detectie.
• Bevestig het incident: zoek naar ondersteunende logs en sluit een false positive of gepland onderhoud uit.
• Bepaal de initiële scope: welke accounts, hosts, gegevens en services zijn betrokken.
• Verklaar een incident wanneer aan de criteria is voldaan. Het moment van bewustzijn start de regelgevingsklokken.

Fase 3: Ernst bepalen en mobiliseren

Een gedeelde ernstsschaal vertelt iedereen hoeveel mensen je moet bellen, hoe snel, en wie geïnformeerd moet worden. Pas de matrix hieronder aan je services en risicotolerantie aan. Behandel het als een interne schaal: juridische betekenis onder NIS2, DORA of de AVG is een afzonderlijke toets.

Ernst	Typische criteria	Respons	Escalatie
SEV-1 Kritiek	Kritieke service down of in gevaar; bevestigde data-exfiltratie; ransomware; aanvaller met domeinbeheerdersrechten	Bridge call binnen 30 minuten; 24/7 tot indamming	Executive sponsor, juridisch en DPO onmiddellijk; controleer meldplicht
SEV-2 Hoog	Gecompromitteerd privileged account; malware op meerdere hosts; persoonsgegevens waarschijnlijk blootgesteld	Bridge call binnen 2 uur; uitgebreide uren	Incident manager, juridisch en DPO dezelfde dag; controleer reporting
SEV-3 Middel	Eén endpoint of gebruikersaccount gecompromitteerd en contained; geen gevoelige gegevens betrokken	Binnen één werkdag	Security lead; wekelijks overzicht
SEV-4 Laag	Geblokkeerde aanval, beleidsovertreding, phishing gerapporteerd maar niet geklikt	Standaardwachtrij	Maandelijkse statistieken

Voor SEV-1 en SEV-2 start de incidentmanager meteen met de rapportagebeslissing. Volg het draaiboek incidentmelding voor NIS2, DORA, CRA en AVG, omdat de NIS2 vroegtijdige waarschuwing binnen 24 uur na bewustwording moet worden ingediend^[3].

Fase 4: Containment en bewijsbewaring

Containment stopt de verspreiding en geeft tijd. Bewijsbewaring zorgt ervoor dat je nog steeds kunt achterhalen wat er is gebeurd en een verzekeringsclaim of klacht bij de politie kunt ondersteunen. Verzamel vluchtige gegevens voordat je systemen wijzigt waar je kunt. RFC 3227 stelt de volgorde van volatiliteit vast: geheugen en netwerkstatus gaan voor schijf.^[5].

• Korte-termijncontainment: isoleer hosts via EDR in plaats van ze uit te schakelen, blokkeer kwaadaardige IP's en domeinen, en schakel gecompromitteerde accounts uit en trek hun sessies in.
• Bewijs: leg geheugen en schijfafbeeldingen van sleutelsystemen vast, exporteer cloud- en identity-logs voordat ze overschrijven, en hash elk artefact.
• Chain of custody: noteer voor elk item wie het heeft verzameld, wanneer, hoe, waar het is opgeslagen en elke overdracht.
• Langetermijncontainment: segmenteer netwerken, roteer credentials in prioriteitsvolgorde, en houd systemen die moeten blijven draaien onder nauw toezicht.

Fase 5: Bedreiging uitschakelen

Bij uitschakeling verwijder je de voetafdruk van de aanvaller, en je bent pas klaar als je de scope begrijpt. Als je uitschakelt voordat je de scope begrijpt, keert de aanvaller terug via een persistentiemechanisme dat je niet hebt gezien.

• Identificeer de initiële toegangsvector en elk persistentiemechanisme: accounts, geplande taken, OAuth-toekenningen, webshells, externe tools.
• Verwijder malware en ongeautoriseerde accounts, en sluit de kwetsbaarheid die is misbruikt.
• Stel credentials in een geplande volgorde opnieuw in: eerst bevoorrechte en serviceaccounts, vervolgens het Kerberos KRBTGT-account twee keer waar Active Directory is betrokken.
• Scan het hele systeem op bekende indicatoren van compromittering voordat je uitschakeling als voltooid verklaart.

Fase 6: Services veilig herstellen

Herstel services in de volgorde van je analyse van bedrijfsimpact, vanuit bekende goede bronnen, met extra monitoring.

• Herstel vanuit back-ups waarvan je hebt geverifieerd dat ze schoon zijn. Controleer de hersteldatum aan de hand van de vroegste bekende activiteit van de aanvaller.
• Bouw kritieke systemen opnieuw op vanuit geharde images waar je niet zeker kunt zijn van hun integriteit.
• Vraag de eigenaren van assets om functionaliteit en gegevensintegriteit te valideren voordat je opnieuw opent voor gebruikers en klanten.
• Houd de verhoogde detectieregels minstens 30 dagen actief.

Fase 7: Beoordelen en verbeteren

De bijlage bij Uitvoeringsverordening 2024/2690 verwacht post-incident reviews die de hoofdoorzaak en de geleerde lessen identificeren. Het verwacht ook dat de resultaten terugvloeien in beveiligingsmaatregelen^[4]. NIST r3 beschouwt verbetering als continu in plaats van een afsluitende fase^[1].

• Houd voor elk SEV-1 en SEV-2 incident binnen twee weken na afsluiting een blameless review.
• Herbouw de tijdlijn, identificeer wat wel en niet werkte, en wijs acties toe aan eigenaren met deadlines.
• Werk het plan, de draaiboeken, de detectieregels en het risicoregister bij.
• Zorg ervoor dat de feiten overeenkomen met de definitieve regelgevingsrapporten.

De bijbehorende template bevat een volledig incidentresponsplan met rolkaarten, de ernstigheidsmatrix, communicatiesjablonen, een bewijsregister en een formulier voor beoordeling na het incident. In Secrato worden het goedgekeurde plan en oefenrapporten eenmalig opgeslagen als bewijs voor de incidentbeheer-controls, en dat ene resultaat telt voor NIS2, CyFun en ISO/IEC 27001.

Hoe dit aansluit op andere frameworks

ISO/IEC 27001:2022 bijlage A controls 5.24 tot 5.28 sluiten bijna één-op-één aan bij de fasen hierboven: planning, beoordeling, reactie, leren en bewijsverzameling. CyFun omvat incidentresponseplanning, analyse en verbetering onder zijn Respond- en Recover-functies. DORA artikel 17 vereist dat financiële entiteiten een gedocumenteerd ICT-gerelateerd incidentbeheerproces hebben met vroegtijdige waarschuwingsindicatoren en procedures voor het registreren, classificeren en escaleren van incidenten. Een goed uitgevoerd plan kan het bewijs voor allemaal leveren, en voor NIS2.

Veelgestelde vragen

Is NIST SP 800-61r2 nog geldig?

NIST stelt dat Revision 3 Revision 2^[2] vervangt. Je kunt de praktische fasering behouden, maar zorg dat de verwijzingen en governance in je plan aansluiten op r3 en CSF 2.0.

Hebben we voor elk type incident een apart plan nodig?

Nee. Houd één plan voor het proces en de rollen, en voeg korte draaiboeken toe voor veelvoorkomende scenario's zoals ransomware, phishing en business email compromise. Elk draaiboek behandelt alleen wat afwijkt van het hoofdplan.

Moeten we besmette machines uitschakelen?

Meestal niet meteen. Een machine isoleren via het netwerk of EDR stopt de verspreiding en houdt het bewijs in het geheugen intact. Schakel alleen uit als isolatie niet mogelijk is en de schade nog steeds toeneemt.

Hoe vaak moeten we het plan testen?

Minstens eenmaal per jaar met een tafeloefening waarbij het management betrokken is, en opnieuw na grote wijzigingen. Gebruik realistische scenario's, inclusief één waarin e-mail en de identiteitsprovider niet beschikbaar zijn.