De meeste patchprogramma’s mislukken niet omdat het team de stappen niet kent. Ze mislukken juist in de tussenruimtes: het apparaat dat nooit in de inventaris is opgenomen, de patch die drie weken lang op de status ‘goedgekeurd’ bleef staan in afwachting van een onderhoudsvenster, of het implementatierapport dat niemand heeft bekeken omdat het dashboard al een nalevingspercentage van 96% aangaf.
Een degelijk patchbeheerproces zorgt ervoor dat die kwetsbare overdrachten tot een herhaalbaar proces worden. Het biedt je een stappenplan, een manier om te controleren of een stap daadwerkelijk is voltooid en een duidelijk antwoord wanneer een auditor vraagt hoe je hebt bepaald welke patches afgelopen dinsdag zijn geïnstalleerd.
Deze handleiding neemt u stap voor stap mee door de volledige levenscyclus. U ziet wat er in elke fase gebeurt, wie er doorgaans verantwoordelijk voor is, waar het proces het vaakst vastloopt en hoe lang elke stap in een goed functionerende omgeving ongeveer in beslag zou moeten nemen. De RMM-software van Kaseya beheert het patchen op miljoenen eindpunten voor MSP’s en interne IT-teams, waardoor een vrij duidelijk beeld ontstaat van waar het misgaat en hoe een „goed“ proces er in elke fase uitziet.
Wat is een proces voor patchbeheer?
Als dit onderwerp nieuw voor je is, begin dan met onze uitgebreide gids‘Wat is patchbeheer?’, en kom daarna hier terug. Voor alle anderen geldt dat het proces de operationele ruggengraat vormt achter de definitie. Het is de herhaalbare cyclus waarbij een kwetsbaarheid of een release van een leverancier wordt omgezet in een gepatcht, gecontroleerd en gedocumenteerd eindpunt.
In de praktijk kom je verschillende benamingen tegen. De levenscyclus van patchbeheer, de workflow van patchbeheer, de procedure voor patchbeheer of simpelweg het patchproces. Ze verwijzen allemaal naar hetzelfde. Het aantal stappen varieert van vier tot tien, afhankelijk van wie erover schrijft, maar de onderliggende logica blijft grotendeels hetzelfde.
We hanteren hier zeven stappen omdat dat het detailniveau is waarbij elke fase een duidelijke verantwoordelijke en een duidelijk resultaat heeft. Bij minder stappen beginnen de stappen in elkaar over te lopen. Bij meer stappen creëer je onderscheidingen die in de praktijk niet bestaan.
Voordat we verder gaan, is er één ding dat de aandacht verdient: het proces voor routinematige, geplande patches is niet hetzelfde als het proces voor nood- of zero-day-patches. Op papier lijken de stappen misschien op elkaar, maar de tijdschema’s, goedkeuringsfasen en risicotolerantie zijn aanzienlijk strakker. We zullen beide behandelen, waarbij we de routinematige werkwijze als basis nemen en de afwijkingen voor noodsituaties benadrukken waar dat het meest van belang is.
Stappenplan voor patchbeheer: 7 belangrijke stappen
Een degelijk patchbeheerproces biedt een gestructureerde methode om updates op te sporen, te prioriteren, te implementeren en te controleren, zonder dat men zich hoeft te baseren op giswerk. Hieronder volgt een overzicht van hoe het proces doorgaans verloopt, van het in kaart brengen van de systemen tot en met de rapportage.
Stap 1: Inventarisatie en inventarisering van bedrijfsmiddelen
Verantwoordelijke: Meestal de eindgebruiker of systeembeheerder, in overleg met de beveiligingsafdeling.
Je kunt geen problemen oplossen waarvan je het bestaan niet kent. De eerste stap is het opstellen en bijhouden van een volledig, nauwkeurig en actueel overzicht van alle apparaten, besturingssystemen, applicaties en firmwareversies in je omgeving. Dat omvat servers, werkstations, laptops, mobiele apparaten, virtuele machines, netwerkapparatuur, IoT-apparaten en alle cloudworkloads die onder jouw beheer vallen.
Het ideaal is niet een spreadsheet die iemand elk kwartaal bijwerkt. Het is een voortdurend bijgewerkte inventaris die is opgebouwd op basis van geautomatiseerde detectie, waarbij elk systeem is aangevuld met informatie over de software-BOM, de OS-versie, het tijdstip van de laatste controle en de eigenaar. Elke leemte in deze inventaris leidt tot een leemte in uw patchdekking, en elke leemte in de dekking komt later aan het licht als de host waarvan niemand zich realiseerde dat deze een verouderde versie van OpenSSL draaide.
Veelvoorkomende storingsoorzaken: BYOD-apparaten waarop de agent niet draait, laptops van externe medewerkers die slechts eens per kwartaal verbinding maken met het VPN, de labserver die iemand heeft opgezet maar vergeten is te registreren, en alles wat zich bevindt in een cloudabonnement dat eigendom is van één enkel team.
Verwachte doorlooptijd: Discovery zelf draait continu. Het duurt doorgaans één tot vier weken om voor het eerst een betrouwbare, volledige basis te verkrijgen, afhankelijk van de omvang van de omgeving en de mate waarin er schaduw-IT aanwezig is.
Stap 2: Controle en identificatie van patches
Verantwoordelijke: Meestal een gezamenlijke verantwoordelijkheid van IT en beveiliging.
Zodra u weet wat u in huis hebt, moet u weten welke oplossingen er beschikbaar zijn om dit te verhelpen. Deze stap houdt in dat u regelmatig de patch-releases bijhoudt van alle leveranciers waarvan de software in uw omgeving draait, evenals beveiligingsadviezen van CISA, PSIRT-teams van leveranciers en bronnen van dreigingsinformatie, om kwetsbaarheden op te sporen die mogelijk een buitengewone reactie vereisen.
Voor Microsoft, Adobe en Oracle verloopt dit proces relatief gestructureerd. Patch Tuesday valt altijd op de tweede dinsdag van de maand, de beveiligingsbulletins zijn voorspelbaar en de meeste tools voor patchbeheer verwerken ze automatisch. De problemen doen zich overal elders voor. Browsers, tools voor videoconferenties, runtime-bibliotheken, niche-bedrijfsapps, netwerkfirmware en printerstuurprogramma's worden allemaal op hun eigen tempo uitgebracht, vaak zonder veel ophef. Dit is een van de sterkste argumenten voor een patchbeheertool die detectie van derde partijen native afhandelt, in plaats van dat uw team honderden RSS-feeds handmatig moet monitoren.
Veelvoorkomende fouten: het volledig negeren van releases van andere leveranciers, het over het hoofd zien van buiten de reguliere patchcyclus vallende beveiligingsadviezen die tussen Patch Tuesdays door worden gepubliceerd, en het beschouwen van CVE-feeds als de officiële bron in plaats van de beveiligingsadviezen van leveranciers.
Verwachte doorlooptijd: doorlopend. Vanaf de release tot de detectie in uw omgeving dient u dit bij tier-1-leveranciers in uren te meten en bij alle andere leveranciers binnen een dag of twee.
Stap 3: Risicobeoordeling en prioritering
Verantwoordelijke: Beveiliging, in overleg met IT wat betreft de operationele gevolgen.
De meeste teams hebben meer beschikbare patches dan ze kunnen testen en implementeren. Door prioriteiten te stellen, zorg je ervoor dat de patches die het belangrijkst zijn als eerste worden uitgerold.
De traditionele aanpak was om te sorteren op CVSS-score en alle kritieke kwetsbaarheden te verhelpen. Dat heeft nog steeds zijn nut, maar op zichzelf is het een te grove methode. Een kwetsbaarheid met een CVSS-score van 9,8 in software die niet met het internet is verbonden, waarvoor geen exploit bekend is en die op drie interne hosts draait, is een heel ander probleem dan een kwetsbaarheid met een CVSS-score van 7,5 waarvoor een werkende exploit bestaat die in het wild actief wordt gebruikt tegen bedrijven in uw sector. Een risicogebaseerde aanpak houdt rekening met de ernst, maar ook met de kriticiteit van de assets, de blootstelling, de beschikbaarheid van exploits en de impact op het bedrijf.
Hier komen de CISA-catalogus met bekende misbruikte kwetsbaarheden en de feeds met dreigingsinformatie goed van pas. Ze geven aan welke kwetsbaarheden aanvallers gebruiken, wat een veel betere indicatie is voor wat je als eerste moet patchen dan alleen de CVSS-score.
Het resultaat van deze stap is een geprioriteerde lijst met globale tijdschema’s. Een gangbaar schema ziet er als volgt uit: kritieke patches worden binnen 48 tot 72 uur geïmplementeerd, patches met een hoge prioriteit binnen 14 dagen, patches met een gemiddelde prioriteit binnen 30 dagen en patches met een lage prioriteit binnen 90 dagen. Cyber Essentials in het Verenigd Koninkrijk vereist dat patches voor kwetsbaarheden met een score van 7,0 of hoger binnen 14 dagen worden geïnstalleerd; dit is een nuttig uitgangspunt geworden voor organisaties die dat niveau van compliance-volwassenheid nastreven. Welke tijdschema's u ook vaststelt, leg ze vast in uw patchbeheerbeleid, zodat de rest van het proces hierop voortbouwt.
Veelvoorkomende fouten: uitsluitend uitgaan van CVSS-scores, gegevens over de misbruikbaarheid negeren, elke „kritieke” patch als even kritiek beschouwen, het omgekeerde probleem waarbij tijdschema’s als deadlines in plaats van streefdata worden gezien, en wachten tot dag 13 om de patch te implementeren.
Geschatte tijdsbesteding: Aantal uren per patchcyclus als uw tools het zware werk voor hun rekening nemen. Een volledige dag of meer als uw team elk advies handmatig beoordeelt.
Stap 4: Patch-test
Verantwoordelijke: IT-operations, in overleg met applicatiebeheerders voor patches met een hoog risico.
Testen is de stap die als eerste wordt geschrapt als een team onder druk staat, en het is de stap waar men het meeste spijt van krijgt als deze wordt overgeslagen. Het gaat er juist om dat je de patch die iets kapotmaakt opmerkt voordat deze in productie gaat.
Ervaren teams maken gebruik van implementatieringen of gefaseerde uitrol. Een patch wordt eerst geïnstalleerd op een representatieve steekproef van testcomputers, die idealiter bestaat uit een mix van hardwaremodellen, besturingssysteemversies en belangrijke applicaties. Na 24 tot 72 uur probleemloze werking wordt de patch doorgegeven aan een grotere pilotgroep. Pas daarna wordt de patch uitgerold naar het volledige productieomgeving. Het exacte aantal ringen is minder belangrijk dan het principe: een enkele implementatie mag op geen enkel moment alle eindpunten tegelijk raken.
Bij routinepatches duurt de testfase doorgaans 24 tot 72 uur. Bij nood- of zero-day-patches kunt u dit terugbrengen tot een paar uur smoke-testing in een kleine testomgeving voordat u de patch op grote schaal uitrolt, waarbij u het hogere risico accepteert in ruil voor een snellere afsluiting van het beveiligingslek. Die afweging moet een weloverwogen beslissing zijn, en niet de standaardprocedure.
Veelvoorkomende fouten: het volledig overslaan van tests op kleine omgevingen, het uitsluitend testen op hardware die niet representatief is voor de productieomgeving, het bestempelen van een patch als „getest“ nadat één host 30 minuten heeft gedraaid, en het ontbreken van een terugvalplan voor het geval er iets misgaat.
Verwachte doorlooptijd: 24 tot 72 uur voor standaardpatches, twee tot twaalf uur voor spoedgevallen, afhankelijk van de risicotolerantie.
Stap 5: Implementatie
Eigenaar: IT-operaties
Bij de implementatie komt het erop aan. Patches worden volgens een vast schema en binnen de onderhoudsvensters die je met de organisatie bent overeengekomen, vanuit de testomgeving naar de productieomgeving overgezet.
Deze stap kent meer knelpunten dan welke andere stap in het proces ook, vooral omdat hier de chaotische praktijk om de hoek komt kijken. Laptops die niet op het netwerk zijn aangesloten wanneer de implementatie wordt uitgevoerd. Eindgebruikers die het opnieuw opstarten steeds uitstellen. Servers die vanwege onderlinge afhankelijkheden zorgvuldig in de juiste volgorde moeten worden uitgevoerd. Patches waarvoor eerst een bepaalde service moet worden gestopt. Apparaten die niet op het netwerk zijn aangesloten en al wekenlang geen verbinding hebben gemaakt.
Een goed geconfigureerde RMM-oplossing doet het meeste werk hier onzichtbaar. Het installeert patches volgens het beleid, probeert het opnieuw wanneer computers weer online komen, voert herstarts uit binnen de afgesproken tijdvensters en brengt uitzonderingen onder de aandacht zodat deze door een medewerker kunnen worden bekeken. Wat u in deze fase van uw tools verwacht, is een hoog succespercentage bij de implementatie zonder dat u er handmatig achteraan moet gaan, plus inzicht in de lange staart van apparaten die de patch de eerste keer niet hebben geïnstalleerd.
Onderhoudsvensters zijn belangrijker dan men denkt. Een patch waarvoor een herstart van een klinisch werkstation midden in een ziekenhuisdienst nodig is, wordt vaak uitgesteld, wat betekent dat de patch in werkelijkheid niet wordt geïnstalleerd, ook al geeft uw dashboard aan dat dit wel het geval is. Het afstemmen van onderhoudsvensters op de daadwerkelijke bedrijfsvoering is wat het verschil maakt tussen patchprogramma’s die er goed uitzien op papier en patchprogramma’s die daadwerkelijk risico’s verminderen.
Veelvoorkomende fouten: ervan uitgaan dat ‘geïmplementeerd’ betekent dat de patch is geïnstalleerd, terwijl het in werkelijkheid betekent dat het pakket is verzonden; geen rekening houden met de grote groep apparaten die niet op het netwerk zijn aangesloten of niet aan de vereisten voldoen; implementeren zonder gecoördineerde onderhoudsvensters; en geen terugvalplan hebben voor het geval een implementatie de productieomgeving verstoort.
Geschatte tijdsduur: enkele minuten tot enkele uren per machine voor de technische implementatie zelf, maar de totale tijd die nodig is om het volledige netwerk te dekken tijdens een reguliere patchcyclus bedraagt doorgaans één tot twee weken, rekening houdend met apparaten die niet op het netwerk zijn aangesloten, uitgestelde herstarts en het afhandelen van uitzonderingen.
Stap 6: Controle
Verantwoordelijke: IT-operations, met controle door de beveiligingsafdeling.
Verificatie is de stap waarvan de meeste teams weten dat ze die beter zouden moeten uitvoeren. Het doel is om, als alles weer rustig is, te controleren of elke patch op elk doelapparaat is geïnstalleerd en of de onderliggende kwetsbaarheid is verholpen.
Er zijn hier twee aspecten. Ten eerste: is de patch succesvol geïnstalleerd? De meeste tools voor patchbeheer geven hierover weliswaar uitsluitsel, maar achter dit antwoord gaat vaak een lange reeks statussen schuil als ‘herstart in behandeling’ of ‘uitgesteld’, die er op het eerste gezicht goed uitzien, maar dat in werkelijkheid niet zijn. Ten tweede: is de kwetsbaarheid daadwerkelijk verholpen? Een afzonderlijke kwetsbaarheidsscan na het patchen brengt gevallen aan het licht waarin een patch weliswaar is geïnstalleerd maar de kwetsbaarheid niet volledig heeft verholpen, of waarin een gerelateerde kwetsbaarheid blijft bestaan omdat er een andere patch nodig was.
De kloof tussen het „succespercentage bij implementatie“ dat door uw patchtool wordt gerapporteerd en het „percentage verholpen kwetsbaarheden“ dat door uw scanner wordt gerapporteerd, is vaak de bron van auditbevindingen. Een team dat een patch-nalevingspercentage van 98% rapporteert, maar slechts 85% van de kwetsbaarheden heeft verholpen, kampt met een tekortkoming in het proces, niet met een probleem met de tool.
Veelvoorkomende fouten: vertrouwen op statistieken over het succes van de implementatie als bewijs dat het probleem is opgelost, geen scan na de implementatie, en nooit onderzoek doen naar de langdurige gevolgen van mislukte implementaties.
Verwachte doorlooptijd: 24 tot 48 uur na de implementatie voordat de scan na de patch is uitgevoerd en betrouwbare gegevens oplevert.
Stap 7: Rapportage en documentatie
Verantwoordelijke: IT-operations, vaak in samenwerking met beveiliging en compliance.
De cyclus is nog niet voltooid zodra de patches zijn gecontroleerd. Deze is pas voltooid wanneer de werkzaamheden zodanig zijn gedocumenteerd dat aan auditors kan worden aangetoond dat de nodige zorgvuldigheid in acht is genomen, dat trends aan het management worden gesignaleerd en dat de bevindingen worden meegenomen bij het verbeteren van de volgende cyclus.
Hoe goede documentatie eruitziet: een overzicht per patchcyclus waarin wordt weergegeven wat er is uitgebracht, wat prioriteit kreeg, wat is geïmplementeerd, wat mislukte en waarom, welke uitzonderingen zijn toegestaan en voor welke apparaten. Statistieken over de tijd die nodig is om patches te installeren, uitgesplitst naar ernstniveau. Percentages voor patch-compliance per klant, per afdeling of per apparaattype. Een duidelijk controlespoor dat een externe controleur kan volgen om de patchgeschiedenis van elk afzonderlijk eindpunt te verifiëren.
Hier liggen ook je verbeterpunten. Als 30% van je kritieke patches buiten de termijn van 14 dagen valt, is de vraag die je moet beantwoorden niet „hoe kunnen we sneller implementeren?“, maar „waar in de voorgaande zes stappen gaat de tijd naartoe?“ Het antwoord ligt bijna altijd bij stap drie (het stellen van prioriteiten verloopt te traag) of stap vijf (de implementatie kent te veel uitzonderingen). Dankzij de documentatie is die diagnose mogelijk.
Veelvoorkomende knelpunten: documentatie die pas achteraf wordt opgesteld, dashboards die de implementatie weergeven zonder context, geen beoordelingscyclus, geen koppeling tussen statistieken en procesverbeteringen.
Tijdsbesteding: maandelijkse evaluatievergadering plus het continu bijhouden van statistieken. De rapportage zelf moet geautomatiseerd zijn; wat tijd kost, zijn de menselijke controle en de daaruit voortvloeiende procesaanpassingen.
Hoe noodpatches het proces veranderen
Het bovenstaande beschrijft de standaardprocedure voor het aanbrengen van patches. Wanneer er een zero-day-kwetsbaarheid of een kwetsbaarheid die actief wordt misbruikt aan het licht komt, wordt die procedure versneld. De zeven stappen blijven hetzelfde, maar de beschikbare tijd wordt teruggebracht van weken tot uren.
In een noodpatchcyclus vindt de identificatie binnen enkele uren na het advies plaats, wordt de prioriteit in feite voor je bepaald (het is kritiek, er wordt misbruik van gemaakt, de patch wordt uitgerold), wordt het testen beperkt tot een snelle rooktest in een kleine omgeving en wordt de implementatie op grote schaal uitgevoerd, in de veronderstelling dat wat storingen te verkiezen zijn boven voortdurende blootstelling. De verificatie en documentatie worden aangescherpt, omdat er een auditgesprek zal plaatsvinden.
Het risico bij noodmaatregelen is meestal niet dat er te snel wordt gehandeld. Het risico is juist dat er geen plan is, waardoor het team onder druk moet improviseren en belangrijke stappen overslaat. Een gedocumenteerde procedure voor noodpatches, met daarin een aangewezen besluitvormer, een vooraf goedgekeurde uitzondering op de normale wijzigingscontrole en een getest herstelplan, is wat het snel aanbrengen van patches veilig maakt.
Wanneer het patchingproces per omgeving verschilt
Servers, eindpunten, apps van derden en cloudworkloads maken allemaal gebruik van dezelfde zevenstappenmethode, maar met aanzienlijke verschillen in de details.
Voor servers is de afhankelijkheidsstructuur van groter belang. Als een databaseserver in de verkeerde volgorde wordt gepatcht ten opzichte van de applicatieservers die ervan afhankelijk zijn, kan dit leiden tot urenlange uitval. De onderhoudsvensters zijn krapper, de wijzigingsbeheersing is strenger en het plannen van terugdraaiingen is absoluut noodzakelijk. De tijd die nodig is om niet-kritieke kwetsbaarheden in servers te verhelpen, is doorgaans langer dan bij eindpunten, en dat is terecht.
Bij eindpunten vormt de ‘long tail’ het probleem. Laptops die worden meegenomen, apparaten die het opnieuw opstarten uitstellen, gebruikers die hun computer afsluiten in plaats van opnieuw op te starten. Bij het patchen van eindpunten is een betrouwbare afhandeling van apparaten die niet op het netwerk zijn aangesloten noodzakelijk, evenals een manier om om te gaan met de onvermijdelijke 5 tot 10 procent van de machines die een bepaalde patchcyclus missen.
Bij applicaties van derden is het volume het probleem. In een typische omgeving zijn tientallen apps van derden aanwezig, elk met een eigen releasekalender, en een aanzienlijk deel van de beveiligingsinbreuken vindt zijn oorsprong in een niet-gepatchte app van een derde partij in plaats van in een niet-gepatcht besturingssysteem. Dit is zo belangrijk dat we het apart hebben behandeld. Raadpleeg onze speciale handleiding over patchbeheer voor apps van derden voor de operationele details.
Voor cloudworkloads betekent onveranderbaarheid een ware ommekeer. In een goed ontworpen cloudomgeving breng je geen patches aan op een actieve instance; je vervangt deze door een nieuwe instance die is opgebouwd vanuit een bijgewerkte image. Het zevenstappenproces blijft van kracht, maar stap vijf lijkt meer op het bouwen van een image en het vervangen van een instance dan op het installeren van software. In hybride omgevingen worden beide werkwijzen naast elkaar toegepast, en daar ligt de grootste operationele complexiteit.
Waar het proces het vaakst vastloopt
Er zijn een paar patronen die steeds weer terugkomen in omgevingen waar het patchingprogramma niet naar behoren functioneert.
Ten eerste is er sprake van een onvolledige inventaris. Als de eerste stap niet goed is uitgevoerd, blijft die tekortkoming in alle volgende stappen bestaan. De hosts waarvan je het bestaan niet kent, krijgen geen patches, en dat zijn vaak juist de hosts die aanvallers als eerste vinden, omdat ze slecht worden onderhouden – om dezelfde reden dat ze niet in de inventaris staan.
Het tweede probleem is de kloof tussen testen en implementatie. Patches worden getest, goedgekeurd en blijven vervolgens liggen in afwachting van een onderhoudsvenster dat door het bedrijf steeds wordt uitgesteld. Twee weken later is de patch nog steeds niet in productie genomen en is de oorspronkelijke urgentie verdwenen. De oplossing hiervoor is doorgaans een nauwere koppeling tussen goedkeuring en implementatie, plus minder, maar betrouwbaardere onderhoudsvensters.
Het derde punt betreft de lange staart van apparaten die niet aan de regels voldoen. Het dashboard geeft 95% aan. De resterende 5% is elke cyclus dezelfde 5%, en dat is bijna altijd de belangrijkste 5%. De laptops van het management, de servers waar niemand aan wil komen, de labomgeving met zijn eigen regels. Een volwassen programma maakt die lange staart zichtbaar, wijst voor elke uitzondering een verantwoordelijke aan en pakt deze aan in plaats van deze te negeren.
De vierde manier is verificatie uitsluitend op basis van de implementatiestatus. De tool meldt dat de update is geslaagd, het team gaat verder, maar uit de kwetsbaarheidsscan drie weken later blijkt dat 8% van de verondersteld gepatchte omgeving nog steeds kwetsbaar is. Om deze kloof te dichten, moeten de resultaten van de kwetsbaarheidsscan als de betrouwbare bron voor het verhelpen van kwetsbaarheden worden beschouwd, en niet het implementatierapport van de patch-tool.
De combinatie van deze faalpatronen verklaart waarom organisaties gemiddeld 209 dagen nodig hadden om de 17 kwetsbaarheden in randapparatuur te verhelpen die Verizon in zijn DBIR 2025 in kaart bracht, terwijl een aanvaller slechts vijf dagen nodig had om misbruik te maken van deze kwetsbaarheden. Het gaat hier om procesproblemen, niet om een gebrek aan bewustzijn.
Hoe de moderne tools van Kaseya het proces veranderen
Handmatig patchen werkt op geen enkele redelijke schaal. Het grote aantal releases, de verscheidenheid aan platforms en de snelheid waarmee kwetsbaarheden worden uitgebuit, zijn inmiddels zo groot geworden dat een team dit onmogelijk nog kan bijhouden met spreadsheets en afzonderlijke implementaties.
Goede tools voegen deze zeven stappen samen tot een samenhangende, geautomatiseerde workflow waarbij mensen alleen op de beslissingsmomenten worden ingeschakeld. Het inventariseren van systemen gebeurt continu. Patches worden binnen enkele uren na de release door de leverancier geïdentificeerd. De prioritering kan op basis van beleid plaatsvinden, waarbij kritieke patches automatisch worden goedgekeurd voor noodimplementatieringen. Het testen verloopt in vooraf gedefinieerde implementatieringen zonder handmatige tussenkomst. De implementatie spoort apparaten op die niet op het netwerk zijn aangesloten en zorgt ervoor dat herstarts binnen de afgesproken tijdvensters plaatsvinden. De verificatie wordt teruggekoppeld naar kwetsbaarheidsscans. De rapportage wordt automatisch gegenereerd.
Dit is het werkingsmodel achter geautomatiseerd patchbeheer, dat tegenwoordig de norm is voor elke omgeving die patchbeheer op grote schaal serieus neemt. Het hierboven beschreven zevenstappenproces vormt de basis van de automatisering; de automatisering zorgt ervoor dat het proces duurzaam is.
De patchbeheersoftware van Kaseya neemt deze workflow uit handen voor IT-teams en MSP’s, voor alle besturingssystemen en meer dan duizend applicaties van derden. Deze oplossing biedt beleidsgestuurde implementatie, implementatieringen, ondersteuning voor apparaten buiten het netwerk en rapportage over patch-compliance, allemaal in één pakket. Datto RMM, onderdeel van de Kaseya RMM-familie, is de cloud-native optie voor teams die dezelfde patchmogelijkheden willen zonder de onderliggende infrastructuur te hoeven beheren.
Het proces is belangrijker dan de tool. Maar zodra het proces goed is opgezet, maakt de juiste tool het verschil tussen een programma dat op papier goed lijkt en een programma dat het systeem daadwerkelijk op het door het bedrijf gewenste tempo bijwerkt. De volgende stap is dan de overgang van proces naar programma: raadpleeg onze begeleidende gids over best practices voor patchbeheer voor de principes die het verschil maken tussen een goed patchprogramma en een uitstekend patchprogramma.
