Vulnerability management: kritieke kwetsbaarheden in firewalls en VPN's beheersen

Wat is vulnerability management?

Vulnerability management is het structurele proces waarmee een organisatie technische kwetsbaarheden:

1. ontdekt;
2. beoordeelt;
3. prioriteert;
4. oplost of mitigeert;
5. controleert;
6. en blijft volgen.

Het gaat dus om meer dan periodiek een vulnerability scan uitvoeren.

Een scanner kan honderden of duizenden bevindingen opleveren. De echte beheersvraag is:

welke kwetsbaarheid vormt voor onze organisatie nu het grootste risico en wie moet daar iets mee doen?

Daarvoor moet technische informatie worden gekoppeld aan de context van de organisatie.

Patch management en vulnerability management zijn niet hetzelfde

Patch management gaat over het gecontroleerd installeren en beheren van software- en beveiligingsupdates.

Vulnerability management is breder.

Een kwetsbaarheid kan bijvoorbeeld worden behandeld door:

• een beveiligingsupdate te installeren;
• een functie tijdelijk uit te schakelen;
• een beheerinterface van internet af te halen;
• netwerktoegang te beperken;
• een configuratie aan te passen;
• aanvullende monitoring in te richten;
• een systeem versneld uit te faseren.

Patchen is dus één mogelijke behandeling. Vulnerability management bepaalt welke kwetsbaarheid eerst aandacht krijgt en welke maatregel passend is.

Waarom firewalls en VPN-systemen extra aandacht verdienen

Een werkplek met een kwetsbare applicatie en een internet-facing VPN-gateway met dezelfde CVSS-score hebben niet automatisch hetzelfde risico.

VPN's, firewalls en andere edge-systemen zijn interessant voor aanvallers omdat zij vaak:

• rechtstreeks vanaf internet bereikbaar zijn;
• authenticatie afhandelen;
• toegang tot interne netwerken geven;
• netwerkverkeer verwerken;
• beheerrechten hebben;
• configuratiegegevens en soms credentials bevatten;
• een centrale positie in de beveiligingsarchitectuur hebben.

Wanneer een aanvaller juist het systeem kan overnemen dat de toegang tot je netwerk moet beschermen, kan de impact groot zijn.

CVSS 10 betekent niet automatisch dat alles direct rood is

CVSS is nuttig, maar geen volledige risicoanalyse.

Bij het prioriteren moet je minimaal kijken naar:

• ernst van de kwetsbaarheid;
• beschikbare exploitcode;
• actief misbruik;
• eenvoud van misbruik;
• internetbereikbaarheid;
• aanwezigheid van het product in de eigen omgeving;
• te verkrijgen rechten of netwerktoegang;
• bedrijfsimpact;
• beschikbare mitigaties;
• noodzaak om op eerdere compromittatie te controleren.

Een CVSS 10-kwetsbaarheid in een intern testsysteem kan een andere prioriteit hebben dan een CVSS 9,8-kwetsbaarheid in de VPN-gateway waarmee medewerkers en leveranciers het netwerk binnenkomen.

Vulnerability management is risicogestuurd, niet alleen scoregestuurd.

Actief misbruik verandert de prioriteit

Wanneer exploitatie daadwerkelijk wordt waargenomen, is de kwetsbaarheid niet meer alleen theoretisch.

Dat betekent meestal:

• patchtermijnen verkorten;
• spoedchange organiseren;
• tijdelijke mitigaties overwegen;
• logging en detectie intensiveren;
• beoordelen of het systeem vóór patching al gecompromitteerd kan zijn.

Een reguliere maandelijkse patchcyclus kan dan onvoldoende zijn.

Patchen is soms pas stap één

Bij een kwetsbaarheid die al actief wordt misbruikt, is alleen installeren van de update niet altijd voldoende.

De patch voorkomt toekomstig misbruik van de betreffende kwetsbaarheid. Hij geeft geen antwoord op de vraag of een aanvaller daarvoor al toegang heeft gehad.

Controleer bij relevante systemen daarom ook:

• authenticatie- en beheerlogs;
• onbekende accounts;
• onverwachte configuratiewijzigingen;
• nieuwe scripts of bestanden;
• afwijkende processen;
• uitgaande netwerkverbindingen;
• leverancier-IoC's;
• verdachte beheeractiviteiten;
• wijzigingen in firewall- en VPN-regels.

Bij aanwijzingen voor compromittatie moet incidentrespons worden gestart. Lees ook Gehackt? Wat nu? Eerste stappen na een cyberincident.

Assetmanagement is de basis

Je kunt een kwetsbaarheid alleen snel beoordelen als je weet dat het getroffen product aanwezig is.

Voor kritieke infrastructuur wil je minimaal weten:

• product en type;
• locatie;
• eigenaar;
• beheerder;
• software- of firmwareversie;
• supportstatus;
• internet-exposure;
• functie binnen het netwerk;
• kritieke bedrijfsprocessen;
• verantwoordelijke voor patching;
• monitoring;
• leverancier of onderhoudspartner.

Voor internet-facing systemen moet bovendien duidelijk zijn welke diensten daadwerkelijk vanaf buiten bereikbaar zijn.

Een CMDB of spreadsheet vertelt wat volgens de administratie aanwezig is. Een externe technische controle vertelt wat er echt zichtbaar is. Die twee beelden horen bij elkaar te passen.

Weet wat er aan je internet hangt

Veel ernstige kwetsbaarheden zitten juist in:

• VPN-gateways;
• firewalls;
• routers;
• mailservers;
• remote-accessproducten;
• managementinterfaces;
• webapplicaties;
• file-transferoplossingen.

Een vergeten appliance of oude beheerinterface kan maandenlang buiten reguliere patchprocessen vallen.

Controleer daarom periodiek:

• publieke IP-adressen;
• DNS-records en subdomeinen;
• open poorten;
• internet-facing services;
• VPN- en beheerinterfaces;
• TLS-certificaten;
• cloudassets;
• oude of tijdelijke systemen.

De vraag is niet alleen “Wat hebben we geregistreerd?”, maar ook “Wat ziet een aanvaller als hij van buiten naar onze organisatie kijkt?”

Vulnerability management in zeven stappen

1. Breng assets in kaart

Weet welke systemen, software en netwerkapparatuur aanwezig zijn.

2. Vind kwetsbaarheden

Gebruik betrouwbare vendor-advisories, NCSC-waarschuwingen, vulnerability scanning en relevante threat intelligence.

3. Bepaal de werkelijke exposure

Controleer of het product aanwezig is, welke versie wordt gebruikt en of de kwetsbare functie actief en bereikbaar is.

4. Prioriteer op risico

Combineer technische ernst met exploitatie, bereikbaarheid, bedrijfsimpact en beschikbare maatregelen.

5. Behandel de kwetsbaarheid

Patch, wijzig configuratie, beperk toegang, mitigeer of faseer het systeem uit.

6. Controleer de oplossing

Verifieer dat update of configuratiewijziging daadwerkelijk succesvol is uitgevoerd.

7. Controleer zo nodig op compromittatie

Vooral bij actief misbruik of langdurige blootstelling. Leg vast wat is gecontroleerd en wat de uitkomst was.

Wie is verantwoordelijk?

Dit moet vóór een incident duidelijk zijn.

Leg bijvoorbeeld vast:

• wie advisories ontvangt;
• wie bepaalt of je geraakt bent;
• wie een spoedpatch mag goedkeuren;
• wie de wijziging uitvoert;
• wie succesvolle installatie controleert;
• wie beoordeelt of incidentonderzoek nodig is;
• wie rapporteert aan management of bestuur.

Bij kritieke systemen is “IT houdt dat wel bij” onvoldoende.

Uitbesteed aan een IT-leverancier?

Vraag bij een urgente kwetsbaarheid niet alleen:

“Hebben jullie gepatcht?”

Vraag ook:

• gebruiken wij het getroffen product?
• welke versie gebruiken wij?
• was onze configuratie kwetsbaar?
• was het systeem vanaf internet bereikbaar?
• wanneer is de update uitgevoerd?
• hoe is succesvolle installatie gecontroleerd?
• is gekeken naar aanwijzingen voor compromittatie?
• welke logging is daarvoor beschikbaar?

Een algemene SLA waarin staat dat updates worden uitgevoerd geeft niet automatisch zekerheid dat een specifieke kritieke CVE tijdig is behandeld.

Uitbesteden van uitvoering is niet hetzelfde als uitbesteden van verantwoordelijkheid.

Twee actuele voorbeelden: Cisco en Check Point

In september 2026 kwamen kort na elkaar ernstige kwetsbaarheden naar buiten in systemen die juist een beveiligingsfunctie vervullen.

Bij Cisco Secure Firewall Management Center werd actief misbruik bevestigd van een kritieke authenticatiekwetsbaarheid.

Bij Check Point VPN-producten waarschuwde het NCSC voor twee kritieke kwetsbaarheden waarmee zonder authenticatie code kan worden uitgevoerd. Het NCSC verwacht snel pogingen tot grootschalig misbruik.

Lees de actuele waarschuwingen over Cisco FMC en Check Point VPN.

De producten verschillen. De beheersvraag is hetzelfde:

weet je of je het product gebruikt, weet je of je kwetsbaar bent en kun je aantoonbaar snel handelen?

Wat moet management hierover weten?

Een bestuurder hoeft geen CVE-nummers uit het hoofd te kennen.

Wel mag hij of zij verwachten dat de organisatie antwoord kan geven op vragen zoals:

1. Weten wij welke kritieke systemen vanaf internet bereikbaar zijn?
2. Kunnen wij binnen enkele uren bepalen of een nieuwe ernstige kwetsbaarheid op ons van toepassing is?
3. Hebben wij termijnen voor kritieke en actief misbruikte kwetsbaarheden?
4. Is duidelijk wie mag besluiten over een spoedwijziging?
5. Kunnen wij aantonen dat onze leverancier daadwerkelijk heeft gepatcht?
6. Controleren wij bij actief misbruik ook of we mogelijk al geraakt zijn?
7. Rapporteren we structureel over achterstallige kritieke kwetsbaarheden?

Wanneer die antwoorden niet direct beschikbaar zijn, zit het probleem vaak niet in de ontbrekende patch. Het probleem zit dan in governance, eigenaarschap en inzicht. De NIS2-verplichtingen en de Cyberbeveiligingswet maken die bestuurlijke verantwoordelijkheid extra concreet. Een NIS2 workshop over risicobeheersing helpt directie en IT om exposure, scenario's, eigenaarschap en besluiten open met elkaar te bespreken.

ISO 27001 en vulnerability management

ISO 27001:2022 behandelt het beheer van technische kwetsbaarheden expliciet in Annex A 8.8 — Management of technical vulnerabilities.

Een organisatie moet informatie over technische kwetsbaarheden verkrijgen, de eigen blootstelling beoordelen en passende maatregelen nemen.

Daarmee sluit vulnerability management rechtstreeks aan op assetmanagement, risicomanagement, change management, patchmanagement, leveranciersmanagement, logging/monitoring en incidentmanagement.

Een vulnerability scanner alleen maakt je dus nog niet aantoonbaar weerbaar.

Samengevat

Nieuwe kwetsbaarheden zijn onvermijdelijk. Dat betekent niet dat iedere CVE een crisis moet veroorzaken.

Een volwassen organisatie weet:

• welke systemen aanwezig zijn;
• welke daarvan vanaf internet bereikbaar zijn;
• welke kwetsbaarheden relevant zijn;
• welke eerst opgelost moeten worden;
• wie verantwoordelijk is;
• en hoe wordt gecontroleerd dat de maatregel werkelijk werkt.

Goed vulnerability management voorkomt dat iedere kritieke kwetsbaarheid opnieuw begint met de vraag: “Hebben wij dit eigenlijk?”

Wil je de werking van maatregelen onafhankelijk laten toetsen? Bekijk dan ook de Cyber Security Audit.