Incident response: wat doe je als het misgaat?

Het gaat een keer mis. Een server wordt gecompromitteerd. Een datalek. Ransomware. Een configuratiefout die productie platlegt. Of een DDoS-aanval die je dienst onbereikbaar maakt. De vraag is niet of je ooit met een incident te maken krijgt, maar of je er klaar voor bent als het gebeurt.

De meeste schade bij beveiligingsincidenten wordt niet veroorzaakt door de aanval zelf. Ze wordt veroorzaakt door de uren en dagen erna: onduidelijkheid over wie de leiding heeft, verkeerde beslissingen onder tijdsdruk, ongecoördineerde communicatie en maatregelen die een incident verergeren in plaats van beperken.

Een goed incidentresponsplan is daarom geen luxe voor grote organisaties. Het is de praktische set afspraken die bepalen hoe je organisatie reageert als er iets fout gaat.

De vier fasen van incidentrespons

1. Voorbereiding

Alles wat je nu doet bepaalt hoe snel je straks reageert. Voorbereiding gaat over drie dingen: mensen, systemen en procedures.

Mensen: wie is verantwoordelijk bij een incident? Wie neemt de technische beslissingen? Wie communiceert extern, naar klanten en media? Wie informeert de directie? Leg dat vast, inclusief escalatielijnen als de eerste persoon niet bereikbaar is. Bij een incident om twee uur 's nachts wil je geen discussie hebben over wie wanneer wat doet.

Systemen: heb je de basismonitoring op orde? Logging van relevante systemen, alerts bij afwijkend gedrag, toegang tot centrale loganalyse? Zorg dat je back-ups beschikbaar zijn en getest. Leg toegangsgegevens en architectuurdocumentatie op een veilige, offline bereikbare locatie – als je gecompromitteerde systemen afsluit, wil je nog steeds bij die informatie kunnen.

Procedures: schrijf een basaal incidentresponsplan. Het hoeft geen honderden pagina's te zijn. Een A4 met beslisboom, contactpersonen en checklist is beter dan een uitgebreid document dat niemand ooit leest.

2. Detectie en analyse

Een incident begint altijd met een signaal. Soms is dat helder: ransomware meldt zich zelf. Soms is het subtiel: ongewone netwerkverkeer, een gebruiker die een phishingmail meldt, een waarschuwing van een externe beveiligingsdienst.

Bij detectie zijn twee vragen cruciaal. Ten eerste: is dit een echt incident of een false positive? Het heeft geen zin om je hele crisisteam bijeen te roepen voor een foutief geconfigureerde monitoring-alert. Ten tweede: wat is de omvang? Welke systemen zijn betrokken? Is er data geëxfiltreerd? Is de aanvaller nog actief?

Analyseer voordat je ingrijpt. De reflex bij een aanval is onmiddellijk afschakelen. Dat is soms juist – maar als een aanvaller nog actief is, kan snel afschakelen ertoe leiden dat je bewijsmateriaal verliest, de aanvaller waarschuwt en gedwongen wordt tot herstel zonder volledig begrip van wat er is gebeurd.

Leg alles vast. Tijdstempels, waarnemingen, beslissingen en de redenen daarvoor. Dit is niet alleen voor het juridische en compliance-traject erna – het helpt ook om de eigen aanpak te verbeteren.

3. Inperking, uitroeiing en herstel

Inperking betekent: stop de schade. Isoleer de getroffen systemen van het netwerk. Blokkeer kwaadaardige IP-adressen. Reset gecompromitteerde accounts. De prioriteit is hier de verdere verspreiding te voorkomen, niet de beschikbaarheid te herstellen.

Uitroeiing volgt daarna: verwijder de malware, dicht de kwetsbaarheid die is misbruikt, verwijder backdoors die een aanvaller heeft achtergelaten. Doe dit grondig. Een halve opruimactie laat aanvallers de mogelijkheid om opnieuw toegang te krijgen.

Herstel is de gecontroleerde terugkeer naar normale operaties. Dit begint met een schone basis: een server waarvan je weet dat die niet is gecompromitteerd, hersteld vanuit een geverifieerde back-up. Test het herstel voordat je productieverkeer toelaat. Monitor intensief in de eerste dagen na herstel.

4. Evaluatie

Na afloop van het incident volgt de post-mortem. Wat is er precies gebeurd? Hoe kon de aanval plaatsvinden? Wat werkte goed in de respons en wat niet? Welke maatregelen voorkomen een herhaling?

Een goede post-mortem is niet gericht op het aanwijzen van schuldigen. Het doel is leren. Schrijf de bevindingen op en vertaal ze naar concrete acties met eigenaar en deadline. Leg het document op als referentie voor toekomstige incidenten.

De meldplicht

Als je organisatie onder de NIS2-richtlijn (in Nederland: de Cyberbeveiligingswet) valt, heb je een wettelijke meldplicht bij aanzienlijke incidenten. De termijnen zijn strak: 24 uur voor de eerste melding bij de bevoegde autoriteit, 72 uur voor de volledige incidentmelding en een maand voor de eindrapportage.

Ook buiten NIS2 kan er een meldplicht gelden. Datalekken waarbij persoonsgegevens betrokken zijn, moeten binnen 72 uur worden gemeld bij de Autoriteit Persoonsgegevens. Als de betrokkenen zelf risico lopen (identiteitsdiefstal, financiële schade), moeten zij ook worden geïnformeerd.

De meldplicht is geen administratieve last die je op kunt pakken als het rustig is. Bouw de melding in je incidentresponsplan in. Wie is verantwoordelijk voor de melding? Welke informatie moet aanwezig zijn? Welk contactpersoon bij het NCSC of de AP gebruik je?

Communicatie tijdens een incident

Communicatie is een van de meest onderschatte onderdelen van incidentrespons. Slechte communicatie kan de reputatieschade van een incident verdubbelen. Goede communicatie kan vertrouwen behouden ook bij ernstige incidenten.

Interne communicatie: zorg dat het juiste team weet wat er speelt, wat de status is en wie welke beslissingen neemt. Schep geen paniek, maar wees ook niet geruststellend als de situatie dat niet rechtvaardigt. Feiten, niet inschattingen.

Externe communicatie: naar klanten, partners en media. De basisregel: communiceer vroeg, communiceer eerlijk en communiceer wat je doet om het probleem op te lossen. Een statement van "we onderzoeken een incident en informeren u zodra we meer weten" is beter dan stilte. Stilte laat ruimte voor speculatie.

Bepaal vooraf wie woordvoerder is. Niet iedereen die betrokken is bij het incident hoeft te praten met klanten of journalisten. Eén stem, afgestemd boodschap.

Wat een plan niet is

Een incidentresponsplan is geen garantie dat alles goed gaat. Incidenten zijn per definitie onverwacht en onverwachte situaties passen nooit precies in vooraf bedachte scenario's.

Een plan is een startpunt. Het geeft structuur op het moment dat de druk hoog is en mensen geneigd zijn ad hoc beslissingen te nemen. Het zorgt dat de basisstappen worden gezet zonder dat je ze hoeft te bedenken terwijl het huis in brand staat.

Oefen er ook mee. Tabletop-oefeningen, waarbij een incidentscenario wordt doorgespeeld zonder dat er daadwerkelijk iets is, laten snel zien waar het plan gaten heeft of onduidelijk is. Eén oefening per jaar is beter dan geen. En dan ontdek je dat het enige exemplaar van het plan staat op de server die je net hebt afgesloten.

De conclusie

Incidentrespons is de discipline die bepaalt hoeveel schade een aanval of storing daadwerkelijk aanricht. De technische maatregelen bepalen hoe groot het aanvalsoppervlak is. Incidentrespons bepaalt wat er daarna gebeurt.

Begin met een simpel plan. Leg vast wie de leiding heeft, hoe je de omvang bepaalt, hoe je isoleert en hoe je communiceert. Sla het op buiten de systemen die je beveiligt. Test het minimaal één keer per jaar. En bij elk incident: documenteer alles en gebruik het om te leren.

Een organisatie die goed reageert op incidenten herstelt sneller, communiceert beter en leert van elk incident. Een organisatie zonder plan verdubbelt de schade.

Hulp nodig bij het opstellen van je incidentresponsplan? Neem contact op met ons team.