Hadden we het vorige week nog over onderhoud waar we met name doelen op de onderhoud van allerlei systemen om te voorkomen dat componenten de “end-of-life” status bereiken. Nu gaan we in op het onderhoud van de software en applicaties. De vraag is daarom:
Wordt er voor gezorgd dat de software altijd up-to-date is en dat de laatste patches op een veilige wijze zijn doorgevoerd?
Aan het doorvoeren van updates en patches zitten meerdere kanten, maar we belichten er twee, namelijk:
- Waarom zouden we updates en patches doorvoeren?
- Hoe kunnen we updates en patches doorvoeren?
Het waarom lijkt natuurlijk simpel. We willen ervoor zorgen dat er geen beveiligingslekken zitten in de software en applicaties die we gebruiken. Door verouderde software te gebruiken kunnen er lekken ontstaan waarmee ongeautoriseerde toegang tot onze informatie mogelijk wordt. Hoewel het antwoord simpel is, zien we nog te vaak dat updates en patches niet of veel te laat worden doorgevoerd. Enerzijds omdat we niet weten dat er een update of patch is, anderzijds omdat we het nogal lastig vinden om ze door te voeren: het werkt toch?
Daarmee belanden we bij de tweede vraag: Hoe kunnen we updates en patches doorvoeren? We richten daar natuurlijk het patchmanagement proces voor in. Daarvoor gebruiken we de formats van ITIL en klaar zijn we, toch? Nou niet helemaal. We moeten er bijvoorbeeld rekening mee houden dat het doorvoeren van updates en patches ook risico’s met zich meebrengt. Het kan zomaar zijn dat door een update het systeem niet meer werkt zoals we willen.
Het klinkt misschien wat cryptisch. Maar stel: je hebt een Iphone waarmee je uiteraard kunt bellen, je mail kunt lezen en nog wel wat meer “smart” dingen kunt doen. De batterij gaat lekker lang mee en je hoeft dus niet al te vaak op te laden. Je koppelt je Iphone aan je Itunes en ziet dat er (weer) een update is. Je besluit om maar even snel de update door te voeren zodat je weer helemaal bij bent. Halverwege de update loopt je Iphone vast en je moet het proces opnieuw herhalen (in de hoop dat het nu wel gaat lukken). Maar, ja hoor, na de tweede keer is het gelukt. Je kunt weer vrolijk bellen en mailen. Maar je constateert wel dat de batterij ineens een stuk minder lang meegaat dan je gewend bent.
Een voorbeeld dat we allemaal wel kennen, toch? Heb je geen Iphone? Dan geldt dit vast ook voor de Blackberry of Nokia. Geloof het of niet, maar een telefoon is voor vele mensen tegenwoordig toch echt een kritisch systeem, zonder telefoon weten we ons geen raad meer. Dit vergelijk kunnen we doortrekken naar de applicaties die we op ons netwerk hebben draaien. Het kan zomaar zijn dat een update of patch er voor zorgt dat het allemaal niet meer zo soepel wil werken, dat we niet meer bij de informatie kunnen en dat het proces tot stilstand komt.
Je moet er niet aan denken, toch? Dan maar liever geen update doorvoeren, maar ja, dan zitten we met het feit dat er gaten in onze software zitten waarmee we een gewild slachtoffer kunnen worden. Maar gelukkig is een een remedie. We testen updates en patches eerst in een test omgeving. We hebben niet voor niets de teststraat, toch?
Ook hiervoor geldt weer dat we keuzes zullen moeten maken. Is de patch zo kritisch dat we niet eerst uitgebreid kunnen testen (en er maar het beste van moeten hopen) of kan de update best een dagje wachten en kunnen we eerst een goede test uitvoeren? Dat is de vraag die we situationeel zullen moeten beantwoorden. Zaken om rekening mee te houden bij het opzetten van het patchmanagement proces.