Auto-updates worden gezien als goed voor de beveiliging, maar dat is niet altijd waar. Dit is de discussiestelling die Computable-lezers vandaag krijgen voorgelegd.
Het automatisch installeren van updates helpt om bekende, openstaande gaten vlot te dichten (of op z’n minst af te dekken). Lang geleden heeft Google’s browser Chrome het voortouw genomen met auto-updates, waarna browsers en andere applicaties en zelfs complete besturingssystemen zijn gevolgd. Niet alleen Google’s browserbesturingssysteem Chrome OS, maar ook Windows 10 volgt de beveiligingsaanpak van auto-updates.
Maar soms zorgt dit ook voor problemen. Zo blijkt de overgang naar het veiligere encryptieprotocol TLS 1.3 niet zonder kleurscheuren te verlopen. De lang geleden al aangekondigde overstap, waarbij de onveilige voorganger in de ban gaat, blijkt sommigen toch te verrassen. Zoals enterprisesoftwareleverancier SAP en securitybedrijf Symantec. De Blue Coat-software van laatstgenoemde struikelt over TLS 1.3, wat inloggen door Chromebooks en Windows-pc’s heeft geblokkeerd. In reactie heeft Google de automatische uitrol van TLS 1.3 gepauzeerd. Auto-updates helpen security dus niet altijd. Wat vind jij?
Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren
Reacties
In het algemeen lijkt het een prima uitgangspunt, maar voor de wat kritischere productiesystemen & applicaties waar stabiliteit en beschikbaarheid een vereiste is, lijkt auto-update me uit den boze. Net zo goed dat je voor zelf gemaakte software alleen geteste, inclusief integratietests etc., updates uitrolt moet je natuurlijk ook uitrol van andere software gecontroleerd doen. Eerst in een testomgeving kijken of alles nog werkt, dan in productie.
Software testen lost ook niet alles op, zeker niet als het niet de primaire functie is die, op een negatieve manier, aangepast is.
Nog niet zo heel lang geleden had ik te maken met een poging bankgegevens te onderscheppen. Dit was gelukkig ook duidelijk zichtbaar. Mijn bank was die ochtend ook al door anderen gebeld en was van het probleem op de hoogte en had dit ook al herleid naar een auto-update van bepaalde netwerkmonitoring-software waar ik ook gebruik van maakte. Mij werd ook direct advies gegeven over welke stappen ik moest ondernemen om het probleem te verhelpen. Topservice wat dat betreft.
Men had ook al met de betreffende (gerenommeerde) softwareleverancier gesproken en e.e.a. was ook al terug herleid naar een medewerker die hun organisatie recent had verlaten.
Ik vermoed dat we deze vorm van in-house hacking alleen maar meer zullen gaan zien en een behoorlijke uitdaging gaat vormen in testtrajecten.
Het voorbeeld dat wordt gegeven heeft meer te maken dat leveranciers niet op dezelfde tijd dezelfde software patches uitrollen. Hierdoor ontstaat het niet meer functioneren van essentiële functies, zeker bij TLS. Heb zelf ondervonden dat bijvoorbeeld SAAS leveranciers zeer langzaam essentiele beveilingspatches niet doorvoeren, waardoor de service niet meer kan worden benut.
Auto-update is een prima mechanisme, zolang als je een update maar eenvoudig kan terugdraaien of van te voeren wordt gewaarschuwd over de impact. Testen volgens OTAP principes kan in deze tijd ernstige problemen veroorzaken door de opgelopen vertraging met dit soort procedures.
Leveranciers zouden overigens ook wel onderscheid kunnen maken tussen zeer essentiële kleine patches en de major patches die impact hebben in een keten.