Arcana IR-documentatie · Nederlandse vertaling English

Template Incident Response Plan (IRP)

Documentbeheer

Kenmerk Waarde Datum
Documentnaam [Titel invullen] [Datum invullen]
Versie [Versienummer invullen] [Datum invullen]
Eigenaar [Eigenaar/team invullen] [Datum invullen]
Status [Draft/Approved/Retired] [Datum invullen]
Volgende reviewdatum [Volgende reviewdatum invullen] [Datum invullen]
Goedkeuringen [Goedkeurder(s) invullen] [Datum invullen]
Wijzigingsoverzicht Eerste versie [Datum invullen]

1. Doel & scope

Doel

Richtlijn: Een verklaring waarom het IRP bestaat en wat het wil bereiken.

Voorbeeld:

Dit Incident Response Plan (IRP) legt het beleid en de procedures vast waarmee [naam organisatie] tijdig en effectief kan reageren op computerbeveiligingsincidenten die gevoelige gegevens of persoonsgegevens (PII) in gevaar kunnen brengen, of die kunnen leiden tot verstoring van de bedrijfsvoering of het halen van de doelen van de organisatie.

Scope

Richtlijn: Leg vast waarop dit IRP van toepassing is en waarop NIET. Baken duidelijk af welke systemen, omgevingen en organisatiegrenzen onder dit plan vallen.

Voorbeeld:

Dit IRP is van toepassing op alle informatiesystemen binnen de operationele grens van de organisatie. Het omvat:

Dit IRP omvat niet:

2. Missie & achterban van het Security Incident Response Team (SIRT)

2.1 Missie

Richtlijn: Leg het hoofddoel van het IR-team vast. Leg uit waarom het team bestaat, voor wie het werkt en voor welke kernresultaten het verantwoordelijk is.

Voorbeeld:

De missie van het Security Incident Response Team (SIRT) van [naam organisatie] is de organisatie, haar medewerkers en haar klanten te beschermen tegen beveiligingsdreigingen. Dat doet het team door een hoge operationele paraatheid te onderhouden, snel en gecoördineerd te reageren om risico's te beheersen en de impact voor klanten te beperken, en door continu te verbeteren met grondige post-incidentreviews die correctieve acties opleveren en toekomstige incidenten voorkomen.

2.2 Achterban (constituency)

Richtlijn: Leg duidelijk vast welke gebruikers, systemen en entiteiten het Security Incident Response Team moet beschermen.

Het SIRT van [naam organisatie] werkt voor een tweeledige achterban:

3. Incident response-beleid

Richtlijn: Link naar het overkoepelende incident response-beleid van je organisatie. Het IR-beleid is het door de directie goedgekeurde document dat het mandaat, de bevoegdheden en de governancestructuur voor incident response vastlegt. Dit IRP is de operationele uitwerking van dat beleid.

Heeft je organisatie nog geen apart IR-beleid, verwijs dan naar het betreffende deel van het bredere informatiebeveiligingsbeleid of het securityprogramma dat incident response-activiteiten mandateert.

Voorbeeld: Het Security Incident Response-beleid van [naam organisatie], opgesteld op [datum], staat op [URL IR-beleid]

4. Definities

Richtlijn: Definieer de belangrijkste begrippen uit het plan, zodat alle stakeholders dezelfde taal spreken. Dat voorkomt onduidelijkheid in stressvolle incidentsituaties.

Begrip Definitie
Security Incident Response Team (SIRT) Het team dat namens de organisatie verantwoordelijk is voor het detecteren van, reageren op en herstellen van beveiligingsincidenten
Incident Response Plan (IRP) Dit document: het formele plan met de processen, rollen en procedures van het SIRT voor het afhandelen van beveiligingsincidenten
Event (gebeurtenis) Een voorval in een informatiesysteem of netwerk dat de bedrijfsvoering negatief kan beïnvloeden, maar nog niet als incident is bevestigd
Security-incident Een bevestigde of vermoede gebeurtenis die leidt tot een opzettelijke negatieve impact op de vertrouwelijkheid, integriteit of beschikbaarheid van gegevens of diensten van de organisatie
Aanvalsvector De methode of het middel waarmee een threat actor zich ongeautoriseerd toegang verschaft
Indicators of Compromise (IOC) Artefacten of bewijs die erop wijzen dat een incident heeft plaatsgevonden of nog gaande is
Kwetsbaarheid Een zwakte in een systeem, proces of maatregel die door een dreigingsbron kan worden misbruikt
Dreiging Elke omstandigheid, gebeurtenis of actor die de bedrijfsvoering, bedrijfsmiddelen of medewerkers schade kan berokkenen
Dreigingsbron De intentie en methode gericht op het misbruiken van een kwetsbaarheid

5. Rollen & verantwoordelijkheden

Richtlijn: Leg de organisatiestructuur van het SIRT vast, zowel in de voorbereidingsfase als tijdens actieve incidenten. Beschrijf per rol de verantwoordelijkheden, bevoegdheden en escalatiepaden. Noem zowel de primaire personen als hun vervangers, zodat de continuïteit gewaarborgd is. Deze sectie behandelt twee situaties:

  1. Voorbereidingsfase: wie zorgt voor paraatheid, training, tooling en het plan zelf
  2. Tijdens een incident: wie stuurt aan, onderzoekt, communiceert en neemt besluiten

5.1 Structuur van het SIRT

Richtlijn: Voeg een organogram met de hiërarchie van het IR-team in, of verwijs ernaar.

5.2 Rollen in de voorbereidingsfase

Rol Verantwoordelijkheden
Executive sponsor / CISO Strategisch eigenaarschap, budget, escalatiebevoegdheid, rapportage aan de raad van bestuur
IR-programmamanager Onderhoudt het IRP, coördineert oefeningen, borgt compliance, bewaakt de paraatheid van het team
IR-teamleads Ontwikkelen en onderhouden playbooks, verdelen het werk, doen kwaliteitscontrole, begeleiden analisten
IR-analisten (on-call) Monitoren alerts, doen de eerste triage, escaleren bevestigde incidenten, documenteren bevindingen
IR-analisten (vast) Ontwikkelen en onderhouden playbooks, doen onderzoeken, bouwen automatiseringen, verbeteren tooling, voeren projecten uit
Security Operations (SOC) 24/7 triage van alerts en phishingmeldingen; escaleren events naar IR
Systeembeheerders Voeren opgedragen mitigerende acties uit, leveren vakinhoudelijke kennis (SME), werken samen met IR
Alle gebruikers Melden verdachte activiteit, werken mee met IR, volgen het beveiligingsbeleid

5.3 Rollen tijdens een incident

Rol Verantwoordelijkheden
Incident Manager Stuurt de hele incident response aan, verdeelt de werkstromen, bewaakt de werklast, neemt kernbesluiten, stuurt de communicatie
IR-analisten Voeren onderzoeks- en hersteltaken uit, documenteren de voortgang, dragen bij aan de post-incidentreview
Juridisch adviseur (Legal) Beoordeelt meldplichten, beoordeelt externe communicatie, schakelt zo nodig externe advocaten in
Communicatieteam Stelt interne en externe communicatie op, stemt af met Legal en het management
Product- en engineeringteams SME's voor de getroffen systemen, voeren containment-, eradication- en recovery-acties uit
Directie SME voor de bedrijfsimpact, wordt geraadpleegd bij besluiten met grote impact

5.4 Opvolgingsvolgorde

Richtlijn: Leg de opvolgingsvolgorde van de belangrijkste besluitvormers vast, zodat de continuïteit gewaarborgd is als de primaire personen niet beschikbaar zijn. Vervangers moeten getraind zijn en weten dat zij stand-by staan.

6. Toepasselijke wetten, regelgeving en standaarden

Richtlijn: Noem alle wetten, regels, frameworks en interne beleidsstukken die richting geven aan je incident response-activiteiten. Zo sluit het IRP aan op de compliance-eisen en kunnen auditors de herkomst van eisen herleiden. Stem dit af op je rechtsgebied en sector.

Voorbeelden van toepasselijke wetgeving:

Voorbeelden van toepasselijke standaarden en richtlijnen:

7. Levenscyclus van incident response

7.1 Voorbereiding

Richtlijn: Beschrijf hoe de organisatie zich op incidenten voorbereidt voordat ze plaatsvinden: trainingsprogramma's, oefeningen, aanschaf van tooling, teamstructuur en preventieve maatregelen. Het doel is het aantal incidenten en hun impact te beperken en tegelijk paraat te zijn.

Training van medewerkers

Richtlijn: Werk de trainingseisen voor IR-medewerkers uit. Voorbeelden:

  • Rolspecifieke IR-training (binnen de eerste 30-90 dagen)
  • Training in het managen van security-incidenten
  • Meelopen en mentorschap voor nieuwe medewerkers
  • Security awareness-training voor alle medewerkers
  • Professionele certificeringen, betaald uit het jaarlijkse opleidingsbudget van de organisatie

Tests en oefeningen

Richtlijn: Beschrijf welke soorten IR-oefeningen de organisatie houdt en hoe vaak. Minimaal één oefening per jaar. Mogelijke soorten:

  • Red team-operaties: volledige aanvalssimulaties die detectie en respons testen
  • Tabletop-oefeningen: begeleide scenariodiscussies om besluitvorming en coördinatie te testen
  • Purple team-oefeningen: gezamenlijke aanvals- en verdedigingsoefeningen om detecties te verbeteren

Leg vast hoe tekortkomingen uit oefeningen worden gevolgd en opgelost.

Incident response-retainer

Richtlijn: Beschrijf eventuele IR-retainerovereenkomsten met derden: de leverancier, de looptijd, vooruitbetaalde uren, de activeringsprocedure, de verwachte respons-SLA's en wie de retainer mag inroepen.

7.2 Detectie & melding

Richtlijn: Beschrijf hoe mogelijke incidenten worden gedetecteerd en bij het SIRT gemeld: geautomatiseerde detectie, handmatige meldkanalen en externe meldroutes.

Bronnen van events

Richtlijn: Noem alle kanalen waarlangs security-events aan het licht kunnen komen. Voorbeelden:

  • SIEM-alerts en geautomatiseerde detecties
  • Bevindingen uit threat hunts
  • Meldingen van medewerkers (chatkanalen, servicedesktickets, e-mail)
  • Meldingen van klanten via supportportalen
  • Meldingen van externe partners of leveranciers
  • Programma's voor het melden van kwetsbaarheden (bug bounty)
  • Threat intelligence-feeds en openbaar onderzoek

Interne meldprocedures

Richtlijn: Beschrijf hoe alle medewerkers vermoedelijke security-events horen te melden. Noem de meldkanalen (bijv. een vast Slack-kanaal, ticketsysteem, e-mailadres) en voorbeelden van meldenswaardige events:

  • Automatische alerts of foutmeldingen die op een mogelijke compromittering wijzen
  • Waarnemingen van afwijkend of onverwacht systeemgedrag
  • Aanwijzingen voor malware, phishing of ongeautoriseerde toegang
  • Meldingen die van externe partijen binnenkomen

Incidentclassificatie en severity-matrix

Richtlijn: Leg vast hoe events worden getrieerd en in severity-niveaus worden ingedeeld. Geef een matrix die kenmerken van een incident koppelt aan een severity. De matrix houdt rekening met:

  • Welke beveiligingsaspecten geraakt zijn (vertrouwelijkheid, integriteit, beschikbaarheid)
  • Het getroffen domein (impact op klanten, impact op de organisatie)
  • Waargenomen acties van de threat actor (verkenning, exploitatie, persistence, lateral movement, exfiltratie)
  • Gevolgen voor privacy en juridische gevolgen
  • Reputatieschade

Voorbeeld severity-matrix:

Severity Omschrijving Kenmerken
0 Een kritiek security-incident met maximale impact op de organisatie <ul><li>Hoge impact op V, I, B</li><li>Hoge impact op klanten</li><li>Hoge impact op de organisatie</li><li>Privacy-impact</li><li>Mogelijk reputatieschade</li><li>Waargenomen acties<ul><li>lateral movement</li><li>data-exfiltratie</li><li>vernietiging van data</li></ul></ul>
1 Een groot security-incident met zeer hoge impact <ul><li>Middelhoge tot hoge impact op V, I, B</li><li>Middelhoge tot hoge impact op klanten</li><li>Middelhoge tot hoge impact op de organisatie</li><li>Mogelijk privacy-impact</li><li>Mogelijk reputatieschade</li><li>Waargenomen acties<ul><li>persistence</li><li>C&C-activiteit</li><li>data-exfiltratie</li><li>lateral movement</li></ul></ul>
2 Een groot security-incident met gemiddelde impact <ul><li>Lage tot hoge impact op V, I, B</li><li>Lage tot middelhoge impact op klanten</li><li>Lage tot middelhoge impact op de organisatie</li><li>Mogelijk privacy-impact</li><li>Mogelijk reputatieschade</li><li>Waargenomen acties<ul><li>exploitatie</li><li>persistence</li><li>C&C-activiteit</li><li>data-exfiltratie</li><li>blootstelling van data</li></ul></ul>
3 Een klein security-incident met lage impact <ul><li>Lage tot hoge impact op V, I, B</li><li>Geen impact op klanten</li><li>Geen of lage impact op de organisatie</li><li>Geen privacy-impact</li><li>Geen reputatieschade</li><li>Waargenomen acties<ul><li>verkenning</li><li>aflevering (delivery)</li><li>exploitatie</li><li>blootstelling van data</li></ul></ul>

7.3 Analyse & triage

Richtlijn: Beschrijf het analyseproces nadat een event is getrieerd en toegewezen: hoe het team onderzoekt, de scope bepaalt, de root cause vaststelt en het incident classificeert. Kernactiviteiten:

  • Onderzoek op basis van hypotheses
  • Vaststellen van TTP's, root cause en attributie
  • Vastleggen van alle analyses in het systeem voor incidentregistratie
  • Escaleren van belangrijke bevindingen naar de Incident Manager
  • Classificeren van events (false positive, bevestigd incident, privacy-incident, enz.)

Verzamelen en bewaren van bewijsmateriaal

Richtlijn: Beschrijf de eisen voor het verzamelen en bewaren van bewijsmateriaal tijdens de analyse:

  • Eisen aan de chain of custody
  • Registratie van bewijsmateriaal (wat is verzameld, door wie, wanneer, waarvandaan)
  • Procedures voor forensische images en geheugendumps
  • Overwegingen over de juridische bruikbaarheid als bewijs

Respons op informatielekkage (spillage)

Richtlijn: Beschrijf hoe de organisatie omgaat met informatielekkage (gerubriceerde of gevoelige gegevens die op niet-geautoriseerde systemen terechtkomen). Neem stappen op voor:

  • Het verzamelen van informatie over de lekkage
  • Afstemming met Legal, engineering en andere betrokken teams
  • Het verwijderen van de gelekte informatie en het oplossen van de root cause
  • Onderzoek of de gelekte informatie is ingezien of misbruikt

7.4 Containment, eradication & recovery

Richtlijn: Beschrijf hoe bevestigde incidenten worden ingedamd, dreigingen worden verwijderd en de normale bedrijfsvoering wordt hersteld. Alle acties op getroffen systemen lopen via de Incident Manager, zodat er geen bewijsmateriaal verloren gaat en threat actors niet worden gealarmeerd. Leg waar van toepassing SLA's voor containment vast.

Containment

Richtlijn: Acties om verdere schade te voorkomen:

  • Containment op korte termijn (direct): noodmaatregelen om actieve schade te stoppen
  • Containment op lange termijn: blijvende maatregelen terwijl het onderzoek doorloopt
  • Bewaren van bewijsmateriaal tijdens de containment
  • Afstemming met systeemeigenaren vóór er wordt ingegrepen

Eradication

Richtlijn: Het volledig verwijderen van artefacten en toegang van de aanvaller uit de omgeving:

  • Verwijderen van malware, backdoors en ongeautoriseerde accounts
  • Patchen van misbruikte kwetsbaarheden
  • Resetten van credentials van gecompromitteerde accounts
  • Valideren dat alle steunpunten van de aanvaller zijn verwijderd

Recovery

Richtlijn: Het terugbrengen van getroffen systemen en diensten naar de normale bedrijfsvoering:

  • Procedures voor het herstellen en opnieuw opbouwen van systemen
  • Valideren van de integriteit van systemen voordat ze terug in productie gaan
  • Verscherpte monitoring op herhaling
  • Communicatie over het herstel van diensten aan de stakeholders

7.5 Post-incidentactiviteiten

Post-incidentreview (PIR)

Richtlijn: Beschrijf het proces voor post-incidentreviews. Een PIR is blameless (zonder schuldvraag) en is erop gericht de bijdragende oorzaken te begrijpen, het incident vast te leggen en acties door te voeren die detectie, respons, preventie en algemene paraatheid verbeteren. Leg vast:

  • Voor welke severity-niveaus een PIR verplicht is (aanbevolen: verplicht vanaf Sev 2)
  • Termijnen (SLA's) voor het opstellen en goedkeuren van de PIR
  • Wie de PIR schrijft en wie hem goedkeurt

Inhoudelijke eisen aan een PIR:

8. Communicatie & notificatie

Richtlijn: Leg vast hoe de organisatie tijdens incidenten intern en extern communiceert. Houd interne afstemming gescheiden van wettelijk verplichte externe meldingen.

Interne communicatie

Richtlijn: Beschrijf de afspraken voor communicatie over de status van een incident binnen de organisatie:

  • Wie per severity-niveau wordt geïnformeerd
  • Welke kanalen worden gebruikt (war room, chat, e-mail, conference calls)
  • Hoe vaak er statusupdates zijn
  • Classificatie van informatie (need-to-know)

Externe notificatie

Richtlijn: Beschrijf de verplichtingen en procedures voor het informeren van externe partijen:

  • Wettelijke meldplichten en termijnen (bijv. 72 uur onder de AVG, 1 uur voor FedRAMP)
  • Criteria en kanalen voor het informeren van klanten
  • Criteria voor het inschakelen van politie en justitie
  • Meldplichten richting CERT/CSIRT
  • Pr en omgang met de media

Inschakelen van externe teams

Richtlijn: Geef een tabel met teams die vaak worden ingeschakeld, intern en extern, met hoe je ze bereikt. Zo kun je ze tijdens een actief incident snel inschakelen.

Team / contact Hoe in te schakelen
Juridisch adviseur (Legal) [Kanaal/methode]
Communicatie/pr [Kanaal/methode]
IT/infrastructuur [Kanaal/methode]
Product engineering [Kanaal/methode]
HR / personeelszaken [Kanaal/methode]
Externe IR-retainer [Hotline/methode]
Toezichthouders [Meldportaal/methode]

9. Documentatie & omgang met bewijsmateriaal

Richtlijn: Leg de eisen vast voor het documenteren van alle acties, besluiten en communicatie rond een incident. Geef aan hoe met bewijsmateriaal wordt omgegaan, zodat de integriteit behouden blijft en eventuele juridische procedures worden ondersteund:

  • Eisen aan de inhoud van het incidentticket of -dossier (status, samenvatting, indicatoren, acties, impact, communicatie, vervolgstappen)
  • Structuur van het war room-document (tijdlijn, bewijsregister, indicatoren, relevante systemen, gecompromitteerde accounts)
  • Procedures voor de chain of custody
  • Bewaartermijnen voor bewijsmateriaal
  • Gevolgde standaarden voor digitaal forensisch onderzoek

10. Metrics & incidentclassificatie voor rapportage

10.1 Metrics

Richtlijn: Leg vast welke metrics uit incidentgegevens worden verzameld om de effectiviteit van het IR-programma te meten. Gebruik metrics om middelen te onderbouwen, trends te zien en verbeteringen te sturen. Voorbeelden:

  • Aantal alerts, onderzoeken en bevestigde incidenten
  • Mean time to detect (MTTD)
  • Mean time to contain (MTTC)
  • Mean time to resolve (MTTR)
  • Incidenten per ontdekkingsmethode, severity en categorie van falende maatregel
  • Percentage afgeronde PIR's en afgesloten correctieve acties

10.2 Incidentclassificatie voor rapportage

Richtlijn: Leg vast hoe incidenten worden geclassificeerd voor interne en externe rapportage. Dit voedt de metrics, trendanalyse en compliancerapportage. Neem categorieën op als:

  • Zekerheid: bevestigd / vermoed
  • Doelgerichtheid: opportunistisch / gericht / onbekend
  • Type threat actor: extern / intern / anders
  • Falende maatregel: accountcompromittering / malware / kwetsbaarheid / blootstelling van data / social engineering / incident bij een derde partij / enz.
  • Ontdekkingsmethode: SIEM-alert / interne melding / melding van klant / bug bounty / externe bron / threat hunt
  • Aanvalstechniek: waar mogelijk gekoppeld aan MITRE ATT&CK
  • Belangrijke data: identificatie, compromittering, containment, notificatie

11. Review & onderhoud

Richtlijn: Leg vast hoe het IRP zelf actueel blijft:

  • Jaarlijkse reviewcyclus en verantwoordelijke eigenaar
  • Aanleidingen voor tussentijdse updates (grote incidenten, organisatiewijzigingen, nieuwe regelgeving)
  • Auditprocedures en automatisering
  • Wijzigingslog en goedkeuringsproces
  • Verzendlijst voor nieuwe versies

12. Coördinatie & informatiedeling

Richtlijn: Beschrijf hoe de organisatie met externe partijen samenwerkt voor het delen van threat intelligence en wederzijdse ondersteuning:

  • Sectorale informatiedelingsgroepen (ISAC's, ISAO's)
  • Relaties met vertrouwde partners
  • Afstemming met overheid, politie en justitie
  • Regels voor het extern delen van informatie over dreigingen en kwetsbaarheden

13. Verspreiding & beschikbaarheid van het plan

Richtlijn: Beschrijf hoe het IRP wordt verspreid en beschikbaar gemaakt voor geautoriseerde medewerkers:

  • Waar het plan staat (beveiligde wiki, documentmanagementsysteem)
  • Wie toegang heeft
  • Offline- of back-upbeschikbaarheid bij grote storingen
  • Classificatieniveau van het document

14. Bijlagen