Kwetsbaarheidsbeheer: een praktische gids voor IT-teams en MSP’s

De meeste organisaties beschikken over een of andere vorm van kwetsbaarheidsbeheer. Een driemaandelijkse scan, een of ander patchingproces, een jaarlijkse penetratietest om aan de regelgeving te voldoen. Wat de meeste organisaties echter missen, is een programma dat rigoureus genoeg is om hun risico’s daadwerkelijk te verminderen.

Een driemaandelijkse scan met een rapport waar niemand iets mee doet, is geen kwetsbaarheidsbeheer. Evenmin als het installeren van patches als er iets kapotgaat. En ook niet een enkele jaarlijkse penetratietest die alleen maar dient om een vakje aan te vinken en daarna in een map belandt. Effectief kwetsbaarheidsbeheer is een continu, datagestuurd proces waarbij zwakke plekken in een IT-omgeving worden opgespoord, geprioriteerd en verholpen voordat aanvallers er misbruik van kunnen maken, en dat zo snel gebeurt dat de tijdspanne waarin misbruik mogelijk is, beperkt blijft.

Volgens het Kaseya State of the MSP-rapport 2026 noemt 53% van de MSP’s cyberbeveiligingsproblemen als een van de grootste zakelijke zorgen. Niet-gepatchte kwetsbaarheden zijn de meest voorkomende reden waarom die zorgen uitmonden in incidenten. Download het volledige rapport.

Wat is kwetsbaarheidsbeheer?

Kwetsbaarheidsbeheer is het doorlopende proces waarbij beveiligingskwetsbaarheden in de IT-omgeving van een organisatie worden geïdentificeerd, beoordeeld, aangepakt en gerapporteerd. Het omvat kwetsbaarheden in software (ontbrekende patches, niet-gepatchte CVE’s), configuratiefouten (standaard inloggegevens, onnodig openstaande poorten, onveilige serviceconfiguraties) en hiaten in het overzicht van bedrijfsmiddelen (apparaten in de omgeving die niet worden gemonitord of beheerd).

Het proces is continu omdat het kwetsbaarhedenlandschap voortdurend verandert. Er worden dagelijks nieuwe CVE’s gepubliceerd. Systemen en applicaties veranderen. Software wordt geïnstalleerd, bijgewerkt en verwijderd. De omgeving aan het einde van deze maand verschilt aanzienlijk van de omgeving aan het begin ervan, en een kwetsbaarheidsprogramma moet die realiteit weerspiegelen in plaats van een momentopname te bieden die al verouderd is voordat het rapport wordt verspreid.

Dit is het verschil tussen een programma voor kwetsbaarheidsbeheer en een kwetsbaarheidsanalyse. Een analyse brengt in kaart wat er op een bepaald moment aanwezig is. Een programma identificeert, prioriteert, verhelpt en controleert voortdurend in een veranderende omgeving.

De levenscyclus van kwetsbaarheidsbeheer

Elk programma voor kwetsbaarheidsbeheer volgt dezelfde operationele cyclus, ongeacht de gebruikte tools of de omvang ervan.

Het in kaart brengen en inventariseren vormt de basis. Je kunt niet beschermen wat je niet kent. Alleen door alle bedrijfsmiddelen volledig in kaart te brengen – inclusief apparaten die niet officieel zijn geregistreerd, schaduw-IT, cloudinstanties en IoT-apparaten – krijgt het scannen echt betekenis. Het is effectiever om dit continu te doen in plaats van periodiek, omdat er tussen de scancycli door nieuwe bedrijfsmiddelen en kwetsbaarheden bijkomen, en een scan van een onvolledige inventaris een onvolledig beeld oplevert.

Bij het scannen en beoordelen worden systemen getoetst aan databases met bekende kwetsbaarheden (CVE’s) en configuratienormen. Het onderscheid tussen geauthenticeerd en niet-geauthenticeerd scannen is van cruciaal belang. Bij niet-geauthenticeerd scannen vanaf de netwerkrand wordt gekeken naar wat een externe aanvaller ziet. Geauthenticeerd scannen, waarbij de scanner zich aanmeldt bij systemen om de interne toestand ervan te beoordelen, levert aanzienlijk vollediger resultaten op. De meeste serieuze programma’s voor kwetsbaarheidsbeheer maken gebruik van beide methoden.

Prioritering bepaalt de volgorde waarin kwetsbaarheden worden verholpen. Niet alle kwetsbaarheden zijn even urgent, en het aantal bevindingen in een echte omgeving is zo groot dat de kwaliteit van de prioritering belangrijker is dan de totale dekking van de scan. De kaders die hiervoor geschikt zijn, worden hieronder uitgebreid besproken.

Het is bij het verhelpen van kwetsbaarheden dat het programma zijn meerwaarde laat zien. De meest voorkomende manier om kwetsbaarheden te verhelpen is het installeren van patches, maar kwetsbaarheden kunnen ook worden aangepakt door middel van configuratiewijzigingen, compenserende maatregelen of het isoleren van getroffen systemen wanneer het niet mogelijk is om onmiddellijk een patch te installeren. Voor het verhelpen van kwetsbaarheden moeten er per risicocategorie vastgestelde SLA-termijnen gelden, en niet één uniform tijdschema waarin een kritieke CVE met een actieve exploit op dezelfde manier wordt behandeld als een configuratiefout met een lage ernstgraad.

Verificatie maakt het proces compleet. Nadat er corrigerende maatregelen zijn genomen, moet er door middel van een scan worden gecontroleerd of de kwetsbaarheden daadwerkelijk zijn verholpen. Patches die niet correct zijn geïnstalleerd, configuraties die zijn teruggedraaid of compenserende maatregelen die niet naar behoren hebben gewerkt, kunnen organisaties ten onrechte doen geloven dat ze een probleem hebben verholpen, terwijl dat niet het geval is. Verificatie zorgt ervoor dat corrigerende maatregelen daadwerkelijk leiden tot een aantoonbare risicoreductie.

Rapportage is bedoeld voor verschillende doelgroepen. Technische teams die de voortgang van herstelmaatregelen volgen, hebben gedetailleerde, bruikbare gegevens nodig. Het management heeft voor rapportages over de beveiligingsstatus trendgegevens nodig die de blootstelling in de loop van de tijd weergeven. Doelgroepen op het gebied van compliance hebben bewijs nodig van een continu beheer van kwetsbaarheden. Een programma dat slechts één van deze rapporttypes oplevert, doet afbreuk aan zijn eigen nut.

Kwetsbaarheidsscans versus penetratietests

Deze twee werkwijzen vullen elkaar aan en worden vaak door elkaar gehaald; het is een veelvoorkomende fout bij het ontwerpen van programma’s om de ene als vervanging voor de andere te gebruiken.

Het scannen op kwetsbaarheden is geautomatiseerd, uitgebreid en continu. Het brengt bekende kwetsbaarheden in alle onderzochte systemen en omgevingen in kaart, stelt een geprioriteerde lijst met bevindingen op en levert operationele gegevens voor het bijhouden van de herstelmaatregelen. Er wordt geen poging gedaan om misbruik te maken van de kwetsbaarheden. Het laat zien waar er zwakke plekken zitten, maar geeft geen uitsluitsel over de vraag of die zwakke plekken daadwerkelijk door een ervaren aanvaller in uw specifieke omgeving kunnen worden misbruikt.

Penetratietesten worden handmatig of semi-automatisch uitgevoerd, zijn gericht en vinden periodiek plaats. Een ervaren tester probeert kwetsbaarheden te misbruiken, waaronder ketens van minder ernstige problemen die afzonderlijk beheersbaar lijken, maar samen toegang tot kritieke systemen kunnen verschaffen, om zo realistische aanvalsroutes aan te tonen. Penetratietesten toetsen of uw beveiliging standhoudt tegen een ervaren aanvaller, en niet alleen of er kwetsbaarheden bestaan.

Beide zijn waardevol en geven antwoord op verschillende vragen. Kwetsbaarheidsscans vormen het doorlopende operationele programma dat de kwetsbaarheden actueel houdt. Penetratietests, die doorgaans jaarlijks of vóór ingrijpende architecturale wijzigingen worden uitgevoerd, geven aan of het operationele programma daadwerkelijk werkt. Het gebruik van een penetratietest als vervanging voor doorlopende scans is een veelgemaakte fout: omdat een test een momentopname is, worden kwetsbaarheden die na de testdatum zijn ontstaan gemist, en in een typische omgeving betreft dit het merendeel van de kwetsbaarheden binnen 90 dagen.

Prioritering: hoe bepaal je wat er als eerste wordt opgelost?

Het doel van prioritering is niet het laagste totale aantal CVE’s. Het gaat erom de kwetsbaarheden aan te pakken die het grootste risico lopen om misbruikt te worden, voordat je ze allemaal kunt patchen, omdat je in de praktijk nooit alle kwetsbaarheden tegelijk kunt verhelpen.

De twee variabelen die het belangrijkst zijn, zijn de misbruikbaarheid en de kriticiteit van de bedrijfsmiddelen. Een CVSS-score is een nuttig uitgangspunt, maar op zichzelf geen volledig beeld. Een kwetsbaarheid met een CVSS-score van 9 waarvoor geen openbare exploit bestaat, is minder urgent dan een kwetsbaarheid met een CVSS-score van 7 die in de KEV-catalogus (Known Exploited Vulnerabilities) van CISA wordt vermeld als actief misbruikt in het wild. De KEV-catalogus is de meest gezaghebbende openbare referentie voor de status van actief misbruik, en elke kwetsbaarheid die daarin staat, moet worden behandeld als een Tier 1-item, ongeacht de CVSS-score.

Een praktisch raamwerk met vier niveaus:

Niveau 1, patch binnen 24 tot 72 uur: kritieke CVSS-kwetsbaarheden in systemen die in verbinding staan met het internet of over uitgebreide rechten beschikken; alle vermeldingen in de CISA KEV-catalogus; kwetsbaarheden waarvan op basis van dreigingsinformatie is bevestigd dat ze actief worden misbruikt.

Niveau 2, binnen 7 dagen patchen: kwetsbaarheden met een hoge CVSS-score; kwetsbaarheden waarvoor proof-of-concept-exploits zijn gepubliceerd; alle kwetsbaarheden in systemen die gevoelige gegevens bevatten of bevoorrechte toegang mogelijk maken.

Niveau 3, binnen 30 dagen verhelpen: kwetsbaarheden met een gemiddelde ernst op standaard-eindpunten.

Niveau 4, status in onderhoudscyclus: kwetsbaarheden met een lage ernstgraad waarvoor geen bewijs is dat er actief misbruik van wordt gemaakt.

Kwetsbaarheden die niet binnen de gestelde termijnen kunnen worden verholpen (vanwege compatibiliteitsbeperkingen van bedrijfskritische applicaties of goedkeuringsprocessen bij klanten) moeten formeel worden gedocumenteerd, waarbij compenserende maatregelen worden toegepast en waarschuwingen voor het verstrijken van de termijn worden ingesteld. Een ongedocumenteerde toezegging van het type „daar komen we wel op terug“ vormt een risico dat steeds groter wordt zonder dat iemand dit bijhoudt.

Kwetsbaarheidsbeheer voor MSP’s

MSP’s die kwetsbaarheidsprogramma’s beheren in meerdere klantomgevingen hebben dezelfde kernfunctionaliteiten nodig als IT-teams binnen één organisatie, met drie aanvullende vereisten: multi-tenancy, rapportage per klant en een prioriteitslaag die de meest urgente zaken binnen het totale klantenbestand aan het licht kan brengen.

Juist bij het prioriteren per klant maakt schaalgrootte echt het verschil. Een MSP die 40 klantomgevingen ondersteunt en elk kwartaal een kwetsbaarheidsscan uitvoert, kan in het totale netwerk honderden CVE’s met een hoge ernstgraad aan het licht brengen. Zonder een raamwerk dat direct aangeeft welke bevindingen CISA KEV-vermeldingen zijn en welke assets de hoogste kriticiteit hebben, wordt het rapport overweldigend en vervalt het programma in de automatische reactie: „patch gewoon wat het makkelijkst is.“ Met zo'n raamwerk is de lijst voor de eerste dag beheersbaar: een specifieke set kritieke bevindingen die binnen 24 tot 72 uur moeten worden verholpen, gesorteerd per klant, terwijl al het andere wordt ingedeeld in wekelijkse en maandelijkse wachtrijen.

De praktische infrastructuur voor kwetsbaarheidsbeheer op MSP-schaal omvat gestandaardiseerde scanbeleidsregels die consistent worden toegepast in alle klantomgevingen, met per klant aanpasbare instellingen voor het tijdstip, de reikwijdte en de inloggegevens van de scan; per klant specifieke kwetsbaarheidsdashboards die accountmanagers inzicht bieden in de huidige blootstelling en de snelheid waarmee maatregelen worden genomen; rapporten voor klanten die geschikt zijn voor QBR-gesprekken en waarin CVE-lijsten worden vertaald naar risicotaal in zakelijke context; en aan SLA’s gekoppelde tracking van herstelmaatregelen die de snelheid van het patchen aantoont en bewijst dat de afgesproken tijdschema’s worden nageleefd.

VulScan, dat via RapidFire Tools deel uitmaakt van de Kaseya-familie, biedt een speciaal voor MSP’s ontwikkelde oplossing voor het scannen van netwerkkwetsbaarheden, met geautomatiseerde detectie en CVE-identificatie binnen klantnetwerken. Kaseya VSA 10 en Datto RMM zorgen voor de implementatie van patches, waarbij geïdentificeerde kwetsbaarheden direct worden omgezet in herstelworkflows. IT Glue de context en documentatie van de bedrijfsmiddelen, waardoor het toekennen van prioriteiten op basis van de kriticiteit van die middelen een nauwkeurig proces wordt in plaats van giswerk.

Ontdek hoe het patchbeheer van Kaseya VSA 10 is geïntegreerd met het opsporen van kwetsbaarheden.

Veelvoorkomende storingen

Programma's voor kwetsbaarheidsbeheer mislukken op voorspelbare manieren. Als je de patronen kent, kun je ze gemakkelijker vermijden.

Scannen zonder actie te ondernemen. Kwetsbaarheidsrapporten die wel bevindingen opleveren, maar niet worden gekoppeld aan een herstelworkflow, hebben geen enkele waarde voor de beveiliging. Een lange lijst met CVE’s zonder toegewezen verantwoordelijken en zonder deadlines voor herstel is slechts een vastlegging van risico’s, geen vermindering ervan.

Prioritering uitsluitend op basis van CVSS. Een CVSS-score geeft de potentiële ernst weer, niet de kans dat er daadwerkelijk misbruik van wordt gemaakt. Het is onlogisch om een kwetsbaarheid met een CVSS-score van 9, waarvoor geen openbare exploit bestaat, als urgenter te beschouwen dan een kwetsbaarheid met een CVSS-score van 7 die in de CISA KEV-lijst is opgenomen. Gegevens over de exploiteerbaarheid uit de KEV-catalogus en feeds met dreigingsinformatie moeten in het model worden meegenomen.

Activa die buiten het bereik vallen. Kwetsbaarheidsbeheer dat het bedrijfsnetwerk scant maar cloudinstanties, externe apparaten of OT- en IoT-infrastructuur over het hoofd ziet, vertoont hiaten die aanvallers zullen ontdekken, omdat zij alles grondig scannen. Het bereik moet de werkelijke omgeving weerspiegelen, niet de omgeving zoals die twee jaar geleden is gedocumenteerd.

Geen verantwoordelijkheid voor het verhelpen van kwetsbaarheden. Kwetsbaarheden zonder toegewezen verantwoordelijke worden niet verholpen. Elke geïdentificeerde kwetsbaarheid moet een benoemde verantwoordelijke hebben, een SLA op basis van risiconiveau en een volgmechanisme. Verantwoordelijkheid zonder deadline is hetzelfde als geen verantwoordelijkheid.

Geen verificatie. Bevestigen dat een patch is geïnstalleerd, is niet hetzelfde als bevestigen dat een kwetsbaarheid is verholpen. Pas door na het verhelpen van de kwetsbaarheid een verificatiescan uit te voeren, wordt de uitgevoerde actie omgezet in een bevestigde risicoreductie.

Kaseya Intelligence: van detectie tot zelfstandig handelen

Traditionele tools voor kwetsbaarheidsbeheer brengen hiaten in kaart en doen aanbevelingen. De operationele bottleneck is altijd dezelfde: een technicus moet de bevinding beoordelen, deze prioriteren ten opzichte van alle andere taken in de wachtrij, en er actie op ondernemen in een tempo dat geen gelijke tred houdt met de snelheid waarmee kwetsbaarheden worden ontdekt en misbruikt.

Kaseya Intelligence uit meer dan drie exabyte aan geaggregeerde en geanonimiseerde gegevens en meer dan 17 miljoen beheerde eindpunten, en maakt de overstap van het in kaart brengen van kwetsbaarheden naar het autonoom uitvoeren van herstelmaatregelen: het installeren van patches, het isoleren van systemen en het valideren van resultaten, zonder dat bij elke stap handmatige tussenkomst nodig is.

Voor MSP’s die kwetsbaarheidsprogramma’s beheren in tientallen klantomgevingen, is de overgang van aanbevelingen naar autonome acties juist wat het programma schaalbaar maakt. Een team dat 40 klanten beheert, kan tijdens een Patch Tuesday-week onmogelijk elke Tier 1-bevinding binnen 72 uur handmatig beoordelen en afhandelen. Met geautomatiseerde beleidsregels voor patchimplementatie die worden uitgevoerd op basis van tier-criteria, zonder dat bij elke stap goedkeuring van een individuele technicus nodig is, wordt de termijn van 72 uur door het systeem gehaald in plaats van door het team gemist. Ontdek Kaseya Intelligence.

Goed uitgevoerd kwetsbaarheidsbeheer valt niet op. De patches worden uitgerold. De bevindingen worden door de verschillende lagen verwerkt. De verificatiescans bevestigen dat de problemen zijn verholpen. De kwartaalrapporten laten een trendlijn zien die de goede kant op gaat. De klanten wier omgevingen op deze manier worden beheerd, hebben geen last van incidenten die worden veroorzaakt doordat bekende, patchbare kwetsbaarheden maandenlang open blijven staan. Degenen die niet op deze manier worden beheerd, ontdekken door middel van incidenten precies welke van de bovenstaande storingsmodi hun programma had.