Vulnerability management als operationele functie, niet als jaarproject

Vulnerability management is een doorlopende operationele functie die bestaat uit vijf onderdelen die elke maand opnieuw draaien: een actueel asset-zicht, een vaste scan-cadans, prioritering op exploiteerbaarheid in jouw omgeving, een remediation-SLA per risicoklasse, en aantoonbaarheid van de doorlooptijd van vondst naar gesloten gat. In de praktijk wordt het in veel organisaties iets anders. Het wordt een jaarlijks project waarin een scanner draait, een rapport wordt opgeleverd, een lijst kwetsbaarheden wordt afgevinkt, en het werk daarna stilvalt tot de volgende cyclus. De functie en het project lijken op elkaar in de vorm, maar ze leveren een tegengesteld resultaat: de functie verlaagt blootstelling structureel, het project legt blootstelling vast op het moment van de scan en laat hem daarna oplopen tot het volgende rapport.

Dit stuk gaat over het verschil. Voor wie de SIEM ruis ziet groeien, de patch-backlog ziet uitdijen en de externe audit ziet aankomen, is het bruikbaarder om vulnerability management opnieuw als functie in te richten dan om er een nieuwe scanner bij te kopen. Wat eromheen hangt aan rapportage, dashboards en tooling is alleen relevant zolang de vijf onderdelen daadwerkelijk draaien.

Waarom is een jaarlijkse scan geen vulnerability management?

Een jaarlijkse scan vertelt je waar je stond op de dag dat hij draaide. Daarna verandert je omgeving elke week: een nieuwe applicatie gaat live, een server-rol wordt aangepast, een leverancier rolt een patch uit die ergens anders een afhankelijkheid breekt, een cloud-team spint een omgeving op die niet in de CMDB staat. De scan van vorig jaar zegt niets over die week. Hij zegt zelfs niets meer over de dag erna, omdat exploitcode voor bekende kwetsbaarheden in een aanmerkelijk deel van de gevallen binnen dagen na publicatie circuleert. Wachten tot de volgende geplande scan is dan geen voorzichtigheid, het is een aanname dat aanvallers zich ook aan jouw kalender houden.

Het NIST Cybersecurity Framework belegt dit niet voor niets in de functies Identify en Protect, met expliciete uitwerkingen in NIST SP 800-40 Revision 4 voor het ontwerpen van een doorlopend patchproces. Het kader spreekt niet over een jaarlijkse cyclus. Het spreekt over continue identificatie van assets, doorlopende beoordeling van blootstelling, en herhaalbare verbeteringen die meetbaar zijn over tijd. ISO/IEC 27002:2022 doet hetzelfde in maatregel 8.8 over technische kwetsbaarheidsbeheersing: de norm verlangt dat informatie over kwetsbaarheden tijdig wordt verkregen, dat de blootstelling wordt beoordeeld in jouw context, en dat er passende maatregelen worden genomen. Tijdig en passend zijn termen met een tempo. Eens per jaar is dat tempo niet.

Het verschil zit ook in wat een scan oplevert. Een scan levert een lijst. Een functie levert een verschil over tijd. Op de lijst staan tienduizenden bevindingen, met een score per bevinding, en zonder ordening op wat in jouw omgeving daadwerkelijk uitbuitbaar is. De functie ordent diezelfde lijst tegen jouw assets, jouw aanvalspaden en jouw blootstelling aan internet, en houdt vervolgens bij hoe lang het duurt voor een bevinding in een bepaalde klasse wordt opgelost. Dat tweede getal, de doorlooptijd, is het werkelijke stuurmiddel. Zonder dat getal weet niemand of de functie specifiek meetbaar effect beschrijven of vertraagt.

Wat moet er minimaal in een operationele VM-cadans zitten?

Een werkbare opzet bestaat uit vijf onderdelen die in een vaste cadans terugkeren. Geen van deze onderdelen vraagt om een nieuwe aankoop. Wat ze wel vragen is dat ze daadwerkelijk zijn belegd, dat de cadans staat, en dat de uitkomsten ergens landen.

Asset-zicht dat aansluit op de werkelijke omgeving. Niet de CMDB van vorig kwartaal, maar een lopend beeld van wat er feitelijk draait, inclusief cloud-resources, schaduw-IT en blootgestelde diensten. Het verschil tussen de CMDB en de werkelijkheid is in de meeste organisaties het eerste gat dat een aanvaller benut. Zonder dit onderdeel scan je een kaart die niet meer klopt.

Een vaste scan-cadans, gedifferentieerd naar risicoprofiel. Externe schil en internet-facing assets vaker dan interne kantoorsystemen, kritieke productie vaker dan secundaire omgevingen, en authenticated scans op de systemen waarvoor dat zinvol is. De cadans hoeft niet ingewikkeld te zijn. Hij moet wel expliciet zijn, want anders sluipt hij richting nul zodra het team druk staat.

Prioritering op exploiteerbaarheid in jouw omgeving. Niet CVSS-volgorde als enige stuurmiddel. FIRST publiceert naast CVSS ook EPSS, een schatting van de kans dat een kwetsbaarheid feitelijk geëxploiteerd wordt in de komende dertig dagen. Gecombineerd met de CISA Known Exploited Vulnerabilities-catalogus en met jouw eigen context (raakt het een kroonjuweel, is het bereikbaar vanaf internet, is er een werkende compenserende maatregel) ontstaat een ordening die zegt waar je vandaag mee begint. Een hoge CVSS-score op een interne testserver zonder netwerkpad zakt. Een matige score op een geëxponeerde dienst die in de KEV-lijst staat, stijgt.

Een remediation-SLA per risicoklasse, en die SLA wordt gehandhaafd. Dit is het onderdeel dat het meest wordt overgeslagen en het meeste verschil maakt. Een SLA spreekt vooraf af binnen hoeveel werkdagen een bevinding in een bepaalde klasse gesloten moet zijn, wie eigenaar is van het sluiten, en wat er gebeurt als de termijn verstrijkt. Zonder die afspraak is elke bevinding op papier even urgent en in de praktijk even uitstelbaar. Met de afspraak verschuift het gesprek van "moeten we dit nu doen" naar "we hebben afgesproken dat dit in zoveel dagen klaar is, wat is de reden dat het er niet is".

Aantoonbaarheid van doorlooptijd, niet alleen van aantal bevindingen. Een rapport dat alleen meldt dat er X kritieke bevindingen waren en Y zijn opgelost, mist het stuurmiddel. Het rapport dat zegt hoe lang een gemiddelde kritieke bevinding open stond, hoe dat verandert per kwartaal, en in welke klasse de SLA stelselmatig wordt overschreden, levert wel sturing op. Dat is ook het cijfer dat een auditor, een verzekeraar en de toezichthouder uiteindelijk willen zien, in plaats van een momentopname.

Wat hier niet bij zit is een tweede scanner, een aparte exposure-engine of een dashboard-laag bovenop wat er al staat. Die dingen kunnen waarde toevoegen, maar ze zijn niet de voorwaarde. De voorwaarde is dat de cadans staat, dat de eigenaar bekend is, en dat de uitkomsten landen waar ze landen moeten. Het Nationaal Cyber Security Centrum benadrukt in zijn handreikingen voor kwetsbaarhedenbeheer dat het gaat om een ingerichte capaciteit, niet om een tool-aanschaf. ENISA komt in opeenvolgende Threat Landscape-rapporten op hetzelfde uit: de organisaties die snel en aantoonbaar remedieren, voelen incidenten anders dan organisaties die snel en aantoonbaar scannen maar traag sluiten.

Hoe weet je of de functie loopt of dat het project verkleed is?

Er is een nuchtere toets, en hij gaat niet over de scanner. Hij gaat over de doorlooptijd. Vraag in je eigen team drie dingen. Wat was de gemiddelde tijd tussen het verschijnen van een kritieke kwetsbaarheid en het sluiten ervan, in de afgelopen drie maanden. In welke klasse stond de SLA het vaakst onder druk, en wat was de reden. Welk percentage van de bevindingen dat als gesloten werd gemeld, kwam in de volgende scan terug omdat de fix incompleet was. Drie vragen, drie getallen. Als geen van de drie te beantwoorden is, dan loopt er geen functie. Dan loopt er een scan-rapport-cyclus, en dat is iets anders.

Een tweede toets gaat over wie de cadans bewaakt. Een functie heeft een eigenaar die de SLA elke week tegen het licht houdt, niet alleen de scanner draaiende houdt. Als die rol niet expliciet belegd is, zakt de cadans naar nul zodra er een incident, een audit of een release druk geeft. Dat is geen falen van het team. Dat is een ontwerpfout: een functie zonder eigenaar leeft op restcapaciteit, en restcapaciteit verdwijnt in een drukke maand.

Een derde toets gaat over change. Vulnerability management botst per definitie met change-management, en in veel organisaties wint change. Een kritieke patch die wacht op het volgende change-window van vier weken, is in de praktijk een geaccepteerde blootstelling van vier weken. Een werkende functie heeft een afgesproken uitzonderingspad voor het kleine deel van de bevindingen dat dat tempo niet verdraagt, met de bijbehorende risicoacceptatie expliciet vastgelegd. Zonder dat pad is de SLA een papieren afspraak die altijd verliest van de change-kalender.

Wat dit betekent voor het gesprek dat jij intern voert

Voor de operationele lead die hiermee intern het gesprek opent: de bruikbare samenvatting is dat vulnerability management geen scanner-vraagstuk is en geen jaarprojectvraagstuk. Het is een functie met vijf onderdelen die elk een eigenaar en een ritme hebben. Naar je CISO is de boodschap dat de stuurinformatie niet zit in het aantal bevindingen, maar in de doorlooptijd per klasse en in de SLA-naleving. Dat is het cijfer dat aantoont dat het programma specifiek meetbaar effect beschrijven of stilstaat, en het is precies het cijfer dat onder NIS2 en in een DORA-context aantoonbaarheid oplevert die verder gaat dan een lijst gesloten tickets.

Naar change-management en operations is de boodschap dat de SLA vooraf moet worden afgesproken en niet ad hoc verdedigd. Naar de leverancier die het uitbesteed scanwerk doet, is de vraag niet "hoeveel kwetsbaarheden vinden we" maar "hoe meet ik dat de doorlooptijd in onze omgeving korter wordt over de tijd, en wie is verantwoordelijk als hij dat niet wordt". Naar het bestuur, op het moment dat de vraag komt, is de bruikbare zin dat je niet meldt hoeveel bevindingen er waren, maar hoe lang ze openstonden en in welke richting dat getal beweegt.

De logische volgende stap is geen offerte voor een nieuw platform, maar een nuchtere inventarisatie van de vijf onderdelen tegen je huidige werkwijze. Heb je een lopend asset-zicht of een verouderde CMDB. Heb je een gedifferentieerde scan-cadans of één frequentie voor alles. Stuur je op CVSS of op exploiteerbaarheid in jouw omgeving. Heb je een SLA per klasse die wordt gehandhaafd, of een lijst zonder termijnen. Meet je doorlooptijd of meet je aantal. Vijf vragen, vijf antwoorden. Op de plek waar het antwoord ontbreekt of "nee" is, ligt het gesprek dat je eerst moet voeren, intern en eventueel met iemand die er onafhankelijk naar kijkt. Pas als die vijf onderdelen staan, levert tooling iets op wat boven het bestaande proces uitstijgt. Andersom koop je een rapport en houd je een blootstelling.