Weten dat je bent gehackt, vertelt je nog niet wat je veilig kunt herstellen. Een organisatie kan haar bestanden misschien terughalen, maar moet nog onderbouwen waarom de systemen die ze gebruiken weer aangesloten kunnen worden. Ze moet nog vaststellen wat de indringer heeft veranderd en of toegang die tijdens de aanval is aangemaakt nog bestaat.
Oktober gaf kort na elkaar drie waarschuwingen. Kwetsbaarheden in PHP werden misbruikt voordat er een patch beschikbaar was, en organisaties, waaronder het Nationaal Cyber Security Centrum en wijzelf, haalden uit voorzorg websites offline. Op 21 oktober beschreef Microsoft hoe de statelijk gelieerde groep Storm-0940 het agentic AI-framework ARTEX gebruikte om honderden organisaties aan te vallen, onder meer via een supply-chainaanval. In sommige gevallen gingen de aanvallers in minder dan drie uur van een eerste voet tussen de deur naar geprivilegieerde cloudtoegang. En het Dutch Institute for Vulnerability Disclosure, DIVD, werd getroffen door een aanvaller die op machinesnelheid werkte: twee tot dan toe onbekende kwetsbaarheden, en meer dan 2.500 sporen waar een zorgvuldige menselijke aanvaller er twintig of dertig achterlaat.
Het patroon is duidelijk. AI kan zwakke plekken sneller blootleggen dan organisaties ze kunnen dichten, waardoor verdedigers minder tijd hebben om te handelen. Als een aanval sneller gaat dan iemand kan reageren, is de stekker eruit trekken misschien de enige optie. De moeilijkere vraag komt daarna: hoe snel kun je kritieke processen herstellen, en hoe weet je dat dat veilig kan?
De verstoring bij Albert Heijn in oktober geeft een idee van wat er financieel op het spel staat. Retaildeskundigen die RTL Z raadpleegde, schatten dat de keten €120 miljoen tot €150 miljoen aan omzet misliep. De thuisbezorging kwam op 23 oktober weer op gang, bijna twee weken na het begin van het incident, eerst met ongeveer een derde van de normale bezorgcapaciteit. De fysieke winkels bleven open, maar met hier en daar lege schappen. Wat het incident veroorzaakte en waarom het herstel zo lang duurde, is niet openbaar gemaakt. De les is simpelweg dat tijd geld is.
Snel herstellen vraagt twee dingen: informatie en de mensen die haar kunnen duiden. Logs laten zien wat er is gebeurd. Alleen een team dat weet hoe de omgeving is gebouwd, hoe die verandert en wat van wat afhangt, kan beoordelen wat dat betekent voor de dienstverlening en of herstel veilig is. Zonder de logs gokt dat team. Zonder het team zijn de logs ruis.
Het schrijven van dit artikel scherpte een tweede les aan. Bij geavanceerde agentic aanvallen wordt detectie het makkelijke deel. Deze aanvallen maken veel lawaai: duizenden acties op machinesnelheid. Het zwaartepunt verschuift bijna volledig naar respons, en daar ligt de echte uitdaging. Als aanvallers binnen drie uur geprivilegieerde cloudtoegang kunnen bereiken, is er geen tijd om eerst uit te zoeken hoe een omgeving werkt. Het team moet snel, op basis van informatie die vooraf is gelogd, vaststellen wat er aan de hand is. Dat houdt de hersteltijd kort.
De informatie achter een herstelbesluit
Een serieus alarm maakt duidelijk dát er onderzoek nodig is. Over de volledige omvang van een compromittering zegt het mogelijk weinig. Voor herstel moeten teams uitzoeken welke systemen en identiteiten zijn geraakt, wat de aanvaller heeft veranderd en hoe zeker ze van die bevindingen zijn.
Met het dichten van het oorspronkelijke toegangspunt is het werk mogelijk nog niet klaar. De richtlijnen van Microsoft omvatten onderzoek naar inloggegevens en rechten die tijdens een aanval zijn gewijzigd, omdat extra toegang kan blijven bestaan nadat dat toegangspunt is gesloten. Een systeem dat normaal functioneert, kan een indringer nog steeds een weg terug bieden.
Dezelfde zorgvuldigheid geldt voor het materiaal waarmee wordt hersteld. De incidentresponsrichtlijnen van NIST raden aan back-ups en andere herstelmiddelen vóór gebruik op integriteit te controleren. Ook moeten herstelde systemen worden gecontroleerd op tekenen van compromittering en moeten de grondoorzaken van het incident worden aangepakt voordat ze in productie gaan. Voor die controles is bewijs nodig over de aanval én over de systemen die worden hersteld.
Dat bewijs hangt deels af van wat is vastgelegd voordat iemand wist dat er een probleem was. Logs van identiteiten en applicaties moeten worden gekoppeld aan activiteit in de infrastructuur onder de dienst. Onderzoekers moeten ook weten waar het zicht onvolledig is. Het ontbreken van een registratie van een niet-gemonitord onderdeel bewijst niet dat dat onderdeel onaangeroerd is gebleven.
Het volume maakt het nog lastiger. Een aanvaller die op machinesnelheid werkt, laat duizenden sporen achter, zoals DIVD ervoer. Die met de hand analyseren kost tijd die het bedrijf niet heeft. Onderzoek vraagt daarom om automatisering én om mensen die kunnen beoordelen wat het bewijs betekent.
Een organisatie heeft niet altijd een volledig forensisch beeld voordat het herstel begint. De richtlijnen van NIST erkennen dat herstel kan starten terwijl de incidentrespons nog loopt. De opgave is om genoeg betrouwbare informatie te verzamelen voor een afgebakend besluit, en de resterende onzekerheid expliciet te maken.
Wat vóór het incident moet worden voorbereid
Het voorbereiden van die informatie is een verantwoordelijkheid van engineering. Teams moeten vaststellen welke aanvalsscenario’s ertoe doen voor een kritieke dienst en of de bijbehorende activiteit waarneembaar zou zijn. Logbronnen moeten aangesloten en bruikbaar blijven terwijl de omgeving verandert. Detectielogica moet aansluiten bij hoe de dienst werkelijk werkt, inclusief de identiteiten en afhankelijkheden.
Ook de architectuur bepaalt hoe nauwkeurig een team kan onderzoeken en herstellen. Segmentatie kan beperken welke systemen een aanvaller bereikt. Zorgvuldig afgebakende toegang kan beperken wat een gecompromitteerde identiteit kan doen. Onderdelen die afzonderlijk te beheren zijn, geven responders mogelijkheden om een incident in te dammen en delen van een dienst in een gecontroleerde volgorde te herstellen.
Verantwoordelijkheden vragen dezelfde helderheid. Wie verantwoordelijk is voor de dienst, moet weten wie toestemming kan geven om die weer in gebruik te nemen. Die relaties moeten al werken wanneer een incident het besluit afdwingt.
Waar MCDR aan bijdraagt
Wij noemen onze aanpak Mission Critical Detection and Response, of MCDR. Die brengt gespecialiseerde detectie en onderzoek samen met de teams die verantwoordelijk zijn voor het beheer van de omgeving. Hun kennis van hoe de dienst is gebouwd en hoe die verandert, helpt om securitybevindingen om te zetten in besluiten over indamming en herstel.
Wat wij anders doen, is waar het werk ligt. Een centraal platform verzamelt en bewaart de logs en draait voor elke omgeving een standaardset detectie-use-cases. Het operationele werk ligt bij de teams die de omgeving beheren en de context hebben: threat modelling voor hun dienst, het ontwikkelen van specifieke use cases, het beschikbaar maken van applicatielogs en het reageren op incidenten. Onze securityspecialisten ondersteunen hen en springen bij waar het bewijs complex wordt. Zo beoordelen de mensen die de systemen kennen de bevindingen.
MCDR neemt ook het volume voor zijn rekening. Als een aanvaller duizenden sporen achterlaat, automatiseert het platform threat hunting en de eerste stappen van een onderzoek op schaal: de relevante logs verzamelen, activiteit correleren over identiteiten, applicaties en infrastructuur heen, en naar voren halen wat aandacht nodig heeft. Daarmee houdt het team met context ruimte voor wat automatisering niet kan: beoordelen wat het bewijs betekent voor de dienst en besluiten wat veilig kan worden hersteld.
We hebben MCDR uitgerold in alle missiekritieke omgevingen die we beheren, ook waar een klant al een eigen interne of externe security operations center heeft. Dat SOC behoudt zijn organisatiebrede rol. MCDR voegt diepgang toe binnen de missiekritieke omgeving, waar onderzoekers en beheerteams vanuit hetzelfde bewijs moeten werken. Relevante bevindingen moeten de mensen bereiken die kunnen handelen, met afgesproken bevoegdheden en een helder beeld van de gevolgen voor de dienst.
Daarom kan respons ook niet alleen van een centraal SOC afhangen. Een centraal team verliest tijd aan overdrachten en mist de context van de omgeving. Met drie uur op de klok moet respons dicht bij de systemen worden georganiseerd, door de teams die ze beheren. Het centrale SOC houdt zijn rol in de hele organisatie. Het responsvermogen verhuist naar waar de context zit.
De implementatie begint bij de kritieke dienst en de aanvalspaden die die dienst kunnen raken. We beoordelen het zicht langs die paden, verbeteren de logbronnen die nodig zijn voor onderzoek en ontwikkelen detectielogica die past bij de omgeving. Responsprocedures koppelen bevindingen vervolgens aan uitvoerbare acties. Testen laat zien of het team de benodigde informatie kan krijgen en de beoogde ingreep kan uitvoeren.
Dit is praktisch engineeringwerk. Tijdens de respons op Log4j ontwikkelden onze engineers detectielogica terwijl het incident zich ontvouwde en doorzochten ze beschikbare logs op sporen van misbruik. Een gepubliceerd interview beschrijft hoe securityspecialisten en klantteams hun kennis bundelden om de getroffen omgevingen te begrijpen en actie te organiseren.
Voor herstel levert MCDR onderzoeksbevindingen die helpen vast te stellen wat er is geraakt en wat er is veranderd. Die bevindingen ondersteunen de engineers en service owners die herstelbesluiten nemen.
MCDR is een cruciaal deel van het antwoord, en een van de dingen die een organisatie goed moet regelen. Snel herstellen hangt ook af van snel patchen, weten wat je draait, beperken hoe ver een aanvaller kan komen en de respons hebben geoefend. De informatiepositie en het team met context zijn het beginpunt.
Een organisatie kan deze voorbereiding testen op één kritieke dienst, door een geloofwaardig aanvalsscenario helemaal tot en met herstel door te lopen. De verantwoordelijken moeten kunnen uitleggen welk bewijs het besluit om de dienst te hervatten onderbouwde en welke onzekerheid er overbleef.
De registraties die nodig zijn voor onderzoek, en de relaties tussen de mensen die ze gebruiken, moeten worden opgebouwd terwijl het bedrijf normaal draait. Hiaten die dan worden ontdekt, kunnen worden aangepakt voordat een storing ze omzet in commerciële schade.
Als herstel moet wachten op informatie, blijft het bedrijf betalen voor het wachten.
Bronnen
[1] Microsoft Security Research and Microsoft Threat Intelligence. AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise. October 21, 2026.
[2] Ahold Delhaize. Ahold Delhaize update on status of cybersecurity incident. October 19, 2026.
[3] NCSC. Update PHP kwetsbaarheden nog steeds reden om direct te patchen. October 21, 2026, updated October 23, 2026.
[4] Schuberg Philis. Jenda Brands on being a Mission Critical Security Engineer and a detection and response expert. April 9, 2024.
[5] NIST. Incident Response Recommendations and Considerations for Cybersecurity Risk Management A CSF 2.0 Community Profile. SP 800-61 Rev. 3, April 2025, recovery guidance on page 34.
[6] AGF reporting estimates made for RTL Z. Cyberproblemen kosten Albert Heijn naar schatting 120 tot 150 miljoen euro omzet. October 20, 2026.
[7] Albert Heijn. Mediastatement inzake cybersecurity incident. Updates of October 21 and 23, 2026.
