Een vulnerability management team krijgt elke maandagochtend een rapport van vierduizend regels binnen. Kritiek, hoog, gemiddeld, laag. De scanner deed precies waarvoor hij is aangeschaft. Wat er in de uren daarna gebeurt bepaalt of dat rapport risico verlaagt of alleen een archief vult.
Het knelpunt van een vulnerability management team zit zelden in de detectie. De tooling staat er, de licentie is betaald, de scans draaien op schema. Alleen ligt het besluit over wat vandaag gepatcht wordt en wat kan wachten nergens formeel belegd. Het resultaat is voorspelbaar: alles wat rood kleurt krijgt aandacht, oranje schuift door, en na twee kwartalen staat de teller op duizenden bevindingen waar niemand nog eigenaar van is.
Scannen is techniek, prioriteren is organisatie
Het NCSC beschrijft kwetsbaarhedenbeheer als een cyclisch proces van vijf fases: beoordelen, prioriteren, behandelen, evalueren en verbeteren. Twee daarvan zijn technisch van aard. De overige drie draaien om afwegingen, mandaat en opvolging. Een vulnerability management team dat alleen op scannen en patchen is ingericht produceert dus activiteit zonder richting.
De casus die het NCSC daarbij uitwerkt legt de kern bloot. Een set netwerkprinters viel jarenlang buiten de asset-inventarisatie, met verouderde firmware en zwakke wachtwoorden. Geen scanner had dat opgelost, want de apparaten stonden nergens geregistreerd. De probleemoorzaak was organisatorisch.
Dat patroon zie je in vrijwel elk kwetsbaarhedenbeheer proces terug. De techniek functioneert. De besluitvorming hapert. Precies dezelfde dynamiek beschreven we eerder bij SIEM-investeringen die stranden zonder getrainde analisten: het gereedschap is zelden het knelpunt.
De vier rollen die het proces dragen
Rollen wegen hier zwaarder dan functietitels. In een team van drie kan iemand prima twee rollen vervullen. Wat niet werkt is een rol die nergens belegd is, want dan valt het besluit stil zodra het spannend wordt. Bij het samenstellen van een securityteam speelt dezelfde afweging.
De vulnerability-analist
Deze rol vertaalt scanoutput naar context. Is de kwetsbare component in jouw omgeving bereikbaar? Draait de aangetaste versie ook echt? Circuleert er publieke exploitcode? Dat is analistenwerk dat dicht tegen threat intelligence aan ligt en iemand vraagt die een advisory kan lezen zonder blind op het CVSS-cijfer te varen. Een vulnerability management team zonder deze rol schuift de interpretatie door naar beheerders die er de tijd noch de context voor hebben.
De asset-owner
De asset-owner weet wat een systeem betekent voor het bedrijfsproces. Wat valt stil als het een nacht offline gaat? Zonder die inbreng kan een vulnerability management team de bedrijfsessentie niet scoren, en zonder essentie is elke prioritering een gok. Het NCSC benadrukt niet voor niets dat de risico-eigenaar aan tafel hoort tijdens het prioriteren.
De patch-engineer
Uitvoeren is een vak apart: testen voor uitrol, onderhoudsvensters afstemmen, terugrolscenario’s klaarzetten. Een patch-engineer die alleen updates aanzet en op het beste hoopt veroorzaakt meer downtime dan de kwetsbaarheden zelf. In OT-omgevingen wordt die spanning nog scherper, zoals we beschreven bij het verschil tussen OT- en IT-security.
De risico-eigenaar
Accepteren is een volwaardige behandeloptie naast updaten en mitigeren. Alleen mag die keuze niet impliciet ontstaan doordat een ticket doodbloedt. Iemand met mandaat zet er zijn naam onder, met een einddatum en een herbeoordelingsmoment erbij. Dit is de rol die in de praktijk het vaakst ontbreekt, en het is precies de rol die een vulnerability management team nodig heeft om nee te kunnen zeggen tegen zijn eigen backlog.
Een patch prioriteit framework dat meer doet dan CVSS
CVSS zegt iets over de theoretische ernst van een kwetsbaarheid en niets over jouw omgeving. Een 9,8 achter drie netwerklagen zonder bedrijfsdata verdient minder haast dan een 6,5 op een internetgerichte applicatie met klantgegevens. Een bruikbaar patch prioriteit framework combineert daarom meerdere signalen die een vulnerability management team los van elkaar kan wegen.
Het NCSC werkt met vier componenten die je per kwetsbaarheid scoort: blootstelling, essentie van het systeem, actuele dreiging en impact bij misbruik. Het gemiddelde van die scores bepaalt de volgorde. Twee internationale bronnen vullen dat beeld aan. De KEV-catalogus van CISA bevat kwetsbaarheden met betrouwbaar bewijs van actief misbruik in het veld en een duidelijke herstelactie. EPSS van FIRST publiceert dagelijks de kans dat een CVE binnen dertig dagen wordt misbruikt.
| Signaal | Wat het je vertelt | Wie levert het aan |
| CVSS-score | Theoretische ernst, los van jouw omgeving | Leverancier of NVD |
| KEV-vermelding | Bewijs van actief misbruik in het veld | CISA-catalogus |
| EPSS-waarde | Kans op misbruik binnen dertig dagen | FIRST |
| Blootstelling | Of het systeem vanaf internet te bereiken is | Netwerk- en assetbeheer |
| Bedrijfsessentie | Wat stilvalt zodra het systeem eruit ligt | Asset-owner |
| Herstelinspanning | Downtime, testlast en terugrolrisico | Patch-engineer |
CISA vertaalt vergelijkbare signalen in SSVC, een beslisboom met vier uitkomsten: Track, Track*, Attend en Act. Waar een score een discussie opent, sluit een beslisboom hem. Een vulnerability management team dat vooraf heeft vastgelegd welke combinatie van blootstelling en misbruikbewijs tot Act leidt hoeft op dinsdagochtend geen vergadering te beleggen.
Een framework moet eerlijk zijn over capaciteit. Genereert het meer werk dan het team aankan, dan wordt het binnen een kwartaal genegeerd. Reken door hoeveel patchacties per week haalbaar zijn voordat je drempelwaarden vastlegt. Dat is dezelfde rekensom die speelt bij de verdeling van je securitybudget.
De SLA-discussie met dev en ops
Hier struikelt het kwetsbaarhedenbeheer proces in de meeste organisaties, en het is de plek waar een vulnerability management team zijn geloofwaardigheid wint of verliest. Security belooft de directie dat kritieke kwetsbaarheden binnen zeven dagen dicht zijn. Ops hanteert een wijzigingsstop rond de kwartaalafsluiting. Development zit midden in een release en de betreffende library-update breekt de build. Alle drie hebben ze gelijk vanuit hun eigen doelstelling.
Een SLA die op papier zeven dagen belooft en in de praktijk zes weken duurt is schadelijker dan helemaal geen SLA, omdat het management denkt dat het risico beheerst is. Drie afspraken helpen hier meer dan een strengere norm.
Differentieer de termijn naar blootstellingsklasse in plaats van naar ernstlabel. Een internetgerichte component krijgt een andere klok dan een intern systeem, ongeacht wat de scanner ervan vindt.
Leg onderhoudsvensters vast in de release-kalender van development, niet in een los securityschema. Wat buiten de planning van het bouwende team valt gebeurt structureel te laat.
Benoem één escalatiepad met een naam erbij. Dreigt een deadline te verlopen, dan gaat het besluit naar de risico-eigenaar, die accepteert of extra capaciteit vrijmaakt. Zonder dat pad wordt stilzwijgen de facto acceptatie. Voor dat gesprek met de directie schreven we een aanpak om je MT mee te krijgen.
Bij organisaties waar dit werkt valt iets anders op: het vulnerability management team zit al vroeg aan tafel bij architectuur- en inkoopkeuzes. Patchbaarheid wordt dan een selectiecriterium, wat achteraf tientallen conflicten scheelt. Diezelfde logica geldt richting leveranciers, zoals we uitwerkten bij detectie van supply chain-risico’s.
Meten zonder vanity-cijfers
Het aantal gesloten bevindingen per maand zegt vrijwel niets. Een vulnerability management team dat duizend lage bevindingen wegwerkt en één actief misbruikte kwetsbaarheid laat staan scoort op die grafiek uitstekend. Het NCSC formuleert de toets scherp: een KPI die bij een goed of slecht resultaat niet tot een besluit leidt, is geen bruikbare KPI.
Vier cijfers doen wel werk voor een vulnerability management team. De doorlooptijd van ontdekking tot herstel, uitgesplitst naar blootstellingsklasse. Het percentage KEV-vermelde kwetsbaarheden dat binnen de afgesproken termijn dicht is. De leeftijdsopbouw van de backlog, omdat een gemiddelde de uitschieters verbergt. En het aandeel geaccepteerde risico’s met een getekende eigenaar en een vervaldatum. Over de bredere opzet hiervan schreven we een framework voor eerlijke teambeoordeling.
Meet ook de belasting. Een kwetsbaarhedenbeheer proces dat wekelijks honderden tickets uitspuugt veroorzaakt hetzelfde effect als een SOC dat verzuipt in alerts. Die uitputting beschreven we bij alert fatigue en burn-outpreventie, en het mechanisme is identiek.
De vaardigheden die dit vraagt
De rollen hierboven vragen mensen die kunnen redeneren over exploiteerbaarheid. Dat is een ander profiel dan iemand die tickets sluit. Het onderscheid tussen beide bepaalt hoe snel een vulnerability management team van scanoutput naar besluit komt.
Voor de analistenkant sluit de opleiding SOC T1 + T2 Analyst goed aan, omdat triage en contextbepaling daar de kern van het programma vormen. Wie de dreigingskant zwaarder wil beleggen komt uit bij de opleiding SOC T3 Analyst, waar hypothesevorming en onderzoek centraal staan. Dat sluit direct aan op wat we schreven over threat hunting opzetten met je bestaande team.
Werkelijke exploiteerbaarheid inschatten leer je het snelst vanaf de aanvallerskant. De opleiding Penetration testing geeft een vulnerability management team het referentiekader om te beoordelen wanneer een theoretische kwetsbaarheid praktisch bruikbaar wordt voor een aanvaller. Dat scheelt veel tijd in de prioriteringsfase.
Heb je die mensen nog niet, dan is intern opleiden vaak sneller dan werven. De opleiding Cyber Security Specialist brengt zij-instromers in vijftien weken op een niveau waarop ze binnen een vulnerability management team zelfstandig meedraaien. Wat dat betekent voor teamopbouw en kosten hebben we uitgewerkt in de vergelijking tussen uitbesteden en intern opbouwen en in de doorrekening van wat een cyberincident werkelijk kost.
Werkgevers die dit voor een heel team willen inrichten vinden op de pagina voor werkgevers de in-company mogelijkheden. Het volledige opleidingsaanbod staat per niveau geordend, de agenda toont de startmomenten.
Beginnen met wat je nu hebt
Een compleet kwetsbaarhedenbeheer proces bouw je niet in een kwartaal. Een werkende versie op kleine schaal wel. Kies je twintig belangrijkste systemen, wijs per systeem een asset-owner aan en leg vast wie de risico-eigenaar is. Draai daarna één volledige cyclus op alleen die twintig: beoordelen, prioriteren, behandelen, evalueren.
Documenteer bij elk besluit waarom je het nam. Die documentatie is het echte product van een vulnerability management team, omdat het de volgende cyclus sneller maakt en de kennis losmaakt van individuen. Gaat dat mis, dan ontstaat hetzelfde probleem als bij playbooks die onder druk niet werken. Schaal daarna op naar de volgende schil systemen. Deze aanpak past binnen het groeipad uit het maturity model met vijf niveaus en bij structurele verbetering van information security via training.
Het verschil tussen organisaties die hun kwetsbaarheden onder controle krijgen en organisaties bij wie dat niet lukt zit zelden in de scanner. Het zit in de vraag of iemand bevoegd is om te beslissen, en of het vulnerability management team die beslissing binnen een werkbare termijn uitgevoerd krijgt. Wil je bespreken hoe je dat voor jouw team inricht, plan dan een kennismaking.
