Wat is Vulnerability Management?
Vulnerability management is het doorlopende proces waarmee een organisatie kwetsbaarheden (security-zwakheden) in systemen, applicaties, netwerken en apparaten opspoort, beoordeelt, prioriteert, verhelpt of beheerst en de voortgang daarvan bewaakt. Het doel is voorkomen dat aanvallers bekende zwakke plekken in uw IT- of OT-omgeving misbruiken. Vulnerability management is breder dan patchen: het omvat ook de keuze om een kwetsbaarheid tijdelijk te accepteren of met andere maatregelen af te schermen. In de industrie is dat de normale situatie, omdat een PLC of SCADA-server lang niet altijd direct een update kan krijgen.
🧠 Wat is een kwetsbaarheid precies?
Een kwetsbaarheid is een zwakke plek in software, firmware, hardware of configuratie die een aanvaller kan gebruiken om vertrouwelijkheid, integriteit of beschikbaarheid aan te tasten. Typische voorbeelden:
- Verouderde software met bekende bugs - bijvoorbeeld een Windows-versie op een HMI die geen beveiligingsupdates meer krijgt
- Ongepatchte firmware - in PLC’s, RTU’s, switches of netwerkkaarten van besturingen
- Zwakke of standaardwachtwoorden - een klassieker bij industriële apparatuur die met fabrieksinstellingen in bedrijf gaat
- Configuratiefouten - onnodige open poorten en services, of een webinterface die zonder authenticatie bereikbaar is
- Ontwerpzwakheden - industriële protocollen die geen authenticatie of encryptie kennen
Publiek bekende kwetsbaarheden krijgen een uniek CVE-nummer. Fouten in configuratie of ontwerp hebben dat meestal niet, maar horen wel in het proces thuis: een vergeten testaccount is net zo misbruikbaar als een ongepatcht lek.
🔄 Wat is het verschil met patchmanagement en vulnerability scanning?
De drie begrippen worden vaak door elkaar gebruikt, maar ze zijn niet hetzelfde:
| Begrip | Vraag die het beantwoordt | Resultaat |
|---|---|---|
| Vulnerability Scanning | Welke bekende kwetsbaarheden zitten er in mijn systemen? | Lijst met bevindingen per asset |
| Patchmanagement | Hoe rollen we updates gecontroleerd en veilig uit? | Geteste en geïnstalleerde patches |
| Vulnerability management | Welke kwetsbaarheden pakken we wanneer en hoe aan, en wie is eigenaar? | Prioritering, besluiten, maatregelen en rapportage |
Scanning is dus één informatiebron en patchen één van de mogelijke oplossingen. Vulnerability management is het overkoepelende besluitvormingsproces dat beide verbindt met risico, eigenaarschap en verantwoording.
🔁 Hoe verloopt het vulnerability-managementproces?
| Stap | Wat u doet | Toelichting |
|---|---|---|
| 1. Inventarisatie | Breng alle systemen, applicaties en apparaten in kaart | Zonder asset-inventaris met firmware- en softwareversies weet u niet wat geraakt is (Asset Management) |
| 2. Signalering | Verzamel informatie over nieuwe kwetsbaarheden | Scans, leveranciersadvisories, NCSC-adviezen, de KEV-catalogus van CISA en machineleesbare CSAF-bestanden |
| 3. Beoordelen | Bepaal of en hoe de kwetsbaarheid in uw situatie misbruikt kan worden | Is de kwetsbare functie actief? Is het systeem bereikbaar? Een VEX-verklaring van de leverancier helpt valse positieven weg te strepen |
| 4. Prioriteren | Bepaal de volgorde van aanpak | Combineer ernst, kans op misbruik, actief misbruik en bedrijfsimpact |
| 5. Verhelpen of mitigeren | Patch, wijzig de configuratie of neem compenserende maatregelen | Via change management; in OT vaak gepland in een onderhoudsstop |
| 6. Verifiëren en rapporteren | Controleer of de maatregel werkt en houd trends bij | Herscan, leg uitzonderingen vast in het risicoregister |
Het proces is een cyclus. Elke dag verschijnen er nieuwe CVE’s, dus een eenmalige scan of audit veroudert snel. Leveranciers als Siemens publiceren hun advisories op een vaste dag (de tweede dinsdag van de maand), wat een natuurlijk ritme geeft voor de beoordeling.
📊 Hoe prioriteert u kwetsbaarheden?
Niemand kan alles tegelijk oplossen. Goede prioritering combineert meerdere signalen, omdat elk signaal een andere vraag beantwoordt:
| Methode | Beheerder | Vraag | Uitkomst |
|---|---|---|---|
| CVSS | FIRST | Hoe ernstig is de kwetsbaarheid technisch? | Score 0,0–10,0; versie 4.0 sinds 2023 |
| EPSS | FIRST | Hoe groot is de kans op misbruik in de komende 30 dagen? | Kans 0–1, dagelijks bijgewerkt |
| KEV | CISA | Wordt de kwetsbaarheid al aantoonbaar misbruikt? | Ja of nee, met vereiste actie |
| SSVC | Carnegie Mellon SEI en CISA | Welke actie past bij deze kwetsbaarheid in onze context? | Track, Track*, Attend of Act |
SSVC (Stakeholder-Specific Vulnerability Categorization) is in 2019 ontwikkeld door het Software Engineering Institute van Carnegie Mellon University, samen met CISA. Het werkt met een beslisboom op basis van misbruikstatus, technische impact, automatiseerbaarheid, de mate waarin het getroffen product verweven is met kritieke bedrijfsfuncties (mission prevalence) en de impact op publiek welzijn. De uitkomst is geen getal maar een actie: van Track (volgen en binnen de normale termijn oplossen) via Attend (sneller dan de normale termijn, met betrokkenheid van leidinggevenden) tot Act (directie stemt de aanpak af en het lek wordt zo snel mogelijk verholpen). Juist het criterium publiek welzijn maakt SSVC bruikbaar voor kritieke infrastructuur.
CVSS 4.0 kent bovendien een aanvullende metriekgroep met onder meer Safety en Automatable. Die beïnvloeden de score niet, maar laten een leverancier aangeven of misbruik fysieke veiligheidsgevolgen kan hebben: precies de informatie die in OT telt.
🧱 Waarom is vulnerability management in OT anders?
In OT is patchen vaak lastiger dan in IT:
- Productiecontinuïteit - een herstart kan een continu of real-time proces stilleggen; patchen wacht op een geplande stop
- Leverancierskwalificatie - updates voor SCADA, PLC’s, RTU’s of MES moeten eerst door de systeemleverancier worden getest en goedgekeurd
- Compatibiliteitsrisico - een slecht geteste patch kan zelf een productie- of veiligheidsincident veroorzaken
- Lange levensduur - legacy-systemen draaien vaak vijftien jaar of langer, soms op besturingssystemen zonder support
- Kwetsbare apparaten - actieve scans kunnen oudere besturingen verstoren, daarom gebruikt OT vaak passieve monitoring om versies en kwetsbaarheden af te leiden
Daarom zijn compenserende maatregelen in OT een volwaardige uitkomst van het proces:
| Situatie | Compenserende maatregel |
|---|---|
| Kwetsbare dienst op een PLC of HMI | Netwerksegmentatie volgens het zones-en-conduits-model en een firewall die alleen noodzakelijk verkeer toelaat |
| Kwetsbaarheid in een remote-accessroute | Toegang alleen via een jump server in de DMZ, met MFA en tijdelijke vrijgave |
| Data moet naar kantoor of cloud | Eenrichtingsverkeer naar een historian in de DMZ, geen directe verbinding met het besturingsnetwerk |
| Systeem zonder patch of support | Hardening, uitschakelen van ongebruikte services en extra netwerkmonitoring |
| Kwetsbaarheid bereikbaar vanaf internet | Direct afsluiten of afschermen; zie internetblootstelling van OT |
Segmentatie, toegangsbeperking en monitoring vormen samen defense in depth: meerdere lagen, zodat één ongepatcht lek niet direct tot een incident leidt.
🛠️ Welke tools ondersteunen vulnerability management?
- Voor IT - scanners als Nessus, Qualys, Rapid7 en OpenVAS, aangevuld met patchtools voor werkplekken en servers
- Voor OT en ICS - platforms van Nozomi, Tenable OT, Dragos en Claroty, die assets en kwetsbaarheden vooral passief uit netwerkverkeer afleiden en gericht actief bevragen
- Kwetsbaarheidsbronnen - de NIST National Vulnerability Database, het door MITRE beheerde CVE-programma, de KEV-catalogus, de European Vulnerability Database van ENISA en leveranciersadvisories in CSAF-formaat
- Componentenoverzicht - een SBOM laat zien welke softwarebibliotheken in een product zitten, zodat u een nieuwe kwetsbaarheid in zo’n bibliotheek snel aan uw installaties kunt koppelen
🔐 Welke normen en wetten eisen vulnerability management?
| Kader | Wat het vraagt |
|---|---|
| ISO 27001 / ISO 27002 | Beheersmaatregel 8.8: beheer van technische kwetsbaarheden |
| IEC 62443-2-1 | Kwetsbaarheden en patches als onderdeel van het beveiligingsprogramma van de asset owner, binnen de IEC 62443-reeks |
| IEC TR 62443-2-3 (2015) | Uitwisseling van patchinformatie tussen asset owner en leverancier |
| IEC 62443-4-1 | Fabrikanten moeten defectbeheer (DM) en beveiligingsupdatebeheer (SUM) inrichten |
| NIS2 / Cyberbeveiligingswet | Artikel 21 lid 2 onder e: beveiliging bij aanschaf, ontwikkeling en onderhoud, inclusief het behandelen en bekendmaken van kwetsbaarheden; de Cbw geldt sinds 15 augustus 2026 |
| Cyber Resilience Act | Fabrikanten behandelen kwetsbaarheden gedurende de supportperiode (in de regel minimaal vijf jaar, korter alleen als het product korter in gebruik is) en melden actief misbruikte kwetsbaarheden sinds 11 september 2026 (CRA-meldplicht) |
| BIO | BIO2, vastgesteld op 23 september 2025, volgt ISO 27001/27002 en bevat dus ook beheer van technische kwetsbaarheden |
NIS2 regelt in artikel 12 ook de andere kant: elke lidstaat wijst een CSIRT aan als coördinator voor coordinated vulnerability disclosure (CVD), en ENISA beheert een Europese kwetsbaarhedendatabase. In Nederland bevestigt het NCSC een CVD-melding binnen één werkdag, beoordeelt die binnen drie werkdagen en streeft naar een oplossing binnen 60 dagen.
🧭 Hoe richt u vulnerability management in een OT-omgeving in?
- Wijs eigenaren aan - per installatie een asset owner die besluit over patchen, mitigeren of accepteren, met een OT-securityspecialist als adviseur.
- Maak de inventaris compleet - inclusief firmwareversies, engineering stations en netwerkcomponenten; passieve detectie vult handmatige lijsten aan.
- Abonneer u op de juiste bronnen - advisories van uw eigen leveranciers (bij voorkeur als CSAF-feed), NCSC-adviezen en de KEV-catalogus.
- Leg prioriteringsregels vast - bijvoorbeeld: actief misbruikt en bereikbaar vanaf internet of de DMZ krijgt voorrang, ongeacht het onderhoudsritme.
- Koppel aan het onderhoudsplan - plan OT-patches in geplande stops en test ze vooraf op een testsysteem of redundante node.
- Documenteer uitzonderingen - elke niet-gepatchte kwetsbaarheid krijgt een compenserende maatregel, een eigenaar en een herzieningsdatum.
- Meet en verbeter - volg bijvoorbeeld de dekking van de inventaris, het aantal open KEV-kwetsbaarheden en de doorlooptijd van melding tot maatregel; een pentest toetst periodiek of de maatregelen werken.
Wie dit vastlegt, kan bij een toezichthouder onder de Cyberbeveiligingswet laten zien dat kwetsbaarheden aantoonbaar en risicogestuurd worden beheerd, ook als niet alles direct gepatcht kan worden.
❓ Veelgestelde vragen
Is vulnerability management hetzelfde als patchmanagement?
Nee. Vulnerability management bepaalt welke kwetsbaarheden een organisatie wanneer en hoe aanpakt; patchmanagement is het gecontroleerd uitrollen van updates. Patchen is één mogelijke uitkomst van vulnerability management, naast configuratiewijzigingen, compenserende maatregelen of het bewust accepteren van een risico.
Hoe vaak moet u scannen op kwetsbaarheden?
In IT scant u bij voorkeur doorlopend of in een vast, kort ritme en altijd na grote wijzigingen, omdat er dagelijks nieuwe CVE’s verschijnen; internetgerichte systemen verdienen de hoogste frequentie. In OT zijn actieve scans riskanter en wordt vaker passieve monitoring gebruikt die doorlopend versies afleidt uit netwerkverkeer. Actieve scans van besturingen vinden dan gepland en in overleg met operations plaats.
Waarom is een hoge CVSS-score niet altijd urgent?
CVSS meet de technische ernst van een kwetsbaarheid, niet het risico in uw situatie. Een kritieke score op een geïsoleerd systeem zonder netwerkverbinding kan minder urgent zijn dan een middelhoge score op een actief misbruikte VPN-gateway. Daarom combineert vulnerability management CVSS met EPSS, de KEV-catalogus en de bereikbaarheid van het systeem.
Wat doet u als een OT-systeem niet gepatcht kan worden?
Als een OT-systeem niet gepatcht kan worden, beperkt u de blootstelling met compenserende maatregelen zoals segmentatie, strikte firewallregels, hardening en extra monitoring. Leg de uitzondering vast in het risicoregister, met een eigenaar en een datum voor herbeoordeling. Plan daarnaast vervanging of migratie als het systeem geen support meer krijgt.
Is vulnerability management verplicht onder NIS2?
Ja. NIS2 noemt in artikel 21 het behandelen en bekendmaken van kwetsbaarheden expliciet als verplichte beveiligingsmaatregel, en in Nederland is dat sinds 15 augustus 2026 via de Cyberbeveiligingswet van kracht. Ook ISO 27001, IEC 62443 en de BIO vragen aantoonbaar beheer van technische kwetsbaarheden.
Wat is coordinated vulnerability disclosure?
Coordinated vulnerability disclosure (CVD) is het afgestemd melden van een gevonden kwetsbaarheid aan de eigenaar of fabrikant, zodat die het lek kan dichten voordat details openbaar worden. In Nederland bemiddelt het NCSC bij CVD-meldingen, en NIS2 verplicht elke lidstaat een CSIRT als CVD-coördinator aan te wijzen.
📌 Samengevat
Vulnerability management is een continu proces om kwetsbaarheden in uw IT- en OT-landschap op te sporen, te prioriteren en aantoonbaar te verhelpen of te beheersen. In OT draait het minder om zo snel mogelijk patchen en meer om goede prioritering, compenserende maatregelen en vastgelegde besluiten, zodat u risico’s beperkt en voldoet aan NIS2, IEC 62443 en ISO 27001.