Skip to main content

De klok tikt sneller dan ooit: waarom patchen na een CVE-publicatie geen dagen meer kan wachten

Jarenlang was patchmanagement een redelijk voorspelbaar proces. Er werd een beveiligingsupdate gepubliceerd, IT-afdelingen beoordeelden de impact, planden een onderhoudsvenster en rolden de update gecontroleerd uit. Soms dezelfde dag, soms een paar dagen later en soms zelfs pas tijdens het eerstvolgende onderhoudsweekend.
Die aanpak staat steeds meer onder druk.

De tijd tussen het publiceren van een kwetsbaarheid en het daadwerkelijk misbruiken ervan wordt namelijk razendsnel korter. Waar vroeger menselijke aanvallers handmatig onderzoek deden naar nieuwe beveiligingslekken, zien we nu dat geautomatiseerde aanvallen vrijwel direct starten zodra een kwetsbaarheid openbaar wordt gemaakt.

Dat stelt organisaties voor een lastige vraag: hoe lang kun je tegenwoordig nog verantwoord wachten met patchen?

De keerzijde van transparantie

Wanneer een softwareleverancier een beveiligingsupdate publiceert, gebeurt dat meestal samen met een CVE (Common Vulnerabilities and Exposures). In die publicatie staat niet alleen dát er een probleem bestaat, maar vaak ook waar het probleem zich bevindt, welke versies kwetsbaar zijn en soms zelfs hoe de kwetsbaarheid werkt.

Dat is logisch. Organisaties moeten immers kunnen beoordelen of zij risico lopen.

Maar diezelfde informatie is ook beschikbaar voor cybercriminelen.

Op het moment dat een CVE wordt gepubliceerd, weten aanvallers precies waar ze moeten kijken. De kwetsbaarheid die eerder alleen bekend was bij de leverancier en onderzoekers, ligt dan op straat. Vanaf dat moment ontstaat een race tussen aanvallers en organisaties.

De vraag is niet meer óf kwaadwillenden de informatie zien, maar hoe snel zij deze kunnen gebruiken.

AI verandert het speelveld

Wat deze ontwikkeling extra interessant maakt, is de invloed van AI.

Vroeger moest een aanvaller een nieuwe kwetsbaarheid analyseren, testomgevingen opzetten en onderzoeken hoe deze misbruikt kon worden. Dat kostte tijd.

Tegenwoordig kunnen geautomatiseerde systemen en AI-gedreven tooling grote delen van dat proces versnellen. Zodra technische informatie beschikbaar komt, kunnen analyses, scans en exploitpogingen grotendeels automatisch plaatsvinden.

Daardoor wordt de tijd tussen publicatie en aanval steeds korter.

Er zijn inmiddels meerdere voorbeelden bekend waarbij organisaties binnen minuten na de openbaarmaking van een kwetsbaarheid al doelwit werden van geautomatiseerde scans en aanvalspogingen. In sommige gevallen werden werkende exploits binnen enkele uren ontwikkeld en verspreid.

Voor organisaties betekent dit dat het traditionele idee van “we plannen deze update volgende week wel in” steeds minder houdbaar wordt.

De praktijk is weerbarstig

Toch is het eenvoudig om vanaf de zijlijn te roepen dat alles direct gepatcht moet worden.

De werkelijkheid is ingewikkelder.

Een update kan productieprocessen verstoren. Kritische applicaties kunnen uitvallen. Medewerkers kunnen tijdelijk niet werken. Sommige organisaties draaien software die eerst uitgebreid getest moet worden voordat een update veilig kan worden uitgerold.

Voor productiebedrijven, zorginstellingen en organisaties met bedrijfskritische systemen is “even patchen” vaak geen kwestie van een druk op de knop.

Daarom ontstaat regelmatig een discussie tussen beschikbaarheid en veiligheid.

Aan de ene kant wil je maximale stabiliteit. Aan de andere kant weet je dat iedere minuut zonder patch een potentieel risico vormt.

Wat kost meer?

Misschien is dat wel de belangrijkste vraag om te stellen.

Wat kost uiteindelijk meer?

Een gecontroleerde verstoring van een uur om een kritieke beveiligingsupdate uit te voeren?

Of een ransomware-aanval die systemen dagenlang onbruikbaar maakt, gegevens versleutelt, klanten raakt en leidt tot herstelkosten, reputatieschade en mogelijk zelfs meldplichtige datalekken?

Veel organisaties zijn gewend om de impact van een onderhoudsvenster direct te zien. Gebruikers merken immers dat systemen tijdelijk niet beschikbaar zijn.

De schade van een mogelijke aanval voelt vaak abstracter. Tot het moment dat die aanval daadwerkelijk plaatsvindt.

Dan blijkt vaak dat de tijdelijke hinder van een update in geen verhouding staat tot de gevolgen van een succesvolle inbraak.

Tijd voor een andere discussie

Wij denken dat de discussie niet langer zou moeten gaan over óf er snel gepatcht moet worden.

De discussie moet gaan over hoe organisaties hun processen zo kunnen inrichten dat kritieke beveiligingsupdates sneller en veiliger kunnen worden uitgerold.

Dat vraagt om keuzes.

Kunnen onderhoudsvensters flexibeler worden ingericht? Zijn systemen voldoende redundant om updates zonder grote impact uit te voeren? Kunnen risico’s beter worden geclassificeerd zodat kritieke CVE’s direct aandacht krijgen?

En misschien de belangrijkste vraag van allemaal:

Accepteren we nog steeds dezelfde patchtermijnen als vijf jaar geleden, terwijl aanvallers inmiddels beschikken over veel snellere en geautomatiseerde middelen?

Conclusie

De tijd tussen het bekend worden van een kwetsbaarheid en het misbruik ervan wordt steeds kleiner. Dat vraagt om een heroverweging van traditionele patchprocessen.

Natuurlijk zal niet iedere update direct uitgevoerd kunnen worden. Maar organisaties doen er goed aan kritisch te kijken naar de impact van uitstel. Want zodra een CVE openbaar wordt gemaakt, begint de klok te lopen.

En die klok tikt tegenwoordig een stuk sneller dan veel organisaties beseffen.

Hoe kijkt jouw organisatie hiernaar? Moet een kritieke securitypatch direct worden uitgerold, ook als dit tijdens kantooruren voor verstoring zorgt? Of blijft een gecontroleerd onderhoudsvenster leidend? De discussie is relevanter dan ooit.

 

Meer weten over dit onderwerp en hoe je dergelijke risico's sneller kunt mitigeren? Neem hierover contact op met

Rolf Warntjes
partner BCONN