IT realiteit

De kwetsbaarheid is niet het lek. De kwetsbaarheid is de tijd.

In cybersecurity gaat het debat steeds vaker over AI. AI kan sneller kwetsbaarheden vinden, sneller patronen herkennen en in sommige gevallen zelfs voorstellen doen voor een oplossing. Dat klinkt indrukwekkend, en dat is het ook. Maar ondertussen wordt een ongemakkelijke waarheid vaak genegeerd: het echte probleem zit niet in het vinden van kwetsbaarheden. Het probleem zit in alles wat daarna komt.

Want een kwetsbaarheid die in minuten wordt ontdekt, maar pas weken later wordt opgelost op productiesystemen, is nog steeds een open deur. Misschien zelfs een gevaarlijkere deur, omdat nu ook aanvallers weten waar hij zit.

AI versnelt dus vooral het begin van het proces. Maar security is geen sprint tot de detectie. Security is pas effectief als de oplossing daadwerkelijk actief is op het systeem dat risico loopt. En precies daar begint de traagheid.

Drie klokken, één pijnlijk gat

Bij kwetsbaarheden lopen in de praktijk drie verschillende klokken tegelijk. De eerste is de ontdekking: een onderzoeker, leverancier of AI-model identificeert een probleem. Dat kan tegenwoordig in uren of zelfs minuten. De tweede klok is de ontwikkeling van een fix: analyse, validatie, patchontwikkeling en release. Dat duurt dagen tot weken. De derde klok is de uitrol: testen, impactanalyse, change management, afhankelijkheden, onderhoudsvensters en uiteindelijk deployment. Daar loopt de tijd vaak pas echt op.

In moderne SaaS-omgevingen kan dit soms binnen een paar dagen worden opgelost. Maar in traditionele enterprise-omgevingen is dertig tot negentig dagen tussen ontdekking en daadwerkelijke patching nog steeds geen uitzondering. In OT, legacy of sterk gereguleerde omgevingen loopt dat soms op tot maanden. Soms wordt een patch zelfs nooit toegepast, omdat de operationele impact groter lijkt dan het risico. Totdat dat risico zich ineens meldt in de vorm van een incident.

Daarmee ontstaat een ongemakkelijke realiteit: AI verkleint de tijd om een lek te vinden, maar de organisatie verkleint niet automatisch de tijd om het lek te dichten.

Sneller ontdekken maakt het gat soms juist groter

Dat klinkt contra-intuïtief, maar het is wel degelijk een reëel risico. Als kwetsbaarheden sneller worden gevonden, neemt ook de snelheid toe waarmee informatie beschikbaar komt voor aanvallers. De tijd tussen disclosure en exploit is de afgelopen jaren al sterk afgenomen. In sommige gevallen verschijnen exploitvarianten binnen uren of dagen nadat een kwetsbaarheid bekend wordt.

Als de organisatie aan de andere kant nog weken nodig heeft om te patchen, ontstaat een gevaarlijk asymmetrisch speelveld. Niet omdat AI faalt, maar omdat AI één deel van de keten versnelt terwijl de rest van de keten blijft functioneren alsof het nog 2012 is.

Securityteams vieren dan dat ze sneller zien wat er mis is, terwijl het risico in werkelijkheid langer zichtbaar én exploiteerbaar op tafel ligt.

Dat is geen vooruitgang. Dat is een versnelde confrontatie met een traag proces.

Patchen is geen technisch probleem meer

Veel organisaties praten nog steeds over patching alsof het een technisch issue is. Alsof de uitdaging zit in het downloaden van een update en op install drukken. In werkelijkheid is patching al lang een organisatievraagstuk geworden.

Een patch moet worden getest. Er moet worden gekeken naar afhankelijkheden. Applicatie-eigenaren moeten akkoord geven. Change Advisory Boards moeten plannen. Legacy-systemen blijken niet compatibel. Productie mag niet uit. Er is een freeze-periode. Er is geen capaciteit. Er is twijfel over impact. Er is onzekerheid over regressie.

En zo verandert een kritieke kwetsbaarheid van een technisch risico in een bestuurlijk proces.

Dat is begrijpelijk. Maar het verandert niets aan het feit dat aanvallers niet wachten op een CAB-agenda.

De verleiding van automatisch patchen

De logische reactie is simpel: als mensen te traag zijn, laat AI of automatisering dan ook het patchen versnellen. En daar zit een interessante, maar ook gevaarlijke route.

Autonomous remediation, risk-based patching en AI-gedreven change automation worden steeds vaker genoemd als oplossing. Het idee is aantrekkelijk: systemen beoordelen zelf risico’s, testen patches automatisch en rollen fixes sneller uit zonder menselijke vertraging.

In theorie verklein je daarmee het patch-window drastisch.

In praktijk introduceer je nieuwe risico’s.

Een automatische patch op een kwetsbaar systeem kan net zo goed een productieproces stilleggen. Een verkeerde risicoclassificatie kan leiden tot fixes op het verkeerde moment. Een supply-chain issue in een geautomatiseerde updateketen krijgt ineens veel grotere impact. En wie is uiteindelijk verantwoordelijk als een AI-gedreven patch een bedrijfskritische omgeving onderuit haalt?

Sneller patchen klinkt rationeel, totdat automatisering een storing op schaal veroorzaakt.

De oplossing is dus niet blind automatiseren. De oplossing is slimmer differentiëren.

Niet elke patch verdient dezelfde behandeling

Hier maken veel organisaties nog een fundamentele fout. Alles loopt door dezelfde change machine.

Een browser-update, een remote code execution in een internet-facing component en een laag-risico library issue komen in hetzelfde proces terecht, met vergelijkbare governance, vergelijkbare wachttijden en vergelijkbare organisatorische frictie.

Dat is absurd.

Kwetsbaarheden moeten niet alleen technisch beoordeeld worden, maar operationeel geclassificeerd op exploitability, exposure en business impact. Sommige patches moeten door een standaardproces. Andere horen in een fast lane. Weer andere moeten gecompenseerd worden met tijdelijke mitigaties totdat patching veilig kan plaatsvinden.

Niet alles hoeft sneller. Het juiste moet sneller.

De echte oplossing zit in het verkorten van de risicotijd

Securityteams sturen nog te vaak op metrics zoals “hoeveel kwetsbaarheden gevonden” of “hoe snel gescand”. Dat zijn comfortabele dashboards, maar ze zeggen weinig over daadwerkelijke blootstelling.

De metric die ertoe doet is simpel: hoe lang is een kwetsbaarheid werkelijk exploiteerbaar in mijn omgeving?

Dat betekent dat organisaties anders moeten gaan denken. Niet alleen sneller detecteren, maar deployment automatiseren waar het veilig kan. Teststraten verkorten. Segmentatie en compensating controls inzetten als patching vertraagt. Kritieke internet-facing systemen een aparte patchroute geven. Configuratiebeheer op orde brengen zodat impact voorspelbaar wordt. En vooral: stoppen met doen alsof elk securityprobleem oplosbaar is met meer detectie.

Want detectie zonder snelle remediatie is in essentie een alarm dat afgaat in een gebouw waarvan de branddeur nog op slot zit.

De ongemakkelijke conclusie

AI gaat kwetsbaarheden sneller vinden dan veel organisaties ze kunnen oplossen. Dat is geen toekomstscenario meer, dat is nu al zichtbaar.

Dat betekent dat security niet langer alleen een detectieprobleem is, maar steeds meer een tijdsprobleem. Een procesprobleem. Een governanceprobleem.

En misschien is dat wel de pijnlijkste conclusie van allemaal.

We hebben jarenlang gedacht dat het grootste risico zat in het niet zien van kwetsbaarheden.

Maar het echte risico blijkt steeds vaker dat we ze wél zien, precies weten wat er moet gebeuren, en vervolgens weken nodig hebben om het daadwerkelijk te doen.

Dat is geen technologisch tekort.

Dat is organisatorische latency. En aanvallers maken daar dankbaar gebruik van.