Incident Response

Allereerst. Incident Response is geen Incident Management. Incident Management is ITIL. Zal dit er even wat dieper inwrijven.

Er bestaat in de moderne organisatie een merkwaardig geloof dat woorden hetzelfde zijn als daden. Als je iets een mooie naam geeft, is het opgelost. Noem een kast “Knowledge Base” en je hebt kennis. Noem een meeting “War Room” en je wint de oorlog. Noem een formulier “Root Cause Analysis” en de oorzaak verdwijnt vanzelf uit schaamte.

En zo komen we bij één van de meest hardnekkige misverstanden in IT: het idee dat Incident Management hetzelfde is als Incident Response.

Ze lijken op elkaar. Ze bevatten allebei het woord “incident”. Dat is ongeveer net zo’n goede reden om ze te verwarren als zeggen dat een brandweerauto hetzelfde is als een brandoorzaakonderzoeker omdat ze allebei “brand” in hun dag hebben.

Incident Management: ITIL, orde, herstel, rust in de tent

Incident Management komt uit ITIL-land. ITIL is een wereld waar alles netjes een proces heeft, inclusief het proces om te bepalen dat je een proces nodig hebt. Het doel van Incident Management is helder en eerlijk:

Zo snel mogelijk de dienstverlening herstellen.

Dus bij Incident Management gaat het over:

• impact op de business: werkt het nog?
• prioriteit: hoeveel mensen hebben last?
• escalatie: wie moet wakker worden gebeld?
• communicatie: wat zeggen we tegen gebruikers?
• workaround: kunnen we dit tijdelijk omzeilen?
• herstel: zet het terug zoals het was

Incident Management is de ambulancedienst van IT. Niet romantisch, maar levensreddend. Je wilt snelheid, structuur, triage, een duidelijke eigenaar en vooral: dat het stopt met bloeden.

En dat is prachtig. Echt. Je wilt Incident Management. Je wilt ITIL. Je wilt dat iemand weet waar de knop “restart” zit.

Alleen… dan komt security binnenlopen met rook om zijn hoofd en zegt: “Wacht eens even. Dit is niet alleen een storing.”

Incident Response: security, tegenstander, bewijs, containment

Incident Response is iets anders. Incident Response is niet “het werkt weer” maar:

Wat is er gebeurd, hoe ver zit het, en hoe stoppen we het zonder het erger te maken?

Bij Incident Response heb je namelijk te maken met een tegenstander. Niet met een bug, niet met een crash, niet met een verkeerd certificaat dat om 02:00 is verlopen omdat iemand het op ‘automatisch’ had gezet in 2017 en daarna nooit meer keek.

Je hebt te maken met:

• inbraak, misbruik, exfiltratie
• persistence (de aanvaller blijft zitten)
• laterale beweging
• privilege escalation
• sporen die verdwijnen
• data die weg kan zijn vóór je “major incident” hebt uitgesproken

Incident Response is meer CSI dan servicedesk. Het is een combinatie van brandbestrijding en forensisch onderzoek, terwijl de brandstichter mogelijk nog in de keuken staat.

En daarom is “zo snel mogelijk herstellen” niet altijd het beste idee. Soms is “zo snel mogelijk herstellen” precies hoe je:

• bewijsmateriaal overschrijft,
• de aanvaller waarschuwt,
• je logs kwijt raakt,
• een geïnfecteerde backup terugzet,
• of de aanvaller netjes mee migreert naar je nieuwe omgeving.

Incident Response is niet de ambulance. Incident Response is: ambulance + politie + recherche + slotenmaker + iemand die zegt: “NIET AANKOMEN, DIT IS EEN CRIME SCENE.”

Het grote probleem: ITIL reflexen in een security-incident

Als organisaties Incident Response en Incident Management door elkaar halen, krijgen ze een voorspelbaar toneelstuk:

1. Er is iets raars.
2. ITIL zegt: “Restore service!”
3. Iemand reboot iets.
4. Het werkt weer.
5. Iedereen blij.
6. Drie weken later blijkt: de aanvaller zat er al die tijd nog.
7. Iedereen niet blij.

Want security-incidenten zijn berucht om één ding: ze hebben een lange staart. De eerste verstoring is vaak niet het probleem, maar een symptoom. De echte vraag is niet “kunnen we de boel weer aanzetten?” maar “waarom ging het uit, en wie zat er aan de knop?”

En ITIL is daar niet slecht in—ITIL zegt ook: “Doe Problem Management, doe RCA.” Alleen: security-incidenten hebben vaak een andere dynamiek. Je RCA kan pas na containment. En containment is niet altijd compatible met “doe het snel weer aan”.

De kern: verschillende doelen, verschillende prioriteiten

Laten we het pijnlijk simpel maken:

Incident Management (ITIL)

• Doel: dienstverlening herstellen
• Maatstaf: downtime omlaag, impact omlaag
• Reflex: workaround, restart, rollback
• Risico: te snel “fixen” en de oorzaak missen

Incident Response (Security)

• Doel: aanvaller stoppen, schade begrenzen, inzicht krijgen
• Maatstaf: containment, scope, herstel zonder herinfectie
• Reflex: isoleren, bewijsmateriaal veiligstellen, triage op sporen
• Risico: te langzaam beslissen en schade laten groeien

Beide zijn nodig. Maar ze zijn niet hetzelfde. En als je ze door elkaar haalt, krijg je het slechtste van twee werelden: je herstelt snel, maar onveilig; of je onderzoekt grondig, maar zonder business-afstemming.

“Maar we hebben een Major Incident proces!”

Ja. En dat is prachtig. En nu de vraag die iedereen haat:
Waar staat je security playbook?
Wie neemt de lead bij een ransomware-achtige situatie? Wie beslist over isolatie? Wie bewaakt logging en bewijs? Wie regelt communicatie met legal en privacy? Wie belt externe partijen? Wie bepaalt wanneer je terug mag naar productie?

Want een Major Incident proces is meestal gebouwd voor storingen, niet voor aanvallen. Een storing is een probleem zonder intentie. Een aanval is intentie met planning. Dat is een ander beest.

Hoe volwassen organisaties het doen: twee sporen, één stuur

Volwassenheid is niet kiezen tussen ITIL en IR. Volwassenheid is ze samen laten werken, met duidelijke rollen.

Praktisch ziet dat er zo uit:

• Incident Manager (ITIL) houdt het overzicht op service-impact, communicatie en coördinatie.
• Incident Commander / IR Lead (Security) bepaalt containment, forensics, herstelstrategie en “wanneer is het echt veilig”.
• Eén gezamenlijke war room, maar met twee disciplines: “service herstellen” én “tegenstander verwijderen”.

En de belangrijkste zin in zo’n situatie is vaak:
“Wacht. Eerst isoleren. Dan pas fixen.”

Want soms is de snelste weg naar herstel… eerst even niet herstellen.

En ja, je moet oefenen (want in het echt is iedereen dommer)

Op papier werkt alles. Op papier is iedereen beschikbaar, zijn contactlijsten actueel en bestaan er back-ups die teruggezet kunnen worden zonder drama.

In werkelijkheid:

• staat het telefoonnummer van de verantwoordelijke in een pdf achter SSO (dat nu niet werkt),
• heeft niemand geoefend,
• en blijken “immutable backups” toch vooral “mappen met goede bedoelingen”.

Daarom moet je dit trainen: tabletop oefeningen, technische drills, ransomware-simulaties. Niet om te cosplayen als een SOC, maar omdat je in een echt incident geen tijd hebt om begrippen uit te leggen. Geloof me.