Patchen in een kleine omgeving

In enterprise-IT-afdelingen is het patchen van systemen een ingewikkeld proces waarbij grote aantallen testsystemen betrokken zijn die de productiesystemen weerspiegelen, zodat elke nieuwe patch die van leveranciers van besturingssystemen en software binnenkomt, kan worden getest in een reële omgeving om te zien hoe deze samenwerkt met de combinaties van hardware en software die binnen de organisatie beschikbaar zijn. In een ideale wereld zou elke afdeling beschikken over een beheerd patchproces dat onmiddellijk reageert op nieuw gepubliceerde patches, deze direct test en toepast zodra de patch als veilig en toepasselijk wordt beschouwd. Maar de wereld is geen ideale wereld en in de praktijk moeten we het stellen met beperkte middelen: fysieke, temporele en financiële.

Patches worden over het algemeen om een aantal belangrijke redenen uitgebracht: beveiliging, stabiliteit, prestaties en, af en toe, om nieuwe functies te leveren. Met uitzondering van het toevoegen van nieuwe functies, wat normaal gesproken via een ander releaseproces wordt afgehandeld, vertegenwoordigen patches een oplossing voor een bekend probleem. Dit is geen scenario van “als het niet kapot is, repareer het dan niet”, maar een scenario van “het is kapot en is nog niet volledig bezweken”, dat aandacht vereist – hoe eerder, hoe beter. Een houding van “achteroverleunen en afwachten” aannemen ten aanzien van patches is onverstandig, aangezien het bestaan van een nieuwe patch betekent dat kwaadwillende hackers een “oplossing” hebben om te analyseren, en zelfs als er voorheen geen exploit bestond, zal die er zeer binnenkort wel zijn. De release van de patch zelf kan de aanleiding vormen voor de onmiddellijke noodzaak van die patch.

Dit patch-ecosysteem schept een behoefte aan een “snel patchen”-mentaliteit. Patches mogen nooit blijven liggen; ze moeten vaak worden toegepast zodra ze zijn uitgebracht en getest. Wachten met patchen kan betekenen dat men draait met kritieke beveiligingslekken of dat systemen onnodig onbetrouwbaar worden gehouden.

Kleine IT-afdelingen beschikken zelden, zo niet nooit, over testomgevingen, of het nu gaat om servers, netwerkapparatuur of zelfs desktops. Niet ideaal, maar realistisch gezien beschikken zelfs als die omgevingen beschikbaar wél waren, weinig kleine afdelingen over de overtollige menselijke IT-middelen om die tests tijdig uit te voeren.

Dit is niet zo somber als het klinkt. Het testen dat voor de meeste patches wordt gedaan, overlapt met het testen dat al door de leverancier is gedaan. Leveranciers kunnen onmogelijk elke interactie tussen hardware en software testen die ooit met hun producten zou kunnen plaatsvinden, maar over het algemeen testen ze een breed scala aan permutaties en kijken ze naar gebieden waar interacties het meest waarschijnlijk zijn. Het is zeldzaam dat een grote leverancier zijn eigen software verlamt met slechte patches. Ja, het komt voor, en het hebben van goede back-ups en terugdraaiplannen is belangrijk, maar in de dagelijkse bedrijfsvoering is patchen een relatief veilig proces dat veel belangrijker is om voortvarend uit te voeren dan om te wachten op gelegenheden die zich wel of niet kunnen voordoen.

Zoals bij elke systeemwijziging worden patches het best toegepast in frequente, kleine doseringen. Als patches voortvarend worden toegepast, hoeven normaal gesproken slechts één of enkele patches tegelijk te worden toegepast. Voor besturingssystemen kunt u nog steeds te maken krijgen met meerdere patches tegelijk, vooral als u slechts wekelijks patcht, maar zelden hoeft u op deze manier tientallen of honderden bestanden tegelijk te patchen. Wanneer dit op deze wijze wordt gedaan, is het veel eenvoudiger om patches op nadelige gevolgen te beoordelen en om terug te draaien als een patchproces slecht verloopt.

Het slechtste scenario voor een klein bedrijf dat geen behoorlijke workflow voor het testen van patches heeft, is om met patchen te wachten. Wachten betekent dat systemen gedurende lange perioden zonder de benodigde zorg blijven en dat patches, wanneer ze uiteindelijk worden toegepast, vaak in grote, bulkmatige patchprocessen worden uitgevoerd. Het tegelijkertijd toepassen van veel patches vergroot de kans dat er iets misgaat, en wanneer dat gebeurt, kan het veel lastiger zijn om vast te stellen welke patch(es) de boosdoener is (zijn) en om een pad naar herstel te bepalen.

Uitgesteld patchen is een proces dat IT of een bedrijf weinig of geen voordeel oplevert, maar wel een aanzienlijk risico met zich meebrengt voor beveiliging, stabiliteit en prestaties. De beste werkwijze voor patchen in een kleine omgeving is om systemen ofwel zo snel mogelijk zichzelf te laten patchen, ofwel een regelmatig patchproces in te plannen, bijvoorbeeld wekelijks, op een moment waarop het bedrijf het best is voorbereid op het mislukken van een patch en het afhandelen van patchherstel. Of u nu kiest voor automatisch patchen of er simpelweg voor kiest dit regelmatig via een handmatig proces te doen, patch vaak en voortvarend voor het beste resultaat.