BLOG – Met de komst van de NIS2-richtlijn worden de eisen voor cyberveiligheid in Europa flink aangescherpt. Organisaties die hun systemen niet up-to-date houden, zijn kwetsbaar en lopen grote risico’s. Hoe houd je je systemen wel bij de tijd en het patchmanagement op orde, vooral in complexe it- en ot-omgevingen?
17 oktober 2024 was een belangrijke datum voor iedereen die met cybersecurity te maken heeft. Op die dag moest de NIS2-richtlijn door de EU-lidstaten in nationale wetgeving zijn omgezet.
Even recapituleren. De Network and Information Security Directive 2 is een aanscherping van de NIS-richtlijn. Meer organisaties gaan onder deze wetgeving vallen, die ook nog eens scherpere eisen stelt aan de beveiliging van netwerken en informatiesystemen. Doel is om de cyberveiligheid van essentiële diensten en digitale infrastructuren beter te kunnen waarborgen. De digitale weerbaarheid ten opzichte van cyberaanvallers moet versterkt worden en de nieuwe wetgeving gaat bedrijven en instellingen in de juiste richting duwen.
Veel organisaties beschikken nog over legacysystemen, die moeilijk te patchen zijn
De Nederlandse regering heeft aangegeven dat zij de deadline van 17 oktober niet haalt. De Nederlandse wet gaat de Cyberbeveiligingswet (Cbw) heten en zal nu naar verwachting tussen april en september 2025 in werking gesteld worden. Dit neemt niet weg dat organisaties die onder de NIS2-richtlijn vallen, aan de nieuwe eisen moeten voldoen. De ontwerptekst van de wet is reeds beschikbaar, dus waarom zou je dat niet willen als organisatie?
Patchmanagement
Een component hierbij is het patchmanagement. Patchen is het up-to-date houden van software of firmware door beveiligingsupdates en optimalisaties toe te passen. Organisaties die aangemerkt zijn in de NIS2, en straks dus de Cbw, moeten daarom beschikken over robuuste procedures voor het tijdig patchen van hun systemen. Dit helpt om geconstateerde beveiligingslekken tijdig te dichten, in ieder geval voordat cyberaanvallers deze kunnen benutten.
Cybersec Netherlands
Op de vakbeurs Cybersec Netherlands is vanzelfsprekend volop aandacht voor cyberdreigingen. De beurs wordt georganiseerd op 6 en 7 november in Jaarbeurs Utrecht. Meld je hier voor het programma-overzicht en een gratis toegangskaart.
Een impressie? Bekijk hier de video-opnames van Cybersec Netherlands 2023.
Kijken we naar NIS2, dan zijn er verschillende aanknopingspunten aan de hand waarvan je als organisatie het patchen meer prioriteit en meer aandacht kunt geven. Zo biedt de richtlijn handvatten om het risicomanagement in kaart te brengen en word je geacht incidenten te rapporteren. Is het patchbeleid niet op orde, dan loop je meer risico’s en in geval van een incident zul je dit kenbaar moeten maken. Het it-landschap is omvangrijk en divers, wat patchen lastig en tijdrovend maakt. Automatiseren ligt voor de hand, tools zijn hiervoor beschikbaar. Hoewel dit zorgt voor meer efficiency en minder menselijke interventie, is dit niet de ultieme oplossing.
Complexiteit
Patchen is dan ook niet zo eenvoudig is als het lijkt. De complexiteit van de it-infrastructuur is toegenomen. Daarnaast beschikken veel organisaties nog over legacysystemen, die moeilijk te patchen zijn. Waar een poging wordt ondernomen, kunnen er compatibiliteitsproblemen optreden. Ten slotte hebben veel organisaties moeite om genoeg menskracht vrij te maken, waardoor tijdig patchen onder druk komt te staan. Door de workload die patchen toevoegt, ontstaat terecht de wens patchen te automatiseren. Echter, we zagen in de CrowdStrike-casus dat een automatische update in live-omgevingen ook desastreuze gevolgen kan hebben. Je moet als organisatie altijd voor ogen houden dat patchen implicaties kan hebben op de hardware.
Forser
De uitdagingen rondom patchen zijn in de omgeving van operationele technologie (ot) nog forser. Ot-systemen, zoals die in productie, energie en andere kritieke infrastructuren, draaien 24/7 en kunnen niet zonder gevolgen worden stilgelegd voor onderhoud of updates. Een korte onderbreking kan leiden tot verstoringen in de productie, verlies van inkomsten of veiligheidsrisico’s. Het stilleggen van deze systemen voor patching vraagt daarom om een zorgvuldige planning, wat in de praktijk zelden op korte termijn kan. Gevolg is dat het patchen wordt uitgesteld, wat grote risico’s met zich mee brengt. Daar komt bij dat juist in de ot-omgeving er veel sprake is van legacysystemen, die ooit ontwikkeld zijn zonder rekening te houden met security. Ten slotte moeten we constateren dat veel ot-systemen in geïsoleerde ruimtes gesitueerd zijn. Deze zijn soms beperkt of helemaal niet verbonden met internet, wat het doorvoeren van patches op afstand lastig maakt. Je moet als operator of it-engineer fysiek naar de hardware om het werk uit te voeren. Dit kost tijd, die er niet is als je cyberaanvallers buiten de deur wil houden.
Dimensies
We kunnen niet met één maatregel de complexiteit van patchen in de ot wegnemen. Wel is gerichter te patchen en dat is door risicogestuurd te werk te gaan. Dit concept heeft twee dimensies:
- Dimensie 1
Je brengt in kaart wat de belangrijkste assets zijn in de infrastructuur: applicaties, netwerken, productiefaciliteiten, etc. De focus komt op het patchen van hardware, software of machines die onmisbaar zijn voor de businesscontinuïteit; - Dimensie 2
Je gaat systemen patchen op basis van de mate van risico dat een specifieke kwetsbaarheid of dreiging vormt voor de organisatie. In plaats van simpelweg alle beschikbare patches blindelings toe te passen, kijk je met deze risicogestuurde aanpak naar welke kwetsbaarheden het grootste potentiële gevaar vormen.
Patchmanagement is een cruciaal onderdeel van NIS2 en vereist een risicogestuurde aanpak om de juiste prioriteiten te stellen in een complexe it- en ot-omgeving. Organisaties moeten nu stappen zetten om hun patchbeleid te optimaliseren en risico’s in kaart te brengen. Wacht niet tot de Cbw in Nederland in werking treedt, maar ga aan de slag met de genoemde dimensies.
Eric ten Bos is industry lead maritime and critical production systems bij Thales
Patch Cherry picking dus.
Artikel gaat mee met oudlid, die vindt dat je alleen belangrijkste patches moet installeren. Probleem is alleen die analyse, in een systeem met zoveel afhankelijkheden met zichzelf en andere systemen.
En wat doe je dan met die minder andere patches ? En je wilt ook gewoon upgraden tbv features of LCM. Daar heb je toch onderhouds windows voor. En dan heb je nog clustering waarbij je in HA systemen de nodes 1 voor 1 patcht zonder de door cluster geleverde service te onderbreken.
Op zich wonderlijk. Geen tijd hebben HA op te zetten, maar wel elke patch gaan onderzoeken.
Dat gebeurt dan vaak ook niet denk ik.
Makkelijkste is tenslotte gewoon om niet te patchen 🙂
Volgens de NIS2-richtlijn moeten organisaties niet alleen de bekende en/of gemelde kwetsbaarheden patchen, maar ook een proces inrichten om de kwetsbaarheden te identificeren en vast te leggen. Dit proces omvat het risicomanagement want het gaat uiteindelijk om de impact op de kritische keten. Identificeren van het risico en daarop acteren hoeft namelijk niet altijd het aanbrengen van een patch te zijn want er zijn meer opties om te voorkomen dat een kwetsbaarheid misbruikt kan worden. Hierdoor lijkt een ouderwets proces zoals het configuratiemanagement me door NIS2 belangrijk te worden want wederom slaat Dino de plank mis in het beheer omdat het lifecycle management vooral om de cont(r)acten in het onderhoud gaan.
Geen geld, geen Zwitsers geldt niet alleen voor de patches want niet gehinderd door enige kennis – gaap – roepen over HA klinkt als de monocultuur van SOA in een wereld van een SPoF door de interface die om oude protocollen gaat. Of een oude stekker want ouderwets de firmware updaten via RS232 geldt voor zo’n 40% van de systemen die een andere afschrijvingstermijn hebben dan de software. Denk dat de grootste uitdaging met NIS2 in het dimensioneren van het probleem zit omdat veel legacy onder de deken van gelaagde oplossingen aan de aandacht ontsnapt is. En met dimensioneren bedoel ik het budgetteren in projectmatig werken want wij van WC-eend zwemmen al heel lang in de vijver van beheer.
Een risico gestuurde aanpak om de juiste prioriteiten te stellen lijkt me om het realisme versus het opportunisme te gaan want NIS2 kent een hoofdelijke aansprakelijkheid voor nalatigheid. Bestuurders zijn namelijk verplicht om een effectief risicobeheer in te richten en zoals gezegd voorzie ik daarin een cruciale rol voor het configuratiemanagement. Wat betreft de analyse van belangrijke patches en minder belangrijke patches gaat het namelijk om de veerkracht van een systeem. HA beschermd bijvoorbeeld niet tegen ransomware als we kijken naar de risico’s en een ouderwetse back-up. Want terug naar de toekomst is het nogal cyclisch als ik kijk naar 54 oude opinies die nog altijd relevant zijn door een visie in het beheer.
Geen bier, geen bijdragen want laag hangende fruit in cherry picking gaat om het verschil tussen beheerbaar en beheersbaar als we kijken naar de risico’s. De technische kant van het patchen is maar één zijde van de medaille want de andere zijde gaat om de beleidsmaatregelen en een controle op de naleving hiervan. Want van papieren tijgers naar bijtende honden lijkt NIS2 vooral om het aantrekken van de teugels te gaan.