PB-019: Management van een major security incident
Documentbeheer
| Kenmerk | Waarde | Datum |
|---|---|---|
| Documentnaam | PB-019: Management van een major security incident | [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:
Een playbook voor leiding en coördinatie bieden bij Sev 0- of major security incidents. Gebruik dit playbook om de incidentleiding in te richten, de war room te runnen, meerdere technische playbooks te coördineren, de communicatie met directie en Legal te verzorgen, prioriteiten voor de recovery te stellen en besluiten bij te houden totdat het incident wordt afgeschaald of gesloten.
-
Scope:
Van toepassing op security-incidenten met grote impact op bedrijf, klanten, regelgeving, bedrijfsvoering of directie. Dit playbook vervangt de technische playbooks niet; het coördineert ze wanneer het incident de respons van één team of één scenario overstijgt.
2. Incidentidentificatie & criteria
Type incident: Management van een major security incident
Triggercondities:
Start dit playbook zodra een van de volgende situaties zich voordoet:
- Het incident wordt uitgeroepen tot Sev 0 of een vergelijkbaar major incident
- Meerdere technische playbooks moeten gelijktijdig onder één leidingstructuur lopen
- Kritieke bedrijfsdiensten, systemen voor klanten, de identity-infrastructuur, de cloud-tenant, back-ups of securitytooling worden wezenlijk geraakt
- Afstemming met directie, Legal, toezichthouders, klanten, publiek, leveranciers of politie/justitie is nodig
- De respons beslaat meerdere teams, regio's, diensten of herstelfasen
Severity-niveaus:
| Severity | Omschrijving |
|---|---|
| Sev 3 | N.v.t. |
| Sev 2 | Teamoverstijgend incident met wezenlijk risico, beperkte bedrijfsimpact of waarvan de directie op de hoogte moet zijn |
| Sev 1 | Major incident met bevestigde impact op bedrijf, klanten, data, productie, identity, cloud of recovery |
| Sev 0 | Impact op de hele organisatie, kritieke diensten of gereguleerde data, publieke impact, afpersing, destructieve impact of impact op crisisniveau |
3. Rollen & verantwoordelijkheden
- Incident Commander: Eigenaar van de leiding, de severity, prioriteiten, het vergaderritme, het besluitenlog, escalatie en besluiten over afschalen of sluiten.
- Plaatsvervangend Incident Commander: Houdt de actielijst bij, volgt blokkades op en ondersteunt de continuïteit bij een langdurige respons.
- Technical Lead: Coördineert de technische workstreams en zorgt dat de relevante playbooks en runbooks worden uitgevoerd.
- Communications Lead: Coördineert updates aan stakeholders, briefings voor de directie, interne berichten en goedgekeurde externe communicatie.
- Scribe (notulist): Houdt de incidenttijdlijn, de actielijst, het besluitenlog en verwijzingen naar bewijsmateriaal bij.
- Overige rollen:
- Legal / Compliance: Beoordeelt verplichtingen uit regelgeving, contracten, wetgeving, verzekeringen en rond openbaarmaking.
- Bedrijfs- / service-eigenaren: Bevestigen de bedrijfsimpact, de prioriteit van de recovery, de impact op klanten en operationele beperkingen.
- Eigenaar leverancier / inkoop: Coördineert ondersteuning door derden als actie van de leverancier nodig is.
- Klantenservice / Customer Success: Coördineert de afhandeling van impact op klanten en de paraatheid van support.
- Recovery Lead: Coördineert prioriteiten, afhankelijkheden en validatie bij het herstel van diensten.
4. Eerste acties
-
Directe stappen:
- Bevestig het uitroepen van het major incident, de severity, de Incident Commander, de Technical Lead, de Communications Lead, de scribe en de executive sponsor.
- Open de war room voor het major incident, de actielijst, het besluitenlog en het vergaderritme.
- Roep de benodigde teams op: engineering, security, platform, applicaties, identity, cloud, netwerk, Legal, communicatie, support en leverancierseigenaren.
- Stel vast welke technische playbooks actief zijn en wijs per workstream een eigenaar aan.
- Start het communicatieproces met directie en Legal als grote impact, impact op klanten, gereguleerde data of externe communicatie mogelijk is.
Beslispunt:
- Het incident vraagt geen coördinatie als major incident → ga alleen verder onder het relevante technische playbook.
- Coördinatie als major incident is nodig → ga door met dit playbook naast alle relevante technische playbooks.
- Externe communicatie kan nodig zijn → schakel Legal/Compliance en de Communications Lead in vóór elke externe verklaring.
5. Onderzoek & analyse
-
Verzamelen van bewijsmateriaal:
- Bevestig dat elke technische workstream bewijsmateriaal veiligstelt via het gekoppelde playbook en de runbooks.
- Houd in de actielijst van het major incident de locaties, eigenaren, verzamelstatus en hiaten van het bewijsmateriaal bij.
- Bewaar besluiten van de leiding, tijdlijnen, statusupdates, beoordelingen van de impact op klanten en juridisch advies als onderdeel van het incidentrecord.
-
Analysestappen:
- Houd een geconsolideerde incidenttijdlijn bij met detectie, impact, containment, eradication, recovery, communicatie en besluiten.
- Volg de actieve technische workstreams en gekoppelde playbooks.
- Bevestig dat elke workstream een actuele hypothese, scope, eigenaar, volgende actie, blokkade en tijdstip voor de volgende update heeft.
- Houd een beoordeling van de bedrijfsimpact bij over diensten, klanten, data, regio's, omzet, bedrijfsvoering en afhankelijkheden voor de recovery.
Beslispunt: Voer de relevante technische playbooks gelijktijdig uit, afhankelijk van wat het incident veroorzaakt:
- Ransomware of destructieve activiteit → PB-002: Ransomware Incident Response
- Malware of verdachte uitvoering → PB-003: Endpoint-malware-infectie / PB-011: Verdachte uitvoering
- Compromittering van account, token, credentials of cloud-identiteit → PB-004: Account Takeover
- Blootstelling, staging of exfiltratie van data → PB-005: Data-exfiltratie
- Compromittering van de cloudomgeving → PB-007: Cloud Compromise
- Compromittering van een webapplicatie → PB-008: Aanval op een webapplicatie
- Privilege escalation → PB-009: Privilege Escalation
- Lateral movement → PB-010: Lateral Movement
- Compromittering van een derde partij → PB-012: Compromittering van een derde partij
- DDoS of aanval op de beschikbaarheid → PB-013: Distributed Denial of Service (DDoS)
- Verloren/gestolen apparaat met grote impact → PB-014: Verloren & gestolen apparaat
- Actieve exploitatie → PB-015: Actieve exploitatie
- Noodsituatie rond een kwetsbaarheid of zero-day → PB-017: Vulnerability Response / PB-018: Zero-Day Response
6. Containment, eradication & recovery
-
Containment-acties:
- Bevestig dat elke technische workstream een eigenaar, een containment-doel, een huidige actie, een risico en een rollbackplan heeft.
- Geef voorrang aan containment-acties die actieve toegang van de aanvaller, impact op klanten, blootstelling van data, destructief risico en impact op bedrijfskritieke diensten verminderen.
- Leg containment-besluiten, risicoacceptaties en zakelijke afwegingen vast in het besluitenlog.
-
Eradication-stappen:
- Bevestig dat elk technisch playbook eigenaar is van het wegnemen van de incidentspecifieke root cause, persistence, kwaadaardige toegang en kwetsbare blootstelling.
- Volg afhankelijkheden tussen workstreams, zoals identity-resets, netwerksegmentatie, herinstallaties, ondersteuning door leveranciers, legal holds en zakelijke goedkeuringen.
- Zorg dat eradication pas als afgerond wordt verklaard als de technical leads bevestigen dat root cause en persistence zijn aangepakt.
-
Recovery-stappen:
- Stel de prioriteit van de recovery vast op basis van bedrijfskritiek, volgorde van afhankelijkheden, impact op klanten, veiligheid en restrisico.
- Maak het herstel van diensten afhankelijk van de containment-status, validatie van de integriteit, gereedheid van de monitoring en goedkeuring door de zakelijke eigenaar.
- Schaal het major incident pas af nadat de Incident Commander heeft bevestigd dat de containment stabiel is, het herstelpad vaststaat, de communicatie op orde is en het resterende risico bekend is.
7. Communicatie & escalatie
-
Interne communicatie:
- Laat het vergaderritme, de actielijst, het besluitenlog en statusupdates van het major incident lopen via de war room-SOP.
- Gebruik de overdracht tussen regio's als leiding of workstreams overgaan naar een andere dienst of regio.
- Informeer getroffen gebruikers of bredere groepen medewerkers als zij actie moeten ondernemen.
-
Externe communicatie:
- Stem communicatie met directie, Legal, toezichthouders, klanten, partners, verzekeraars, media of politie/justitie af via de goedgekeurde processen.
- Stem communicatie met leveranciers af via de SOP voor leverancierscommunicatie.
-
Escalatiecriteria:
Situatie Escaleren naar Vergaderritme, actielijst of besluitenlog voor een major incident nodig SOP-007: War room-management bij een major incident Afstemming met directie, Legal, toezichthouders, klanten, media of verzekeraar nodig SOP-003: Escalatie en communicatie met Legal en directie Ondersteuning door leverancier of provider nodig SOP-005: Communicatie met leveranciers tijdens een security-incident Respons over meerdere regio's of van lange duur vraagt om overdracht van de leiding SOP-002: Incidentoverdracht tussen regio's Actie of advies voor getroffen gebruikers nodig SOP-004: Gebruikersnotificatie tijdens een security-incident
8. Post-incidentactiviteiten
-
Lessons learned:
- Houd een PIR over de leidingstructuur, severity-besluiten, het communicatieritme, de kwaliteit van besluiten, overdrachten, de coördinatie van technische workstreams, de prioritering van de recovery en de uitkomsten voor stakeholders.
- Beoordeel of het major incident vroeg genoeg is uitgeroepen en op het juiste moment is afgeschaald.
- Stel hiaten vast in coördinatie, onduidelijk eigenaarschap, vertraagde besluiten, ontbrekend bewijsmateriaal of mislukte communicatie.
-
Documentatie bijwerken:
- Werk technische playbooks, SOP's, escalatiepaden, contactlijsten, statustemplates, templates voor het besluitenlog en richtlijnen voor herstelprioriteiten bij op basis van de PIR-bevindingen.
- Volg alle vervolgacties met eigenaren, deadlines en validatiecriteria.
9. Referenties & gekoppelde bronnen
-
Playbooks:
- PB-002: Ransomware Incident Response
- PB-003: Endpoint-malware-infectie
- PB-004: Account Takeover
- PB-005: Data-exfiltratie
- PB-007: Cloud Compromise
- PB-008: Aanval op een webapplicatie
- PB-009: Privilege Escalation
- PB-010: Lateral Movement
- PB-011: Verdachte uitvoering
- PB-012: Compromittering van een derde partij
- PB-013: Distributed Denial of Service (DDoS)
- PB-014: Verloren & gestolen apparaat
- PB-015: Actieve exploitatie
- PB-017: Vulnerability Response
- PB-018: Zero-Day Response
-
Runbooks:
-
SOP's:
- SOP-001: On-call van een engineeringteam oproepen bij security-incidenten
- SOP-002: Incidentoverdracht tussen regio's
- SOP-003: Escalatie en communicatie met Legal en directie
- SOP-004: Gebruikersnotificatie tijdens een security-incident
- SOP-005: Communicatie met leveranciers tijdens een security-incident
- SOP-007: War room-management bij een major incident
10. Bijlagen
-
Verwachte opbrengsten:
- Registratie van het uitroepen van het major incident en de severity
- Lijst van actieve workstreams en eigenaren
- Link naar de war room, actielijst en besluitenlog
- Geconsolideerde incidenttijdlijn
- Vastlegging van communicatie met directie, Legal, klanten en leveranciers
- Plan met herstelprioriteiten en afhankelijkheden
- Vastlegging van het besluit tot afschalen of sluiten
- Actiepunten uit de PIR en hun eigenaren
-
Veelgemaakte fouten:
- Een major incident te laat uitroepen
- Meerdere technische playbooks uitvoeren zonder één leidingstructuur
- Ontbrekende besluitenlogs of actie-eigenaren
- Herstelwerk laten starten vóór containment en validatie van de integriteit
- Externe communicatie versturen vóór goedkeuring door Legal en communicatie
- Context kwijtraken bij langdurige overdrachten of overdrachten tussen regio's
Bijdrager
Vishal Thakur GitHub: https://github.com/malienist
Heeft bijgedragen aan het Arcana Incident Response Documentation Framework.