Patchmanagement: wat is dat nou eigenlijk?

DNB stuurt op het nakomen van haar Good Practice Informatiebeveiliging. Termen die je hierin veelvuldig terug ziet komen zijn ‘patches’, ‘een patchmanagement proces’ en ‘een strikt patch regime’. Maar wat betekenen deze termen eigenlijk? En hoe geef je hier invulling aan in de praktijk? Onze Risicomanagement Consultants Bas de Vries en Jamiel Arens leggen dit uit.

 

Patchmanagement: de basisprincipes

Om te beginnen is het belangrijk om te weten wat een patch precies is. Een patch is een installatiebestand dat een kwetsbaarheid of fout in een programma herstelt (een soort pleister plakt) of een programma verbetert (bijv. een extra functionaliteit toevoegt). Kwetsbaarheden in een programma kunnen een bedreiging vormen voor de informatiebeveiliging van een bedrijf. Daarom is het van groot belang dat een bedrijf een goed plan van aanpak heeft bij een dergelijke bedreiging. Deze kwetsbaarheden moeten namelijk zo snel mogelijk verholpen (of wel gepatched) worden.

Patchen is een complex proces. Patches kunnen namelijk meerdere IT systemen raken. Ook kan een de implementatie van een patch zorgen voor instabiliteit in het IT landschap van een bedrijf. Daarom moet een patch goed getest worden voordat deze uitgerold wordt in het IT landschap. Samenvattend draait patchmanagement om het gecontroleerd en planmatig identificeren van kwetsbaarheden en het testen en uitrollen van patches. Het doel hiervan is om up to date te zijn en tegelijk het productieproces zo min mogelijk te verstoren.

 

Een voorbeeld: VPN kwetsbaarheden

Veel bedrijven gebruiken een VPN verbinding om hun bedrijfsinformatie te beveiligen. Via deze VPN verbinding kan een medewerker vanaf een externe locatie toegang krijgen tot het netwerk van de organisatie. Uiteraard is het van belang om te controleren de persoon die toegang wilt verkrijgen tot de verbinding, ook echt een medewerker van het bedrijf is. Door middel van een aantal stappen wordt dit geverifieerd door de VPN tool.

Als de VPN software een kwetsbaarheid bevat, werkt de beveiliging onvoldoende. Iemand kan daardoor onrechtmatig toegang verkrijgen tot gevoelige bedrijfsinformatie. Vaak brengt een producent voor dergelijke kwetsbaarheden snel een patch op de markt. Nadat zo’n patch uitkomt, worden vaak vrijwel direct kant en klare oplossingen gemaakt om de beveiliging te omzeilen. Bij een softwarefout moet dus snel gehandeld worden. Anders kan het goed mis gaan.

Een voorbeeld uit de praktijk is de ‘VPN Exploit’. Voor de tweede keer in korte tijd is een kwetsbaarheid in de VPN Software van bedrijven ontdekt. Door een exploit in de VPN beveiliging bleek bij ruim 900 bedrijven vertrouwelijke bedrijfsgegevens kwetsbaar te zijn voor kwaadwillenden. Dit probleem had al ruim twee maanden eerder kunnen worden opgelost. Hiervoor was namelijk een patch beschikbaar, maar deze is door veel bedrijven niet geïnstalleerd.

 

Patchmanagement in de praktijk: waar moet je op letten?

Patchmanagement is één van de basiselementen in het veilig stellen van jouw bedrijfsinformatie. En moet daarom op orde zijn. Maar hoe geef je hier praktisch invulling aan? Een duidelijke invulling van het proces wordt in de ‘best practice’ van de DNB niet uitgewerkt. Het proces is namelijk sterk afhankelijk van het soort activiteiten dat jouw bedrijf uitvoert, het IT landschap en de grootte van het bedrijf. Begin in ieder geval, met het proportionaliteitsbeginsel in gedachten, met het beantwoorden van de volgende vragen:

• Is het duidelijk wie binnen het bedrijf verantwoordelijk is voor patchmanagement?
• Is er duidelijk inzicht in de kwetsbaarheden van het IT-landschap en alle IT-procedures?
• Zijn de beveiligingsrisico’s goed gemonitord, zodat het bedrijf tijdig op de hoogte is van problemen in de software?
• Worden problemen (aanvallen) of kwetsbaarheden in de programma’s proactief ontdekt door interne monitoring?
• Hebben we een doordacht proces om patches effectief uit te rollen (zodat medewerkers het niet te lang uit kunnen stellen)?
• Zijn de update-rate en doorlooptijden elk moment helder?
• Komen de gevolgen van softwarefouten snel aan het licht door een lookback proces met bijvoorbeeld backtesting op verdachte accounts en gebeurtenissen en het intrekken van bestaande certificaten?
• Bestaat zicht op het patchmanagement bij outsourcingspartners, zodat er geen ingangen via externe partijen zijn?