‘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.
Johan,
In mijn ervaring werkt het alleen maar hebben van beleid niet. Er moet juist een goede organisatie zijn van de uitvoering en controle daarop. Waakhonden als het CBP In jouw voorbeeld spelen daarbij een rol.
De focus moet niet liggen op techniekvragen, maar op vragen naar bedrijfsimpact. Uit jouw lijstje zijn dus de eerste en laatste vraag belangrijk, al zou ik meer focussen op wie de bestuurder is die verantwoordelijk is om een eigenaar aan te wijzen, te zorgen dat de eigenaar weet wat er van hem/haar verwacht wordt en wat de consequentie is als hij/zij dat niet doet – denk aan SOx. Als die bestuurder vervolgens de hete adem van een waakhond voelt komt het wel goed met die techniek. Men gaat dan o.a. vanzelf vragen om een goed patchbeleid…
Je vraagt je anno 2015 af waarom IT afdelingen patchmanagement, de het meest noodzakelijke beheerproces nog niet hebben ingebed in de organisatie. Hier is geen nieuw beleid nodig, maar goed sturend management.
Vooral niet aanvliegen als een technisch feestje, maar een proces inrichten en maandelijks patchen, met ad-hoc matching voor de kritieke patches.
Hallo Lex, bedankt voor je reactie.
Laat ik er mee beginnen dat ik het met je eens ben en dat een beleid alleen niet effectief is.
De balans vinden tussen techniek, processen, beleid en het menselijke aspect zal altijd een uitdaging blijven. De drijfveer zal ook vanuit het bestuur moeten komen, maar de lijnen uitzetten is één ding. Het toepassen blijft vaak lastiger, daarom is het krachtig om een praktisch beleid te hebben. De structuur in een organisatie is niet altijd duidelijk, juist niet in stressvolle situaties.
De effectiviteit van het beleid komt naar boven (binnen dit onderwerp) als de engineer zijn/haar energie kan stoppen in het testen van patches en afhankelijkheden in plaats van constant in overleg te moeten en uit te leggen wat het plan is. Dat heeft hij/zij (of een collega) al gedaan bij het tot stand komen van het beleid.
Ik ben geen voorstander van bureaucratie (in sommige gevallen wordt het namelijk gebruikt als een soort van dagelijkse stiptheidsactie), maar soms is het handig om in één klap een groot aantal keuzes te maken.
Hallo Willem, ook bedankt voor jouw reactie.
Helemaal mee eens, het probleem zit volgens mij dan ook in het bepalen van de scope. Begin met het aanwijzen van de eigenaren van de belangrijkste systemen en hun verwachtingen. Hier gaan uiteraard nog wat acties aan vooraf, maar begin desnoods met het onderbuik gevoel.
De moeilijkheid zit voornamelijk bij de organisaties die net groter aan het worden zijn, dat het patchen andere processen in de weg kan zitten en verschillende systemen van elkaar afhankelijk zijn.
Voor wat betreft het beleid, het klinkt niet als een effectief beleid als het noodzakelijke beheerproces nog niet ingebed is.