Niet elke critical CVE is automatisch kritiek voor jouw organisatie. Of een kwetsbaarheid daadwerkelijk urgent is, hangt af van context: staat het kwetsbare systeem bij jou in gebruik, is het bereikbaar vanaf het internet, en bestaat er al een werkende exploit? Een CVSS-score van 9.8 zegt iets over de ernst van een kwetsbaarheid in het algemeen, maar niets over het risico dat jij persoonlijk loopt. In dit artikel beantwoorden we de meest gestelde vragen over CVE-beoordeling, CVSS-scores en hoe je vulnerability management opbouwt dat echt aansluit bij jouw situatie.
Wat bepaalt of een CVE écht kritiek is voor jouw situatie?
Of een CVE kritiek is voor jouw organisatie, wordt bepaald door drie factoren: of het kwetsbare systeem bij jou in gebruik is, of dat systeem bereikbaar is voor een aanvaller, en of er een realistische exploit beschikbaar is. Een kwetsbaarheid die in theorie een score van 10.0 haalt maar alleen van toepassing is op software die jij niet gebruikt, is in de praktijk irrelevant voor jouw risicobeoordeling.
Dit klinkt eenvoudig, maar in de praktijk worstelen veel organisaties hier dagelijks mee. Securityteams worden overspoeld met meldingen van nieuwe critical CVE’s, terwijl de capaciteit om ze allemaal te beoordelen beperkt is. Het gevolg is dat teams óf alles als urgent behandelen en vastlopen, óf een prioritering hanteren die niet goed is doordacht.
De kern van goede CVE-beoordeling is contextualisering. Dat betekent: koppel elke nieuwe kwetsbaarheid aan je eigen asset inventory, je netwerktopologie en je dreigingslandschap. Pas dan kun je bepalen of een patch morgen moet worden doorgevoerd of volgende maand.
Hoe werkt de CVSS-score en waar schiet die tekort?
De CVSS-score (Common Vulnerability Scoring System) is een gestandaardiseerde methode om de ernst van een kwetsbaarheid te beoordelen op een schaal van 0 tot 10. De score is gebaseerd op factoren zoals aanvalsvector, complexiteit, vereiste privileges en de impact op vertrouwelijkheid, integriteit en beschikbaarheid. Een hoge score signaleert dat een kwetsbaarheid in ideale omstandigheden voor een aanvaller ernstig is.
Maar precies daar zit de beperking: CVSS beoordeelt kwetsbaarheden in isolatie, zonder rekening te houden met jouw specifieke omgeving. De score houdt geen rekening met:
- Of het kwetsbare systeem bij jou überhaupt in gebruik is
- Of het systeem intern staat of publiek bereikbaar is
- Of er compenserende maatregelen zijn zoals netwerksegmentatie of aanvullende authenticatie
- Of er actieve exploitatie in het wild plaatsvindt
- Hoe het kwetsbare systeem zich verhoudt tot andere systemen in jouw omgeving
Een CVSS-score is daarmee een startpunt voor beoordeling, geen eindoordeel. Organisaties die uitsluitend op basis van CVSS-scores prioriteren, lopen het risico om veel tijd te steken in patches die weinig impact hebben op hun werkelijke aanvalsoppervlak, terwijl gevaarlijkere combinaties van zwaktes onopgemerkt blijven.
Wat is het verschil tussen CVSS-score en werkelijk exploitatierisico?
Het werkelijke exploitatierisico is de kans dat een aanvaller een kwetsbaarheid succesvol misbruikt in jouw specifieke omgeving. Dat is fundamenteel anders dan de CVSS-score, die de theoretische ernst van een kwetsbaarheid weergeeft onder optimale aanvalsomstandigheden. Een kwetsbaarheid met een hoge CVSS-score kan een laag exploitatierisico hebben als jouw omgeving de aanvalsvector neutraliseert.
Een praktisch voorbeeld: een kritieke kwetsbaarheid in een webserver die alleen intern bereikbaar is, heeft een veel lager werkelijk risico dan een kwetsbaarheid met een lagere CVSS-score in een publiek bereikbare applicatie die direct is gekoppeld aan je productiedatabase.
Twee aanvullende factoren bepalen het werkelijke exploitatierisico sterk:
- Exploitbeschikbaarheid: Bestaat er al een publiek beschikbare exploit of proof-of-concept? Databases zoals CISA’s Known Exploited Vulnerabilities (KEV) catalogus geven hier inzicht in.
- Aanvalspadcontext: Kan een aanvaller deze kwetsbaarheid combineren met andere zwaktes in jouw omgeving om een werkend aanvalspad te creëren? Een handmatige pentest brengt dit soort gecombineerde risico’s in kaart, iets wat een geautomatiseerde scanner niet kan.
Welke vragen moet je stellen bij elke nieuwe critical CVE?
Bij elke nieuwe critical CVE moet je minimaal vijf vragen beantwoorden voordat je bepaalt hoe urgent de patch is. Deze vragen vormen samen een snelle risicobeoordeling die CVSS-scores in context plaatst en je helpt prioriteiten te stellen.
- Gebruiken wij het kwetsbare systeem of de kwetsbare software? Als het antwoord nee is, stop dan hier. De CVE is irrelevant voor jouw organisatie.
- Is het kwetsbare systeem bereikbaar voor een aanvaller? Staat het publiek op internet, of alleen intern? Is er netwerksegmentatie aanwezig?
- Bestaat er al een werkende exploit? Controleer CISA KEV en bronnen zoals Exploit-DB. Actieve exploitatie in het wild verhoogt de urgentie sterk.
- Welke data of systemen zijn bereikbaar via dit aanvalspad? Een kwetsbaar systeem zonder toegang tot gevoelige data of kritieke processen heeft een ander gewicht dan een systeem dat centraal staat in je infrastructuur.
- Zijn er compenserende maatregelen aanwezig? Denk aan WAF-regels, aanvullende authenticatie, monitoring of netwerksegmentatie die de exploitatie bemoeilijken.
Deze vijf vragen kosten weinig tijd maar voorkomen dat je resources verspilt aan patches die nauwelijks bijdragen aan je werkelijke veiligheid.
Wanneer is een CVE met lage score toch urgent voor jouw organisatie?
Een CVE met een lage CVSS-score kan urgent zijn wanneer die kwetsbaarheid onderdeel wordt van een aanvalspad waarbij meerdere zwaktes worden gecombineerd. Aanvallers denken niet in losse bevindingen, maar in ketens van stappen die samen leiden tot toegang tot wat ze willen bereiken. Een lage score betekent niet dat een kwetsbaarheid onschadelijk is, alleen dat ze in isolatie beperkte impact heeft.
Concrete situaties waarin een lage CVE-score toch directe actie vereist:
- De kwetsbaarheid geeft een aanvaller een eerste voet aan de grond (initial access) in jouw omgeving, ook al is de directe impact beperkt
- Ze is combineerbaar met een misconfiguratie in je cloudomgeving of te ruime permissies op accounts, waardoor privilege escalation mogelijk wordt
- Ze bevindt zich in een systeem dat toegang heeft tot privileged accounts of kritieke bedrijfsprocessen
- Ze maakt laterale beweging mogelijk tussen systemen die normaliter gescheiden zijn
Dit is precies de reden waarom kwalitatief securityonderzoek verder kijkt dan individuele bevindingen. Een aanvaller die een SSRF-kwetsbaarheid combineert met een managed identity, ruime Azure RBAC-rechten en toegang tot een Key Vault kan volledige controle over cloudresources krijgen, terwijl geen van die stappen op zichzelf als critical is beoordeeld. Losse scores vertellen dat verhaal niet.
Hoe bouw je een contextueel vulnerabilitymanagementproces op?
Een contextueel vulnerabilitymanagementproces bouw je op door kwetsbaarheden altijd te beoordelen in relatie tot jouw specifieke omgeving, niet op basis van generieke scores alleen. Dat vraagt om een gestructureerde aanpak met vier bouwstenen: een actuele asset inventory, inzicht in je aanvalsoppervlak, een prioriteringsmodel dat context meeneemt, en continue monitoring in plaats van periodieke snapshots.
Stap 1: Zorg voor een actuele asset inventory
Je kunt geen kwetsbaarheid beoordelen als je niet weet welke systemen je hebt. Een actuele inventarisatie van alle assets, inclusief cloudresources, SaaS-applicaties en third-party koppelingen, is de basis van alles. Veel organisaties onderschatten hoe snel hun omgeving verandert door nieuwe applicaties, accounts en cloudresources.
Stap 2: Koppel kwetsbaarheden aan aanvalsoppervlak en context
Zodra een nieuwe CVE verschijnt, koppel je die direct aan je asset inventory. Welke systemen zijn kwetsbaar? Zijn ze intern of extern bereikbaar? Welke data of processen zijn via die systemen bereikbaar? Dit geeft een directe prioritering op basis van werkelijk risico in plaats van theoretische ernst.
Stap 3: Gebruik een gelaagd prioriteringsmodel
Een effectief model kijkt naar drie lagen: bekende kwetsbaarheden en CVE’s, individuele zwaktes zoals misconfiguraties en te ruime permissies, en gecombineerde aanvalspaden waarbij meerdere zwaktes samen een serieus risico vormen. De derde laag wordt door veel organisaties over het hoofd gezien maar is vaak waar het echte risico zit.
Stap 4: Test continu in plaats van eenmalig
Een jaarlijkse pentest geeft inzicht op één moment, maar je omgeving verandert doorlopend. Nieuwe applicaties, gewijzigde permissies, extra cloudresources: elke wijziging kan een nieuw aanvalspad openen. Continuous testing houdt inzicht actueel, zodat je niet alleen weet dat je op de testdag veilig was, maar ook de 364 dagen erna. Meer over deze aanpak lees je op de pagina over Continuous-Q.
Hoe Q-Cyber helpt bij CVE-beoordeling en vulnerability management
Wij helpen organisaties om verder te kijken dan CVSS-scores en generieke kwetsbaarheidslijsten. In plaats van een stapel bevindingen zonder context, brengen wij in kaart welke kwetsbaarheden in jouw specifieke omgeving daadwerkelijk een risico vormen en hoe aanvallers die zouden combineren tot een werkend aanvalspad.
Concreet biedt Q-Cyber:
- Handmatige pentests waarbij onze ethical hackers denken zoals een echte aanvaller en gecombineerde aanvalspaden blootleggen die scanners missen
- Contextuele risicoanalyse waarbij bevindingen worden beoordeeld op basis van jouw omgeving, niet op basis van generieke scores
- Continuous-Q voor organisaties die na een baseline pentest doorlopend inzicht willen houden in hun aanvalsoppervlak
- Pragmatisch advies over patchprioritering en compenserende maatregelen, onafhankelijk van softwareleveranciers
Wil je weten welke CVE’s in jouw omgeving daadwerkelijk urgent zijn? Neem contact op en we kijken samen naar jouw situatie.
Gerelateerde artikelen
- Hoe denkt een hacker tijdens een cyberaanval?
- Wat zegt het aantal gevonden vulnerabilities over de kwaliteit van een pentest?
- Factuurhackfraude: wat is het en hoe voorkom je het?
- Informatiebeveiliging in de zorg: speciale eisen
- Wat is cloud security?
- Antivirus vs. EDR: wat heeft jouw bedrijf nodig?
- Wat is business continuity management?
- Wat is een penetratietest en wanneer heb je die nodig?
- Phishing herkennen: 7 tips voor medewerkers
- Hoe kies je tussen verschillende pentest methodologieën?