Geen technisch verhaal over patchmanagement-jargon. Gewoon een eerlijk antwoord op waarom dit ertoe doet, en hoe je het zo inricht dat niemand het zelf hoeft te onthouden.

[list] In het kort

• Een update lijkt vaak een kleine herstelling, maar dicht regelmatig een concreet beveiligingslek dat al bekend is bij aanvallers.
• Uitstellen voelt onschuldig, maar hoe langer een bekend lek openstaat, hoe langer je een makkelijk doelwit bent — niet in theorie, maar heel concreet.
• Een update kan iets kapotmaken, maar dat risico is te beheersen door updates eerst te testen voordat ze overal worden uitgerold.
• Software die niet meer wordt ondersteund, krijgt geen updates meer — en wordt daarmee met de dag kwetsbaarder, ook als hij "gewoon nog werkt".
• De beste opzet is niet dat iedereen zelf aan updates denkt, maar dat het automatisch en centraal wordt geregeld, met controle op wat en wanneer.

"We hebben het nog niet bijgewerkt, komt nog wel" is een zin die bijna elk bedrijf wel eens heeft gezegd. Het probleem is niet dat het menselijk is om dit uit te stellen — het probleem is wat er in die tussentijd openstaat.

[question] Waarom is dit zo belangrijk als updates soms alleen kleine foutjes lijken te herstellen?

Een deel van de updates lost inderdaad kleine, onopvallende foutjes op. Maar een ander deel — de beveiligingsupdates — dicht een concreet, specifiek beveiligingslek. Zodra zo'n lek bekend wordt, weten aanvallers precies waar ze moeten zoeken bij bedrijven die de update nog niet hebben geïnstalleerd. Het verschil tussen "we hebben het nog niet bijgewerkt" en "we zijn kwetsbaar voor een bekend, specifiek lek" is dus kleiner dan het voelt.

[key] Wat is het verschil tussen een beveiligingsupdate en een gewone feature-update?

Een feature-update voegt iets nieuws toe of verbetert iets — fijn om te hebben, maar zelden urgent. Een beveiligingsupdate dicht een specifiek gat dat kan worden misbruikt. Die twee worden vaak in dezelfde update-melding gebundeld, waardoor het lastig te zien is welk deel urgent is en welk deel kan wachten. Daarom is het verstandiger om updates centraal te laten beheren, in plaats van dat elke medewerker zelf een inschatting maakt van wat belangrijk is.

[warning] Kan ik updates niet gewoon uitstellen tot een rustiger moment?

Dat kan, maar de prijs van uitstel is niet zichtbaar totdat het te laat is. Een rustiger moment voelt logisch, maar een bekend beveiligingslek wordt niet rustiger naarmate de tijd verstrijkt — integendeel, hoe langer een lek bekend is, hoe meer geautomatiseerde aanvallen er specifiek naar zoeken. Uitstellen is geen neutrale keuze, het is een keuze om langer kwetsbaar te blijven voor iets dat al bekend en oplosbaar is.

[wrench] Verstoort een update ooit onze productie of lopende processen?

Dat kan, vooral bij systemen die nauw samenwerken met specifieke apparatuur of machines. Dat risico is precies waarom updates in een professionele opzet niet blindelings overal tegelijk worden uitgerold: ze worden eerst getest op een beperkte groep, en pas daarna breder toegepast als blijkt dat er niets stuk gaat. Voor systemen die echt niet mogen haperen — bijvoorbeeld gekoppeld aan productieapparatuur — wordt dat testmoment bewust extra zorgvuldig gedaan.

[cog] Hoe voorkom ik dat een update zelf iets kapotmaakt?

Door niet elke update meteen overal in één keer te installeren. Een gefaseerde aanpak — eerst een klein deel van je systemen, dan pas de rest — laat zien of een update ergens problemen geeft, voordat het je hele organisatie raakt. Dat is precies het soort gestructureerd beheer waar centrale IT-ondersteuning voor bedoeld is: niet elke medewerker die zelf op "later" klikt, maar een bewuste, geteste uitrol.

[warning] Wat gebeurt er als software niet meer wordt ondersteund en dus geen updates meer krijgt?

Dan blijft elk lek dat vanaf dat moment wordt ontdekt voor altijd openstaan — er komt simpelweg geen oplossing meer. Software die "gewoon nog werkt" kan daardoor alsnog een groeiend risico zijn, ook zonder dat je er iets van merkt in het dagelijks gebruik. Dit is een van de dingen die het lastigst te zien is zonder iemand die er structureel naar kijkt: functioneel werkt het nog prima, terwijl de bescherming eromheen langzaam is weggevallen.

[question] Hoe weet ik of alles bij ons wel up-to-date is?

Het eerlijke antwoord: dat weet je meestal pas zeker als iemand het systematisch nakijkt, niet door zelf rond te lopen en op schermen te kijken of er een meldingsbolletje staat. Voor een klein aantal apparaten is dat nog te overzien, maar zodra je meerdere systemen, servers en werkplekken hebt, is een centraal overzicht de enige manier om dit betrouwbaar te weten — niet een aanname dat het wel goed zal zitten.

[check] Moeten updates automatisch, of wil je daar zelf controle over houden?

Het beste van beide: automatisch waar dat veilig kan, met controle op de achtergrond voor de gevallen waar dat niet zomaar kan. Volledig automatisch zonder enige controle brengt het risico van hierboven met zich mee (een update die ergens iets kapotmaakt). Volledig handmatig, waarbij iemand het zelf moet onthouden, brengt het risico van uitstel met zich mee. De middenweg — automatisch uitrollen volgens een geteste, gefaseerde aanpak — combineert snelheid met controle.

[clock] Tot slot

Updates uitstellen voelt als een kleine, onschuldige keuze, maar in de tussentijd blijft een bekend, oplosbaar risico gewoon openstaan. De beste aanpak is niet dat iedereen er zelf aan moet denken, maar dat het centraal, getest en gefaseerd gebeurt — zodat het risico van een kapotte update én het risico van uitstel allebei klein blijven.

Weet je zeker dat alles bij jullie up-to-date is?

Plan een afspraak met Marcel

Wil je eerst weten waar jullie nu staan?

Doe de ICT Quickscan →

Vraag een Cyber Threat Assessment aan →