Managed hosting door True

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'.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5249181). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

Ik kan me zeker wel vinden in dit onderwerp omdat het wat mij betreft gewoon standaard moet zijn in de gehele ICT keten. Waar ik me telkens over heb verbaast, eigenlijk nog steeds, is dat er in meer dan 75% van de gevallen sprake is van een hele summiere en vrijblijvende vorm van changemanagement laat staan dat men in de organisatie toe komt aan iets als 'patch management'.

Beiden zijn een noodzaak in de ICT keten waar het veiligheid betreft en beiden zouden dan gewoon onlosmakelijk aan elkaar gekoppeld moeten zijn. Pas dan kun je een goed werekende prioriterig implemeteren. Gegevn het feit dat ik in de regel vrij weinig over 'patchmanagement' hoor, doet mijn vermoeden gestand dat dit 'Standaard' onderdeel vrijwel niet leeft.

Kwalijke zaak.

Goed artikel.

Even een Rezaatje doen om 'Schoosteen Will' en zijn 'WC-eend' vriendjes te pesten:

http://www.computable.nl/artikel/opinie/security/5248088/1276896/licht-uit-spot-aan.html

Natuurlijk kun je er ook voor kiezen om een hele stack aan oplossingen te bouwen, let in dat geval even op de constatering van deze experts aangaande nijpende tekort aan beheercapaciteit. Aangezien de discussie op mijn schrijven verzandde in een discussie over All-People-Seems-To-Need-Data-Processing ezelsbruggetje van het OSI-model lijkt die constatering me empirisch bewezen. Ja, ja de struisvogel stak zijn kop in het zand om tegen te mol te vertellen dat het prachtig weer is.

Voor wie een oplossing zoekt die kan beschermen tegen zero day aanvallen.....

Patch management is belangrijk. Natuurlijk is het hartstikke vervelend dat patches ook problemen kan veroorzaken. Maar hoe groot zijn de problemen die kunnen ontstaan als je de patches niet uitvoert? Zoals Rick Den Breejen in de laatste Alinea al zegt, patching alleen is niet zaligmakend. Bij security gaat het over mens, processen en techniek. Drie belangrijke pilaren die alle drie geadresseerd dienen te worden om de risico's te kunnen verlagen. Patchen is een van de vele maatregelen die genomen moeten worden. Naast de maatregelen die Rick noemt zou ik graag willen toevoegen dat 40% van de security incidenten wordt veroorzaakt door menselijk handelen. Vergroting van het bewustzijn van medewerkers over de cyber-risico's waaraan ze blootstaan (zowel op het werk als thuis) zal de mensen weerbaar maken en het aantal security incidenten verlagen.

Het bepalen van de noodzaak van de patch is belangrijk en het is verstandig, in mijn ogen, om daar vooraf afspraken over te maken.
Ik sluit me dan ook geheel aan bij de een-na-laatste paragraaf van het stuk met betrekking tot: "Maar de belangrijkste reden is het ontbreken van een deugdelijk patch management beleid en proces...".

Zie ook mijn stuk, met name over de aandachtsgebieden voor het bepalen van de hoeveelheid tijd tussen beschikbaar komen van de patch en het daadwerkelijk patchen.

http://www.computable.nl/artikel/opinie/security/5211511/1276896/het-is-tijd-voor-een-patchbeleid.html

Patchen – tja – zo een beetje het meest ondankbare werk in IT land – altijd achter de feiten aanhollend.

Zo is daar de stelling “Never fix a running system” – vrij vertaald: waarom zou je patchen als er geen problemen zijn? Misschien omdat de al eens eerder genoemde contractuele kaartenhuizen verplichten om security patches met een bepaalde classificatie binnen een bepaalde tijd uit te voeren?
Maja - gaat het dan mis, dan is er weer een ander contract uit datzelfde kaartenhuis waarin staat dat het incident binnen een bepaalde tijd opgelost moet zijn. Lukt dit niet, dan moet de zaak teruggedraaid worden en begint het hele spel van voren af aan…

Dan zijn daar inmiddels ook de beruchte zero-day aanvallen waarbij de maker van een bepaald stukje software nog niet eens de tijd heeft gekregen om maatregelen te nemen.
Natuurlijk kan je in dergelijke gevallen prima het cloaking-concept toepassen! Waarna de betreffende adviseur onder het gemompel van een paar prachtige, nietszeggende volzinnen voldaan terugloopt naar zijn ivoren toren wachtend op een volgende voorbijganger die toch echt hoognodig en zonder enig respect de les gelezen moet worden…

“We are the Borg. You will be assimilated. Resistance is futile.”

https://drive.google.com/file/d/0B6sBaM2HpWOKUEE1b09KN0FKZjA/view?pli=1

;-)

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×