‘Groene Hart Ziekenhuis overtreedt wet met verouderde software’ kopten nieuwsartikelen onlangs. Het ziekenhuis had de beveiliging van computersystemen niet op orde en overtrad daarmee de wet. Hoe kan het toch dat veel organisaties het beveiligingsniveau van software nog steeds niet onder controle hebben?
Het legacy software vraagstuk is zeker ook een beveiligingsrisico, maar van een andere orde dan het patchen van bekende gebreken in de software. Kwaadwillende krijgen gemakkelijker vat op bestaande systemen doordat bekende (kritische) security patches gewoonweg niet worden uitgevoerd.
Deze essentiële software-updates worden door adviesorganen (Sans.org, Australian Signals Directorate (ASD), European Union Agency for Network and Information Security (ENISA)) zelfs de beste bescherming van systemen genoemd. De urgentie voor het uitvoeren van deze patches wordt vaak onderschat.
Beschikbare tijd
De tijd die organisaties hebben om patches uit te voeren ligt aan de gevoeligheid van de data binnen de systemen. De volgende vragen kunnen helpen om de urgentie te bepalen:
- Wat zijn de gevolgen als er iets mis gaat met het desbetreffende systeem en wie ondervindt daar gevolgen van? Gaat het bijvoorbeeld om e-mail, facturaties, de website of in het geval van het Groene Hart Ziekenhuis om medische gegevens?
- Zijn de toegangswegen tot de informatie voldoende gelaagd?
- Is per patch het belang bepaald op de eigen systemen? Gaat het bijvoorbeeld om front- of backend systemen?
- Is het mogelijk voor een aanvaller om aan de voorwaarden (via netwerk of lokaal, de authenticatie, complexiteit, et cetera) te voldoen voor het misbruiken van het lek?
- Is er een mogelijkheid om de security patches te testen?
- Wie is er verantwoordelijk voor het patchen en wie is de eigenaar van het systeem?
Ook kleine, ogenschijnlijk weinig betekenisvolle security updates kunnen, indien deze niet uitgevoerd worden, gecombineerd leiden tot inbreuk in de systemen. Daarom is het planmatig onderhoud van it-systemen aan te raden. Niet-planmatig onderhoud, waarbij er pas wordt ingegrepen na bijvoorbeeld een melding van een eindgebruiker, is kostbaar en risicovol.
Juist voor de kritische systemen binnen de organisatie zijn kritische security updates belangrijk. En is het voor de gehele organisatie niet beter om van te voren te weten of een systeem tijdelijk niet beschikbaar is?
Toch biedt ook planmatig onderhoud geen 100 procent bescherming van de it-systemen. Er zijn uitzonderingen bijvoorbeeld in de vorm van out-of-band-patches die direct moeten worden uitgevoerd om een lek te dichten, zoals het Drupal 7- en ShellShock-lek.
Beleid opstellen
Het is daarom belangrijk om een beleid op te stellen voor het uitvoeren van dit soort kritische patches. Hierin moet opgenomen zijn wie er verantwoordelijk is voor het initiëren van acties. Op basis van de impact van de dreiging, de randvoorwaarden voor misbruik van de eigen omgeving en de kritieke systemen, moet zoveel mogelijk vooraf worden bepaald wat de acties zijn. Dit kunnen acties zijn zoals de service/applicatie afsluiten, de configuratie aanpassen en/of functionaliteit inperken.
Er zullen altijd lekken blijven die wel bekend zijn bij aanvallers en niet bij de verdedigers. Maar, zoals vaker wordt gezegd: 'Aanvallers hebben ook een budget'. Zij zullen (meestal) gaan voor de weg van de minste weerstand. Door op de bekende kwetsbaarheden geen actie te ondernemen en verouderde software te gebruiken, maak je het kwaadwillenden wel heel eenvoudig.
