Over het algemeen wordt het installeren van software updates of patches beschouwd als een goede manier om een systeem veilig te houden. Uit onderzoek, gepresenteerd tijdens DIMVA 2011, bleek dat bij de besmette computers er geen significant verschil was of die computers wel of niet over recente patches of antivirus-software beschikte. Het is hoog tijd om eens na te denken of het klakkeloos installeren van updates eigenlijk wel verstandig is.
Het idee dat het installeren van software updates goed is voor beveiliging wordt versterkt door regelgeving (Compliancy rules), die vaak vereist dat security updates binnen een redelijke termijn geïnstalleerd worden. Verder wordt het idee versterkt door security experts die roepen dat dit nodig is. Helaas is dit 'papegaaigedrag' waarbij zij niet al te veel beroep doen op hun verstand. En als je om ondersteuning vraagt omdat je problemen hebt met hun software, is de eerste vraag van de leverancier vaak of je wel alle patches geïnstalleerd hebt. Als dat niet zo is, dan moet je eerst alle patches installeren en kijken of dan het probleem verholpen is. Zo niet, dan mag je nog een keer bellen.
Maar als we nu eens wel ons verstand gebruiken of gewoon eens wat feitenonderzoek doen, zouden we dan aanwijzingen vinden dat het klakkeloos installeren van patches bijdraagt tot de veiligheid van systemen?
Er is altijd eerst een kwetsbaarheid en daarna, vaak vele maanden later, stelt de leverancier een patch beschikbaar. Het feit dat de details van de kwetsbaarheid al die tijd geheim gehouden zijn, betekent niet dat helemaal niemand die kwetsbaarheid heeft gebruikt of misbruikt. De kwetsbaarheid was al aanwezig sinds de installatie van het product en er is geen enkele reden om te veronderstellen dat deze al die tijd door niemand is misbruikt. In de periode tussen het beschikbaar komen en de installatie van de patch is er een periode dat het systeem extra kwetsbaar is.
Catastrofe
Soms werkt software niet meer na het uitvoeren van een patch. Hierdoor lopen updates zelfs uit op een catastrofe. Herinnert u zich nog hoe een update van McAfee Anti Virus in 2010 werelwijd miljoenen pc's onbruikbaar maakte? Als gevolg hiervan moesten zelfs patiënten van intensive care afdelingen geevacueerd worden omdat kritieke levensfuncties niet meer gemonitord konden worden. En dan zijn er mensen die dit veilig noemen. Even googlen levert nog veel meer van zulke voorbeelden.
In tegenstelling tot bovenstaande komt het ook voor dat de garantie vervalt als de software of de configuratie van een installatie is aangepast na oplevering. In mijn persoonlijke ervaring is dit voorgekomen in Scada-omgevingen en bij telefonie-oplossingen. Mede als gevolg hiervan is de laatste Windows 3.51 server onder mijn beheer uitgefaseerd in 2006. De dienst die dit systeem leverde was niet op een andere manier beschikbaar.
Onder ideale omstandigheden is het patchen van servers in een vloek en een zucht gedaan. Inloggen, patch installeren en klaar. Maar de omstandigheden zijn niet altijd ideaal en dan kan het heel veel werk zijn. Als de dienst die de server biedt niet onderbroken mag worden, wordt de patch geïnstalleerd bij nacht en ontij. En omdat we niet graag werken bij nacht en ontij, sparen we de patches op en installeren we ze allemaal in één keer. En als dan onverhoopt de patch ge-deïnstalleerd moet worden, dan kan het nog echt spannend worden, want na het deïnstalleren heb je niet altijd een werkend systeem. Misschien is het ook niet zo verwonderlijk als je je realiseert dat de patch is geleverd door dezelfde leverancier die oorspronkelijk ondeugdelijke software had geleverd. Waarom zou de patch dan foutloos zijn en zonder problemen geïnstalleerd of gedeïnstalleerd kunnen worden?
En het wordt nog erger. Vaak repareert een update niet alleen een onvolkomenheid in bestaande functionaliteit, maar bevat de update ook nieuwe functionaliteit. Iets waar je zelden om gevraagd hebt. Zelfs als die functionaliteit wel gewenst is, dan leidt het patchen geregeld tot onaanvaardbare onbeschikbaarheid van het systeem. Het communicatiesysteem voor hulpdiensten C2000 ligt elke paar weken korte of langere tijd plat voor updates. Soms is het systeem anderhalf uur lang niet beschikbaar, terwijl het 24×7 beschikbaar hoort te zijn.
Bij het klakkeloos en routinematig installeren van updates, herstel je zelfs onvolkomenheden waarvan je niet eens wist dat die bestonden of repareert de update een kwetsbaarheid in een component die je toch niet gebruikt. Dit zijn twee voorbeelden waar een update geinstalleerd wordt zonder dat daar enige noodzaak voor was, maar met gebruik van andere woorden.
Het niet uitvoeren van patches kan ook veel geld schelen. Toen ik goedkope inktpatronen kocht was het resultaat teleurstellend. Ik stapte weer over op de dure patronen van de printer leverancier. Toen de verkoper mij had uitgelegd dat die printer leverancier zijn printer drivers van updates voorzag om de niet originele patronen te herkennen, heb ik een paar maanden geen updates van de printer driver geaccepteerd. De goedkope inktpatronen worden echter ook aangepast en na een paar maanden had ik goedkope inktpatronen die wel goede resultaten gaven. En omdat ik mijn printerdrivers sindsdien niet meer update, werken die goedkope patronen nog steeds.
Automatisch is kwetsbaar
Het automatische updaten van systemen is eenvoudig aan te vallen. De updates worden zelden via veilige protocollen (https) opgehaald en daardoor is het voor de hacker relatief eenvoudig om zijn eigen software te injecteren als een slachtoffer een update download en vervolgens installeert. Er is zelfs software beschikbaar die dit kan, dus de aanval ligt nu ook binnen het bereik van script kiddies.
De feiten spreken voor zich. Er zitten wat haken en ogen aan het automatisch downloaden en installeren van updates. Daarom moeten we wat vaker nadenken of een update überhaupt geïnstalleerd moet worden. Daarbij helpt het als je weet wat het niveau van operational security is van het te patchen systeem (Attack Surface Security Metric of rav, zie OSSTMM 3). Daarbij wordt niet alleen gekeken of bepaalde software missschien over een bekende kwetsbaarheid beschikt, maar worden alle getroffen beveiligingsmaatregelen in ogenschouw genomen. Er zal blijken dat een patch lang niet altijd nodig is, omdat andere beveiligingsmaatregelen verhinderen dat de kwetsbaarheid benut kan worden. En als beheerders hier goed over nadenken en weloverwogen hebben besloten een update niet uit te voeren, dan zou het auditors sieren als zij meegaan in deze gedachte en niet star vasthouden aan vuistregels en zogenaamde best practices.
Wanneer wel installeren
Natuurlijk komt het ook voor dat een patch werkelijk de beste oplossing is in een bepaalde situatie. In die situatie kan er weloverwogen toe worden besloten om de patch wel te installeren. Dan doen we dat door eerst de update te downloaden (via https) en de integriteit van de update te verifiëren, waarna de update via het vulnerability management proces geïnstalleerd kan worden.
Daarbij helpt het om te weten of een systeem over een kwetsbaarheid beschikt. Vulnerability scanners hebben hier zeker een toegevoegde waarde. Zelfs als blijkt dat een systeem over een kwetsbaarheid beschikt en er nog geen patch beschikbaar is, kunnen andere maatregelen overwogen worden om de kans op succesvolle uitbuiting te verminderen.
Of het wel noodzakelijk of verstandig is om een beschikbare patch te installeren of niet, is voor ieder bedrijf een individuele afweging. En om te bepalen of het wel of niet verstandig is, kunnen we niet klakkeloos en zonder hierover na te denken zomaar alle beschikbare updates installeren. Nee, om dat te bepalen moeten we ons verstand gebruiken. Au!
Bottom line: veel vaker zou besloten moeten worden om patches niet uit te voeren. Het is veel beter om systemen op andere manieren te beschermen. Pas als het patchen de beste oplossing is, dan kies je ervoor!
Cor Rosielle, cto Outpost24
Wanneer ik het artikel lees krijg ik (wellicht ten onrechte) de indruk dat men de de neiging heeft rechtstreeks te patchen in een productie / life omgeving. Dit is in mijn ogen niet verstandig.
In de sectoren waar ik gewerkt heb (met als kenmerk hoge beschikbaarheid / hoge betrouwbaarheid) was er altijd een uitgebreid testtraject alvorens patches in productie werden geïnstalleerd. Eerst wordt, zoals ook in het artikel gesuggereerd wordt, gekeken of de betreffende vulnerabilities überhaupt van toepassing kunnen zijn. Nadat een selectie is gemaakt van de benodigde patches worden deze eerst op een testsysteem geïnstalleerd, en pas na een uitvoerige regressietest wordt besloten of de patches wel of niet uitgerold kunnen worden in “het veld”.
Dit kost weliswaar tijd (en dus geld) maar het belang van de beschik- en betrouwbaarheid van de systemen weegt hier nog steeds tegenop. En als je systemen goed geprogrammeerd en ingericht zijn, dan valt het aantal patches wat je echt nodig hebt reuze mee, zo blijkt.
Patching via een OTAP-straat is natuurlijk de aanbeveling en nooit rechtstreeks te patchen. En natuurlijk zijn je systemen en netwerken conform baselines en het least-privilege-principe (LPP) ingericht. Blijft toch nog de AV-patches. Die moet je patchen maar daar heb je weinig invloed op en AV-software draait met veel privileges. What-to-do….iedereen naar Linux en Apple?
Interessant artikel. Het valt me op dat er geen onderscheid wordt gemaakt tussen patches (of zijn het updates?) van een besturingssysteem, applicaties die op dat os geïnstalleerd zijn, applicaties die onderdeel uitmaken van dat os, drivers voor dat os (software voor hardware aansturing) en firmware (software op de hardware).
Verder is het natuurlijk een kwestie van economics, er zijn tal van organisaties die moeten kiezen tussen volledig geautomatiseerd patchen (waar mogelijk) of ad-hoc patchen (lees: niet of te laat patchen) omdat er nu eenmaal geen budget is om alle systemen en patches te controleren. Dan is vaak de keuze snel gemaakt (op hoop van zegen maar met enigszins een veilig gevoel…)
Want wat heb je aan beschik- en betrouwbare systemen als al je ten onder gaat aan het onderhoud ervan?
Schijn veiligheid is nog steeds een belangrijke drijfveer voor dit soort praktijken. Wie wordt er nou boos wanneer door een uitgebreide security check op Schiphol je vliegtuig later vertrekt en je je afspraak mist? Wat heb je liever wordt dan gezegd? Maar goed, ik dwaal af. Nogmaals, een interessant artikel. Ik ga nu mijn koffiezetapparaat patchen…
@RvE: Misschien verwacht je deze reactie niet van een security consultant, maar waarom zou je AV draaien op een server? Daar is zelden noodzaak toe (als eindgebruikers software kunnen starten op de server, zoals bij Citrix of terminal servers, dan valt er wat voor te zeggen). En als je geen AV draait, hoeft je het ook niet te updaten en loop je niet de risico’s die met updates gemoeid gaan. Er is wel een verhoogd risico omdat je kwetsbaarder bent voor malware (niet alleen virussen). Je gebruikers zullen je dankbaar zijn als je AV van de servers verwijdert. Het wordt soms lastiger om aan je auditor uit te leggen waarom er geen AV draait.
Voor AV geldt eigenlijk hetzelfde als voor het uitvoeren van patches: gebruik het als het de beste oplossing is.
@Gunk: Veel producten worden verkocht door het zaaien van angst. Deze producten dragen weinig of niets bij aan de veiligheid van systemen. De schijnveiligheid op Schiphol is ook het gevolg van angst zaaien. Blijkbaar vindt de gemiddelde mens het acceptabel om lang in de rij te staan en zich te onderwerpen aan allerlei inspecties gebaseerd op veel technologie, hoewel bij herhaling is aangetoond dat dit onvoldoende werkt. Voor bestuurders en politici is dit ook wel fijn, want die besteden veel geld aan allerlei uiterlijk vertoon van beveiliging. Als het dan mis gaat, dan kunnen zij in ieder geval zeggen dat zij zoveel gedaan hebben om de veiligheid te garanderen, maar dat er ook grenzen zijn aan de bescherming die zij kunnen bieden. Ik weet wel wat ik liever heb: dat al dat geld en arbeid wordt gestoken in betere beveiliging en niet in dure high tech oplossingen waarvan de resultaten dubieus zijn (ik heb mij laten vertellen dat er op de zwaarst bewaakte luchthaven ter wereld (luchthaven Ben-Gurion in TelAviv, Israel) geen body scanners nodig zijn).
Goed artikel. Niet updaten om het updaten zelf.
Het is niet altijd zinvol om de laatste OS- en applicaties updates, firmware en drivers te installeren. Automatische updates zorgen ook voor risico’s, zoals storingen en tragere systemen, en die moeten tegen andere risico’s afgezet worden. Ook ik heb heel veel slechte updates en patches gezien. Security updates moet je natuurlijk wel altijd overwegen, en ze eerst testen voor zover dat mogelijk is. Testen kost extra doorlooptijd, maar de security updates lopen sowieso achter de werkelijkheid aan; soms jaren.
Bij andere patches moet er wel een probleem of tekortkoming zijn die opgelost kan en moet worden.
Helaas stellen de meeste ict-servicebedrijven de eis dat de laatste updates altijd geïnstalleerd moeten zijn wanneer je recht op hulp wilt behouden. Als klant moet je dus een bonus-malus regeling afspreken. Dan zijn deze ‘dienstverleners’ wel wat voorzichtiger met updaten.
Ik zie vaak systemen die al jaren niet meer vernieuwd kunnen worden en nog langer goed draaien.
@Cor, een AV applicatie op een fileserver kan wel handig zijn (en dan van een ander merk dan die op de client).
Precies PaVaKe: Eerst uitgebreid een patch testen, alvorens een “live omgeving” te updaten.
Ik heb zelden zo een slecht artikel in de Computable gelezen. Het enige dat ik de Computable tegoed kan houden is het feit, dat het onder de rubriek ‘Opinie’ is geplaatst en daarmee de mening van de auteur weergeeft.
Ik ben het namelijk wel eens met de eerste zin, dat het installeren van software patches “over het algemeen” een goede manier is om een systeem veilig te houden. Als ik dan bijvoorbeeld vandaag weer lees, dat er privé gegevens van duizenden studenten op straat zijn beland omdat een SQL-lek niet gepatcht was, dan denk ik: ja, dit had gewoon voorkomen kunnen worden.
Wat mij irriteert aan het artikel is het ontbreken van elke nuance dan ook. Natuurlijk moet een beheerder nadenken of de patch wel van toepassing is voor het systeem waarvoor hij verantwoordelijk is. Natuurlijk moet de patch eerst op een testsysteem geïnstalleerd worden en moet er een fall-back scenario zijn in het geval, dat de patch tot problemen met andere applicaties leidt.
Het klakkeloos installeren van patches leidt zeker niet tot een hogere mate van beveiliging van een systeem, je moet je verstand immers blijven gebruiken. Maar het, zoals in het artikel wordt beschreven, negeren van patches omdat dit de mogelijkheid biedt om goedkopere toners te gebruiken, is een typisch geval van gebrek aan inzicht in het verschil tussen privé en zakelijke context.
De boodschap van het artikel is goedbedoeld, de inhoud daarentegen verveelt zijn doel volledig.