De noodzaak van Risk-Based Vulnerability Management

Het aantal kwetsbaarheden dat jaarlijks wordt gepubliceerd, groeit al jaren. In 2023 waren het er 28.818. In 2024 waren het er 40.009, een stijging van bijna 39% in één jaar (bron). En dat zijn alleen de CVE's die het officiële registratieproces doorlopen hebben. Inmiddels is AI een versneller geworden in het vinden én exploiteren van kwetsbaarheden. Dit leidt tot nog meer meldingen. Veel meer. Implementeer daarom een vorm van Risk-Based Vulnerability Management (RBVM). Want alleen nog 'hoog' en/of 'kritiek' verwerken gaat je ook niet meer redden.

De kwetsbaarheid van CVSS

Niet elke 9.8 is een crisis

Veel organisaties sturen op CVSS-scores. Begrijpelijk: het is een getal, het is beschikbaar en het geeft een gestandaardiseerde indruk van de ernst (severity). Maar CVSS meet de technische ernst van een kwetsbaarheid in een theoretisch vacuüm. Het zegt niets over jouw omgeving, jouw systemen, jouw configuratie of de mate waarin aanvallers de kwetsbaarheid actief misbruiken.

Een CVSS 9.8 op software die je niet gebruikt, is geen probleem. Een CVSS 6.5 op een internet-facing authenticatiecomponent waarvan actieve exploitatie is gemeld, is wél urgent. Wie alleen op 'kale' CVSS-scores stuurt, heeft een false positiveprobleem aan de ene kant (hoge score, geen relevantie) en een false negative risico aan de andere kant (lage score, wél reëel gevaar). Daar is natuurlijk wat aan te doen. Je moet ook wel.

"Maar CVSS meet de technische ernst van een kwetsbaarheid in een theoretisch vacuüm. Het zegt niets over jouw omgeving, jouw systemen, jouw configuratie of de mate waarin aanvallers de kwetsbaarheid actief misbruiken."

SSVC als triagekader

Niet elk signaal verdient een analyse

Stakeholder-Specific Vulnerability Categorization (SSVC) is ontwikkeld door CISA en SEI/CMU als alternatief voor pure CVSS-sturing. De gedachte is simpel: niet elke kwetsbaarheid verdient evenveel aandacht. SSVC helpt je te bepalen welke kwetsbaarheden wél een eigen analyse verdienen en welke je kunt afdoen via een standaard follow-up of zelfs kunt negeren. Dat laatste ligt niet in het karakter van menig security analist 😃

SSVC werkt via een beslisboom. Je doorloopt een aantal vragen die leiden tot een prioriteit. De meest relevante beslisfactoren voor de meeste organisaties zijn:

• Exploitation: wordt de kwetsbaarheid actief misbruikt? Is er publiek beschikbare exploit-code? Of is er (nog) geen bekend misbruik? CISA's Known Exploited Vulnerabilities (KEV) catalog en scores als EPSS (Exploit Prediction Scoring System) zijn hierbij nuttige bronnen. EPSS geeft een kansschatting (0-100%) dat een kwetsbaarheid de komende 30 dagen actief wordt misbruikt.
• Exposure: is het getroffen systeem bereikbaar van buitenaf (internet-facing), of bevindt het zich volledig intern? Systemen aan de buitenrand van je netwerk verdienen meer aandacht dan een niet-geëxporteerde databaseserver in een afgeschermd segment.
• Impact: wat is de verwachte impact als de kwetsbaarheid succesvol wordt misbruikt? Dat hangt sterk af van je BIV-classificatie van het systeem. Een systeem met hoge beschikbaarheidsvereisten weegt anders dan een testomgeving.

Op basis van deze factoren leidt SSVC tot een van vier prioriteiten: Track (monitor, maar doe niets extra's), Track* (monitor nauwlettend), Attend (plan remediation in) of Act (direct handelen). Alleen de kwetsbaarheden die op Attend of Act uitkomen, verdienen een eigen diepgaande analyse.

"SSVC helpt je te bepalen welke kwetsbaarheden wél een eigen analyse verdienen en welke je kunt afdoen via een standaardrespons of zelfs kunt negeren."

Na de triage: de ernst inschatten

Van prioriteit naar actie

Stel dat een kwetsbaarheid na SSVC-triage op Attend of Act uitkomt. Dan begint het echte werk: bepalen wat de ernst is voor jouw specifieke situatie en wat de beste respons is. Hiervoor zijn twee methodieken beschikbaar die verder gaan dan een CVSS-getal.

• De OWASP Risk Rating Methodology laat je de kans en impact apart inschatten via meerdere factoren. Aan de kansenkant kijk je naar de vaardigheden van een aanvaller, de toegankelijkheid van de kwetsbaarheid, de benodigde authenticatie en de detecteerbaarheid. Aan de impactkant kijk je naar technische impact, maar bij voorkeur naar business (!) impact. Het resultaat is een combinatie die je zelf weegt op basis van wat voor jouw organisatie telt. Het is natuurlijk bewerkelijker dan CVSS overnemen, maar het levert een oordeel op dat aansluit bij jouw context. De scores zullen bijna altijd lager zijn dan de CVSS-score.
• De CVSS Environmental Score is de andere route. Hierbij vertrek je vanuit de Base Score en pas je die aan met twee sets aanvullende metrics. De Modified Base Metrics laten je de technische parameters aanpassen aan jouw situatie (is het systeem echt extern bereikbaar?). De Environmental Metrics laten je de BIV-vereisten meewegen die voor jouw organisatie gelden. Beide methodieken vragen hetzelfde: goede informatie over je eigen systemen. Zonder een up-to-date CMDB of assetregistratie is dit moeilijk uitvoerbaar.

Beide methodieken vergen tijd en informatie. Die rechtvaardig je door eerst de triage (SSVC) te doorlopen: je voorkomt zo grotendeels dat je die energie steekt in kwetsbaarheden die er bij nader inzien niet toe doen.

De spanning die (over)blijft

Efficiëntie versus zorgvuldigheid

De kern van RBVM is een balanceeract. Aan de ene kant wil je snel doorpakken: de toestroom van nieuwe (of: bijgewerkte) meldingen is groot en capaciteit is schaars. Aan de andere kant wil je geen false negatives: kwetsbaarheden die je afdoet als Track, terwijl ze in jouw context wél urgent zijn. Die spanning lost zich niet op door betere tooling of methodes alleen. De kwaliteit van SSVC-triage staat of valt met de kwaliteit van de informatie die je erin stopt. Is je assetregistratie betrouwbaar genoeg om te weten welke systemen extern bereikbaar zijn? Heb je per systeem de BIV-classificatie beschikbaar? Weet je welke softwareversies daadwerkelijk draaien? Leg je de (business)kritikaliteit vast?

Ik zie in de praktijk dat dit soort basisinformatie bij gemeenten en andere overheidsorganisaties vaak niet op orde is. Dat maakt RBVM niet onmogelijk, maar wel een stuk lastiger. De false negative is daarin het grootste risico. Een kwetsbaarheid die je mist of te laag inschat, kan weken later als incident terugkomen. Dat is pijnlijker dan een false positive, waarbij je te veel tijd in iets steekt dat achteraf niet urgent bleek. Hanteer de SSVC-beslisboom daarom (eerste) aan de conservatieve kant.

Waar past dit in BIO2 en Cbw?

Alhoewel geen eis, wel een logische invulling

De BIO2 stelt in maatregel 8.8 dat kwetsbaarheden in systemen tijdig worden geïdentificeerd, beoordeeld en behandeld. De Cyberbeveiligingswet (Cbw, art. 21) stelt in aanvulling daarop een zorgplicht voor bestuurders voor het beheersen van risico's. RBVM is een goede invulling van beide: je kunt aantonen dat je kwetsbaarheden systematisch beoordeelt en dat je prioritering is gebaseerd op reëel risico voor jouw organisatie, niet op een getal uit een database.

Dat is ook de redenering die je richting je CISO of bestuur kunt gebruiken. Niet "wij patchen alles met CVSS > 7", maar "wij beoordelen alle kwetsbaarheden via een gestructureerde triagemethode en handelen op basis van exploitatiestatus, blootstelling en impact voor onze specifieke omgeving." Dat is volwassener, en het is eerlijker over wat je wél en niet aandacht geeft.