Home Security Hoeveel gapende gaten zitten er in uw IT-infrastructuur?

Hoeveel gapende gaten zitten er in uw IT-infrastructuur?

211

Wie de IT-sites een beetje in de gaten houdt, weet dat er op wekelijkse basis groots nieuws is over nieuw ontdekte beveiligingslekken in veel gebruikte software. Er is altijd veel angst rondom deze zogenaamde zero-days, omdat ervan wordt uitgegaan dat cybercriminelen er eerder in slagen om malware te schrijven die de lekken exploiteren, dan dat de software-leverancier met een patch kan komen. Dat is natuurlijk een realistisch scenario dat terecht nerveus maakt. Maar zero-days zijn bij lange na niet het grootste probleem.

Onderzoek heeft aangetoond dat bij 90% van de geslaagde aanvallen op zakelijke netwerken gebruik is gemaakt van beveiligingslekken waarvoor op het moment van de aanval weldegelijk al een goedwerkende oplossing voor het lek in kwestie – een zogenaamde patch – beschikbaar was gesteld door de producent van de software. Het grote beveiligingsprobleem ligt dus bij het niet (tijdig) installeren van dergelijke patches. Bovendien maken cybercriminelen ook steeds actiever gebruik van dit gegeven: uit analyses van patches die ter beschikking worden gesteld door de softwareproducenten halen zij net de kennis om malware te maken die gebruik maakt van de beveiligingslekken.  En die malware is dan bijgevolg uiterst gevaarlijk voor alle netwerken waar die patches nog niet zijn uitgerold.

Dat patches op bedrijfsnetwerken niet altijd (goed) worden uitgerold, is best begrijpelijk. De IT-beheerder heeft vaak geen idee welke software er door alle verschillende werknemers wordt gebruikt, laat staan dat hij een goed overzicht heeft van welke softwareversies er precies draaien. Bovendien gebeurt het nogal eens dat patches conflicteren met bepaalde (minder gangbare) programma’s die door bedrijven worden gebruikt, of dat bepaalde –voor de gebruiker belangrijke functionaliteiten-  bij een patch of een update verloren gaan, waardoor wordt geopteerd voor ‘niet aankomen’.

Om ondanks deze moeilijkheden toch grip te krijgen op het patchbeleid, en daarmee op een essentieel onderdeel van de beveiliging van de IT-infrastructuur, is het verstandig om een uitgebreide procedure vast te leggen, een zogenaamde UPMS (Update / Patch Management System). Een dergelijke procedure zou moeten bestaan uit de volgende stappen:

Update / Patch Management System voor IT-Infrastructuur

1)       Het updaten van de inventaris op het gebied van software en hardware. Wat wordt er precies allemaal gebruikt binnen het netwerk?

2)       Het verzamelen van informatie. Bij elke uitrol van software of hardware zou de IT-beheerder op de hoogte moeten zijn van de te installeren versie en de mogelijke problemen daarvan, zoals bekende bugs en beveiligingslekken en of er al updates en patches beschikbaar zijn.

3)       Het maken van een strategie en planning. Niet alle patches hoeven altijd over het hele netwerk te worden uitgerold. Factoren die in de overweging een belangrijke rol zouden moeten spelen, zijn onder andere de ernst van het beveiligingslek, de mate van bekendheid van het lek, hoe gemakkelijk en uitgebreid het lek kan worden misbruikt door cybercriminelen en of de patch eventueel afhankelijk is van vorige (wellicht niet-uitgevoerde) patches.

4)       Het testen van patches. Dit is een cruciale fase die veel problemen kan voorkomen. Het testen moet gebeuren op systemen die qua configuratie alle systemen binnen het netwerk simuleren. Vaak is het niet mogelijk om een complete fysieke testopstelling te maken die aan deze voorwaarde voldoet. In dat geval is het mogelijk om virtuele machines te gebruiken, al geven die geen realistisch beeld van de fysieke problemen die zouden kunnen optreden, zoals problemen met bandbreedte en gebrek aan schijfruimte.

5)       Het in inplannen van de uitrol. Veel patches kunnen niet worden uitgevoerd op een systeem dat in gebruik is, of vereisen een reboot van het systeem, waardoor het raadzaam is om patches uit te rollen buiten kantooruren. Bij zeer ernstige beveiligingslekken kan hierop een uitzondering worden gemaakt. Het is in alle gevallen verstandig om gebruikers vooraf te waarschuwen dat er gepatcht gaat worden, omdat het (onverwacht) invloed zou kunnen hebben op de functionaliteiten van programma’s, of omdat het een werkonderbreking kan veroorzaken. Ook is het verstandig om voor de uitrol een back up te maken van de oude situatie, zodat de uitrol kan worden teruggedraaid als zich toch compatibiliteitsproblemen voordoen.

6)       Het uitrollen van de patches. Dit is niet altijd alleen maar een kwestie van patches naar clients pushen. Vaak is het verstandig om een volledige virusscan te doen voor de uitrol om problemen te voorkomen. Een andere belangrijke raad is het controleren van de authenticiteit van de patch door de checksum te controleren. Als die klopt, is het zeker dat er geen fouten zijn opgetreden bij de download van de patch.

7)       Verificatie en reportage. Het is onverstandig om er blindelings op te vertrouwen dat de patch op alle systemen zonder problemen is verlopen. Het is slim om te controleren of het versienummer van de gepatchte software inderdaad is veranderd en of lekken inderdaad zijn gedicht. Controleer de deployment logs om te zien of zich problemen hebben voorgedaan. En betrek vooral ook de eindgebruikers in de evaluatie. Kunnen zij na de patch al hun werkzaamheden nog altijd naar behoren uitvoeren?

Na de zevende stap begint meteen stap 1 alweer. Patchen is dus meer dan een proces, het is een cyclus. Eentje die overigens voor een groot deel kan worden geautomatiseerd met de juiste software-oplossing.

Een uitgebreidere versie van het stappenplan is omschreven in de G Data Techpaper ˈPatch Management – Best Practicesˈ, die hier kan worden gedownload.

Jan van Haver, country manager Benelux & UK bij G Data Software

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in