Er was een tijd waarin je na de bekendmaking van een kwetsbaarheid een paar weken had. Een leverancier bracht een patch uit, je plande een onderhoudsvenster, en de kans dat iemand jou in die tussentijd aanviel was klein, omdat het schrijven van een werkende exploit specialistisch werk was. Die tijd is voorbij. Het schrijven van exploits is geautomatiseerd, het zoeken naar kwetsbare systemen op internet ook, en de eerste aanvallen op een nieuw gepubliceerde kwetsbaarheid komen inmiddels binnen een werkdag. In sommige gevallen binnen enkele uren. Wie op een patchcyclus van weken zit, is per definitie te laat.
Hetzelfde geldt aan de andere kant van de inbraak. Waar een aanvaller vroeger dagen nodig had om zich vanaf een eerste account naar de kroonjuwelen te werken, zien we nu incidenten waarin de tijd van eerste toegang tot impact in minuten wordt gemeten. Geautomatiseerd inloggen met gestolen gegevens, geautomatiseerd doorbewegen, geautomatiseerd uitrollen. De aanvaller wacht niet meer op kantooruren.
Wat dit betekent voor de verdediging
Het eerlijke antwoord is dat veel organisaties hun beveiliging nog hebben ingericht op aannames van vóór deze versnelling: een handmatige prioritering van patches, detectie die pas aanslaat als een aanvaller al een tijdje binnen is, en een responsproces dat begint met een mail naar de IT-afdeling. Elk van die aannames faalt als de tegenstander op machinesnelheid werkt.
Drie verschuivingen zijn nodig. Ze zijn niet nieuw, maar de urgentie is dat wel.
1. Verklein wat van buiten bereikbaar is
Alles wat aan internet hangt, wordt binnen uren na een publicatie geprobeerd. De vraag is dus niet alleen hoe snel je patcht, maar hoeveel er te patchen valt. Elke VPN-gateway, firewall-interface, ouderwetse remote desktop of vergeten testomgeving is een kandidaat. Weet wat er van jou aan internet hangt, haal weg wat niet nodig is, en zet wat overblijft achter identiteit: toegang via een beheerd apparaat en een geverifieerde gebruiker, niet via een open poort. Dat is het praktische gezicht van Zero Trust.
2. Ga ervan uit dat het misgaat, en maak het traag
Assume breach betekent niet dat je het opgeeft; het betekent dat je de aanvaller die binnen is, tijd laat kosten. Segmentering in het netwerk en in de identiteiten: beheerdersrechten die alleen op het moment zelf en voor één taak worden uitgegeven, geen accounts die overal bij kunnen, geen platte netwerken waarin één werkplek de back-upserver kan zien. Elke drempel die je opwerpt is tijd. En tijd is alleen iets waard als je hem gebruikt om te detecteren.
3. Detectie en eerste ingreep moeten net zo snel zijn
Als een aanval in minuten verloopt, is een melding die ’s ochtends wordt opgepakt te laat. De eerste stappen, een sessie beëindigen, een account blokkeren, een apparaat isoleren, moeten automatisch kunnen, op basis van signalen uit identiteit, cloud en werkplek. Een analist beoordeelt daarna wat er gebeurd is en wat er nog moet gebeuren. Andersom werkt niet meer.
Daar hoort een randvoorwaarde bij die vaak onderschat wordt: een actueel overzicht van systemen, accounts, sleutels en tokens. Wie bij een incident eerst moet uitzoeken wat er allemaal is, verliest de uren die hij niet heeft.
Een oefening die we aanraden
Neem je huidige beveiligingsprogramma en doe de volgende aanname: het aantal aanvallen verdrievoudigt, ze verlopen vier keer zo snel, en er wordt actief misbruik gemaakt van kwetsbaarheden waarvoor nog geen patch is. Welke maandelijkse activiteiten moeten dan continu worden? Waar ontbreekt detectie? Welke drempels kun je opwerpen om de aanvaller te vertragen? En wie beslist er om drie uur ’s nachts?
Het is een confronterende oefening, maar geen onmogelijke. Dezelfde technologie die aanvallers versnelt, is beschikbaar voor de verdediging. Ons SOC++ is daar precies op ingericht: detectie op identiteits- en cloudsignalen, geautomatiseerde eerste ingreep, en analisten die je omgeving kennen. Niet omdat het modern klinkt, maar omdat de tegenstander niet meer wacht.