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 aanbrengen van patches wanneer er iets kapotgaat. En evenmin als één jaarlijkse penetratietest die dient om een vakje aan te vinken en vervolgens 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 maken, en dit gebeurt zo snel dat de tijdspanne waarin misbruik mogelijk is, beperkt blijft.

Volgens het Kaseya State of the MSP-rapport uit 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.

Zoek en verhelp kwetsbaarheden voordat aanvallers dat doen.

Kaseya VSA 10 scant continu alle beheerde endpointsen op ontbrekende patches en kwetsbaarheden in de software, en stuurt deze gegevens rechtstreeks door naar geautomatiseerde herstelworkflows.

Ontdek Kaseya VSA 10

Wat is vulnerability management?

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

Het proces is continu, omdat het kwetsbaarhedenlandschap voortdurend in beweging is. 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 wezenlijk 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 kwetsbaarheidsbeoordeling. Bij een beoordeling wordt vastgesteld 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, ongeacht de gebruikte tools of de omvang, volgt dezelfde operationele cyclus.

Inventarisatie vormt de basis. Je kunt niet beschermen wat je niet kent. Een volledige inventarisatie van bedrijfsmiddelen – inclusief apparaten die niet officieel zijn geregistreerd, schaduw-IT, cloudinstanties en IoT-apparaten – is wat het scannen zinvol maakt. Een inventarisatie die continu plaatsvindt in plaats van periodiek, is effectiever, omdat er tussen de scancycli door nieuwe bedrijfsmiddelen en nieuwe kwetsbaarheden ontstaan, 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 gezien 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 hebben dezelfde urgentie, 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 goed werken, 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 risiconiveau 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 de cirkel rond. 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, zorgen ervoor dat organisaties ten onrechte denken dat ze iets hebben verholpen terwijl dat niet het geval is. Verificatie zorgt ervoor dat corrigerende maatregelen daadwerkelijk leiden tot een bevestigde risicoreductie.

Rapportage richt zich op 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 voortdurend 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 gebruik van de ene als vervanging voor de andere is een veelvoorkomende fout bij het ontwerpen van programma’s.

Het scannen op kwetsbaarheden verloopt geautomatiseerd, uitgebreid en continu. Het identificeert bekende kwetsbaarheden in alle onderzochte systemen, stelt een op prioriteit gerangschikte lijst met bevindingen op en levert de 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 uitgebuit.

Penetratietests worden handmatig of semi-automatisch uitgevoerd, zijn gericht op specifieke aspecten en vinden periodiek plaats. Een ervaren tester probeert kwetsbaarheden te misbruiken, waaronder ketens van kwetsbaarheden met een lagere ernstgraad die afzonderlijk beheersbaar lijken, maar die samen toegang tot belangrijke systemen kunnen verschaffen, om zo realistische aanvalsroutes aan te tonen. Penetratietests 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 blootstelling aan risico’s actueel houdt. Penetratietests, die doorgaans jaarlijks of vóór ingrijpende architecturale wijzigingen worden uitgevoerd, geven antwoord op de vraag of het operationele programma daadwerkelijk werkt. Het gebruik van een penetratietest als vervanging voor doorlopende scans is een veelvoorkomende vervangingsfout; het momentgebonden karakter van een test betekent dat kwetsbaarheden die na de testdatum zijn ontstaan, over het hoofd worden gezien – 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 te verminderen die het meest waarschijnlijk worden misbruikt voordat je ze allemaal kunt patchen, omdat je in een echte omgeving niet alle kwetsbaarheden tegelijkertijd kunt patchen.

De twee variabelen die het belangrijkst zijn, zijn de uitbuitbaarheid en de kriticiteit van de asset. Een CVSS-score is een nuttig uitgangspunt, maar op zichzelf een onvolledige indicatie. 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 een kwetsbaarheid die actief in het wild wordt uitgebuit. De KEV-catalogus is de meest gezaghebbende openbare referentie voor de status van actieve uitbuiting, en elke kwetsbaarheid die daarin is opgenomen, 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 op systemen die in verbinding staan met het internet of die over uitgebreide rechten beschikken; elke vermelding in de CISA KEV-catalogus; kwetsbaarheden waarvan op basis van dreigingsinformatie is bevestigd dat ze actief worden misbruikt.

Niveau 2, patch binnen 7 dagen: 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-endpointsen.

Niveau 4, behandeling in de 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 (beperkingen op het gebied van compatibiliteit met bedrijfskritische applicaties, goedkeuringsprocessen voor wijzigingen bij klanten) moeten formeel worden gedocumenteerd, waarbij compenserende maatregelen worden toegepast en waarschuwingen voor veroudering worden ingesteld. Een ongedocumenteerde „daar komen we nog wel op terug“ is een risico dat steeds groter wordt zonder dat iemand het in de gaten houdt.

Beheer van kwetsbaarheden 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 omgevingsoverzicht naar voren kan halen.

De uitdaging om per klant prioriteiten te stellen is waar schaalgrootte echt het verschil maakt. Een MSP die 40 klantomgevingen ondersteunt en elk kwartaal een kwetsbaarheidsscan uitvoert, kan in het totale park enkele honderden CVE’s met een hoge ernstgraad aan het licht brengen. Zonder een raamwerk dat onmiddellijk vaststelt welke bevindingen CISA KEV-vermeldingen zijn en welke assets de hoogste kriticiteit hebben, is het rapport overweldigend en valt het programma terug op „patchen 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 overige 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 aangepaste 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 aanbrengen van patches aantoont en bewijs levert dat de afgesproken tijdschema’s worden nageleefd.

VulScan, onderdeel van de Kaseya-familie via RapidFire Tools, biedt een speciaal voor MSP’s ontwikkelde oplossing voor het scannen van netwerkkwetsbaarheden, met geautomatiseerde detectie en CVE-identificatie in de netwerken van klanten. Kaseya VSA 10 en Datto RMM zorgen voor de implementatie van patches, waarbij geïdentificeerde kwetsbaarheden direct worden omgezet in workflows voor het verhelpen ervan. IT Glue bevat de contextgegevens en documentatie van de assets, waardoor het toekennen van prioriteiten op basis van de kriticiteit van de assets nauwkeurig verloopt en geen giswerk is.

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 een vastlegging van het risico, niet een vermindering ervan.

Prioritering uitsluitend op basis van CVSS. Een CVSS-score meet de potentiële ernst, niet de waarschijnlijkheid 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 uitbuitbaarheid uit de KEV-catalogus en threat intelligence-feeds moeten deel uitmaken van het model.

Activa die buiten het bereik vallen. Kwetsbaarheidsbeheer waarbij het bedrijfsnetwerk wel wordt gescand, maar cloudinstanties, externe apparaten of OT- en IoT-infrastructuur buiten beschouwing worden gelaten, vertoont hiaten die aanvallers zullen ontdekken, omdat zij grondig scannen. Het bereik moet een weerspiegeling zijn van de daadwerkelijke omgeving, niet van de omgeving zoals die twee jaar geleden is gedocumenteerd.

Geen verantwoordelijkheid voor het verhelpen van kwetsbaarheden. Kwetsbaarheden waaraan geen verantwoordelijke is toegewezen, worden niet verholpen. Elke geïdentificeerde kwetsbaarheid moet een benoemde verantwoordelijke hebben, een SLA op basis van risiconiveau en een volgsysteem. 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 een verificatiescan na het verhelpen van de kwetsbaarheid wordt een activiteit omgezet in een bevestigde risicoreductie.

Kaseya Intelligence: van detectie tot autonoom 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 niet 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 endpointsen, 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 overstap 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 het implementeren van patches, 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. Bekijk Kaseya Intelligence.

Goed uitgevoerd kwetsbaarheidsbeheer valt niet op. De patches worden uitgerold. De bevindingen worden door de verschillende niveaus 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 onopgelost blijven. Degenen die niet op deze manier worden beheerd, ontdekken door middel van incidenten precies welke van de bovenstaande storingsmodi hun programma vertoonde.

Belangrijkste punten

• Kwetsbaarheidsbeheer is een continu proces, geen driemaandelijkse scan of jaarlijkse penetratietest. De omgeving verandert te snel om met een eenmalige aanpak gelijke tred te kunnen houden met het kwetsbaarheidslandschap.
• Een prioritering waarbij de CVSS-score, de status van actieve uitbuiting volgens de CISA KEV en de kriticiteit van de asset worden gecombineerd, is aanzienlijk effectiever dan het behandelen van alle kwetsbaarheden alsof ze even urgent zijn. Elke kwetsbaarheid in de CISA KEV-catalogus is een Tier 1-item, ongeacht de CVSS-score.
• Scans en penetratietests geven antwoord op verschillende vragen. Scans zorgen voor continue operationele dekking. Penetratietests toetsen of de beveiligingsmaatregelen en het herstelprogramma daadwerkelijk standhouden tegen een ervaren aanvaller.
• Voor MSP’s zorgen kaders voor prioritering per klant, gestandaardiseerde scanbeleidsregels en het bijhouden van herstelmaatregelen in combinatie met SLA’s ervoor dat kwetsbaarheidsbeheer schaalbaar is binnen een omgeving met meerdere klanten, zonder dat het personeelsbestand evenredig hoeft mee te groeien.