20 mei 2015 15:41

Patches: technisch of menselijk probleem?

[Blog] Zijn de problemen van cybercriminaliteit het gevolg van de tekortkomingen van de gebruiker? Of ligt het toch vooral aan té kwetsbare software?

IT-securityjournalist Brenno de Winter wierp onlangs in een artikel een opmerkelijk punt op: het omvangrijke probleem van cybercrime is niet vooral het gevolg van de tekortkomingen van de gebruiker, maar vooral van slechte, kwetsbare software. Menig IT-beheerder zal een paar keer met zijn ogen moeten knipperen bij het lezen van het stuk, dat verscheen in ICT Magazine van mei 2015. Jarenlang was immers het adagium: PICNIC (Problem In Chair, Not In Computer). Is dat adagium niets meer waard?

Voor wie het stuk niet heeft gelezen, is het handig om enkele argumenten te herhalen. In oktober 2011 organiseerde De Winter ‘Lektober’ waarin 700 meldingen van lekken in software werden gedaan. In maart 2015 publiceerde IBM de uitkomst van een uitgebreid eigen onderzoek: men had de producten van 2.600 leveranciers geanalyseerd en vond daarin maar liefst 9.600 lekken. In 2014 vond een onderzoeker in de apps in de Google Play Store duizenden lekken.

Deze cijfers zijn huiveringwekkend. De aanbeveling van de auteur aan ontwikkelaars om betere software te ontwikkelen is absoluut zinnig. Maar het is een illusie om te denken dat onkraakbare, 100% veilige software ooit de norm zal worden. Uiteindelijk is software het product van mensen, die nu eenmaal menselijke fouten zullen maken. Patches zullen dus altijd een realiteit blijven. Het is aan gebruikers om deze te installeren om hun systeem met de minst onveilige variant van software uit te rusten.

Over het uitvoeren van patches in zakelijke netwerken bestaat veel discussie. De theorie, die door IT security-experts wordt gepredikt, gaat ervan uit dat software niet langer veilig is als er beveiligingslekken in gevonden zijn. Daarbij komt nog dat reverse-engineering ervoor zorgt dat systemen na het uitkomen van een patch exponentieel onveiliger worden dan vóór de patch, totdat de patch is toegepast. Malwareschrijvers analyseren uitgekomen patches direct om te ontdekken welk lek de patch dicht. Razendsnel vinden zij manieren om misbruik te maken van het veiligheidslek met een exploit. Dat werkt uitstekend, omdat men in de praktijk niet zit te wachten op patches waarmee de beveiligingslekken gedicht worden.

De praktijk zijn namelijk de bedrijven, voor wie goed werkende software een noodzaak is om productie te draaien. Het concept ‘never change a running system’ is nog altijd sterk in zwang. Patches hebben een slechte reputatie. Die brengen namelijk vaak veranderingen aan in de software, die nogal eens ingrijpende gevolgen voor de werking van de software hebben. Voor veel bedrijven is de kleine kans dat juist dit beveiligingslek zal leiden tot infectie van het netwerk minder erg dan de kans dat het bedrijf een dag stil komt te liggen.[related_article id=”162330″]

Hierdoor worden patches vaak niet direct of zelfs nooit uitgevoerd. Microsoft komt deze realiteit nu onder ogen en gaat het proces van patchen radicaal wijzigen. Bij Windows 10 worden patches eerst aangeboden aan consumenten. Wanneer miljoenen consumenten een bepaalde patch hebben geïnstalleerd, kan een redelijk accurate voorspelling worden gedaan over de effecten van een patch in zakelijke omgevingen. Als er geen serieuze klachten binnenkomen, dan wordt de patch beschikbaar gesteld aan zakelijke gebruikers. Zo hoopt Microsoft een snelle uitrol van patches binnen zakelijke netwerken te stimuleren.

Er kleven echter twee grote bezwaren aan dit plan. Ten eerste wordt de periode waarin bedrijfsnetwerken exponentieel kwetsbaarder zijn verlengd, doordat malwareschrijvers nu nog vóór de beschikbaarheid van de patch voor de zakelijke netwerken aan het proces van reverse engineering kunnen beginnen. Bedrijven die wel altijd goed hebben gepatcht worden nu dus opeens benadeeld. Ten tweede zal het bedrijven niet aansporen om de patches nu wél uit te voeren. Dat patches niet binnen een maand, of misschien twee maanden worden uitgerold, kan worden toegeschreven aan angst voor problemen met de patch. Maar dat een patch een jaar lang niet wordt uitgerold, ligt aan iets anders. Het is namelijk goed mogelijk om een patch binnen een maand (of twee) te testen op een testsysteem en zo technische problemen uit te sluiten. Bovendien zou er na twee maanden, als er problemen waren met de patch, inmiddels duidelijkheid over zijn geweest. Andere bedrijven, die de patch ondertussen wel hadden uitgerold, zouden klachten hebben gehad.

Systeembeheerders die dit tweede punt bestrijden met het argument dat een succesvolle uitrol bij andere bedrijven hen nu eenmaal niet van de effectiviteit van een patch overtuigt, omdat hun bedrijfsinfrastructuur niet te vergelijken is met andere netwerken, zullen door een proeftijd waarbij de patch door consumenten is gebruikt al zeker niet overtuigd raken. De nieuwe tactiek van Microsoft zal dus geen positief effect hebben. Slechts twee zaken kunnen helpen: Allereerst moeten softwareontwikkelaars hun patches uitgebreider testen voordat ze ze wereldkundig maken, om schadelijke patches uit te bannen. Verder moeten systeembeheerders patches serieuzer nemen. Elk bedrijf dient een patchbeleid te ontwikkelen. Creëer een realistische testomgeving en test patches binnen die omgeving enkele dagen of weken. Wanneer er geen problemen met een patch zijn: rol hem uit! Als het adagium PICNIC nog wel actueel is, ben jij als netwerkbeheerder in elk geval niet het probleem in de stoel.