Een incidentresponsplan vanaf nul opstellen

Een cyberaanval kondigt zich niet aan. Op een ochtend gaat er een waarschuwing af, iemand opent een ticket, en tegen de tijd dat het management op de hoogte wordt gebracht, breidt de schade zich al uit. Wat het verschil maakt tussen bedrijven die een inbreuk binnen enkele uren onder controle krijgen en bedrijven die maandenlang bezig zijn met herstel, is niet betere technologie. Het is voorbereiding. Om precies te zijn: of er al een plan was voordat er iets misging.

Een incidentresponsplan (IRP) is een gedocumenteerde, geteste procedure voor het opsporen, indammen en herstellen van beveiligingsincidenten. Dat klinkt nogal bureaucratisch. In de praktijk maakt het het verschil tussen een beheerste reactie en georganiseerde chaos om 2 uur ’s nachts.

Wat wordt eigenlijk als een incident beschouwd?

Niet elke waarschuwing is een incident. Een mislukte inlogpoging is ‘ruis’. Ransomware die een bestandsserver versleutelt, is dat niet. Dit onderscheid is belangrijk, omdat het bepaalt wie er bij wordt betrokken en hoe snel.

Algemene categorieën die het de moeite waard zijn om vast te leggen voordat er iets gebeurt:

• Datalek: ongeoorloofde toegang tot gevoelige of aan regelgeving onderworpen gegevens
• Malware-infectie: ransomware, spyware, wipers, trojans
• Denial-of-service: aanvallen die systemen vertragen of platleggen
• Interne bedreiging: opzettelijke of onopzettelijke handelingen door medewerkers of ingehuurde krachten
• Inbreuk op de toeleveringsketen: aanvallen die via software van leveranciers binnendringen (SolarWinds is hiervan het schoolvoorbeeld)
• Ongeautoriseerde toegang: diefstal van inloggegevens, uitbreiding van rechten, laterale verplaatsing

Een phishing-e-mail waarop is geklikt maar die niets heeft achtergelaten, is iets anders dan een e-mail waarbij een Cobalt Strike-beacon is geïnstalleerd. Het plan moet beide situaties aanpakken en het team snel duidelijk maken wat wat is.

Waarom de meeste plannen in de praktijk niet werken

Veel organisaties beschikken over een document voor incidentrespons. Maar er zijn er veel minder waarvan iemand het daadwerkelijk heeft gelezen. En er zijn er nog minder die het hebben getest in een situatie die op een echt scenario lijkt.

De gebruikelijke problemen: het document is drie jaar oud, er staan contactgegevens in van mensen die het bedrijf hebben verlaten, er wordt uitgegaan van tools die inmiddels zijn vervangen, en niemand van het daadwerkelijke responsteam heeft het ooit gezien. Het blijkt dat er een aanzienlijk verschil bestaat tussen het hebben van een beleidsdocument en het beschikken over een operationeel draaiboek. Het ene voldoet aan de eisen van auditors. Het andere is wat je gebruikt als de productie om 3 uur ’s nachts uitvalt en niemand weet wie bevoegd is om een gecompromitteerde server offline te halen.

De zes fasen en wat ze in de praktijk betekenen

Het NIST SP 800-61 -raamwerk verdeelt de incidentrespons in zes fasen. SANS hanteert een vergelijkbare indeling, maar met andere benamingen. Hoe dan ook, de structuur blijft hetzelfde.

Voorbereiding

Alles wat aan een incident voorafgaat. Hier vindt het echte werk plaats: vaststellen wat een incident precies is, het responsteam samenstellen en opleiden, de infrastructuur voor logboekregistratie en waarschuwingen opzetten, en tabletop-oefeningen houden. Een detail dat voortdurend over het hoofd wordt gezien: het vooraf goedkeuren van maatregelen. Tijdens een lopend incident kost het wachten op juridische goedkeuring om een server te isoleren tijd die je niet hebt. Bepaal van tevoren wat er onmiddellijk kan worden gedaan, en door wie, zonder dat er escalatie nodig is.

Identificatie

Er is iets gebeurd. De vraag is: wat precies? In deze fase gaat het erom waarschuwingen om te zetten in bevestigde incidenten, signalen uit SIEM- en EDR-tools met elkaar in verband te brengen, de omvang vast te stellen en een tijdlijn op te stellen. De snelheid hangt hier rechtstreeks samen met de kwaliteit van de logboekregistratie die tijdens de voorbereiding is ingesteld. Onbruikbare logbestanden leiden tot trage identificatie. Trage identificatie betekent minder opties.

Inperking

Beperking op korte termijn is snel en rigoureus: besmette hosts isoleren, IP-adressen van aanvallers blokkeren, gecompromitteerde accounts uitschakelen. Beperking op lange termijn is nauwkeuriger: tijdelijke oplossingen, opnieuw geconfigureerde systemen, verbeterde monitoring van specifiek gedrag. Een beslissing die steeds weer terugkomt: onmiddellijk de verbinding verbreken of eerst de aanvaller in de gaten houden? Het verbreken van de verbinding beperkt de schade. Monitoring brengt de volledige omvang aan het licht. Er zijn goede argumenten voor beide benaderingen. Deze afweging moet van tevoren worden besproken en mag niet onder druk worden geïmproviseerd.

Uitroeiing

Verwijder de dreiging volledig. Breng patches aan op de kwetsbare punten die zijn misbruikt, verwijder malware en mechanismen die ervoor zorgen dat de malware blijft aanwezig, vernieuw inloggegevens en herstel gecompromitteerde systemen op basis van schone images. Door deze stap over te slaan of te overhaasten, raken organisaties twee weken later via dezelfde aanvalsvector opnieuw gecompromitteerd. Dit gebeurt vaker dan er over wordt bericht.

Herstel

Herstel de diensten in volgorde van prioriteit. Controleer of de systemen vrij van bedreigingen zijn voordat u ze weer aansluit. Houd nauwlettend in de gaten of er zich iets herhaaldelijk voordoet. En zorg dat u aan de meldingsverplichtingen voldoet – volgens de AVG moet u de toezichthoudende autoriteiten binnen 72 uur op de hoogte stellen na een inbreuk op persoonsgegevens. Die termijn wordt niet opgeschort omdat het herstel nog gaande is.

Gedane ervaringen

De fase die de meeste teams overslaan omdat ze uitgeput zijn. En juist daarom is deze fase zo belangrijk. Binnen twee weken moet er een evaluatie na afloop van het incident plaatsvinden: wat is er gebeurd, wat werkte wel, wat werkte niet, welke tekortkomingen zijn aan het licht gekomen, welke veranderingen worden doorgevoerd en wanneer. Leg dit vast. Pas het plan aan. Voer de veranderingen vervolgens ook daadwerkelijk door; anders was het niet meer dan een vergadering.

Hulpmiddelen die een plan uitvoerbaar maken

Het IRP beschrijft wat er moet gebeuren. Hulpmiddelen zorgen ervoor dat dit onder druk snel kan worden uitgevoerd.

• SIEM: Splunk, Microsoft Sentinel en IBM QRadar voor logboekcorrelatie op grote schaal
• EDR: CrowdStrike Falcon, SentinelOne, Microsoft Defender voor gedragsdetectie en isolatie van eindpunten
• SOAR: Palo Alto XSOAR, Splunk SOAR voor geautomatiseerde uitvoering van playbooks
• Inlichtingen over cyberdreigingen: MISP en Recorded Future voor achtergrondinformatie over de TTP’s van aanvallers
• Forensisch onderzoek: Velociraptor, Magnet AXIOM en Volatility voor onderzoek en het veiligstellen van bewijsmateriaal

De tools zijn minder belangrijk dan de vraag of mensen weten hoe ze die onder druk moeten gebruiken. Een Splunk-instantie met 400 dashboards en geen runbooks helpt niemand.

Belangrijke informatie over de harmonisatie van regelgeving

Afhankelijk van de sector en de regio is een IRP geen optie, maar een wettelijke verplichting. Belangrijkste kaders:

• NIST SP 800-61 Rev. 2: de basisnorm voor de Amerikaanse federale overheid en de meeste bedrijfsomgevingen
• ISO/IEC 27035: internationale norm voor incidentbeheer
• Artikel 33 van de AVG: meldingsplicht binnen 72 uur bij inbreuken op de beveiliging van persoonsgegevens in de EU
• NIS2-richtlijn: meldingsverplichtingen bij incidenten voor exploitanten van essentiële diensten in de hele EU
• DORA: EU-vereisten inzake de veerkracht van de financiële sector die sinds januari 2025 van kracht zijn, met expliciete verplichtingen inzake IR-tests
• PCI DSS v4.0: documentatie- en jaarlijkse testvereisten voor de betalingssector

NIS2 en DORA zijn de regelgevingen die organisaties momenteel overrompelen. Beide leggen de lat aanzienlijk hoger wat betreft documentatie, testfrequentie en rapportagetermijnen.

Aanbieders die het overwegen waard zijn

Sommige organisaties bouwen hun IR-capaciteit volledig in eigen beheer op. De meeste beschikken echter niet over het personeel of de nodige ervaring om dit goed aan te pakken, met name wat simulaties en tests betreft. Een korte opsomming:

DXC Technology verzorgt de ontwikkeling van end-to-end IR-programma’s: het opstellen van plannen, tabletop-oefeningen en beheerde detectie en respons. Het bedrijf is bijzonder sterk in gereguleerde sectoren (energie, gezondheidszorg, financiële dienstverlening), waaronder softwareoplossingen voor de energiesector, waarbij naleving van de regelgeving vanaf het begin in het project is ingebouwd.

Secureworks (Atlanta) biedt naast hun Taegis XDR-platform ook IR-retainerdiensten aan. Hun Counter Threat Unit publiceert doorlopend informatie over bedreigingen die rechtstreeks wordt verwerkt in updates van de playbooks, wat handig is voor teams die detectie en respons in één omgeving willen integreren.

WithSecure (Helsinki) hanteert een adviserende aanpak bij de ontwikkeling van IR-programma’s, waarbij sterk wordt aangesloten bij de Europese regelgeving. Dit past beter bij organisaties die voor het eerst IR-capaciteit opbouwen dan bij organisaties die op zoek zijn naar een puur beheerde dienst.

Trustwave (Chicago) combineert beheerde beveiligingsdiensten met IR-advies via SpiderLabs, een intern ‘red team’ dat de afgelopen tien jaar enkele van de meest gedetailleerde rapporten over bedreigingen in de sector heeft opgesteld.

Orange Cyberdefense (Frankrijk) verzorgt de grensoverschrijdende IR-coördinatie in meerdere EU-rechtsgebieden tegelijk. Dit is nuttig voor multinationals die in verschillende landen tegelijkertijd aan hun NIS2- en AVG-verplichtingen moeten voldoen.

De fouten die zich telkens weer voordoen

Zelfs goed voorbereide teams maken voorspelbare fouten. De fouten die het vaakst voorkomen:

• Het plan niet testen: een document dat nog nooit onder gesimuleerde druk is getest, is giswerk
• Geen vastgestelde communicatieprotocollen: wie spreekt met de pers, wie belt de toezichthouder, wie brengt de klanten op de hoogte
• Ervan uitgaan dat de back-ups in orde zijn zonder ze te controleren
• Zonder derden buiten beschouwing te laten: cloudproviders, SaaS-leveranciers en MSP’s moeten bij het proces worden betrokken en mogen niet pas achteraf op de hoogte worden gesteld
• IR beschouwen als een functie die uitsluitend onder de IT valt: juridische zaken, communicatie, HR en het management spelen allemaal een rol bij een ernstig incident

En de grootste fout: het plan als een eenmalig project beschouwen. Bedreigingen veranderen. Systemen veranderen. Mensen vertrekken. Een IRP dat niet actief wordt bijgehouden, is al verouderd voordat het nodig is.

Veelgestelde Vragen

Hoe lang duurt het om een werkend IRP helemaal vanaf nul op te bouwen?

Een basisplan kan binnen vier tot zes weken worden opgesteld. Voor een volwaardig programma met draaiboeken, geteste oefeningen en integratie van tools is realistisch gezien drie tot zes maanden nodig.

Hoe vaak moet het worden getest?

Minimaal één keer per jaar. DORA en de meeste bedrijfsraamwerken schrijven tegenwoordig voor dat er twee keer per jaar tabletop-oefeningen moeten plaatsvinden, met ten minste één volledige simulatie. Na elk ernstig incident of elke ingrijpende systeemwijziging moet er onmiddellijk een evaluatie plaatsvinden.

Wat is het verschil tussen een tabletop-oefening en een red team-oefening?

Een tabletop-oefening is gebaseerd op discussie; er worden scenario’s doorgenomen, zonder dat er daadwerkelijk met systemen wordt gewerkt. Een ‘red team’-oefening simuleert actief de technieken van aanvallers tegen echte infrastructuur. Beide zijn waardevol en testen verschillende aspecten.

Wat is de eerste stap wanneer een incident wordt vastgesteld?

Roep het responsteam op, leg de tijdstippen en de eerste indicatoren vast en start de vooraf goedgekeurde inperkingsmaatregelen. Raak geïnfecteerde systemen niet aan om ze op te schonen voordat het forensisch bewijsmateriaal is veiliggesteld; die informatie geeft namelijk pas een volledig beeld van wat er precies is gebeurd.

• Over
• Laatste berichten

Milena Baghdasaryan

Content-specialist bij PowerDMARC

Milena is een ervaren schrijfster en content creator met meer dan 7 jaar ervaring in het creëren van boeiende content over IT, cyberbeveiliging, virtuele evenementen en meer. Ze heeft bewezen werk van hoge kwaliteit af te leveren voor internationale tijdschriften en is afgestudeerd aan prestigieuze instellingen zoals New York University Abu Dhabi, UWC China en het Europacollege.

Laatste berichten van Milena Baghdasaryan (Bekijk alle berichten)

• Een incidentresponsplan vanaf nul opstellen - 8 september 2026
• De nieuwe manier waarop hackers financiële AI-assistenten misleiden - 7 september 2026
• Best practices voor DNS-beveiliging: een complete checklist voor beveiligingsverbeteringen - 7 september 2026