Patchbeheer versus kwetsbaarheidsbeheer: wat is het verschil?

Beveiligingsteams en MSP’s gebruiken de termen ‘patchbeheer’ en ‘kwetsbaarheidsbeheer’ vaak in één adem, alsof ze hetzelfde betekenen. Dat is echter niet het geval. Het door elkaar halen van deze twee begrippen is een van de meest voorkomende redenen waarom organisaties uiteindelijk een beveiligingsprogramma hebben dat er druk uitziet, maar niet effectief is. Patches worden geïnstalleerd zonder dat duidelijk is welk risico ze aanpakken. Kwetsbaarheden worden gescand zonder dat er een duidelijk plan is voor het verhelpen ervan. En ergens tussendoor wordt iets cruciaals over het hoofd gezien.

Kaseya werkt samen met MSP’s en IT-teams die wereldwijd duizenden endpointsen beheren, en de verwarring tussen deze twee werkwijzen komt voortdurend naar voren. In dit bericht wordt precies uitgelegd wat elk proces doet, waarin ze van elkaar verschillen en hoe het gecombineerde gebruik ervan de hiaten opvult die ontstaan wanneer slechts één van beide afzonderlijk wordt toegepast. De patchbeheersoftware en de tool voor het scannen van kwetsbaarheden van Kaseya zijn ontworpen om in combinatie te werken, waardoor we direct inzicht krijgen in hoe beide werkwijzen in echte IT-omgevingen op elkaar inwerken.

Wat is het verschil tussen patchbeheer en kwetsbaarheidsbeheer?

Patchbeheer is een specifiek operationeel proces. Kwetsbaarheidsbeheer is het strategische programma dat aangeeft welke problemen moeten worden opgelost en in welke volgorde. Het aanbrengen van patches maakt deel uit van kwetsbaarheidsbeheer, maar vormt niet het geheel ervan.

De eenvoudigste manier om het te omschrijven: kwetsbaarheidsbeheer spoort zwakke plekken op en rangschikt deze op prioriteit. Patchbeheer verhelpt die zwakke plekken waarvoor een software-update beschikbaar is. Een organisatie die alleen patchbeheer toepast, sluit weliswaar bekende deuren, maar controleert niet per se of er nog open ramen zijn. Een organisatie die alleen kwetsbaarheidsbeheer toepast, heeft weliswaar een duidelijk beeld van haar kwetsbaarheden, maar beschikt over een zwakke uitvoeringsmechanisme om deze te verhelpen.

Patch management

Patchbeheer is het proces waarbij software-updates worden geïdentificeerd, getest en geïmplementeerd op alle apparaten en systemen in uw omgeving. Leveranciers brengen patches uit om fouten te verhelpen, beveiligingslekken te dichten, de prestaties te verbeteren en de compatibiliteit te waarborgen. In de praktijk houdt dit in dat apparaten worden gescand om ontbrekende patches op te sporen, dat updates in een gecontroleerde omgeving worden getest voordat ze op grote schaal worden uitgerold, dat goedgekeurde patches binnen vastgestelde onderhoudsvensters worden geïmplementeerd en dat wordt gecontroleerd of ze succesvol zijn toegepast.

De reikwijdte van patchbeheer reikt inmiddels veel verder dan alleen het besturingssysteem. Hoewel updates van besturingssystemen van Microsoft, Apple en Linux-distributies het meest in het oog springen, zijn browsers, productiviteitspakketten, tools voor toegang op afstand en bedrijfsapplicaties net zo vaak het doelwit van aanvallers. Een omgeving waarin Windows volledig up-to-date is, maar Chrome twee versies achterloopt, blijft daardoor kwetsbaar. Patchbeheerprogramma’s zijn er juist op ontworpen om al deze aspecten op grote schaal bij te houden.

Beheer van kwetsbaarheden

Kwetsbaarheidsbeheer is het doorlopende proces waarbij beveiligingszwakheden in een IT-omgeving worden opgespoord, geclassificeerd, geprioriteerd en verholpen. Het heeft een bredere reikwijdte dan patchbeheer: terwijl patchbeheer zich richt op software-updates, omvat kwetsbaarheidsbeheer het volledige beeld van de blootstelling, inclusief verkeerde configuraties, onveilige netwerkdiensten, verouderde versleutelingsprotocollen, te soepele toegangscontroles, software die het einde van de levensduur heeft bereikt en ontbrekende patches.

De kerncyclus bestaat uit scannen, beoordelen, prioriteren, verhelpen en verifiëren. Tools voor het scannen op kwetsbaarheden onderzoeken apparaten, applicaties en netwerkdiensten en vergelijken de bevindingen vervolgens met bekende CVE-databases en beveiligingsbenchmarks. Elke bevinding krijgt een ernstscore, meestal op basis van het Common Vulnerability Scoring System (CVSS), om teams te helpen beslissen wat ze als eerste moeten verhelpen. Het verhelpen kan betekenen dat er een patch wordt toegepast, maar het kan ook betekenen dat een configuratie wordt gewijzigd, een dienst wordt uitgeschakeld, een systeem wordt geïsoleerd of dat het risico wordt geaccepteerd wanneer er geen oplossing bestaat.

De prioriteringsfase is het moment waarop kwetsbaarheidsbeheer precies dat doet wat patchbeheer niet kan. Een lijst met 500 ontbrekende patches zegt niets over welke drie op dit moment actief worden misbruikt. Kwetsbaarheidsbeheerprogramma’s die gebruikmaken van dreigingsinformatie brengen die bevindingen met hoge urgentie aan het licht en plaatsen ze bovenaan de wachtrij, ongeacht hun ruwe CVSS-score.

Patchbeheer versus kwetsbaarheidsbeheer: de belangrijkste verschillen

Beide werkwijzen zijn gericht op het verminderen van beveiligingsrisico’s, maar benaderen het probleem vanuit verschillende invalshoeken en vinden plaats op verschillende niveaus van de stack. Patchbeheer is een proces dat gericht is op de uitvoering. Kwetsbaarheidsbeheer is een programma dat gericht is op risico’s. In de onderstaande tabel wordt weergegeven waarin ze van elkaar verschillen op de aspecten die het belangrijkst zijn.

Toepassingsgebied

Patchbeheer is beperkt tot software waarvoor een door de leverancier uitgebrachte update beschikbaar is. Als een leverancier geen oplossing heeft uitgebracht, valt er in het kader van patchbeheer niets te implementeren. Dat is een reële beperking. Veel kwetsbaarheden die aanvallers misbruiken, hebben helemaal niets te maken met ontbrekende patches: het gaat om open poorten, standaard inloggegevens die niet zijn gewijzigd, verkeerd geconfigureerde diensten of systemen die het einde van hun levensduur hebben bereikt en nooit meer een update zullen ontvangen. Kwetsbaarheidsbeheer heeft een bredere opdracht. Het identificeert kwetsbaarheden in al deze categorieën, ongeacht of er een patch bestaat, en stuurt de aanpak aan die voor elk geval het meest geschikt is.

Prioritering

Bij patchbeheer wordt prioriteit toegekend op basis van de ernstclassificatie van de leverancier en de releasedatum. Dat is een redelijk uitgangspunt, maar geeft geen volledig beeld. Een als ‘kritiek’ beoordeelde CVE op een geïsoleerde interne testserver vormt niet hetzelfde risico als een als ‘gemiddeld’ beoordeelde CVE op een openbare webserver waarop al actieve pogingen tot misbruik plaatsvinden. Kwetsbaarheidsbeheer houdt rekening met dreigingsinformatie, de kriticiteit van bedrijfsmiddelen en de zakelijke context om een prioritering op te stellen die het daadwerkelijke gevaar weerspiegelt, in plaats van uitsluitend de classificatie van de leverancier. Dat onderscheid is vooral van belang wanneer teams onder druk staan wat betreft beschikbare middelen en niet alles in één keer kunnen verhelpen.

Cadans

Patchbeheer volgt doorgaans een vaste cyclus, meestal gekoppeld aan maandelijkse releasekalenders van leveranciers, zoals Microsofts ‘Patch Tuesday’, met een versneld traject voor kritieke ‘out-of-band’-updates. Kwetsbaarheidsbeheer vindt continu plaats. Elke dag worden er nieuwe CVE’s gepubliceerd, omgevingen veranderen naarmate systemen worden toegevoegd, opnieuw geconfigureerd of aangesloten op nieuwe diensten, en de informatie over bedreigingen verschuift naarmate er nieuwe exploits opduiken. Een programma dat slechts één keer per maand de blootstelling in kaart brengt, zal steevast het moment missen waarop het risico het grootst is.

Sanering

Elke actie op het gebied van patchbeheer verloopt volgens hetzelfde stramien: een ontbrekende update opsporen, deze testen en implementeren. Kwetsbaarheidsbeheer omvat een breder scala aan corrigerende maatregelen, afhankelijk van wat de bevinding precies inhoudt. Dat kan het aanbrengen van een patch betekenen, maar ook het uitschakelen van een overbodige dienst, het versterken van een configuratie, het segmenteren van een netwerk, het aanscherpen van toegangscontroles of, wanneer er geen praktische oplossing bestaat, het vastleggen van een risicoacceptatie met een vastgestelde evaluatiedatum. Als alle bevindingen als patchproblemen worden behandeld, worden de bevindingen die dat niet zijn, verkeerd aangepakt.

Waar patchbeheer en kwetsbaarheidsbeheer elkaar overlappen

Het gebied waar de grootste overlap bestaat, betreft softwarekwetsbaarheden waarvoor patches beschikbaar zijn. Wanneer bij een kwetsbaarheidsscan een CVE wordt gevonden waarvoor een oplossing van de leverancier beschikbaar is, verloopt het herstelproces rechtstreeks via het patchbeheerproces. Op dit kruispunt moeten de twee disciplines met elkaar communiceren: kwetsbaarheidsbeheer stelt vast wat er moet worden verholpen en bepaalt de prioriteit, terwijl patchbeheer de implementatie uitvoert.

Juist bij deze overdracht lopen veel programma’s vast. Een kwetsbaarheidsscan levert een bevinding op. Die komt in een wachtrij terecht. Het patchbeheerteam, dat met een aparte tool en een aparte backlog werkt, ziet dit niet. Er gaan weken voorbij. De bevinding blijft openstaan. Aanvallers zien dit patroon op grote schaal en maken er misbruik van.

Volgens het „2025 Data Breach Investigations Report“ van Verizon is het misbruik van kwetsbaarheden als eerste toegangsweg met 34% gestegen ten opzichte van vorig jaar en is dit nu goed voor 20% van alle bevestigde datalekken. Die stijging is niet te wijten aan het feit dat nieuwe kwetsbaarheden ongewoon ernstig zijn. Het komt doordat de doorlooptijden voor het verhelpen van kwetsbaarheden te lang zijn. Voor een deel van de kritieke kwetsbaarheden in edge-apparaten en VPN’s constateerde Verizon dat de mediane tijd tussen de bekendmaking en grootschalige misbruiking nul dagen bedroeg, nog voordat de meeste beveiligingsbeheerders de kans hadden gehad om in te grijpen.

Deze overlap strekt zich ook uit tot het gebied van compliance. PCI DSS, HIPAA, NIST en CIS Controls vereisen allemaal bewijs van systematische identificatie van kwetsbaarheden en tijdige herstelmaatregelen. Een programma waarin scans en patches gegevens uitwisselen, levert dat bewijs veel overzichtelijker op dan twee losstaande tools met afzonderlijke rapporten.

Waarom patch- en kwetsbaarheidsbeheer allebei nodig zijn

Geen van beide werkwijzen is op zichzelf voldoende.

Patchbeheer zonder kwetsbaarheidsbeheer houdt in dat updates volgens schema worden geïnstalleerd zonder dat er een duidelijk beeld is van de daadwerkelijke blootstelling. Het kan zijn dat u efficiënt patches installeert, terwijl een verkeerde configuratie op een server die in contact staat met het openbare internet of een vergeten verouderd systeem waarvoor geen updates beschikbaar zijn, ongemerkt toegankelijk blijft. Volgens het rapport ‘2024 State of Ransomware’ van Sophos begon 32% van de ransomware-aanvallen in dat jaar met een niet-gepatchte kwetsbaarheid. Alleen patches toepassen, zonder de prioriteringslaag van kwetsbaarheidsbeheer, zorgt ervoor dat de meest risicovolle hiaten het moeilijkst te zien zijn.

Kwetsbaarheidsbeheer zonder patchbeheer betekent weliswaar een goed overzicht, maar een zwakke uitvoeringsmotor. Scans leveren bevindingen op. Bevindingen vragen om actie. Als het installeren van patches handmatig of inconsistent verloopt, blijft de kloof tussen weten en verhelpen groot. Volgens onderzoek van Indusface slaagt meer dan 52% van de ondernemingen er niet in om kritieke patches binnen 30 dagen na de release toe te passen. Zonder geautomatiseerd patchbeheer dat hand in hand gaat met kwetsbaarheidsbeheer, is het vrijwel onmogelijk om die kloof op grote schaal te dichten.

Voor MSP’s zijn beide aspecten van dit antwoord om verschillende redenen van belang: klanten willen weten of ze gedekt zijn. Patchrapporten geven antwoord op de vraag „Zijn we up-to-date?“ Kwetsbaarheidsbeheer geeft antwoord op de vraag „Zijn we veilig?“ Alleen door beide toe te passen, krijg je een eerlijk antwoord op beide vragen.

Hoe stel je een geïntegreerd programma op?

Voor integratie is geen enkel platform nodig, maar wel een gezamenlijke workflow. Het belangrijkste verband is eenvoudig: wanneer bij een kwetsbaarheidsscan een CVE wordt gevonden waarvoor een patch beschikbaar is, moet die bevinding direct worden meegenomen bij het stellen van prioriteiten voor patches en de implementatie versnellen. Juist die ene gegevenskoppeling dicht de kloof die de meeste programma’s open laten.

Daarnaast zijn er een aantal werkwijzen die ervoor zorgen dat het gecombineerde programma in de praktijk goed functioneert:

• Eerst de inventaris van de bedrijfsmiddelen: beide disciplines zijn afhankelijk van de kennis van wat er in de omgeving aanwezig is. Apparaten die niet in de inventaris staan, worden niet gescand en krijgen geen patches.
• Stel de scanfrequentie in op basis van het risiconiveau: systemen die in verbinding staan met het internet en systemen met een hoge waarde moeten wekelijks of continu worden gescand. Interne systemen met een lager risico kunnen doorgaans maandelijks worden gescand. Elke belangrijke wijziging, zoals de implementatie van een nieuwe applicatie of een grote patchcyclus, moet aanleiding geven tot een gerichte scan.
• Stel SLA’s voor het verhelpen van problemen vast op basis van ernst: een gangbare richtlijn is dat kritieke bevindingen binnen 24 tot 72 uur worden aangepakt, ernstige binnen zeven dagen, gemiddelde binnen 30 dagen en minder ernstige binnen 90 dagen. Uitzonderingen moeten worden gedocumenteerd en er moet een vaste evaluatiedatum worden vastgesteld; uitstel voor onbepaalde tijd is niet toegestaan.
• Controleer na het verhelpen van het probleem: een geïmplementeerde patch is niet hetzelfde als een geverifieerde patch. Door na een herstelcyclus opnieuw te scannen, wordt de cirkel rondgemaakt en wordt het bewijsmateriaal geleverd dat nalevingskaders vereisen.
• Omgaan met bevindingen waarvoor geen patch beschikbaar is: Als er geen update bestaat, moet het kwetsbaarheidsbeheer een andere aanpak hanteren: het beveiligen van de configuratie, netwerksegmentatie, compenserende maatregelen of een gedocumenteerde risicoacceptatie. Door bevindingen waarvoor geen patch beschikbaar is zonder plan in de wachtrij te laten staan, stapelt het restrisico zich stilletjes op.

Beheer patches en kwetsbaarheden met Kaseya

Het beheren van patches en kwetsbaarheden als onderling gekoppelde processen is in principe eenvoudig, maar in de praktijk moeilijker vol te houden zonder tools die beide onderdelen van de workflow ondersteunen. Het meest voorkomende knelpunt is de overdracht: een kwetsbaarheidsscan brengt een CVE aan het licht waarvoor een patch beschikbaar is, maar er is geen automatische koppeling tussen die bevinding en de wachtrij voor het implementeren van patches.

De patchbeheersoftware van Kaseya automatiseert het in kaart brengen, testen en implementeren op Windows-, macOS- en Linux-endpointsen, en omvat zowel besturingssysteemupdates als applicaties van derden. Voor MSP’s zijn het afdwingen van beleid per klant en rapportage over naleving standaard ingebouwd, zodat hetzelfde programma dat uw eigen omgeving beschermt, kan worden uitgebreid naar elke klant die u beheert.

VulScan, de tool van Kaseya voor kwetsbaarheidsbeheer, biedt interne en externe netwerkscans met geautomatiseerde inventarisatie van bedrijfsmiddelen, op CVSS gebaseerde risicoscores en aanbevelingen voor herstelmaatregelen. De tool is speciaal ontwikkeld om te voldoen aan de dekkingsvereisten en kostenstructuur waarmee MSP's en interne IT-teams werken, zonder de complexiteit en overhead van platforms op enterprise-niveau.

Door beide in dezelfde omgeving uit te voeren, wordt de kloof tussen kennis en oplossing overbrugd. Bevindingen met betrekking tot kwetsbaarheden worden direct meegenomen bij het vaststellen van de prioriteit van patches, de herstelmaatregelen worden gevolgd totdat ze zijn bevestigd, en beide onderdelen van het programma leveren rapportages op die antwoord geven op de vragen van klanten en auditors.