Blog
Dom Patchen: Waarom haast je systeem kan breken!
En hoe jij dat eenvoudig kan voorkomen
Vorige week hebben we allemaal kunnen meemaken wat een schade een te snel aangebrachte patch kan veroorzaken. Ik hoop dat je het alleen van afstand hebt mogen meemaken, maar best veel van jullie zijn daadwerkelijk de klos geweest. CrowdStrike heeft een brakke patch uitgerold en veel klanten van CrowdStrike hebben die kennelijk ongezien geïnstalleerd. Ik kan me namelijk niet voorstellen dat die patch door een rigoureus testprogramma gekomen zou zijn.
De gevolgen op korte termijn
Een bijna complete verstoring van het luchtvaartverkeer, ziekenhuizen die hun werk niet meer kunnen uitvoeren, banken die geen betalingen meer voor hun klanten kunnen uitvoeren, retail ketens die hun personeel niet meer in kunnen plannen, grote en kleine bedrijven die urenlang of zelfs dagen de duren moeten sluiten. Voor veel slachtoffers een geluk bij een ongeluk dat het vlak voor een weekend gebeurde, dan hebben ze het weekend om puin te ruimen. Voor luchthavens, ziekenhuizen en banken is er nog een dagenlange nasleep, ook al is het probleem wat minder groot dan op de dag dat voor hen de wereld stilviel. Er zijn nog steeds passagiers gestrand ..
De gevolgen op lange termijn
Ik heb geen kristallen bol, maar die heb ik niet nodig om te weten dat deze muis nog een lange juridische staart gaat krijgen. CrowdStrike zal als de aandacht hiervan af is zijn naam wel veranderen. Het is ook wel iets om over na te denken als je op het punt staat om een Microsoft vendor lock-in te kopen door met je hele hebben en houwen naar Azure te gaan met een contract voor 3 jaar of langer.
Er zijn best veel slechte patches
Als we alleen al naar “Patch Tuesday” van Microsoft kijken dan moet er vaak een patch teruggetrokken worden omdat die niet goed is. Het is niet elke maand raak, maar veel te vaak naar mijn mening. En niet alleen mijn mening telt … Soms treft het alleen een bepaalde groep gebruikers, soms zijn álle Windows klanten de klos. En het gaat best vaak om 'blauwe schermen', ofwel een PC die volledig onbruikbaar wordt. En als je PC niet meer bruikbaar is dan moet je eerste weten welke patch nou de rotte appel is en dan een lange weg volgen om hem er weer af te halen.
In dat licht is het best een slechte zet van Microsoft geweest om de meeste Windows gebruikers te dwingen om patches te installeren. Op Windows 10 en Windows 11 worden patches geïnstalleerd zonder dat de gebruiker of de eigenaar van de computer daar toestemming voor geeft. Er worden best vaak rotte patches op jouw Windows machines geïnstalleerd die je niet tegen kan houden, ook niet als je al weet dat die patch niet ok is en je PC en jou in de problemen gaat brengen.
En dat is alleen nog maar Microsoft. Er zijn ook veel andere software leveranciers die zonder toestemming updates installeren. Google doet dat met Chrome bijvoorbeeld, en wie heeft er nu geen Chrome op zijn PC, al is het maar als tweede browser. Global Stats StatCounter schrijft aan Chrome een marktaandeel van bijna 66% toe ...
Als het niet stuk is, moet je het ook niet repareren
Ik heb een Logitech muis en toetsenbord. Regelmatig krijg ik van Logitech de melding dat er een ‘kritische’ update voor mijn drivers is. Als ik dan kijk wat de patch doet dan is dat bijna altijd het ondersteunen van nieuwe hardware. Hardware die ik helemaal niet heb. Aangezien de bestaande driver vlekkeloos werkt op de hardware die ik wel heb is die update voor mij overbodig. Het is zelfs een significant risico. De bestaande driver werkt probleemloos en de nieuwe kan een bug bevatten. Aangezien het een driver is, potentieel een bug die de hele machine onbruikbaar maakt.
Ja dat mag je best ‘kritisch denken’ vinden. Dat is het ook. Dat zouden meer mensen moeten doen vind ik. Ook bij andere software moet je je afvragen of je wel de allernieuwste update nodig hebt. Want wat hebben ze echt aangepast in de nieuwe release? En is een mooier knopje het risico waard dat je PDF reader het niet meer doet? Of je email programma?
Veel leveranciers roepen tegenwoordig dat je alle patches zo snel mogelijk moet installeren. En daar ben ik het absoluut niet mee eens. Voor kritische security patches is het natuurlijk noodzakelijk dat ze met gezwinde spoed aangebracht worden, mits getest als je daar de mogelijkheid voor hebt. En overige security patches moet je ook niet aan je voorbij laten gaan. Maar alle andere patches moet je kritisch bekijken of je ze wel nodig hebt. En als ze een probleem oplossen dat je sowieso niet hebt of functionaliteit toevoegen die je niet gaat gebruiken dan zou ik heel terughoudend zijn met installeren.
Test je patches
Zakelijke gebruikers hebben meestal veel meer mogelijkheden om patches niet aan zich op te laten dringen. Ze kunnen met bepaalde instellingen afdwingen dat patches niet gedwongen geïnstalleerd worden. En software gebruiken die patches pas automatisch installeert als deze getest en goedgekeurd zijn door de IT afdeling. Want software bevat soms – en vaker dan we weten - bugs en met goed testen vind je die uiteraard.
Dat je nooit 100% moet vertrouwen op de testen van je leverancier heeft CrowdStrike wel laten zien. En Microsoft bevestigt dat ook een paar keer per jaar. Dat los je alleen op door zelf te testen.
"Maar Hugo, wat als er een groot security lek is, waar hackers al misbruik van maken?" hoor ik je vragen. Voor die situatie heb je een versnelde testprocedure nodig, die alleen de patch voor dat specifieke lek uitgebreid onder de loep neemt. Zulke patches worden door leveranciers meestal in grote haast gemaakt (vanzelfsprekend, want het lek moet NU gedicht), met een verkorte testprocedure, en dat geeft een grotere kans op fouten dan een gewone patch. Als zo'n patch je systemen omver trekt dan ben je verder van huis dan als een kwetsbaarheid een paar uur langer openstaat. Je kunt zo'n kwetsbaarheid bovendien vaak tijdelijk vermijden door je firewall aan te passen of software componenten uit te zetten. Er zijn zoveel manieren om risico’s te vermijden.
Voor kleine bedrijven en consumenten is dit helaas geen oplossing. Waar mogelijk is het wel verstandig om de installatie van patches iets uit te stellen. Dan heb je een grotere kans dat iemand anders over de bug struikelt en de patch teruggetrokken wordt voor die op jouw PC geïnstalleerd wordt. Automatische updates lijken handig maar zijn potentiële probleemmakers.
Het probleem zit niet altijd in een systeem dat je patcht
Verschillende systemen praten met elkaar. Als één daarvan gepatcht wordt en de ander niet, dan kun je bijvoorbeeld de connectiviteit verliezen. Zo ondersteunen nieuwere SSL-libraries verouderde protocollen niet meer, uit security overwegingen. En als je dan nog wat legacy-machines of legacy-software hebt (en wie heeft er geen legacy) dan praat je gepatchte machine niet meer met je legacy. Heel veilig natuurlijk, alleen werkt het ineens niet meer. Wel veilig, absoluut onwenselijk.
Zo zijn er nog heel veel voorbeelden. De moraal van het verhaal is dat je afhankelijkheden hebt in je applicatie landschap en dat je die moet meenemen als je patches test. Zeker als je centrale componenten zoals je active directory server gaat patchen.
Het échte probleem blijft vaak onzichtbaar
Niet alle fouten trekken je systeem direct omver. Een minder in het oog springend probleem is dat een patch je systeem structureel langzamer maakt. Dat zien we bij de klanten van Sciante met regelmaat. Dat hebben we bijvoorbeeld gezien bij de upgrade van SQL Server 2012 naar 2014. En bij de BIOS patches voor Spectre en Meltdown. Dat lijkt niet zo'n groot issue, maar hoeveel werktijd verlies je hiermee? Het gaat soms om tientallen procenten dat een systeem langzamer wordt. Je wilt op zijn minst inzichtelijk hebben dat het gebeurt en hoe groot de gevolgen zijn.
Gevolgen zijn het vertragen van je medewerkers, maar denk ook aan oplopende cloud kosten als het systeem minder efficiënt is. Precies wat je niet wil en steeds meer bedrijven en organisaties weten de weg naar ons te vinden om voor eens en altijd van deze problematiek af te zijn, want het is gelukkig grotendeels te voorkomen.
Hoe blijf ik ‘in control’?
Een belangrijke stap is goed monitoren. Ook in je test- of acceptatie-omgeving waar je patches test. En de monitoring in de gaten hebben. Als je zelden op je snelheidsmeter kijkt kun je ook verrast worden met een bekeuring. Met goede monitoring ken je de situatie voor en na de patch. En kun je die vergelijken om te zien wat de invloed van de patch op je prestaties is.
Hulp nodig? Maak een afspraak voor een zoom call van 15 minuten (of wat langer) met mij en je weet hoe je problemen voor kunt zijn. Laat je niet verrassen door verstoringen en maak vandaag nog een afspraak!