Patch-management is kwestie van prioriteren

Patches zijn ontzettend belangrijk voor de beveiliging van systemen. Toch blijkt dat patches vaak te lang blijven liggen voordat deze daadwerkelijk kunnen worden toegepast. Binnen welke tijd zouden organisaties de patches moeten uitvoeren volgens Computable experts? De experts leggen uit waar het vaak fout gaat en geven tips om valkuilen te voorkomen.

Volgens Government Crypto Specialist bij Compumatica secure networks, Ad Koolen, is het moeilijk te zeggen binnen welke tijd een patch moet worden geïnstalleerd. Dit is volgens hem namelijk afhankelijk van een aantal factoren. Zo is er een verschil tussen de typen patches die worden uitgebracht, vult Albert Kramer, Technical Manager Continental Europe bij Trend Micro, aan. ‘Een patch om bijvoorbeeld de stabiliteit van een applicatie of besturingssysteem te verbeteren of nieuwe features toe te voegen en patches om de bescherming tegen kwetsbaarheden naar een hoger niveau te tillen.’ Deze twee typen patches moeten dan ook verschillend van elkaar behandeld worden. Volgens Roy Samson, principal consultant bij Capgemini, moeten de zogenaamde functionele patches worden geïnstalleerd, wanneer nodig en na uitvoerig testen, maar moeten de security patches juist zo snel mogelijk worden toegepast.

Rob van der Veer, principal consultant bij Software Improvement Group, noemt patchen een kwestie van prioriteren. ‘De tijd waarbinnen een patch het beste wordt geïnstalleerd is ten eerste niet voordat belangrijkere patches worden geïnstalleerd en ten tweede niet voordat de afhankelijke it eerst wordt getest met de nieuwe patch.’ Volgens Kramer is het vanzelfsprekend dat security patches een hogere prioriteit moeten hebben. ‘Het gat tussen het vinden van de kwetsbaarheid en de patch moet zo kort mogelijk zijn. Vaak zijn hackers en malware-schrijvers namelijk in staat om binnen een paar uur de eerste vulnerabilities al te misbruiken door middel van kwaadaardige code of tooling.’ Ook Eddy Willems, Global Security Evangelist bij G Data, wijst erop dat wanneer een patch beschikbaar komt, malware-schrijvers hiermee worden geattendeerd op een zwak punt in het systeem. ‘Met behulp van reverse engineering kunnen zij zo een exploit maken die deze nieuwe zwakke plek kan uitbuiten. Hoe langer een patch niet wordt geïnstalleerd, des te meer kans heeft de malwareschrijver om het netwerk te infecteren.’

De prioriteit kan volgens Vincent van Kooten, regional manager Benelux bij FireEye, worden bepaald door twee vragen te stellen. ‘Ten eerste: Hoe kritiek is deze vulnerability? En ten tweede: Welke systemen in het bedrijf zijn hierdoor vulnerable?’ Daarnaast is het volgens Koolen van Compumatica ook belangrijk om na te gaan hoe betrouwbaar de softwareleverancier is die de patch vrijgaf. ‘Bij AVG is het bijvoorbeeld gebeurd dat een patch voor hun antivirus software een Windows.DLL voor een virus aanzag en deze uitschakelde waardoor de gepatchte pc’s niet meer konden opstarten.’ De risicobepaling kan je laten uitvoeren door vulnerability scanning tools, waarmee elke kwetsbaarheid een score krijgen op basis van CVSS, adviseert Erik Remmelzwaal, algemeen directeur bij DearBytes. ‘Tegenwoordig zijn dit soort tools eigenlijk onmisbaar om controle over dit probleem te krijgen.’ Dit is allemaal onderdeel van change management, waarbij wordt vastgesteld wat de impact en mogelijke risico’s zijn van een bepaalde patch of update.

Testen

Over het algemeen kan je volgens Koolen stellen dat een patch, afhankelijk waarvoor hij geschreven is, zo snel mogelijk moet worden ingevoerd. Maar toch is het niet altijd verstandig om een patch klakkeloos over te nemen, zonder deze getest te hebben in een testomgeving, meent Peter Westerveld, directeur en security consultant bij Sincerus consultancy. Van Kooten legt uit dat de productie omgeving van de organisatie in de test omgeving moet worden gesimuleerd, om de impact van de patch goed te kunnen bepalen. Willems vindt het dan ook begrijpelijk dat it-afdelingen het netwerk niet willen beschadigen met patches die compatibiliteitsproblemen geven met de aanwezige hard- en software, maar tegelijkertijd hoeft het testen volgens hem in een goed opgezette testomgeving absoluut geen weken te duren. Uiteindelijk moet het uitrollen van een patch volgens de experts zeker binnen een week tijd plaatsvinden.

Vertraging bij patch-management

Ondanks dat het testen in principe niet heel lang hoeft te duren, is dit toch één van de oorzaken van vertraging bij patch-management, weet Westerveld. Zo is één van de belangrijkste drempels om een patch of update niet meteen uit te voeren volgens Koolen dat sommige organisaties geen testomgeving voorhanden hebben. Een vaak gehoord probleem is volgens Martijn van Lom, general manager Kaspersky, dan ook dat bedrijven in het verleden problemen hebben ondervonden bij het patchen van een kritieke applicatie. ‘Met als resultaat dat ze huiverig zijn om patches snel uit te rollen en de patches vooraf uitvoerig willen testen.’ Koolen: ‘Men is dus minder angstig voor het risico van een securitybreach dan voor het uitvallen van systemen door verkeerde patches of updates.’

Daarnaast hebben organisaties niet altijd de juiste middelen beschikbaar om te zien welke patches er beschikbaar zijn, zegt Kramer. ‘Men ziet bijvoorbeeld wel dat er een patch voor Windows beschikbaar is, maar niet er ook patches uitgekomen zijn voor Adobe of andere applicaties.’ Willems bevestigt dit: ‘Veel (kleinere) bedrijven leggen zich bij het patchen uitsluitend toe op de patches van Microsoft. Dan vergeet men eenvoudigweg de patches van alle andere software, waaronder de kwetsbare Java en Adobe Flash.’ Ook zitten er vaak compatibiliteitsredenen achter om patches niet uit te voeren, vervolgt hij. ‘Op bepaalde machines of servers draait dan specifieke software of er zijn machines specifiek voor het aansturen van bepaalde hardware en die werken niet altijd met de laatste versies van het besturingssysteem en software.’

Overigens gebeurt het volgens Willems ook zeer regelmatig dat bepaalde servers of toestellen in de patch cycle vergeten worden. Bijvoorbeeld omdat ze ergens in een serverkast staan, uit het zicht, legt hij uit. ‘Ook gebeurt het dat er op apparaten van medewerkers handige programma’s staan, die de werknemers zelf hebben geïnstalleerd omdat zij hen helpen bij hun werkzaamheden, maar waar de it-afdeling geen goed overzicht van heeft, waardoor patches van die software gewoon gemist worden.’

Verder is er volgens Van Kooten vaak sprake van te weinig mensen die teveel werk moeten verrichten; het feit dat er meer aandacht vanuit het management is voor compliance dan voor it-security;  het feit dat patching nog steeds niet als belangrijk wordt ervaren, de zogenaamde ‘het komt wel’-mentaliteit.

Maar de belangrijkste reden is het ontbreken van een deugdelijk patch management beleid en proces, meent security consultant Rick Den Breejen van Crypsys secure computing. Westerveld is het met hem eens. ‘In de meeste gevallen wordt onterecht door ict-management aangenomen  dat beheerders dit ‘er wel even bij doen’. Maar in de praktijk sneeuwen dit soort handelingen altijd onder door werkdruk, productie verstorende incidenten en andere beheersactiviteiten.’ Ook Raoul Vernede, security manager bij Wageningen UR, wijst erop dat patchen voor beheerders niet het leukste werk is. ‘Het aantal patches is best groot en dat is dus een hele klus om deze tijdig uit te rollen. Het is ook nooit klaar en regelmatig zorgen updates of patches voor nieuwe problemen, omdat ze niet goed genoeg getest zijn door de leverancier. Het is voor een beheerder makkelijker om niks te veranderen aan een goed draaiend systeem dan updates te doen.’ 

Geen garantie

Uiteindelijk is het volgens Den Breejen belangrijk je te beseffen dat patch-management geen garantie is voor veilige systemen. ‘Het is hoogstens een onderdeel voor een beveiligd systeem. Naast patch management zijn maatregelen als multi-factor authentication, Intrusion Detection/Prevention System (IDS/IPS), gedegen UTM-filtering, encryptie en een goed ingericht antivirus systeem onmisbaar.’ Hoe je er toch voor kunt zorgen dat je het patch-management verbetert, is te lezen in het artikel ‘Belangrijkste tips bij patch-management’.