Het patchbeheerproces: een stapsgewijze handleiding

De meeste patchprogramma’s mislukken niet omdat het team de stappen niet kent. Ze mislukken juist in de hiaten daartussen: het apparaat dat nooit in de inventaris is opgenomen, de patch die drie weken lang in de status ‘goedgekeurd’ bleef hangen 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 volgorde die je kunt volgen, 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 endpointsen 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 patchbeheerproces?

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 endpoints.

In de praktijk zul je zien dat er verschillende benamingen voor worden gebruikt. De levenscyclus van patchbeheer, de workflow van patchbeheer, de procedure voor patchbeheer of simpelweg het patchproces. Ze beschrijven allemaal hetzelfde. Het aantal stappen varieert tussen de vier en de tien, afhankelijk van wie erover schrijft, maar de onderliggende logica verandert niet veel.

We hanteren hier zeven stappen, omdat dat het detailniveau is waarbij elke fase een duidelijke verantwoordelijke en een duidelijk te leveren 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 er dieper op ingaan, is er één ding dat de aandacht verdient: de procedure voor routinematige, geplande patches is niet dezelfde als die voor noodpatches of zero-day-patches. Op papier lijken de stappen misschien op elkaar, maar de tijdschema’s, goedkeuringsfasen en risicotolerantie worden aanzienlijk strakker. We zullen beide behandelen, waarbij we de routinematige procedure als basis nemen en de afwijkingen voor noodsituaties benadrukken waar dat het belangrijkst is.

Werkstroom van patchbeheer: 7 belangrijke stappen

Een degelijk patchbeheerproces biedt een gestructureerde aanpak om updates op te sporen, te prioriteren, te implementeren en te controleren, zonder dat men zich op giswerk hoeft te baseren. Hieronder wordt beschreven 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 volledige, nauwkeurige en actuele inventaris van alle apparaten, besturingssystemen, applicaties en firmwareversies in je omgeving. Daaronder vallen servers, werkstations, laptops, mobiele apparaten, virtuele machines, netwerkapparatuur, IoT-apparaten en alle cloud-workloads 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 softwarecomponenten, de OS-versie, het tijdstip van de laatste controle en de eigenaar. Elke leemte in deze inventaris leidt tot een leemte in je 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 ingehuurde medewerkers die eens per kwartaal verbinding maken met het VPN, de laboratoriumserver die iemand heeft opgezet en vergeten is te registreren, en alles wat zich bevindt in een cloudabonnement dat eigendom is van één enkel team.

Verwachte doorlooptijd: De Discovery-fase zelf loopt continu door. 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 sprake is van schaduw-IT.

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 elke leverancier wiens software in uw omgeving draait, evenals beveiligingsadviezen van CISA, PSIRT-teams van leveranciers en bronnen van dreigingsinformatie met betrekking tot kwetsbaarheden die mogelijk een buitengewone reactie vereisen.

Voor Microsoft, Adobe en Oracle verloopt dit proces relatief gestructureerd. Patch Tuesday valt op de tweede dinsdag van de maand, de beveiligingsbulletins zijn voorspelbaar en de meeste patchmanagementtools verwerken ze automatisch. De problemen doen zich overal elders voor. Browsers, tools voor videoconferenties, runtime-bibliotheken, niche-bedrijfsapplicaties, netwerkfirmware en printerstuurprogramma’s worden allemaal volgens hun eigen ritme uitgebracht, vaak zonder veel ophef. Dit is een van de sterkste argumenten voor een patchbeheertool die het detecteren van patches van derden standaard ondersteunt, in plaats van dat uw team honderden RSS-feeds handmatig moet bijhouden.

Veelvoorkomende fouten: het volledig negeren van releases van derden, het over het hoofd zien van out-of-band-beveiligingsadviezen die tussen de 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 te meten in uren voor tier-1-leveranciers en binnen een dag of twee voor alle andere leveranciers.

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 aanpak. Een kwetsbaarheid met een CVSS-score van 9,8 in software die niet in contact staat met het internet, 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 actief in het wild 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.

Dit is waar de CISA-catalogus met bekende misbruikte kwetsbaarheden en de feeds met dreigingsinformatie hun nut bewijzen. 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 prioriteitenlijst met globale tijdschema’s. Een veelgebruikt kader 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ïmplementeerd; 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 ze in de rest van het proces worden overgenomen.

Veelvoorkomende fouten: uitsluitend uitgaan van CVSS, gegevens over de uitbuitbaarheid 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 je tool het zware werk voor je doet. Een volledige dag of meer als je team elk advies handmatig beoordeelt.

Stap 4: Patch-test

Verantwoordelijke: IT-operations, in overleg met applicatieverantwoordelijken voor patches met een hoog risico.

Testen is de stap die als eerste wordt geschrapt wanneer een team onder druk staat, en het is de stap waar men het meeste spijt van heeft 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 endpointsen tegelijk raken.

Bij routine-patches duurt de testfase doorgaans 24 tot 72 uur. Bij nood- of zero-day-patches kun je dit terugbrengen tot een paar uur ‘smoke testing’ op een kleine ring voordat je de patch op grote schaal uitrolt, waarbij je het hogere risico accepteert in ruil voor een snellere afsluiting van het kwetsbaarheidsvenster. 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 terugdraaiplan 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 vastgesteld schema en binnen de onderhoudsvensters die je met de organisatie hebt afgesproken, 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 een rol gaat spelen. Laptops die niet op het netwerk zijn aangesloten wanneer de implementatie wordt uitgevoerd. Eindgebruikers die het opnieuw opstarten steeds uitstellen. Servers die vanwege afhankelijkheden zorgvuldig in de juiste volgorde moeten worden uitgevoerd. Patches waarvoor eerst een specifieke service moet worden gestopt. Apparaten die niet op het netwerk zijn aangesloten en al wekenlang geen verbinding hebben gemaakt.

Een goed geconfigureerde RMM doet het grootste deel van het werk hier onzichtbaar. Het installeert patches volgens het beleid, probeert het opnieuw wanneer computers weer online komen, voert herstarts uit binnen afgesproken tijdvensters en brengt uitzonderingen onder de aandacht zodat deze door mensen kunnen worden bekeken. Wat je in deze fase van je tools verwacht, is een hoog succespercentage bij de implementatie zonder dat je er handmatig achteraan moet gaan, plus inzicht in de ‘long tail’ 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 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 in rapportages en patchprogramma’s die daadwerkelijk risico’s verminderen.

Veelvoorkomende storingspatronen: ervan uitgaan dat ‘geïmplementeerd’ betekent dat de patch is geïnstalleerd, terwijl het in werkelijkheid betekent dat het pakket is verzonden; het negeren van het grote aantal apparaten dat niet op het netwerk is aangesloten of niet aan de vereisten voldoet; implementeren zonder afgestemde onderhoudsvensters; en het ontbreken van een terugdraaiplan voor het geval een implementatie de productieomgeving verstoort.

Verwachte tijdsduur: enkele minuten tot enkele uren per machine voor de technische implementatie zelf, maar de totale tijd die nodig is om het volledige park tijdens een routinematige patchcyclus te dekken, bedraagt doorgaans één tot twee weken, rekening houdend met apparaten die niet op het netwerk zijn aangesloten, uitgestelde herstarts en de afhandeling 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, zodra de rust is teruggekeerd, 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 uitsluitsel, hoewel achter het antwoord vaak een lange reeks statussen schuilgaat 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 de 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 de 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 verholpen, geen scan na de implementatie uitvoeren, en nooit de ‘long tail’ van mislukte implementaties onderzoeken.

Verwachte doorlooptijd: 24 tot 48 uur na de implementatie voordat de scan na de patch wordt uitgevoerd en betrouwbare gegevens oplevert.

Stap 7: Rapportage en documentatie

Verantwoordelijke: IT-operaties, 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 endpoints te verifiëren.

Hier vind je ook je verbeterpunten. Als 30% van je kritieke patches buiten het 14-daagse venster 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 (prioritering verloopt te traag) of stap vijf (de implementatie kent te veel uitzonderingen). Dankzij de documentatie is die diagnose mogelijk.

Veelvoorkomende problemen: documentatie die pas achteraf wordt opgesteld, dashboards die de implementatie weergeven zonder context, geen beoordelingscyclus, geen koppeling tussen statistieken en procesverbeteringen.

Verwachte tijdsbesteding: maandelijkse evaluatievergadering plus het continu vastleggen van statistieken. De rapportage zelf zou geautomatiseerd moeten zijn; wat tijd kost, zijn de menselijke beoordeling 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. Dezelfde zeven stappen blijven van toepassing, 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 prioritering 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 ring en wordt de implementatie op grote schaal uitgevoerd, vanuit de verwachting dat enige storingen te verkiezen zijn boven voortdurende blootstelling. De verificatie en documentatie worden aangescherpt, omdat er een auditgesprek zal plaatsvinden.

Het risico bij noodmaatregelen ligt meestal niet in het feit 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 gedocumenteerd noodpatchproces, inclusief een aangewezen besluitvormer, een vooraf goedgekeurde uitzondering op de normale wijzigingscontrole en een geteste terugdraaimogelijkheid, zorgt ervoor dat snel patchen veilig verloopt.

Wanneer het patchingproces per omgeving verschilt

Servers, endpointsen, 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 endpointsen, en dat is terecht.

Bij endpointsen 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 endpointsen 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 applicaties van derden aanwezig, elk met een eigen releasekalender, en een aanzienlijk deel van de beveiligingsinbreuken vindt zijn oorsprong in een niet-gepatchte applicatie van derden 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 applicaties van derden voor de operationele details.

Voor cloud-workloads betekent onveranderbaarheid een echte doorbraak. In een goed ontworpen cloudomgeving breng je geen patches aan op een actieve instantie; je vervangt deze door een nieuwe instantie die is opgebouwd vanuit een bijgewerkte image. Het zevenstappenproces blijft van toepassing, maar stap vijf lijkt meer op het bouwen van een image en het vervangen van een instantie dan op het installeren van software. In hybride omgevingen worden beide patronen uiteindelijk naast elkaar toegepast, en daar ligt de grootste operationele complexiteit.

Waar de processtroom het vaakst vastloopt

Er zijn een aantal patronen die steeds weer terugkomen in omgevingen waar het patchingprogramma niet naar behoren functioneert.

Ten eerste is er sprake van een onvolledige inventaris. Als stap één niet goed is uitgevoerd, wordt die tekortkoming in alle volgende stappen doorgetrokken. De hosts waarvan je het bestaan niet kent, krijgen geen patches, en juist die hosts worden vaak als eerste door aanvallers gevonden, omdat ze slecht worden onderhouden – om dezelfde reden dat ze niet in de inventaris staan.

Ten tweede is er de kloof tussen testen en implementatie. Patches worden getest, goedgekeurd en blijven vervolgens wachten op een onderhoudsvenster dat door de organisatie 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, in combinatie met minder, maar betrouwbaardere onderhoudsvensters.

Het derde punt betreft de ‘long tail’ 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 deze ‘long tail’ 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 gelukt, 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 faalwijzen is de reden waarom organisaties gemiddeld 209 dagen nodig hadden om de 17 kwetsbaarheden in edge-apparaten 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 op elke redelijke schaal werkt niet. Het aantal releases, de verscheidenheid aan platforms en de snelheid waarmee kwetsbaarheden worden uitgebuit, zijn allemaal zo groot geworden dat een team dit niet meer kan bijhouden met spreadsheets en afzonderlijke implementaties.

Goede tooling voegt de zeven stappen samen tot een samenhangende, geautomatiseerde workflow waarbij mensen alleen op de beslissingspunten worden ingeschakeld. Het in kaart brengen van assets verloopt continu. Het identificeren van patches gebeurt binnen enkele uren na de release door de leverancier. Prioritering kan beleidsgestuurd zijn, waarbij kritieke patches automatisch worden goedgekeurd voor noodimplementatieringen. Het testen vindt plaats in vooraf gedefinieerde implementatieringen zonder handmatige tussenkomst. De implementatie spoort apparaten op die niet op het netwerk zijn aangesloten en zorgt voor herstarts binnen afgesproken tijdvensters. De verificatie levert feedback aan kwetsbaarheidsscans. De rapportage wordt automatisch gegenereerd.

Dit is het werkingsmodel achter geautomatiseerd patchbeheer, dat inmiddels de standaard 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, met beleidsgestuurde implementatie, implementatieringen, ondersteuning voor apparaten buiten het netwerk en rapportage over patch-compliance, allemaal in één oplossing. 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 op orde is, maakt de juiste tool het verschil tussen een programma dat op papier goed lijkt en een programma dat de IT-omgeving daadwerkelijk op het door het bedrijf gewenste tempo van patches voorziet. De volgende stap is dan de overgang van proces naar programma: raadpleeg onze bijbehorende gids over best practices voor patchbeheer voor de principes die het verschil maken tussen een goed werkend patchprogramma en een uitstekend patchprogramma.