1 Inleiding

Dit groeiboek richt zich op cybersecurity in de infrastructuur in het licht van veiligheid, beschikbaarheid en privacy . Hoewel het document specifiek ingaat op tunnels, is de inhoud breed toepasbaar op alle infrastructurele werken met (industriële) automatisering, waaronder bruggen, sluizen en stuwen.

1.1 Leeswijzer

Hoewel dit groeiboek is ingedeeld in opzichzelfstaande hoofdstukken, is er wel een verband tussen de hoofdstukken. Dit is in onderstaande figuur weergegeven. De hoofdstukken over de aspecten en wet- en regelgeving zijn in alle gevallen relevant. Maar voor bijvoorbeeld assetmanagement is het niet noodzakelijk om het hoofdstuk over verificatie en validatie te lezen.

Figuur 1.3: De onderdelen in het groeiboek.

Het groeiboek is zo opgezet dat het eenvoudig is om in de toekomst onderdelen toe te voegen of te wijzigen. Alleen op die basis is het mogelijk de gedachte achter een digitaal groeiboek vorm te geven.

1.2 Aanleiding en doel

Uit diverse onderzoeken komt naar voren dat overheid, bedrijfsleven en burgers stappen moeten nemen om hun digitale weerbaarheid te vergroten. Echter, dit gebeurt niet snel genoeg en men loopt achter op de ontwikkelingen. Dit blijkt onder andere uit het Cybersecuritybeeld Nederland van het Nationaal cybersecuritycentrum (NCSC).

Met deze handreiking willen de leden binnen het COB-netwerk de bewustwording rondom cybersecurity verbeteren en alle bij de realisatie en het beheer van infrastructurele projecten betrokken partijen kennis laten nemen van belangrijke aspecten van cybersecurity. Met deze kennis zijn de betrokkenen in staat de digitale weerbaarheid van hun object te beoordelen en processen zodanig in te richten dat tijdig de juiste maatregelen worden genomen om cyberincidenten te voorkomen of te beheersen. Ook wil deze handreiking partijen helpen bij het organiseren om eventueel opgetreden effecten bij incidenten te kunnen mitigeren.

Dit groeiboek is dan ook bedoeld om iedereen die beroepsmatig betrokken is bij de veiligheid in en om tunnels (en andere objecten in de infrastructuur waarin vergelijkbare technologie is toegepast) een laagdrempelige instap in de wereld van cybersecurity te geven. Het implementeren en borgen van cybersecurity is binnen de infra een voorwaarde voor de veiligheid van iedereen in en om het object.

Het ontbreken van cybersecurity kan enorme gevolgen hebben. Zo kunnen cyberincidenten schade en letsel met zich meebrengen, en dan gaat het niet alleen om financiële schade. Schade aan de bedrijfscontinuïteit van vitale en niet-vitale processen kan grote maatschappelijke en economische impact hebben, waarbij ook de veiligheid van mensen in het geding komt. Daarnaast kan imagoschade (door het ontbreken van cybersecurity of door schade als gevolg van een geslaagde aanval) voor een organisatie een zeer grote impact hebben. De geloofwaardigheid van de organisatie tegenover (potentiële) opdrachtgevers kan ernstig beschadigd raken. Tegen financiële risico’s kun je als organisatie allerlei maatregelen nemen, denk aan verzekeringen en/of het reserveren van een risicobudget, maar imagoschade is niet te verzekeren en is vaak blijvend.

Het management in zowel de publieke als de private sector is niet altijd in even goede mate doordrongen van de realiteit als het gaat om de dreiging van een cyberincident. Veel gehoorde uitspraken zijn:

• Wat is er nu bij ons te halen?
• Wij zijn toch niet interessant?
• Bij ons gebeurt dit niet hoor!
• Wij hebben onze zaken wel voor elkaar.
• Onze systemen zijn niet aan internet gekoppeld.

Bovendien schrikken de kosten van beveiligingsmaatregelen menig organisatie af.

Het is echter niet meer de vraag óf je wordt gehackt, maar wanneer en met welke impact.

Voor de meest actuele meldingen zie: Nationaal cybersecuritycentrum (NCSC).

1.3 Scope

Dit groeiboek geeft personen en partijen die betrokken zijn bij tunnels zicht op wat er allemaal komt kijken op het gebied van cybersecurity binnen tunnels. Het boek geeft geen uitwerkingen van systemen, ontwerpen en procedures, omdat deze project-, organisatie- en systeemspecifiek zijn. Dit document draagt dan ook veel overwegingen aan, maar het kan en zal niet compleet zijn.

De eerste editie van dit groeiboek is uitgegeven op 30 mei 2018, de tweede versie op 26 november 2019. In de tweede uitgave is het groeiboek uitgebreid met de gehele levenscyclus van een tunnel/object en worden de taken en verantwoordelijkheden van alle betrokken stakeholders tijdens deze fase beschreven.

In de derde editie (2020) is de opzet en indeling van het groeiboek ingrijpend veranderd. Het doel was de traceerbaarheid en vindbaarheid van onderwerpen en aspecten te verbeteren. Dat maakt het voor de lezer makkelijker om te filteren op aspect of onderwerp, en in één keer relevante informatie bij elkaar te vinden.

De derde uitgave bevat bovendien enkele belangrijke aanvullingen en uitbreidingen, waaronder een tool om een volwassenheidsanalyse uit te voeren, een verduidelijking op de relatie tussen cybersecurity en tunnelveiligheid, en een voorbeeld voor een businesscase waarin argumenten, methoden en effecten zijn opgenomen.

In de vierde editie (2021) is aandacht besteed aan een aantal specifieke onderwerpen uit de praktijk. Kort samengevat:

• Herstel en bedrijfszekerheid: hoe zorg je ervoor dat je na een incident snel en controleerbaar weer operationeel bent en hoe beperk je schade door een incident?
• Patching en servicing: onderhoud is bedoeld om systemen beter te maken, maar nieuwe code of componenten en tijdelijke open poorten vormen ook een risico. Hoe beheersen we dat risico en gebruiken we die kans?
• Renoveren: in hoeverre wijkt renovatie af van nieuwbouw? Wat is het verschil met normale exploitatie, normaal onderhoud; in welke ‘hoek’ levert dit extra of andersoortige risico’s op?
• Relatie cybersecurity en tunnelveiligheid: is een notitie toegevoegd die de verschillende gezichtspunten op deze relatie belicht.

1.4 Wat is cybersecurity voor OT?

Bij cybercriminaliteit denken de meeste mensen al snel aan aanvallen op de bedrijfs-IT-omgeving. Denk bijvoorbeeld aan een DDoS-aanval die een dienst platlegt, malware die bedrijfsinformatie steelt of een database die met foutieve data wordt vervuild. Echter, de tijd dat hackers het alleen hadden voorzien op traditionele IT-omgevingen is voorbij. Steeds vaker hebben zij het ook gemunt op de operationele technologie (OT); de omgeving van bijvoorbeeld energiebedrijven en fabrieken. En daar is de schade direct vele malen groter. Een kritiek OT-bedrijfsproces dat zomaar wordt stilgelegd, kan betekenen dat de productielijnen in een fabriek platliggen, terminals dichtgaan, tunnels en bruggen onveilig zijn of sluizen niet meer opengaan of sluiten. De gevolgen zijn dan niet te overzien.

In dit document wordt het volgende verstaan onder cybersecurity:

Alle beveiligingsmaatregelen die men neemt om schade te voorkomen door een storing, uitval of misbruik van een informatiesysteem of computer. Ook worden maatregelen genomen om schade te beperken en/of te herstellen als die toch is ontstaan. Voorbeelden van schades zijn dat men niet meer in een computersysteem kan komen wanneer men dit wil of dat de opgeslagen informatie bij anderen terecht komt of niet meer klopt. De maatregelen hebben te maken met processen in de organisatie, technologie en gedrag van mensen.

(Bron: cybersecurity-woordenboek)

Noot:

Een OT-systeem is een informatiesysteem of computer, aangevuld met industriële automatisering. Omdat OT-systemen de digitale wereld en de fysieke wereld met elkaar verbinden, kan een cyberincident naast de in de definitie genoemde schade ook schade veroorzaken in de fysieke wereld. Een voorbeeld hiervan is letsel (personen): een aanrijding met een onverwacht sluitende afsluitboom voor een tunnel of een brug.

1.5 Werkgroep cybersecurity en ISAC Tunnels

Tijdens de bijeenkomst ‘Veilige software’ op 10 februari 2015 van het COB platform Veiligheid is door Jaap van Wissen van Rijkswaterstaat een toelichting gegeven op de information sharing and analysis centres (ISAC’s) voor vitale sectoren in Nederland, zie figuur hieronder.

Figuur 1.1: Overzicht ISAC’s die actief zijn in Nederland. Standaard is in elke ISAC een drietal verschillende publieke organisaties aangesloten: het NCSC, de Algemene Inlichtingen- en Veiligheidsdienst (AIVD) en Team High Tech Crime (THTC) van de Nationale Politie. (Bron: NCSC)

Naar aanleiding van deze bijeenkomst is het initiatief ontstaan voor een werkgroep Cybersecurity en voor een ISAC gericht op cybersecurity in tunnels.

Het ISAC Tunnels is opgezet met de volgende taak- en doelstelling:

1. Het ISAC Tunnels biedt een veilige en vertrouwde omgeving waarbinnen partijen die deel uitmaken van de tunnel-community binnen de vitale infrastructuur, samen met de met (cyber)security belaste overheidspartijen, gevoelige en vertrouwelijke informatie over cyberdreigingen en best practices kunnen uitwisselen.
2. Het ISAC Tunnels is een gremium waar het delen van kennis, informatie en ervaringen ten aanzien van cybersecurity tussen leden binnen de tunnel-community centraal staat.
3. Het ISAC Tunnels draagt bij aan het versterken van de (keten)beveiliging in de sector door een permanent (menselijk) netwerk te vormen, waardoor partijen elkaar ook buiten het overleg makkelijk weten te vinden.
4. Toegevoegde waarde, onderling vertrouwen en de statuten staan aan de basis van het ISAC Tunnels.

Dit groeiboek is opgesteld door de werkgroep Cybersecurity van het COB. In de werkgroep hebben ongeveer veertig deelnemers zitting, vanuit marktpartijen zoals ingenieursbureaus, systemintegrators, leveranciers en cyberbeveiligingsbedrijven, en overheden. De leden van de besloten ISAC Tunnels zijn ook lid van de werkgroep. Het ISAC beslist zelf welke informatie met de werkgroep Cybersecurity gedeeld kan worden of uitsluitend onder de ISAC-leden blijft.

In Bijlage 4 Overzicht werkgroep deelnemers is een overzicht opgenomen van de deelnemers van de werkgroep.

1.6 Terminologie

Voor de automatiseringssystemen in de tunnels worden verschillende termen gebruikt, zoals

industrial automation and control systems (IACS), industrial control systems (ICS), industriële automatisering (IA) en operationele technologie (OT). In dit groeiboek wordt de term OT aangehouden voor de operationele systemen, netwerken en applicaties.

Met de term ‘tunnel’ wordt in dit document het tunnelsysteem inclusief aansluiting op het wide area network (WAN) en verkeerscentrale bedoeld, zie onderstaande schematische weergave. De verkeerscentrale en het WAN behoren dus niet tot het tunnelsysteem.

Figuur 1.2: Schematische voorstelling tunnelsysteem en verkeerscentrale.

Voor een toelichting op het gebruikte jargon in dit document en binnen de cybersecuritysector, kunt u het woordenboek van Cyberveilig Nederland raadplegen.

2 De aspecten van cybersecurity

Voor het structureren van informatie rondom cybersecurity is het handig gebruik te maken van een indeling. Deze indeling gebeurt aan de hand van de drie aspecten:

• Mens
• Organisatie
• Techniek

Het opsplitsen van een vraagstuk aan de hand van deze drie aspecten helpt om een situatie te analyseren en te beschrijven, of een maatregel op te stellen. De drie aspecten staan los van elkaar, maar hebben in de praktijk wel invloed op elkaar. In onderstaande figuur is dit weergegeven.

Figuur 2.1: Aspecten cybersecurity.

Het aspect ‘mens’ is van toepassing als er sprake is menselijk gedrag. In het geval van cybersecurity gaat het dan bijvoorbeeld om incidenten als gevolg van menselijk handelen (geen wachtwoord gebruiken, een onbevoegde toelaten). Er is sprake van het aspect ‘techniek’ als iets direct het gevolg is van, of van invloed is op, een technische eigenschap (niet geupgrade versie, deurslot defect). Bij het aspect ‘organisatie’ is er sprake van invloed van processen, regels, procedures enz. Voorbeelden hiervan zijn: geen actief beleid omtrent cybersecurity, te veel volmachten bij dezelfde persoon enz.

Het is belangrijk te realiseren dat de drie aspecten invloed hebben op elkaar. Zo kan een wens zijn dat medewerkers (‘mens’) laptops niet te lang onbeheerd laten. Het ligt dan voor de hand dat de ICT-afdeling een app (‘techniek’) implementeert en in beheer neemt (‘organisatie’). Dit voorbeeld laat zien bij het beschrijven van een situatie of maatregel alle drie aspecten afzonderlijk aan bod moeten komen. Maar ook dient de toegepaste technologie passend te zijn bij de organisatie en aan te sluiten bij de kennis en ervaring van de factor ‘mens’. De driehoek dient dus in evenwicht te zijn. Enkel als alle drie de aspecten zijn ingevuld, is het mogelijk cybersecurity op een correcte wijze te implementeren.

De volgende paragrafen gaan dieper in op de drie aspecten.

2.1 Mens

Het aspect ‘mens’ heeft betrekking op de invloed die een persoon of personen kunnen hebben op cybersecurity. Deze invloed is het gevolg van iemands handelen of gedrag in een bepaalde situatie.

De meeste mensen zijn zich vaak niet of nauwelijks bewust van de risico’s van de manier waarop ze handelen. Medewerkers delen nog veel te vaak inloggegevens met collega’s, of schrijven deze bij de desbetreffende installatie op een briefje. Ook komt het voor dat onderhoudspersoneel gegevensdragers (laptops, USB-sticks, etc.) aansluit op installaties waarop ze onderhoud moeten uitvoeren zonder deze vooraf te scannen op malware. Andere voorbeelden van ongewenst gedrag zijn het bekijken van de inhoud van ‘gevonden’ USB-sticks, het kwijtraken van informatie — zowel op papier als op digitale media — en het delen van informatie met niet-geautoriseerde personen, zowel bewust als onbewust. Maar ook personen die ontslagen worden, in financiële moeilijkheden zitten, ontevreden of incapabel zijn, blijken een belangrijke risicofactor te vormen.

Dergelijke voorbeelden laten zien dat gedrag leidt tot risico’s die bij het opstellen van een risico-inventarisatie moeten worden meegenomen. Het is belangrijk bewust te zijn van de mogelijke gevaren die aan gedrag kleven en daartoe de nodige maatregelen op te nemen. Voorbeelden hiervan zijn het blokkeren van accounts, het regelmatig wijzigen van wachtwoorden en het opleiden van medewerkers. Immers, menselijk gedrag kan technische en procedurele maatregelen teniet doen. Als een cyberrisico door een technische en/of procedurele maatregel wordt opgelost, maar deze hindert mensen te veel in hun werkzaamheden, dan leidt dit al snel tot een workaround. Deze workaround maakt het meestal niet veiliger. De golden triangle — de balans tussen functionaliteit, beveiliging en gebruiksgemak — is daarom van essentieel belang.

Ruim zeventig procent van de gemelde veiligheidsincidenten heeft onwetendheid en onjuist handelen van mensen als voornaamste oorzaken. Daarmee vormen mensen dan ook een belangrijke factor voor cybersecurity. Het is daarom van belang dat mensen opleiding krijgen (kennis en bewustwording) en gefaciliteerd worden om veilig gedrag te ontwikkelen. Dit betreft beheerders, bedienaars, onderhoudspersoneel en andere betrokkenen die aan objecten werkzaamheden uitvoeren.

2.2.1 Bewustwording (awareness)

Bewustwording is de goedkoopste en meest effectieve methode om een basis te leggen voor cybersecurity binnen een organisatie. Een voorbeeld van een campagne om mensen bewust te maken, is de website Veilig bankieren. Hier zijn tips en filmpjes te vinden over het herkennen dat iets niet in de haak is met mailtjes of telefoontjes die zogenaamd van je bank afkomstig zijn. Zodra bijvoorbeeld om persoonlijke gegevens wordt gevraagd of om je bankpas terug te sturen naar de bank, moeten de alarmbellen gaan rinkelen. ‘Je bank zal dit soort dingen namelijk nooit van je vragen. Met andere woorden: Hang op! Klik weg! Bel uw bank!’

2.2.2 Opleiden, trainen en oefenen (OTO)

Cyberincidenten kunnen leiden tot een crisissituatie waarbij de veiligheid van mens of milieu niet meer geborgd kan worden. Om een handelingsperspectief te hebben bij een dergelijke crisis, is het belangrijk de organisatie goed voor te bereiden op te nemen stappen. Dit kan door middel van een traject van opleiden, trainen en oefenen (OTO). Een zogeheten OTO-traject is dan ook erg belangrijk in de crisismanagement-structuur. Frequent opleiden, trainen en oefenen dient in een organisatie continu op de agenda te staan.

In 8 Incidentrespons en herstel is meer informatie over incidenten en herstel opgenomen.

Belang van OTO

Binnen de infra neemt het bewustzijn voor cybersecurity toe. Het voldoen aan een van de belangrijkste eisen, ‘een veilig object’, wordt niet alleen bereikt met techniek en redundante oplossingen. Het gaat met name ook over beleid, processen en procedures, zowel tijdens de verschillende realisatiefasen als in de exploitatiefase. Honderd procent veilig bestaat niet en zou ook niet economisch te verantwoorden zijn. Dat geldt ook voor ‘cyberveilig’. Eisen dat men alles op orde heeft, kan dan ook niet. Doelstellingen zijn:

• De risico’s zijn in kaart gebracht en worden beheerd.
• Er is bepaald wat een acceptabel risiconiveau is.
• Het is duidelijk welke beheersmaatregelen moeten worden genomen en waarom.
• Er is een gedegen OT-securitybeleid aanwezig.

Bij het in kaart brengen van de risico’s, bijvoorbeeld via een security assessment, is het belangrijk om de drie aspecten ‘mens’, ‘organisatie’ en ‘techniek’ te onderzoeken. Deze aspecten dienen gezamenlijk benaderd te worden. Alleen dan is cybersecurity op een verantwoorde wijze te managen en zijn verantwoorde kosteneffectieve maatregelen te nemen. Door OTO kan de juiste balans gevonden worden tussen mens, organisatie en techniek.

Ondanks het toenemende bewustzijn bevindt het domein van cybersecurity binnen de infra zich nog in een ontwikkelingsfase. Een ‘cyberroadmap’ met daarin de verbeteringen die men de komende jaren van plan is door te voeren, is daarbij onmisbaar.

Het is vanzelfsprekend dat OTO een essentieel onderdeel uitmaakt van de cyberroadmap. HIerdoor is het mogelijk prestaties te verbeteren en ook – zeker in hectische situaties – cruciale vergissingen te vermijden. Het hebben en het onderhouden van, en het oefenen met kaders en plannen helpt om de continuïteit te waarborgen en vergroot het zelfbewustzijn en het zelfvertrouwen van medewerkers. Hierdoor is het ook mogelijk fouten en omissies in draaiboeken te vinden en te herstellen voordat zich een echte crisis voordoet.

Aandachtspunten OTO-traject

Getraind blijven! Het is belangrijk om het bewustzijn van mensen snel op het gewenste niveau te krijgen. Dit kan uitstekend door middel van een training. Maar: hoe zorg je ervoor dat betrokken personen niet net zo snel weer terugvallen in de oude gewoontes? Het antwoord is: blijven herhalen. Herhalen zorgt ervoor dat de mensen scherp blijven. Dit kan op veel verschillende manieren; enkele voorbeelden:

• Een periodieke herhalingscursus (klassikaal of via e-learning).
• Toolboxmeetings.
• Nieuwsbrieven/mailings.
• Cybersecurityflyers.
• Doordenkers/oneliners/tegelwijsheden.
• Narrowcasting.
• Serious games en quizzen tijdens bijeenkomsten.
• Ervaringen van incidenten delen met de organisatie.

Personeel in een organisatie dient zich bewust te zijn van factoren die in het werkproces kunnen leiden tot een crisis en waarbij vervolgens een passende crisisaanpak noodzakelijk is. Daarnaast is het belangrijk om dan niet alleen de crisisrollen te kennen, maar ook de daarbij behorende handelingsperspectieven en werkwijzen.

2.2 Organisatie

IEC 62443-2-2 en ISO 27002 geven een handreiking voor de rollen en vereisten die voor informatiebeveiliging en cybersecurity belegd moeten worden. In onderstaande figuur staat een voorbeeld van cybersecurityrollen. Deze rollen kunnen belegd worden bij evenzovele specialisten. Zeker bij kleinere projecten/contracten zal het duidelijk zijn dat dit niet haalbaar en ook niet wenselijk is.

Figuur 2.2: Voorbeeld cybersecurityrollen.

Door taken, verantwoordelijkheden en bevoegdheden op het gebied van cybersecurity in de organisatie in te bedden, is het mogelijk gedetecteerde risico’s bij de juiste persoon/probleemeigenaar te beleggen. Zij kunnen helpen om tijdens de risicoanalyse een juiste inschatting te maken van de dreiging en de impact. Wanneer hun expertise niet toereikend is om een goede beoordeling te maken, dienen zij de juiste personen erbij te betrekken, of een opleidingsprogramma te volgen dat ze in staat stelt om wel zelf een beoordeling te maken.

Twee veel voorkomende specifiek ondersteunende rollen:

• Gemandateerde functionaris voor koppelen van apparatuur Er is expliciete toestemming nodig voor elke niet-standaard koppeling van apparatuur. De gemandateerde functionaris bepaalt de kaders voor toestemming, de registratie van te koppelen apparatuur en inzicht in de risico’s, en past de kaders toe.
• Geautoriseerd personeel voor toegang tot loggegevens Voor de toegang tot loggegevens gelden zeer hoge vertrouwelijkheidseisen. Deze gegevens kunnen persoonsgegevens bevatten en daarmee onder de AVG vallen. Daarnaast zullen loggegevens vaak informatie bevatten die kwetsbaarheden van een systeem kunnen onthullen aan een hacker, bv. versie-informatie, IP-adressen, gebruikte protocollen e.d. Aan personen die toegang hebben tot loggegevens of deze verwerken, worden daarom extra eisen gesteld.

Naast de cybersecurity-bewustwording van alle bij de tunnel betrokken personen, moeten er specifieke functionarissen benoemd zijn én gelden er enkele specifieke eisen m.b.t. medewerkers die operationeel zijn bij het beheer van de tunnel (eigen en ingehuurd personeel), zie de hoofdstukken hierna.

Uitbesteed werk

Omdat veel werk wordt uitbesteed, is het noodzakelijk om hier specifieke aandacht aan te besteden. Voor uitbesteed werk is het van groot belang dat de ingeschakelde derde partij alle procedures en maatregelen kent én volgt die voor de interne organisatie gelden. Als het noodzakelijk is om hiervan af te wijken, zorg er dan voor dat deze afwijking gelegitimeerd en vastgelegd wordt, zodat deze afwijkingen altijd traceerbaar en verklaarbaar zijn.

Het is de verantwoordelijkheid van de opdrachtnemer dat herbelegde activiteiten en verantwoordelijkheden aantoonbaar voldoen aan de oorspronkelijk gestelde eisen. Wettelijk blijft de tunnelbeheerder echter hoofdelijk eindverantwoordelijk voor de veiligheid van het object. Hij moet zich vergewissen van de herbelegde activiteiten. Afhankelijk van de aard en omvang van het project/contract zijn zeer veel organisatievormen gangbaar, zie ook hoofdstuk 4 Cybersecuritymanagement.

2.3 Techniek

Het aspect ‘techniek’ betreft alle aanwezige apparatuur, onderdelen, voorwerpen, software, enz. en al datgene dat hier direct mee heeft te maken. Dit zijn dus ook onderhoudscontracten, onderhoudsschema’s, enz. De techniek is een belangrijke aspect voor cybersecurity en vraagt daarom om optimale inzet. Echter, de techniek is niet onfeilbaar en vereist periodieke evaluatie en – indien nodig – aanpassing.

Om cyberrisico’s te beperken, is het noodzakelijk dat tunnelapparatuur (maar ook de door onderhoudsmedewerkers gebruikte hulpmiddelen zoals laptops en datadragers) virusvrij en up-to-date zijn en blijven. Deze noodzaak wordt nog eens versterkt doordat de deelsystemen vaak afkomstig zijn van verschillende leveranciers. De toegangspunten dienen zodanig technisch gefaciliteerd te worden, dat er veilig gewerkt kan worden. Ook dient inzichtelijk te zijn welke installaties toegankelijk zijn van buitenaf (remote access). De praktijk leert dat risico’s niet altijd duidelijk zijn en opgemerkt worden. Zo kan een deelinstallatie voor onderhoudswerkzaamheden gebruikmaken van een (draadloze en internet)toegang. Door middel van dit toegangspunt is het mogelijk dat het totale netwerk benaderbaar is. Door de juiste monitoring toe te passen, kunnen deze kwetsbaarheden worden geïdentificeerd.

Noot: De techniek moet veilig en robuust zijn, maar moet het uitvoeren van onderhouds- en herstelwerk niet onmogelijk maken: anders gaan onderhoudsmedewerkers ‘eromheen’ werken, of blijven reparaties liggen.

3 Wet- en regelgeving

3.1 Overzicht

Het overgrote deel van de wet- en regelgeving op het gebied van cybersecurity is afkomstig van de Europese Unie (EU). De EU is daarmee een belangrijke aanjager voor het tot stand brengen van een gezamenlijk normenkader op het gebied van cybersecurity binnen de EU. De EU heeft hiervoor twee belangrijke instrumenten tot zijn beschikking, namelijk verordeningen en richtlijnen.

Voor verordeningen, zoals de Algemene verordening gegevensbescherming (AVG), geldt dat zij integraal geldend zijn voor alle lidstaten. Voor richtlijnen, zoals de ‘Netwerk- en informatieveiligheidrichtlijn’ (NIB), geldt dat lidstaten deze eerst moeten omzetten naar nationale wetgeving. De NIB is door Nederland omgezet in de Wet beveiliging netwerk- en informatiesystemen (Wbni).

De operationele veiligheidregimes zijn de kaders voor cybersecurity:

• Tunnelveiligheid (tunnelwet, TSI-SRT – technical specifications for interoperability safety in railway tunnels)
• Spoorveiligheid (Spoorwegwet, Wet lokaal spoor)
• Publieksveiligheid, arboveiligheid, milieuveiligheid
• Sociale veiligheid
• etc.

Binnen deze regelgeving is cybersecurity (nog) niet specifiek benoemd, maar een tunnelbeheerder kan de risico’s ten aanzien van cybersecurity niet negeren bij het beheersen van de andere veiligheidsrisico’s. De regelgeving loopt hier kennelijk achter op de werkelijkheid. Het is de verantwoordelijkheid van de tunnelbeheerder om deze manco’s op te vullen.

Voor wegtunnels geldt ook een specifieke tunnelwet. Voor spoortunnels gelden de Spoorwegwet en de Wet lokaal spoor. De organisatie, taken en verantwoordelijkheden voor de tunnelbeheerder, veiligheidsbeambte en bevoegd gezag zijn bij het spoor wettelijk anders ingericht. In de door het COB/KPT opgestelde verkenning Gevolgen inwerkingtreding wet lokaal spoor is een duidelijk schema opgenomen. Ondanks de verschillen, is het overgrote deel van dit groeiboek wel van bruikbaar voor spoortunnels.

De in dit hoofdstuk genoemde wet- en regelgeving heeft als uitgangspunt het beheersen van risico’s. Dit groeiboek biedt daarmee een goed startpunt voor het realiseren van cybersecurity teneinde te voldoen aan de geldende wet- en regelgeving.

3.2 Tunnelwet

In de Wet aanvullende regeling voor wegtunnels (Warvw) en Regeling aanvullende regeling voor wegtunnels (Rarvw) komen diverse rollen aan de orde met betrekking tot veiligheid . Zie voor meer informatie hierover de publicatie Tunnelveiligheid verklaard van het KPT. Een overzicht van belangrijke rollen:

Zoals eerder gezegd geldt de tunnelwet alleen specifiek voor wegtunnels. Voor spoortunnels is er andere wet- en regelgeving (zie boven). De op basis van de tunnelwet te beheersen risico’s gaan over gebeurtenissen in de tunnel. De verplichte risicoanalyse op basis van QRA-Tunnels beschouwt alleen incidenten in de tunnel veroorzaakt door het verkeer en sluit alle van buiten komende risico’s (en dus ook cybersecurity-gerelateerde risico’s) uit. De tunnelbeheerder die ook de risico’s op het gebied van cybersecurity wil beheersen, kan gebruikmaken van de Cybersecurity implementatierichtlijn objecten van Rijkswaterstaat. Er is (nog) geen ondersteuning beschikbaar in de vorm van een programma voor kwantitatieve risicoanalyse.

3.3 Informatiebeveiliging

3.3.1 Baseline informatiebeveiliging overheid (BIO)

SInds 1 januari 2020 is de Baseline informatiebeveiliging overheid (BIO) van kracht voor alle lagen van de overheid. De BIO vervangt de Baseline informatiebeveiliging (BIR), de Interprovinciale baseline informatiebeveiliging (IBI), de Baseline informatiebeveiliging gemeenten (BIG) en de Baseline informatiebeveiliging waterschappen (BIWA). Die BIO is gebaseerd op de internationale normen ISO/IEC 27001 en ISO/IEC 27002 (zie 3.5.1 ISO/IEC 27000-serie).

3.3.2 Wet beveiliging netwerk- en informatiesystemen (Wbni)

De Wet beveiliging netwerk- en informatiesystemen (Wbni) is de Nederlandse implementatie van de Europese richtlijn voor Netwerk- en informatiebeveiliging (NIB-richtlijn) en is per 9 november 2018 in werking getreden. Het doel van de wet en de richtlijn is ervoor te zorgen dat ‘aanbieders van essentiële diensten en digitale dienstverleners passende technische en organisatorische maatregelen nemen om de risico’s van cyberincidenten te beheersen’ (artikel 7) en de bedrijfscontinuïteit te waarborgen. De kans op een cyberincident is te reduceren door het nemen van proactieve, afschrikkende en preventieve maatregelen. Daarnaast verplicht de wet aanbieders om maatregelen (zowel detectief als correctief) te nemen om, wanneer zich toch een cyberincident voordoet, de gevolgen daarvan zoveel mogelijk te beperken (artikel 8).

Aanbieders van essentiële diensten (AED’s) en digitale dienstverleners

De werking van de Wbni beperkt zich tot ‘aanbieders van essentiële diensten en digitale dienstverleners’ (AED’s). De minister van Justitie en Veiligheid wijst de essentiële diensten aan; ze zijn te vinden in het Besluit beveiliging netwerk- en informatiesystemen (Bbni). Het ministerie informeert de betreffende organisaties dat ze zijn aangemerkt als aanbieder van een essentiële dienst.

De minister evalueert op regelmatige basis de lijst van aanbieders van essentiële diensten. In het oorspronkelijke Bbni (geldend vanaf 1 januari 2019) is voor de transportsector alleen een aanwijzing opgenomen voor de divisie havenmeester van het Havenbedrijf Rotterdam en voor dienstverleners betrokken bij de afhandeling van het luchtverkeer. Inmiddels zijn de deelsectoren weg- en spoorvervoer (hoofdwegennet) als vitaal B aangemerkt. De beheerders van bruggen en tunnels inclusief bediening in het rijkswegen/spoornet zijn nu als AED’s aangewezen en vallen onder de Wbni.

Digitale dienstverleners moeten zelf bepalen of ze onder de werking van de Wbni vallen. Dit is het geval als:

• het gaat om een online marktplaats, zoekmachine en/of cloud dienstverlener; met
• 50 of meer werknemers in dienst of een balanstotaal of jaaromzet van €10 miljoen; en
• een Europese hoofdvestiging in Nederland of een vertegenwoordiging in Nederland.

Zorgplicht

De wet legt een zorgplicht op aan organisaties die onder de werking van de Wbni vallen. Deze organisaties moeten maatregelen nemen om de risico’s voor de beveiliging van hun netwerk- en hun informatiesystemen te beheersen. De maatregelen moeten dus zijn afgestemd op de specifieke risico’s die voor de betreffende organisatie gelden. Over specifieke maatregelen laat de wet zich niet uit. De wet stelt dat bij het bepalen van de maatregelen in ieder geval met de volgende aspecten rekening moet worden gehouden:

• De beveiliging van systemen en voorzieningen.
• Behandeling van incidenten.
• Het beheer van de bedrijfscontinuïteit.
• Toezicht, controle en testen.
• Inachtneming van internationale normen.

Daarnaast moet een organisatie passende maatregelen nemen om cyberincidenten, die de beveiliging aantasten, te voorkomen en de gevolgen hiervan zoveel mogelijk beperken.

Meldplicht

Naast een zorgplicht kent de Wbni ook een meldplicht. Organisaties die onder de werking van de wet vallen, zijn in bepaalde gevallen verplicht om een cyberincident te melden. Zo moet een organisatie een incident melden wanneer dit incident ‘aanzienlijke gevolgen’ heeft of kan hebben voor de continuïteit van de geleverde dienst.

Of er sprake is van een incident met aanzienlijke gevolgen is afhankelijk van een aantal factoren:

• Het aantal gebruikers dat door de verstoring van de dienst wordt getroffen.
• De duur van het incident.
• De omvang van het geografisch gebied dat door het incident is getroffen.

Als een incident aanzienlijke gevolgen heeft voor de continuïteit van een dienst maar niet valt

onder de meldplicht, kan de betrokken dienstverlener dat incident melden. Een vrijwillige melding hoeft niet in behandeling te worden genomen, maar kan wel worden doorgestuurd naar een crisisteam.

3.3.3 Algemene verordening gegevensbescherming (AVG)

Cybersecurity faciliteert naast beschikbaarheid en veiligheid ook privacy. De uitvoeringswet Algemene verordening gegevensbescherming (AVG), of in het Engels GDPR, heeft betrekking op de verwerking van persoonsgegevens van natuurlijke personen. De AVG geeft regels waaraan dit soort verwerkingen moeten voldoen.

Definitie persoonsgegeven

De AVG hanteert in artikel 4 een brede definitie van het begrip ‘persoonsgegeven’. Samengevat komt erop neer dat alle informatie die te herleiden is tot een natuurlijk persoon geldt als een persoonsgegeven. Dit kunnen onder andere kentekens zijn, camerabeelden, informatie uit logbestanden en, met opkomst van smart mobility, ook gegevens die een voertuig uitwisselt met de omliggende infrastructuur. Praktisch gezien zijn persoonsgegevens in de context van dit groeiboek bijvoorbeeld: camerabeelden van personen en kentekens, audio-opnames en inloggegevens van medewerkers.

Ook de context van de gegevens kan belangrijk zijn. Het koppelen van verschillende anonieme gegevens kan als resultaat een persoonsgegeven opleveren, omdat de combinatie van gegevens dermate uniek is dat deze is te herleiden naar een natuurlijk persoon.

Definitie verwerking

De AVG hanteert niet alleen een brede definitie van het begrip persoonsgegeven, ook het begrip ‘verwerking’ wordt breed geïnterpreteerd. Onder de verwerking schaart de AVG vrijwel iedere handeling met betrekking tot persoonsgegevens. Het gaat in ieder geval om verzamelen, vastleggen, ordenen, structureren, opslaan, bijwerken of wijzigen, opvragen, raadplegen, gebruiken, doorzenden, verspreiden, beschikbaar stellen, samenbrengen, met elkaar in verband brengen, afschermen, wissen en vernietigen van gegevens.

Doel en grondslag

Wanneer sprake is van een verwerking van persoonsgegevens stelt de AVG dat een legitiem doel en een grondslag noodzakelijk zijn. Verwerken van persoonsgegevens zonder legitiem doel en wettelijke grondslag is een no-go. Voor tunnelbeheerders is het doel te vinden in het zorgen voor een veilige doorstroming van het verkeer in de tunnel. De wettelijke grondslag is te vinden in de wettelijke taak van de wegbeheerder.

Naast doel en grondslag is dataminimalisatie een belangrijk thema binnen de AVG. Dit betekent dat niet méér persoonsgegevens mogen worden verwerkt dan noodzakelijk zijn voor het doel, maar het betekent ook dat persoonsgegevens niet langer dan noodzakelijk mogen worden bewaard.

Beveiliging van persoonsgegevens

De AVG eist dat de verwerkingsverantwoordelijke de juiste technische en organisatorische maatregelen neemt om een passend beveiligingsniveau te waarborgen. Wat die maatregelen zijn, is afhankelijk van de huidige stand der techniek: wat nu als een passende maatregel geldt, is over een jaar misschien niet meer passend. Daarnaast is een passend beveiligingsniveau ook afhankelijk van de risico’s die met de verwerking gepaard gaan. Bij deze risicoanalyse gaat het om de risico’s die de natuurlijke persoon loopt van wie de gegevens worden verwerkt.

Daarnaast geeft de AVG in artikel 32 een aantal verplichte beveiligingsmaatregelen:

• Pseudonimisering en versleuteling van persoonsgegevens.
• Het vermogen om op permanente basis de vertrouwelijkheid, integriteit, beschikbaarheid van de persoonsgegevens te garanderen.
• Het vermogen om bij een fysiek of technisch incident de beschikbaarheid van en de toegang tot de persoonsgegevens te herstellen.
• Een procedure voor het op gezette tijden beoordelen van de doeltreffendheid van de technische en organisatorische maatregelen te beoordelen.
• Een procedure voor het op verzoek van de natuurlijke persoon verwijderen van zijn/haar persoonsgegevens.

Meldplicht datalekken

De AVG kent een meldplicht wanneer sprake is van een datalek. In de volgende gevallen is sprake van een datalek:

• Inbreuk op de vertrouwelijkheid: wanneer sprake is van een onbevoegde of onopzettelijke openbaring van, of toegang tot, persoonsgegevens.
• Inbreuk op integriteit: wanneer sprake is van een onbevoegde of onopzettelijke wijziging van persoonsgegevens.
• Inbreuk op beschikbaarheid: wanneer sprake is van een onbevoegd of onopzettelijk verlies van toegang tot, of vernietiging van persoonsgegevens.

Volgens de bovenstaande definitie is bijvoorbeeld het onbedoeld verwijderen van camerabeelden een datalek.

Wanneer sprake is van een datalek, moet de verwerkingsverantwoordelijke dit vastleggen in zijn datalekregister. Daarnaast kan het zijn dat de verwerkingsverantwoordelijke het datalek moet melden bij de Autoriteit Persoonsgegevens. Dit is echter alleen noodzakelijk als het datalek leidt tot een risico voor de rechten en vrijheden van betrokkenen. Het is daarom belangrijk om bij het constateren van een datalek meteen de functionaris gegevensbescherming van de organisatie te betrekken (zie kader).

3.4 Overige regelgeving

Naast de AVG en de Wbni bestaat nog andere wet- en regelgeving die invloed heeft op de cybersecurity van een tunnel. Zo gelden voor de rijksoverheid nog de volgende regelingen:

• Voorschrift Informatiebeveiliging Rijksdienst (VIR).
• Voorschrift Informatiebeveiliging Rijksdienst – Bijzondere Informatie (VIR-BI). Het VIR-BI benadrukt de zorgplicht van ieder departement en van diens lijnmanagement voor de beveiliging van bijzondere informatie bij de rijksdienst. Het VIR-BI is te beschouwen als een aanvulling op het VIR. Het VIR-BI, hoewel geschreven voor de rijksdienst, bevat prima aanvullingen die ook voor gemeenten en provincies te gebruiken zijn bij de bescherming van bijzondere informatie. Met de toenemende vervlechting van processen en informatie dienen er op termijn een soortgelijk voorschrift, bijvoorbeeld een classificatie-voorschrift, en maatregelen voor gemeenten te komen.
• Cybersecurity implementatierichtlijn objecten RWS (CSIR). Deze CSIR is een door Rijkswaterstaat opgestelde nadere invulling gebaseerd op onder meer de BIO en bevat specifieke voorschriften voor de objecten die in beheer zijn bij Rijkswaterstaat. In 2020 heeft Rijkswaterstaat gewerkt aan een update van CSIR om deze enerzijds in lijn te brengen met de BIO en anderzijds meer maatregelen uit IEC 62443 op te nemen. De nieuwe versie is in 2021 verschenen.

3.5 Internationale normen

Voor cybersecurity bestaan internationale en nationale normen. Een belangrijke voor informatietechnologie (IT) is de ISO 27000-serie. Het IEC 62443-normenkader is voor de operationele technologie (OT), wat de ISO 27000 serie is voor de IT.

3.5.1 ISO/IEC 27000-serie

De Internationale standaardisatie-organisatie (ISO) heeft een hele reeks aan normen opgesteld rond het onderwerp van het beveiligen van informatie. De belangrijkste daarvan zijn:

• ISO/IEC 27001 Information Security Management Deze norm beschrijft een managementsysteem om de veiligheid van de informatie van een organisatie te borgen; het zogenaamde information security management system, ISMS. Organisaties kunnen hun ISMS laten certificeren tegen deze norm.
• ISO/IEC 27002 Code of Practice for Information Security Controls Deze norm beschrijft een verzameling maatregelen die ingezet kunnen worden ten behoeve van het ISMS. Welke maatregelen gekozen worden, hangt af van de uitkomst van een informatie-risicoanalyse.
• ISO/IEC 27003 Guidance Deze norm geeft richtlijnen en handvatten voor het implementeren van een ISMS.
• ISO/IEC 27004 Monitoring, Measurement, Analysis and Evaluation Deze norm beschrijft methoden en technieken om de effectiviteit van de maatregelen die ten behoeve van het ISMS zijn genomen, te beoordelen.
• ISO/IEC 27005 Information Security Risk Management Deze norm geeft richtlijnen voor het risicomanagement dat bij een ISMS hoort.
• ISO/IEC 27035 Incident Management Deze norm geeft richtlijnen voor het plannen van een voorbereiden op incidentrespons.
• ISO/IEC 27701 Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines Deze norm specificeert eisen voor en geeft hulp bij het uitbreiden van een ISMS ten behoeve van de bescherming van privacygevoelige gegevens. Het volgen van deze norm is nodig, maar niet voldoende voor het voldoen aan de AVG.

3.5.2 IEC 62443

De normenreeks IEC 62443 bestaat uit veertien delen, waarvan er tot nu toe acht zijn gepubliceerd. Onderstaande figuur geeft een overzicht. De standaard hanteert de afkorting IACS (industrial automation and control systems) in plaats van de term operationele technologie (OT).

Figuur 3.1: Overzicht van de normenreeks IEC 62443. (Bron: IEC)

De normreeks kent vier ‘lagen’ die gericht zijn op verschillende doelgroepen:

1. 1. IEC 62443-1-x General – Vier delen met algemene, voor alle doelgroepen toepasbare, informatie.
      • IEC TS 62443-1-1 Concepts and Models (gepubliceerd) – Beschrijft de concepten en modellen in de standaard.
      • IEC TR62443-1-2 Master Glossary of terms and abbreviations – Dit technische rapport zal de beschrijving van alle in de normenreeks gebruikte termen en afkortingen bevatten.
      • IEC 62443-1-3 System Security Conformance metrics – Dit normdeel zal een serie kwantitatieve metrieken beschrijven die afgeleid zijn van de fundamentele eisen, systeemeisen en verbonden eisen.
      • IEC TR62443-1-4 IACS security life-cycle and use-cases – Dit technische rapport zal een meer gedetailleerde beschrijving geven van de levenscyclus voor IACS-security. Tevens zullen verschillende usecases worden beschreven om de verschillende toepassingen te illustreren.
   2. IEC 62443-2-x Policies & Procedures – Deze normenreeks is gericht op de eigenaren van assets en beschrijft een cybersecuritymanagementsysteem (CSMS) en alles wat daarvoor nodig is.
      • IEC 62443-2-1 Requirements for an IACS security Management System (gepubliceerd) – Dit normdeel beschrijft wat nodig is om een CSMS voor OT te definiëren en te implementeren. Dit normdeel heeft verwantschap met ISO 27001. Het is gericht op asseteigenaren en aanbieders van oplossingen.
      • IEC 62443-2-2 IACS Security Program Rating – Deze norm zal een manier beschrijven om de kwaliteit van het veiligheidsprogramma te meten, gebaseerd op mogelijkheden van de technische maatregelen gecombineerd met de volwassenheid van de organisatie om procedurele maatregelen in de praktijk toe te passen.
      • IEC TR62443-2-3 Patch management in the IACS environment (gepubliceerd) – Dit technische rapport beschrijft hoe patch-management kan worden toegepast in een OT-omgeving. Het zal worden herschreven als een standaard. Het is gericht op asseteigenaren en aanbieders van oplossingen
      • IEC 62443-2-4 Security program requirements for IACS service providers (gepubliceerd) – Dit normdeel beschrijft de eisen waaraan OT-service providers moeten voldoen. Het is gericht op aanbieders van oplossingen zoals fabrikanten, systeem-integratoren en wederverkopers.
      • IEC TR62443-2-5 Implementation guidance for an IACS security Management System – Dit normdeel beschrijft wat nodig is om een effectief CSMS te hebben, en heeft verwantschap met ISO 27003.
   3. IEC 62443-3-x System – Deze normenreeks is gericht op system integrators en beschrijft welke technieken moeten worden toegepast om het juiste niveau van security te kunnen bereiken.
      • IEC TR 62443-3-1 Security technologies for IACS (gepubliceerd) – Dit technische rapport beschrijft de toepassing van verschillende beveiligingstechnieken in een OT-omgeving.
      • IEC 62443-3-2 Security risk assessment and system design – Dit normdeel beschrijft hoe om te gaan met veiligheidsrisicoanalyse en systeemarchitectuur. Het introduceert de termen ‘zones’ en ‘conduits’. Het is gericht op asseteigenaren en aanbieders van oplossingen.
      • IEC 62443-3-3 System security requirements and security levels (gepubliceerd) – In dit normdeel worden de foundational requirements (FR) en security assurance levels (SL) beschreven. Voor elke FR zijn één of meerdere security requirements (SR) gedefinieerd en wordt aangegeven welke SR voor welk SL van toepassing is. Het is gericht op asseteigenaren en aanbieders van oplossingen
   4. IEC 62443-4-x Component – Deze normenreeks is gericht op de leveranciers van componenten die gebruikt worden om een systeem mee samen te stellen. Onderwerpen zijn eisen aan het ontwikkelen van producten en de beveiligingseisen die aan componenten gesteld moeten worden.
      • IEC 62443-4-1 Product development (gepubliceerd) – Dit normdeel beschrijft de afgeleide eisen die van toepassing zijn voor het ontwikkelen van producten. Het is gericht op aanbieders van oplossingen zoals fabrikanten, systeem-integratoren en wederverkopers.
      • IEC 62443-4-2 Technical security requirements for IACS components (gepubliceerd) – Dit normdeel bevat de versameling van afgeleide eisen die de SR’s vertalen naar deelsystemen en componenten van het system under consideration. Het is gericht op aanbieders van oplossingen zoals fabrikanten, systeem-integratoren en wederverkopers.

3.6 Cybersecurity en tunnelveiligheid

Een ogenschijnlijk (en op papier) veilige tunnel kan wel degelijk onveilig zijn zonder dat de verantwoordelijke tunnelbeheerder en zijn veiligheidsbeambte zich daarvan bewust zijn. Dat komt doordat cybersecurity vooralsnog geen onderdeel is van het toetskader voor tunnelveiligheid zoals bedoeld in de tunnelwet. In een separate memo, te downloaden van de COB-kennisbank, geeft de werkgroep Cybersecurity van het COB nadere toelichting op de relatie tussen cybersecurity en veiligheid in het algemeen en tunnelveiligheid in het bijzonder. >> Publicatie Cybersecurity en tunnelveiligheid op de kennisbank .

4 Cybersecuritymanagement

Door taken, verantwoordelijkheden en bevoegdheden op het gebied van cybersecurity in de organisatie in te bedden, maakt cybersecurity onderdeel uit van de standaard processen van de organisatie. Dit dient drie doelen:

1. 1. 1. Het onderkennen van cybersecurityrisico’s.
      2. Het formuleren van maatregelen en deze te beleggen bij de juiste personen met vakkennis, zodat de maatregelen op een juiste wijze worden geïmplementeerd.
      3. Het toetsen aan wet- regelgeving en veranderende dreigingen van de instandhouding en evaluatie van maatregelen.

4.1 Cybersecuritymanagementsysteem (CSMS)

Een cybersecuritymanagementsysteem (CSMS) kan helpen om cybersecurity voor de OT-omgeving op gestructureerde en valideerbare wijze te managen en te borgen binnen een OT-organisatie. Een CSMS bestaat uit een set van plannen, rapportages, maatregelen, instructies, beleid, procedures en evaluatieprocessen die de organisatie helpt om aandacht te hebben voor cybersecurity zonder het overzicht te verliezen. Bij een CSMS hoort een periodieke toetsing van de overeenstemming met en effectiviteit van het CSMS.

Kenmerkend aan infrawerken en tunnels is het feit dat er sprake is van een of meer leveranciers, een gebruikersorganisatie en een regie- of beheerdersorganisatie. Een en ander is afhankelijk van de contractvorm (zie paragraaf hierna). Het CSMS kan dan gedistribueerd zijn over deze partijen, maar dient altijd als één geheel te functioneren.

Opmerking: In organisaties waar bedrijfsbreed al een information security management system (ISMS) van kracht is, is het handiger om daar bij aan te sluiten. In organisaties waar de automatisering voornamelijk uit OT-systemen bestaan, is een CSMS conform IEC 62443 te overwegen.

4.2 Contractvormen

De contractvorm heeft invloed op de organisatie van cybersecurity. De meest gebruikte contractvormen in de infrastructuur zijn:

1. 1. 1. Design, build, finance, maintain (DBFM)
      2. Design, build, finance, maintain, operate (DBFMO)
      3. Design and construct (D&C)
      4. Engineering and construct (E&C)
      5. Prestatiecontract (PC)

Deze contractvormen onderscheiden zich in de mate waarin de fasen ontwerp, realisatie en onderhoud zijn opgenomen in het contract. Voor cybersecurity heeft dat gevolgen voor de invloed die de opdrachtnemer heeft op de invulling van de cybersecurity-maatregelen. Bij D&C – en nog sterker bij E&C – bepaalt de opdrachtgever de organisatorische en (een deel van) de technische maatregelen. De primaire coördinatie van de cybersecurity-activiteiten ligt dan ook bij de opdrachtgever. De uitvoering van specifiek genoemde activiteiten wordt daarentegen bij de opdrachtnemer belegd. Bij DBFM en DBFMO vult de opdrachtnemer de gehele organisatie in, waarbij de opdrachtgever een toetsende rol heeft.

Prestatiecontracten zijn gericht op het beheren van een object of areaal en omvatten geen ontwerp- en realisatiewerkzaamheden. In dit contract is het aan de opdrachtnemer om minstens de bestaande beveiligingsmaatregelen in stand te houden.

4.3 Organisatievorm gedurende levenscyclus

In de diverse fasen van de levenscyclus van een object zijn verschillende organisatievormen van toepassing. Zo kennen we voor productontwikkeling productgroepen, voor bouwprojecten een ontwerp- en realisatietraject conform het V-model uit de systems engineering (zie ISO 15288) en voor instandhouding (inclusief de sloopfase) de PDCA-cyclus. Onderstaande figuur illustreert deze verschillende vormen. De organisatievorm heeft directe gevolgen voor de taken van de cybersecurity-functionarissen.

Figuur 4.1: Organisatievormen gedurende de levenscyclus van een object.

Cybersecurity is een integraal onderdeel van al deze activiteiten en werkzaamheden. Het is van belang de overgang tussen de fasen als risico te erkennen en hier tijdig op in te spelen. Zo is het bijvoorbeeld aan te bevelen de beheerder reeds vroeg in de ontwikkel- en ontwerpfase te laten aansluiten.

Om de relatie met cybersecurity op een duidelijker wijze weer te geven, is een relatieschema opgesteld, zie hieronder.

Figuur 4.2: Relatieschema cybersecurity.

Onderstaande tabel geeft een toelichting op de taken en verantwoordelijkheden behorende bij het relatieschema.

De invulling van de organisatie is afhankelijk van de omvang en de complexiteit van de scope (nieuwbouw, renovatie, onderhoud en sloop). Een aantal organisatiemodellen is beschreven in IPM (Rijkswaterstaat) en ISO 55000 (assetmanagement).

4.4 Basis-organisatiemodel voor cybersecurity

Onderstaand overzicht toont de cybersecurityrollen in elke fase van de levenscyclus. Afhankelijk van de omvang van het werk kunnen, in een bepaalde fase, meerdere rollen vallen onder de cybersecuritycoördinator.

4.5 Tips voor een geoliede samenwerking

4.6 Praktijkvoorbeeld: TBV-matrix voor een wegtunnel

Onderstaande TBV-matrix (taken, bevoegdheden en verantwoordelijkheden) geeft een voorbeeld van een rolverdeling tussen een opdrachtgever en opdrachtnemers bij een tunnelproject. Er is geprobeerd een praktische invulling te geven op basis van een gezamenlijke verantwoordelijkheid van opdrachtnemer en opdrachtgever met een oog op het resultaat waarbij kennis en kunde van alle partijen optimaal worden ingezet.

Drie opmerkingen vooraf:

1. 1. 1. Per contract/organisatie/object is de invulling verschillend. De tabel is vooral bedoeld om het gesprek hierover aan te gaan met alle betrokken partijen.
      2. De tabel probeert een balans te geven tussen enerzijds bewust aansprakelijk zijn (zoals de tunnelbeheerder voor veel aansprakelijk is), en anderzijds de verantwoordelijkheid voor de daadwerkelijke uitvoering van taken.
      3. Cyberincidenten overstijgen al gauw de context van het contract. Op directieniveau zijn afspraken nodig over hoe om te gaan met de impact op objecten buiten de scope, en met de gevolgen van externe incidenten.

Figuur 4.3: Voorbeeld TBV-matrix op basis van DBFM-contractvorm. De matrix is ook op groter formaat te downloaden.

De opdrachtgever geeft in de aanbesteding de juiste kaders mee. Daarna krijgt de opdrachtgever de rol van een ‘betrokken toetser’ en ‘adviseur met bijbehorende verantwoordelijkheden’. De opdrachtnemer stelt in de ontwerpfase de plannen en instructies op in samenwerking met alle specialisten. Belangrijke rollen liggen bij procesmanagement en bij de ICT-inrichting van de werkomgeving van de opdrachtnemer. In de realisatiefase worden de technische maatregelen uitgevoerd en gevalideerd. Het proces van het opstellen van toestandrapportages, jaarlijks evalueren, auditen en updaten van de risicoanalyses vindt tijdens de operationele fase plaats.

4.7 Cybersecurity-risicomanagement

Cybersecurity-risicomanagement dient ter beheersing van de risico’s van beveiligingsincidenten over de gehele levenscyclus van een OT-systeem. Dit proces begint – na het afleiden van de cybersecurity-doelstellingen uit de operationele doelstellingen van de operatie – met de cybersecurity-risicoanalyse. Deze analyse is een onderdeel van het ontwerpproces en is uit te voeren voor alle fasen van de levenscyclus van een OT-systeem: van nieuwbouw, onderhoud, renovatie tot sloop (wat gebeurt er met oude data, verbindingen, organisatie, mensen, etc.?). De analyse dient maatregelen in kaart te brengen die aansluiten op een reëel dreigingsbeeld en/of de kwetsbaarheid van het (bestaande) systeem en organisatie. Het gaat hierbij om cybersecurity-maatregelen die bruikbaar en betaalbaar (efficiënt en effectief) zijn en die de doelstellingen van het systeem en de beoogde operatie faciliteren.

De ontwerpkeuzes zijn afwegingen tussen de (vaak tegenstrijdige) aspecten als: de technische mogelijkheden en beperkingen, de operationele bruikbaarheid, de organisatorische en financiële beperkingen en menselijke aspecten. Maatregelen kunnen zowel preventief als correctief zijn: ze zijn bedoeld om de kans te verminderen op het optreden van een cyberincident en – als een incident toch optreedt – het effect op het systeem en de impact op de operatie te verminderen. De cybersecurity-risicoanalyse maakt inzichtelijk wat de restrisico’s en de herstelmaatregelen van het systeem en de operatie zijn.

Cybersecurity-risicomanagement dient te zijn ingebed in het assetmanagement van een specifiek systeem (object of asset) en dient dus een geïntegreerd onderdeel te vormen van assetmanagement. De ISO 55000 is een bruikbare richtlijn voor assetmanagement en betreft alle levenscycli van een asset.

4.8 Quickscan voor ‘cybervolwassenheid’

Voor veel assetmanagers en assetowners is cybersecurity nog minder bekend terrein. Om hierover met elkaar in gesprek te gaan, is door het COB de Quickscan cybersecurity tunnel opgesteld. Deze quickscan biedt aan de hand van 21 vragen globaal inzicht in de sterktes en zwaktes van de organisatie of het object op het gebied van cybersecurity. De quickscan kan worden gebruikt voor een specifiek object of (deel)organisatie binnen het domein van de infrastructuur. Door de vragenlijst gezamenlijk in te vullen, ontstaat een eerste beeld van belangrijke aandachtspunten vanuit het oogpunt van cybersecurity, en hoe het betreffende object of de organisatie daarop scoort. Omdat de quickscan op globaal niveau inzicht geeft, is deze vooral bedoeld als inleiding voor verder gesprek om op specifieke punten concreter in te zoomen. Het is raadzaam om u bij het doorlopen van de quickscan te laten begeleiden door experts op het gebied van cybersecurity, van binnen uw organisatie, of daarbuiten.

5 Logging en monitoring

5.1 Waarom logging en monitoring?

Ondanks alle maatregelen is het onmogelijk om cyberincidenten geheel te voorkomen. Bovendien wordt meestal een zeker restrisico geaccepteerd. Monitoring van de technische systemen dient om continu de status van de digitale veiligheid in de gaten te houden. Hierdoor is het mogelijk nieuwe kwetsbaarheden te signaleren en cyberincidenten beter te detecteren en af te handelen.

Het doel van monitoring is afwijkend gedrag te onderkennen om incidentdreiging te detecteren, cybersecurity gerelateerde gebeurtenissen vast te leggen en eventueel bewijs hiervan te verzamelen. Dit kan uiteraard pas nadat het ‘normale’ gedrag is vastgesteld. De Baseline Informatiebeveiliging Overheid (BIO) vraagt maatregelen om aan deze doelstelling te kunnen voldoen. De verantwoordelijkheid voor het voldoen aan de BIO, waaronder securitymonitoring, ligt bij de beheerder.

Waar het rapport Cybersecuritybeeld Nederland 2019 liet zien dat het in 2018 gemiddeld 78 dagen duurde voordat werd opgemerkt dat een inbreuk was gemaakt op het systeem, is dat in 2019 volgens Cybersecuritybeeld Nederland 2020 gedaald naar 56 dagen. Dat staat nog steeds in schril contrast met de gemiddelde tijd die een aanvaller nodig heeft; die wordt slechts in uren gemeten. Het is en blijft dus noodzakelijk dat voldoende detectie- en preventiemaatregelen zijn genomen om het systeem en de processen goed te monitoren en testen. Hierbij valt te denken aan:

1. 1. • Hoe goed je SOC is.
      • Hoe snel je patcht.
      • Hoe snel je reageert op een incident.
      • Hoe snel je dreigingsinformatie kunt verwerken.
      • Hoe je met een crisis omgaat.

Een afgestemd en vastgesteld escalatiemodel zal naar verwachting het sneller melden en escaleren van afwijkend gedrag ondersteunen en er toe bijdragen dat een incident eerder en beter kan worden opgelost.

Voor de inrichting van monitoring heeft het Nationaal cybersecuritycentrum de Handreiking voor implementatie van detectie-oplossingen beschikbaar gesteld.

5.2 Implementatie van logging en monitoring

Voor de implementatie van logging en monitoring volgt hieronder op hoofdlijnen een opsomming van maatregelen waaraan men zou kunnen denken. Daarbij geldt dat de loggegevens lokaal op een apparaat (computer, switch, etc.) staan. Het is aan te bevelen deze centraal op te slaan op een logserver. Daarnaast moeten zowel de lokale als de centrale bestanden met loggegevens worden beschermd tegen onbevoegd veranderen of verwijderen.

6 Risicogestuurde aanpak

Er zijn verschillende manieren om te komen tot maatregelen voor cybersecurity. Deze staan beschreven in de eerste paragraaf van dit hoofdstuk. In de overige paragrafen wordt dieper ingegaan op de risicogestuurde aanpak. Deze aanpak stelt stakeholders in staat de digitale weerbaarheid van een object of project continu te beoordelen en aan te passen aan de actualiteit. Dit gebeurt door processen zodanig te optimaliseren dat tijdig de juiste maatregelen worden genomen om cyberincidenten en/of opgetreden effecten en gevolgen van incidenten te mitigeren.

6.1 Aanpak voor het bepalen van maatregelen

Er is sprake van een regelgestuurde aanpak als er voor een bepaalde dreiging een vooraf vastgestelde set van maatregelen voorhanden is. Voorbeelden hiervan zijn de BIO en de standaarden ISO 27001 en ISO 27002. Deze bevatten gezamenlijk ongeveer 340 (generieke) technische en organisatorische maatregelen die bij een bepaald incident of dreiging van toepassing zijn. Het voordeel van een dergelijke aanpak is dat het stellen van eisen aan cybersecurity eenvoudig is. Het nadeel is dat voor zowel de opdrachtgever als de opdrachtnemer op voorhand niet duidelijk is wat het wenselijke beveiligingsniveau is voor de specifieke operatie en dat er verwarring en onenigheid ontstaat over de inschatting van dreiging, maatregelen en restrisico’s. De one-size-fits-all-aanpak leidt dan ook vaak tot een ongenuanceerde veelheid aan (overbodige en kostbare) maatregelen. De opdrachtgever voegt daarom vaak de regel ‘comply-or-explain’ toe aan de eisen om een vorm van schaalbaarheid te introduceren.

Een risicogestuurde aanpak is in feite maatwerk. Deze aanpak faciliteert situationele risicosturing en bewerkstelligt dat de reactie precies voldoende is (niet te veel en niet te weinig) voor de beoogde operatie, de situationele dreiging, de operationele doelstelling (effectief) en de geaccepteerde restrisico’s. Daarmee wordt de operatie tegen zo min mogelijke kosten beschermd (efficiënt). Dit is een ideale aanpak in geval van nieuwe en one-of-a-kind systemen.

Een ander kenmerk van deze aanpak is dat de opdrachtgever zelf vooraf de bedoelde operatie, de operationele doelstellingen, de te accepteren restrisico’s (c.q. incidenten), cybersecuritydoelstelling en -eisen vaststelt voor de opdrachtnemer. Bij deze aanpak vereist dan ook een actief beheer van maatregelen: waarom zijn voor welke risico’s welke maatregelen toe te passen? Periodiek moet de lijst opnieuw worden bekeken of het risico is veranderd en/of de (en welke) maatregel moet worden aangepast.

Een nadeel van deze aanpak is dat op voorhand de beveiligingskosten moeilijk zijn te voorspellen. Een voorwaarde voor deze aanpak is daarom dat zowel opdrachtgever als opdrachtnemer wederzijds transparantie betrachten en hetzelfde volwassenheidsniveau hebben om deze onzekerheid samen te managen, én dat de opdrachtgever voldoende budget reserveert.

Er is sprake van een classificatiegestuurde aanpak als op alle systemen met dezelfde dezelfde beveiligingsklasse (bijvoorbeeld zeer-kritisch, kritisch en minder-kritische operatie) dezelfde maatregel van toepassing is. Dit is mogelijk in een omgeving met veel vergelijkbare systemen. De opdrachtgever deelt (op basis van een generieke risicoanalyse) de verschillende systemen in beveiligingsklassen in en stelt voor elke beveiligingsklasse een (vaste) set maatregelen vast. Afwijkingen kunnen op basis van ‘comply-or-explain’ plaatsvinden. In feite is deze aanpak een combinatie van de beide andere aanpakken. CSIR is een voorbeeld van een dergelijke aanpak.

Een voordeel van een dergelijke aanpak is dat de opdrachtgever zelf het wenselijke beveiligingsniveau vaststelt en er minder variaties zijn in maatregelen. Een classificatiegestuurde aanpak kan dezelfde nadelen hebben als een risicogestuurde aanpak. De volwassenheid aan beide zijden is ook hier van belang, maar in geringere mate.

In de praktijk is er vaak sprake van een combinatie van deze verschillende aanpakken.

6.2 Basisprincipes

Soorten risico’s

Het is belangrijk te realiseren dat er twee soorten risico’s bestaan. Ten eerste brengt het product risico’s met zich mee, bijvoorbeeld door de geautomatiseerde bediening of het bewaken en besturen van een tunnel, brug of sluis. Anderzijds levert het project of de uitvoering zelf ook risico’s op. Dit hoofdstuk gaat eerst in op de risico’s van het product, daarna op de risico’s van het project.

Gelaagde beveiliging

De basis voor het inventariseren van de situatie en de te definiëren maatregelen is het concept van een integrale gelaagde beveiliging, defense in depth, zie de figuur hieronder. Elke beveiligingslaag vertegenwoordigt een deel van het geheel. Omdat de onderdelen per laag verschillen, zijn ook de te nemen maatregelen verschillend. Het nemen van verschillende maatregelen zorgt ervoor dat een zwakte in de ene laag gecompenseerd kan worden door een maatregel in een andere laag. Door voor elke laag een adequate beveiliging te creëren, ontstaat een beveiligingsconcept dat opeenvolgend zorgt voor de beveiliging van de kern. Het voordeel van deze stapeling van beveiligingslagen is dat de kans op een verstoring van het geheel kleiner wordt doordat er verschillende beveiligingen moeten falen om het geheel te doen falen.

Figuur 6.1: Schematische weergave beveiligingslagen.

Afwegingen

Naast de risicoanalyse worden ook vaak een kosten-batenanalyse en een analyse van de operationele doelstellingen uitgevoerd. Op voorhand hoeft namelijk niet ieder risico te worden afgedekt: wanneer de kosten van de maatregelen om een risico te beperken hoger zijn dan de mogelijke schade of letsel ten aanzien van de gestelde operationele doelen (veiligheid, beschikbaarheid en privacy), dan is het ook mogelijk het risico te accepteren. Dit heet dan het restrisico.

Het is noodzakelijk het geheel of gedeeltelijk afdekken of accepteren van risico’s in overeenstemming te brengen met de risicobereidheid van de organisatie en de mogelijkheden van de organisatie om operationele incidenten te kunnen absorberen. Het permanent of periodiek uitvoeren van risicoanalyses is daarom een voorwaarde voor een goed cybersecuritybeleid. Dit staat bekend als risicomanagement (ook wel risk management of risk control genoemd). Zie ook 4 Cybersecuritymanagement.

Risicostrategie

Welke risicostrategie een organisatie hanteert, hangt sterk samen met de vraag welk risiconiveau acceptabel is. Algemeen worden de volgende strategieën onderkend:

1. 1. • Vermijden Door bepaalde activiteiten niet te doen, kun je de risico’s die die activiteiten met zich meebrengen vermijden. Bijvoorbeeld: door geen USB-stick te gebruiken, wordt het risico dat een virus vanaf een USB-stick de installatie binnendringt voorkomen.
      • Verminderen Door het nemen van maatregelen wordt het risiconiveau verlaagd. Dit kunnen proactieve maatregelen zijn die de kans van optreden verkleinen of reactieve maatregelen die de gevolgen van het optreden van het risico kleiner maken, of een combinatie daarvan.
      • Accepteren Als het risiconiveau lager is dan wat acceptabel wordt gevonden, óf als een maatregel een grotere negatief effect heeft dan het optreden van het risico, kan gekozen worden het risico te accepteren. Het accepteren van risico’s moet altijd door hoger management worden bekrachtigd.
      • Overdragen Het is ook mogelijk om een situatie door derden te laten overnemen als een dreiging zich voordoet (outsourcen), of het risico te verzekeren.
      • Exploiteren Als het gevolg van een risico een positief effect heeft, kun je daar gebruik van maken. Voor cybersecurity-gerelateerde risico’s zal deze strategie zelden gekozen kunnen worden.

6.3 Overzicht

Procesmatig bestaat de risicogestuurde aanpak uit zes stappen en is als volgt weer te geven:

Figuur 6.2: Risicogestuurde aanpak in zes stappen.

De verschillende stappen hebben de volgende functies:

1. 1. 1. De inventarisatie dient voor het vastleggen van:
         • De actuele situatie aan de hand van de drie aspecten (zie hoofdstuk 2 De aspecten van cybersecurity).
         • De operationele doelstellingen.
      2. Risicoanalyse: vaststellen hoe de risico’s te beheersen zijn of zijn terug te brengen tot een aanvaardbaar niveau.
      3. Maatregelen opstellen: per risico een strategie bepalen en, indien nodig, maatregelen benoemen en restrisico’s bepalen na het invoeren van de maatregel.
      4. Maatregelen selecteren: per risico bepalen welke maatregel wordt uitgevoerd.
      5. Maatregelen implementeren: de gekozen maatregelen toepassen.
      6. Borging van de uitgevoerde maatregelen.

6.4 Inventarisatie van dreigingen

Zowel in een bestaande situatie als voor nieuwbouw is het essentieel vast te leggen wat de bestaande (‘as is’) dan wel de gewenste (’to be’) situatie is ten aanzien van exploitatie, beheer en onderhoud, en welke operationele doelstellingen hierbij horen. Het vastleggen van de operationele doelstellingen gebeurt in de vorm van procesbeschrijvingen (Engels: concept of operations, ConOps). Een belangrijk onderdeel hiervan vormen de verschillende typen en aantallen cyberincidenten: welke (typen) incidenten houden we voor mogelijk, wat is acceptabel en wat moet ‘tot het uiterste’ voorkomen worden? Restrisico’s zijn bepalend bij het vaststellen van wat acceptabel is in geval van incidenten. Het NCSC geeft jaarlijks een update van het algemene dreigingsbeeld van cyberincidenten in Nederland.

De inventarisatie dient om in inzicht te krijgen in de dreigingen die de operationele doelstellingen nadelig beïnvloeden.

Een veel gebruikte lijst van dreigingen in een OT-omgeving is de volgende:

1. 1. 1. Ongeoorloofde toegang door niet-geautoriseerde personen tot:
      2. Bedien‐ en technische ruimten.
      3. ICT en OT/SCADA‐systemen en/of documentatie, zoals tekeningen, handleidingen en dergelijke.
      4. Datanetwerk (via internet of draadloze toepassingen, of een openstaande poort).
      5. Ontbrekende informatie over zwakke plekken in de beveiliging en over incidenten alsmede een handelingsperspectief.
      6. ICT en OT/SCADA‐systemen bevatten kwetsbaarheden en zijn vatbaar voor malware.
      7. Het niet kunnen detecteren en analyseren van afwijkend gedrag of incidenten op het datanetwerk via logging en monitoring.
      8. Risico’s geïntroduceerd door bedienend- en/of onderhoudspersoneel. Deze zijn zich wellicht niet bewust van onveilige situaties, beschikken niet over de juiste opleiding en training, hebben geen geheimhoudingsverklaring getekend of beschikken niet over een recente verklaring omtrent het gedrag (VOG).
      9. Functionele wijzigingen brengen onvoorziene veiligheids‐ en beveiligingseffecten met zich mee en kunnen zelfs de functionele werking van ICT en OT/SCADA‐systemen deels of volledig doen uitvallen.
      10. De handhaving en de effectiviteit van de cybersecurity-maatregelen is niet gewaarborgd evenmin als structurele borging bij alle betrokken (onder)aannemers.
      11. Bij systeemstoringen of functionele wijzigingen is er geen terugvaloptie (geen back‐up en herstelproces).

6.5 Risicoanalyse opstellen

Na de inventarisatie volgt het opstellen van de risicoanalyse. Dit gebeurt aan de hand van de in de inventarisatie opgestelde lijst van dreigingen. De dreigingen dienen hierbij zo concreet mogelijk gespecificeerd te zijn. De indeling naar aspecten 2 De aspecten van cybersecurity kan helpen bij het opstellen van zo’n lijst.

Het risico is vast te stellen door per dreiging de kans van optreden te bepalen, en te bepalen wat de gevolgschade (‘impact’) is als de dreiging daadwerkelijk optreedt. Het risico is dan de combinatie van impact en kans: risico = kans x impact.

Een ‘cybersecuritydreigingslog’ is een middel om het dreigingsbeeld voor een specifieke operationele omgeving of systeem te monitoren. Cybersecurityexperts bepalen vaak de cybersecuritydreigingen. Het is aan te raden om deze door ‘peers te challengen’ op realiteitswaarde, en door de opdrachtgever en gebruikers te (laten) evalueren ten aanzien van de impact op de operatie. Dat geldt zeker als het gaat om het accepteren van restrisico’s (zie hierna), omdat de restrisico’s een impact (kunnen) hebben op de operatie.

Methoden

Globaal bestaan er twee methoden voor het opstellen van risicoanalyses:

1. 1. • Kwalitatieve methode: deze manier maakt gebruik van kwalitatieve schattingen bij risico’s.
      • Kwantitatieve methode: de risico’s worden gespecificeerd in meetbare criteria, bijvoorbeeld in financiële gevolgen of aantal te accepteren incidenten (restrisico’s) cq. letselgevallen.

Bij industriële automatisering wordt vaak gebruikgemaakt van een fault tree analysis (foutenboom), of een failure mode, effects (and criticality) analysis, de FME(C)A. Specifiek voor cybersecurity kan een threat model (dreigingenmodel) worden opgesteld.

Bronnen voor risicoanalyse en -management voor cybersecurity zijn:

1. 1. • Handreiking risicoanalyse, door het Nationaal adviescentrum vitale infrastructuur (Navi)
      • IEC 62443, Technical security requirements

Voor OT-systemen is de IEC 62443-3-2 van toepassing. Deze norm beschrijft het ‘security risk assessment and system design’.

1. 1. • ISO 27000: Deze serie omvat verschillende informatiebeveiligingsnormen. De norm ISO 27000 is met name gericht op IT-omgevingen, zoals kantoorautomatisering (SAP, Microsoft Office, e.d.). Deze past op onderdelen niet op OT-systemen zoals de bediening, besturing en bewaking van tunnels (zie ook Bijlage 2 OT vs. IT). Bij tunnels is immers continu gebruik essentieel, hetgeen niet aan de orde is bij kantoorautomatisering.
        • ISO 27001, Information security management
        • ISO 27005, Information security risk management
        • ISO 27035, Incidentrespons
      • ISO 31000, risicomanagement
      • Handreikingen en leidraden ProRail en Rijkswaterstaat

Beschikbaarheid en integriteit staan bovenaan de OT-agenda. Enerzijds moet een maatregel bescherming bieden tegen aanvallen hiertegen, anderzijds mag de maatregel de bedrijfsprocessen niet verstoren. Tegelijkertijd moet ook de dreiging op de IT-omgeving worden tegengegaan (‘gemitigeerd’), terwijl de prioriteit hier bijvoorbeeld op confidentialiteit kan liggen. Om beide werelden effectief te beveiligen, ligt een geïntegreerde ‘IT/OT-aanpak’ van cybersecurity voor de hand. Voor elke operatie en voor elk systeem dient een specifiek dreigingsbeeld te worden vastgesteld. Dit geldt zowel voor het ontwerpproces als bij het vaststellen (en evalueren) van de specifieke cybersecurity-maatregelen.

Zwakheden en gevolgen vinden

Op basis van de eerder genoemde set van dreigingen is het mogelijk risico’s te definiëren door bij elke dreiging één of meer zwakheden te vinden en één of meer (nadelige) gevolgen. Dat kan bijvoorbeeld gebeuren volgens dit stappenplan:

1. 1. 1. Een van de dreigingen is dat een niet-geautoriseerde persoon toegang krijgt tot een technische ruimte.
      2. Vervolgens dient de opsteller van de risicoanalyse zich af te vragen wat er zou kunnen gebeuren als een dergelijke situatie zich voordoet:
         • De betreffende persoon kan apparatuur uitschakelen.
         • De betreffende persoon kan toegang krijgen tot het netwerk.
         • De betreffende persoon kan toegang krijgen tot een SCADA-computer.
      3. Voor elk van die kwetsbaarheden is een gevolg te geven:
         • Als apparatuur wordt uitgeschakeld, kan het object (de tunnel) niet meer worden bediend noch bewaakt.
         • Als iemand toegang krijgt tot het netwerk kan hij het netwerkverkeer afluisteren en manipuleren en op die manier de besturing beïnvloeden.
         • Als iemand toegang krijgt tot een SCADA-computer kan hij dat deel van de installaties bedienen en besturen zonder zicht te hebben op wat er in de tunnel gebeurt.
      4. Dan is het het eindeffect te bepalen:
         • Als de tunnel niet te bedienen is, is deze niet veilig en moet deze worden gesloten.
         • Als de commando’s die over het netwerk worden verstuurd worden gemanipuleerd, kunnen onbedoelde effecten in en om de tunnel plaatsvinden die de veiligheid van de weggebruikers nadelig beïnvloeden.
         • Als iemand een deelinstallatie bedient zonder zicht te hebben op het effect, kunnen onbedoelde effecten in en om de tunnel plaatsvinden die de veiligheid van de weggebruikers nadelig beïnvloeden
      5. Als ten slotte het volledige beeld van dreiging, kwetsbaarheden en gevolgen in beeld is gebracht, volgt het schatten van de kans van optreden.
      6. Voor elk van de risico’s wordt zo het risiconiveau bepaald en kan worden besloten of dat wel of niet acceptabel is.

Merk op dat dit slechts een voorbeeld is en niet bedoeld om volledig te zijn! Bovenstaand stappenplan is ook toe te passen voor het tunnelsysteem als geheel, maar ook per deelsysteem om een meer gedetailleerd beeld te verkrijgen.

In geval van bestaande systemen wordt de inventarisatie gedaan op basis van het huidige systeemontwerp, huidige maatregelen en de huidige kwetsbaarheden (‘as is’). Na de risicoanalyse volgen nieuwe maatregelen en dat is feitelijk een nieuw systeemontwerp (‘to be’). In geval van nieuwe systemen is de inventarisatie op basis van de beoogde operatie en operationele doelstellingen, en de dreigingen en ontworpen cybersecurity-maatregelen.

Nulmeting

Op basis van de lijst van risico’s en de IEC 62443-3-2 is het mogelijk een zogeheten nulmeting te doen en de omvang van het risiconiveau te schatten zonder het realiseren van beheersmaatregelen. De nulmeting maakt dan duidelijk wat de belangrijkste risico’s zijn en welke beheersmaatregelen nodig zijn om het risico tot een acceptabel niveau terug te brengen. Wat dat acceptabele niveau is, moet de organisatie bepalen die het te realiseren object gaat beheren. Deze krijgt namelijk te maken met de gevolgen van het optreden van het risico en de noodzaak om binnen een redelijke termijn en tegen redelijke kosten de normale functies van het object weer te herstellen. In de volgende paragraaf komen mogelijke maatregelen aan de orde.

Risico’s van het project

Zoals hierboven al gesteld, zijn er ook de risico’s van het project zelf. Het gaat daarbij niet meer over risico’s van de OT, maar risico’s die het gevolg zijn van het feit dat in het project informatie wordt geproduceerd die mogelijk interessant is voor kwaadwillenden. Daarin is dan weer onderscheid te maken in informatie over het project (wie werkt eraan, hoeveel kost het, hoe gaat het met de planning, etc.) en informatie over het te realiseren object (de ontwerpdocumentatie). In dit groeiboek is met name de ontwerpdocumentatie van belang: voor het beschermen van de informatie over het project zijn op andere plaatsen voldoende handreikingen te vinden.

Als ontwerpdocumentatie in verkeerde handen terechtkomt, bestaat de kans dat een kwaadwillende partij deze onderzoekt op zwakke plekken en ziet hoe de verdediging tegen aanvallen is gerealiseerd. Daarom is het belangrijk om met name voor deze documentatie ook een risicoanalyse uit te voeren. Hierbij kan ISO 27005 als basis dienen. Onderwerpen die daarbij aan de orde dienen te komen:

1. 1. • Wie heeft fysieke toegang tot de ontwerplocaties en de werkplekken ter plekke? Alleen mensen die er werken mogen toegang hebben, anderen niet. Er zijn daarom maatregelen vereist die toegang voor onbevoegden tegengaan.
      • Beveiliging van de opslag van de ontwerpdocumentatie; wie mag wat en hoe is dit afgeschermd?
      • Wat wordt van medewerkers in het project verwacht ten aanzien van communicatie, zowel intern als extern, en hoe kan ontwerpdocumentatie op beveiligde en vertrouwde wijze worden gedeeld?
      • Hoe is het review- en goedkeuringsproces ingericht en welke risico’s kleven daar aan? Wie mag wat zien en hoe is dit geborgd?
      • Hoe zijn de computersystemen beveiligd die gebruikt worden bij het opstellen van de ontwerpdocumentatie?

Typen beveiliging

Bij de analyse van de fysieke toegangsbeveiliging kijkt men naar beveiliging door het plaatsen van iets tastbaars, zoals een hekwerk, verlichting of bewakers. Zodoende wordt de toegang tot een object en de bijbehorende (technische) ruimtes en (technische) kasten gecontroleerd en beheerd.

Analyses in het kader van technische beveiliging hebben betrekking op de hardware en software van het systeem. Hiertoe behoren firewalls, antivirus-software, beveiligde verbindingen, het blokkeren van USB-poorten, encryptie en mechanismen voor identificatie en authenticatie. In tunnelinstallaties wordt in toenemende mate gebruikgemaakt van apparatuur die met het internet is verbonden. Denk voor tunnels hierbij niet alleen aan pc’s en servers, maar juist ook aan camera’s, netwerkapparatuur, intercom, HF, etc. Elk apparaat moet veilig zijn te gebruiken en te onderhouden. Dit geldt ook op afstand!

De veiligheid van technische maatregelen is gebaseerd op vertrouwen in de producten en leveranciers. Immers, als in een product achterdeurtjes of ongepatchte kwetsbaarheden aanwezig zijn, is het mogelijk een veiligheidsconcept volledig te ondermijnen. De gebruikte producten moeten veilig geconfigureerd en ingezet zijn, maar ze moeten ook voor een lange periode te onderhouden zijn (veiligheidsupdates). Ondersteuning van (product)leveranciers is hierbij van cruciaal belang.

Belangrijk bij de analyse is dat men zich realiseert dat updates niet alleen fouten verhelpen, maar vaak ook nieuwe of gewijzigde functionaliteiten meebrengen. Het is nodig om updates uitgebreid te testen vóór deze te implementeren. Dit kan betekenen dat er voor elke omgeving een representatieve test- en acceptatieomgeving nodig is.

6.6 Maatregelen opstellen

De risicoanalyse en de bijbehorende maatregelen gaan uit van de drie aspecten: mens, organisatie en techniek, zie ook hoofdstuk 2 De aspecten van cybersecurity.

1. 1. 1. Mens: bewustzijn, taken, bevoegdheden en verantwoordelijkheden van medewerkers, beheerders, onderhoudspersoneel e.a.
      2. Organisatie: visie, strategie en beleid, governance, standaardisatie, juridische aspecten, contracten beheer, AVG, processen, procedures, etc.
      3. Techniek: fysieke toegangsbeveiliging, IT, OT, hardware, software, de gebouwde omgeving.

In onderstaand figuur zijn de drie aspecten weergegeven met hun onderlinge relaties. Een gedegen beheersplan moet alle drie de aspecten adresseren. Om een bepaald risiconiveau (classificatie) te bereiken, is daarom een zorgvuldig afgewogen set aan maatregelen vereist.

Figuur 6.4: Aspecten cybersecurity.

Maatregelen hebben vaak impact op meer dan één aspect en moeten voor het beoogde effect in balans zijn met elkaar. Als bijvoorbeeld alleen technische maatregelen worden gerealiseerd en de andere aspecten worden genegeerd, zal de beoogde risicobeheersing niet worden bereikt. Sterker nog, er kunnen nieuwe, nog niet voorziene risico’s ontstaan doordat mensen de maatregelen, waarvan zij de reden en het belang niet kennen en/of zien, gaan omzeilen. Een voorbeeld hiervan is het invoeren van minimumeisen aan wachtwoorden. Dit heeft vaak tot gevolg dat men sterke wachtwoorden op een briefje schrijft en dit op de monitor of onder het toetsenbord plakt. Hierdoor wordt de maatregel teniet gedaan en neemt het risico in feite zelfs toe.

Er bestaat een veelheid aan informatie over cybersecurity-maatregelen in de vorm van best practices, internationale en nationale normen, algemene richtlijnen, checklists en richtlijnen van de fabrikant. In het algemeen geldt dat voor een specifiek OT-systeem in een specifieke omgeving en voor een specifiek operationeel doel, keuzes worden gemaakt (in het ontwerpproces) voor specifieke cybersecurity-maatregelen, als een subset van generieke maatregelen. Met behulp van een risicoanalyse zijn maatregelen tegen een mogelijke dreiging te benoemen. De IEC 62443 is hierbij een belangrijke richtlijn.

Effect op de dreiging

Maatregelen zijn in te delen naar het effect dat ze hebben op de dreiging. Maatregelen kunnen proactief, reactief of gericht op herstel zijn.

In onderstaande figuur is dit schematisch weergegeven. Proactieve maatregelen (staying healthy) aan de linkerkant dienen voornamelijk om de kans op een cyberincident te verkleinen. Ze dienen dan ook om de asset te beschermen tegen bijvoorbeeld malware en manipulatie of wijzigingen van software en/of hardware bij het falen van de fysieke toegangsbeveiliging. De herstellende maatregelen (healing quickly) aan de rechterkant hebben tot doel de impact te reduceren en na een incident de asset zo snel mogelijk weer volledig functioneel te krijgen. Voorwaarde is wel dat het incident is gedetecteerd; zonder detectie vinden geen herstelmaatregelen plaats.

Figuur 6.5: Schematische weergave proactieve- en herstelmaatregelen.

Een verdere onderverdeling van maatregelen ziet er als volgt uit:

1. 1. • Preventie: het voorkomen of het verminderen/verkleinen van de kans dat de dreiging optreedt.
      • Detectie: het detecteren van een (potentiële) dreiging als deze optreedt.
      • Repressie: het beperken van de schade van de dreiging.
      • Correctie: het (deels) corrigerend optreden op het moment dat een dreiging zich voordoet.

Proactieve maatregelen hebben overigens als doel om de diagnose-, reparatie- en inbedrijfstellingstijd sterk te verkorten. Correctieve maatregelen dragen bij aan het beperken van de schade m.b.t. imago en hersteltijd van de functie(s).

Gefaseerde aanpak

Tijdens de verschillende fasen van een project kunnen verschillende sets aan maatregelen nodig zijn. Hieronder zijn met name voor de ontwerp- en bouwfase enige aandachtspunten opgenomen. In elke fase komen de drie aspecten die in hoofdstuk 2 De aspecten van cybersecurity zijn geïntroduceerd opnieuw aan de orde.

Restrisico’s

Het nemen van een maatregel heeft gevolgen voor de dreiging of het risico. Het restrisico is het risico dat overblijft na het nemen van een specifieke maatregel die hoort bij een specifiek risico of dreiging. Om de effecten van de verschillende maatregelen te kunnen vergelijken, is het nodig per maatregel dit restrisico te bepalen. Dit restrisico is grotendeels bepalend bij de keuze welke maatregel uiteindelijk wordt toegepast.

6.7 Maatregelen selecteren

Het selecteren van maatregelen kan (sterk) afhankelijk zijn van de staat van het object en de technische status van de aanwezige installaties. Bij nieuwbouw zal er meer keuzevrijheid zijn dan bij een verouderd bestaand object. Bij een bestaand object kunnen de leeftijden en toegepaste technologieën van de bestaande installaties immers sterk verschillen.

Bij nieuwbouw kan er dan ook sprake zijn van security by design, waarbij cybersecurity geïntegreerd wordt in het ontwerp van de installatie(s) en het integrale totaalontwerp. Bij renovatie daarentegen gaat het om security by customization: maatwerk in de werkende installaties(s) en over de installaties heen (protectieschil).

Afhankelijk van het risico is een transparante afweging vereist die leidt tot een besluit welke combinatie van maatregelen tegen cyberincidenten en welke maatregelen voor herstel minimaal nodig zijn. Maatregelen dienen een bepaald doel en dit doel is, zolang een maatregel van kracht is, afhankelijk van de ‘mens’, ‘organisatie’ en ‘techniek’. Het niet (goed) naleven van de maatregelen (bijvoorbeeld een workaround maken omdat het te veel moeite kost om onderhoud te plegen) kan ertoe leiden dat het risico weer toeneemt.

Uit de risico-inventarisatie en -analyse volgt wat het restrisico is bij het optreden van gebeurtenissen door het nemen van een maatregel. Verschillende maatregelen kunnen leiden tot zeer uiteenlopende resultaten. Zo zullen sommige maatregelen nauwelijks effect hebben en andere daarentegen juist veel. Ook is het mogelijk dat de ene maatregel een negatief effect heeft op een andere maatregel of dat een maatregel een negatief effect heeft op de functionaliteit van het object. Het is in deze fase van belang de juiste maatregelen te nemen. Dit kiezen van deze juiste maatregelen is een iteratief proces. Omdat dit een zorgvuldige afweging vergt, moet dit bij voorkeur gebeuren door een team van de juiste deskundigen.

De figuur hieronder illustreert het effect van meerdere maatregelen die op zichzelf geen volledige zekerheid bieden. In zo’n geval moeten deze bij voorkeur zodanig worden gekozen dat ze elkaars zwakke plekken afdekken. Als alle maatregelen een gelijke zwakke plek kennen, ontstaat een situatie zoals in het Zwitserse-kaasmodel wordt weergegeven.

Figuur 6.6: Het Zwitserse-kaasmodel. (Bron: James Reason)

Na een eerste selectie wordt opnieuw per onderdeel bekeken wat de (rest)risico’s zijn als de geselecteerde maatregelen worden uitgevoerd. Maatregelen moeten elkaar dus bij voorkeur zoveel mogelijk versterken. Uiteraard geldt hoe meer proactieve maatregelen worden genomen, des te kleiner de kans op optreden van een dreiging wordt. Echter, dit kan nadelige gevolgen hebben voor het instandhouden van de maatregelen, zoals beheerskosten en het mogelijk bemoeilijken van het onderhoud van en wijzigingen aan de installatie/systeem.

Het risicoverschil dat ontstaat door het nemen van de maatregel is het verschil in impact indien geen maatregel wordt genomen ten opzichte van wanneer de maatregel wel wordt genomen. Het restrisico is het effect (inclusief kans daarop) dat overblijft als alle beheersmaatregelen zijn genomen. Deze restrisico’s zijn toe te lichten met scenario’s, tijds-, financiële en/of personele consequenties van het optreden van het risico. De set van geselecteerde maatregelen kunnen vervolgens de input vormen van een nieuwe ronde van selectie. Het selectieproces is ten einde zodra het totale restrisico voldoende laag is. Uiteindelijk is het ook nodig dat het restrisico bestuurlijk acceptabel is.

6.8 Maatregelen implementeren

Nadat is vastgesteld welke maatregelen moeten worden genomen, zullen deze ook moeten worden geïmplementeerd. Daarbij is het mogelijk dat, vanwege budgettaire of technische beperkingen, niet alle maatregelen in één keer kunnen worden gerealiseerd. Het kan dan helpen om de maatregelen te rangschikken enerzijds op volgorde van het effect op het risiconiveau en anderzijds op volgorde van de financiële en/of technische impact. Op basis daarvan kan een volgorde van implementatie worden voorgesteld. Daarbij zal tijdelijk een restrisico bestaan dat hoger is dan het acceptabele risiconiveau. Dit hogere restrisico zal dan expliciet moeten worden geaccepteerd door de organisatie.

6.9 Patching en servicing

Deze paragraaf biedt praktische handvatten en tips voor het omgaan met patching en servicing (onderhoud) in het licht van de beschikbaarheid van een tunnel-object. Dit ter ondersteuning van betrokken object- c.q. tunnelbeheerders, technisch specialisten en veiligheidsadviseurs.

Noot: als in dit hoofdstuk over patches wordt gesproken, worden daarmee beveiligingspatches bedoeld.

6.9.1 Inleiding

In de bijlage ‘Cybersecurity en tunnelveiligheid ‘ is in een aantal voorbeelden beschreven hoe cybersecurity en tunnelveiligheid elkaar. Zo kan een fysiek incident het gevolg zijn van gebrekkig (of zelfs falend) cybersecuritybeleid. En bij de bewaking van de fysieke veiligheid van tunnels door tunneloperators, zijn zij volledig afhankelijk van (complexe) procesautomatiseringssystemen, ook wel industrial automation control systems (IACS) genoemd. Veelal wordt gedacht dat het hier alleen gaat om de besturingssystemen (SCADA/PLC), maar het betreft ook de systemen voor dynamisch verkeersmanagement (DVM), camera’s (CCTV), omroep en intercom, gebouwbeheer, toegangscontrole, enz. Al deze systemen zijn met elkaar verbonden door middel van een OT-netwerk dat veelal is verbonden met een verkeerscentrale die op afstand van de tunnels staat. Als deze systemen niet betrouwbaar (blijken) te zijn, moet de vraag worden gesteld of de tunnel wel veilig is en dus open mag blijven. Hiermee komt de beschikbaarheid van het tunnelsysteem als onderdeel van het gehele weginfrasysteem in de omgeving in het geding.

Bij oplevering en overdracht van een nieuwe of gerenoveerde tunnel van de projectorganisatie naar de beheerorganisatie, wordt deze geacht veilig te zijn ontworpen, getest en in bedrijf gesteld. Daarbij is bekend dat met name voor deze techniek een aanzienlijk hoger afbreukrisico geldt dan voor civiele constructie. In de projectfase zal de aannemer de expertise op dit specialistische gebied dan ook binnen de eigen organisatie hebben of deze inhuren om ervoor te zorgen dat hij aan zijn verplichtingen kan voldoen.

Na overdracht zal de IACS-omgeving ook gedurende de exploitatiefase (cyber)veilig gehouden moeten worden. Dit kan met behulp van patching.

“Patchmanagement is het proces voor het managen van patches en/of upgrades voor software met als doel de systemen up to date en veilig te houden”

Een goede inbedding van patchmanagement in de organisatie is nodig om de schijnbare tegenstelling tussen de belangen van de security officer (vertrouwelijkheid en integriteit) en die van de service manager (beschikbaarheid) te managen.

Er kunnen in principe twee soorten patches worden onderscheiden:

1. 1. • Beveiligingspatches zijn gericht op het verbeteren van de beveiliging en het mitigeren van dreigingen en misbruik. Denk hierbij aan zero-days en uitbuiten van kwetsbaarheden.
      • Functionele patches zijn gericht op het toevoegen van functies of verbeteren van de werking. Denk hierbij aan updates en upgrades.

In de praktijk worden beide soorten patches vaak gecombineerd in één en dezelfde update en kunnen ze niet los van elkaar worden toegepast. Dit betekent dat zowel de verbeterde beveiliging als de gewijzigde functionaliteit moet worden beoordeeld en getest op juiste werking en (ongewenste) neveneffecten. Het uitvoeren van beveiligingspatches dient te worden uitgevoerd conform het overkoepelende patchmanagementproces.

Patching binnen het OT-domein kan in het algemeen, en specifiek voor een tunnel, een uitdaging zijn. Zoals aangegeven kenmerkt een tunnel-object zich namelijk door een veelheid aan systemen die:

1. 1. • verschillend van aard zijn (leverancier, soort);
      • verschillend in toepassing of specifiek voor een toepassing ontwikkeld zijn;
      • ontwikkeld zijn met het oog op langdurige inzet en beschikbaarheid;
      • qua ontwerp niet opgezet zijn met beveiliging in het achterhoofd – geen ‘security by design’ (NB. dit geldt met name voor de nog niet gerenoveerde tunnels, voor de meest recente tunnels is beveiliging wél in het ontwerp meegenomen);
      • verdeeld zijn over meerdere locaties en via een verkeerscentrale veelal onderling verbonden zijn.

Op basis van bovenstaande is te concluderen dat het praktisch onmogelijk is om alle systemen van een tunnel permanent intrinsiek veilig te houden d.m.v. patching. De werkgroep stelt de volgende aanpak voor:

1. 1. 1. Ontwikkel een proces Patchmanagement met aanvullende, mitigerende maatregelen om een veilige situatie te creëren.
      2. Uitgangspunt van dat proces moet zijn: “Pas patches gecontroleerd toe”.
      3. Patchmanagement is is geen doel op zichzelf. Het is onderdeel van een bovenliggend framework ten aanzien van het in stand houden van een veilige infrastructuur.
      4. Voorwaarden voor patchmanagement zijn een (getest) back-up- en herstelproces en een gecontroleerd wijzigingsproces.
      5. Zorg voor voldoende expertise indien dit niet binnen de eigen organisatie voorhanden is.

Een proces Patchmanagement moet een duidelijk beslismoment hebben om een patch al dan niet toe te passen. Een patch moet worden uitgerold als het huidige risico groter is dan acceptabel én de patch het risiconiveau reduceert en geen invloed heeft op de functionaliteit van het object. Het niet-uitvoeren van een patch kan het aanbrengen van een toekomstige, misschien noodzakelijke, patch verhinderen of ernstig bemoeilijken.

6.9.2 Vertrekpunt

Als vertrekpunt is in dit groeiboek de best practice Patchmanagement uit de Cybersecurity implementatierichtlijn 2.4 (CSIR, bijlage 8) van Rijkswaterstaat genomen. Deze is geëvalueerd en waar van toepassing specifiek gemaakt voor gebruik binnen de beheerprocessen van een tunnelobject. Verdere zijn de volgende bronnen relevant:

1. 1. 1. IEC 62443-2-3 Patch management in the IACS environment Deze internationale standaard is ontwikkeld door een community van onder andere vrijwilligers en mag gebruikt worden mits naar de standaard wordt gerefereerd.
      2. NIST 800-82 Guide to industrial control systems (ICS) security Bevat een beperkte paragraaf over patching en verwijst naar NIST 800-40 “Guide to enterprise patch management technologies”.
      3. DHS recommended practice for patch management of control systems De versie 2008 is wellicht niet meer actueel, maar bevat mogelijk nog wel bruikbare informatie. Deze versie wordt wél gerefereerd vanuit het overzicht Recommended practices van het Cybersecurity & Infrastructure Agency.

6.9.3 Processen rond patching

Patching moet (kan) niet gezien worden als losstaand onderdeel van de organisatie. Het is een onderdeel van het overkoepelende levenscyclusmanagement. Binnen dat proces zijn verschillende onderdelen belegd die van aanschaf tot afvoer van de asset en via reguliere processen ingeregeld moeten worden:

1. 1. • Behoefte
      • Selectie
      • Pilot
      • Aanschaf
      • Onderhoud
      • Afvoer

Patching heeft binnen het proces Onderhoud raakvlakken met een aantal processen die met elkaar in verband staan:

1. 1. • Verandermanagement
      • Beheer
      • Assetmanagement
      • Configuratiemanagement
      • Contractmanagement

Onder het beheerproces is patching belegd. Binnen dit proces worden alle vormen van patches beheerd en beheerst toegepast. Dit geldt voor de diverse componenten die aanwezig zijn binnen het landschap van de beheerorganisatie:

1. 1. • Software
      • Firmware
      • Hardware

Voor deze processen dienen op verschillende niveaus beschrijvingen aanwezig te zijn voor het uitvoeren van de werkzaamheden en de borging binnen de organisatie:

1. 1. • Procesbeschrijvingen
      • Werkinstructies
      • Rapportage

Patching heeft invloed op alle operationele IT- en OT-processen en zal ook van invloed zijn op de continuïteit binnen de organisatie als het niet of niet goed wordt uitgevoerd. Het kan direct en indirect zorgen voor het stoppen van processen, workflows en, in worstcasescenario’s, een complete shutdown van het bedrijf. Denk hierbij aan:

1. 1. • Niet werkende software
      • Niet juist werkende software
      • Niet juist werkende hardware
      • Kwetsbaarheden die uitgebuit kunnen worden door cybercriminelen
      • Kwetsbaarheden die uitgebuit kunnen worden door virussen en ransomware
      • Het niet kunnen voldoen aan wettelijke vereisten
      • Het niet kunnen garanderen en valideren van data en uitkomsten
      • Etc.

Patching is essentieel om de verschillende processen binnen de organisatie betrouwbaar en integer te houden en de continuïteit te waarborgen.

6.9.4 Effectief patchmanagement

Uitgangspunten en voorwaarden

Voordat een effectief patchmanagementproces kan worden ingericht, dient te worden voldaan aan een aantal noodzakelijke voorwaarden.

Allereerst moet inzicht bestaan in welke apparatuur zich in het object bevindt en welke software en firmware (inclusief versie en patchlevel) op die apparatuur is geïnstalleerd. In feite betekent dit dat van het object een ‘software bill of materials’ (SBOM) beschikbaar moet zijn en in de CMDB moet zijn verwerkt. Dit is weer onderdeel van de processen asset- en configuratiemanagement, waarin de CMDB wordt onderhouden. Vervolgens moet een proces worden ingericht dat voor elk configuratie-item (CI-element in de CMDB), informatie beschikbaar maakt over de kwetsbaarheden die bekend zijn en of hiervoor patches beschikbaar zijn of komen.

Daarnaast moet binnen de organisatie duidelijk zijn waar en hoe de taken en verantwoordelijkheden voor beheer, onderhoud en (cyber)security zijn belegd. Ook moet helder zijn wat het beleid van de organisatie is op het gebied van informatiebeveiliging, (cyber)security en patching, aangezien dat de randvoorwaarden geeft waarbinnen het patchmanagement moet worden vormgegeven. Een belangrijk besluit dat elke organisatie moet nemen, is het risiconiveau dat als acceptabel wordt gezien. Dit is een belangrijk gegeven voor het risicomanagementproces. Dit acceptabele risiconiveau moet worden beschreven in alle facetten die voor een organisatie van belang zijn, zoals acceptabele financiële schade, acceptabel aantal ongevallen met of zonder verzuim per tijdseenheid, aantal overledenen per tijdseenheid, etc.

Het beveiligingsbeleid moet uitgewerkt zijn in processen, procedures en werkwijzen die bekend zijn bij alle medewerkers die ermee werken. Ook moet duidelijk vastgelegd zijn wat de voor de organisatie geldende processen zijn voor risicomanagement en wijzigingsmanagement.

Tot slot is een noodzakelijke voorwaarde het beschikbaar zijn van een permanente, representatieve testomgeving. Representatief betekent dat testen uitgevoerd in die omgeving een voorspelling geven van het gedrag van de productieomgeving. Het hoeft dus geen exacte kopie te zijn van de productieomgeving, maar de omgeving zou wel van elk individueel apparaat dat in de productie voorkomt een exemplaar moeten bevatten met exact dezelfde firmware en software.

Inrichting

Rijkswaterstaat heeft in de CSIR in paragraaf 2.5.3 maatregelen geformuleerd op het gebied van patching en in bijlage 8 van hetzelfde document een richtlijn beschreven voor het inrichten van het patchmanagementproces.

In de figuur hieronder is een overzicht weergegeven van de verschillende processtappen die onderdeel zijn van patchmanagement. Zoals bij de uitgangspunten al is aangegeven, begint het proces bij het beschikbaar hebben van de assets met al hun kenmerken. Vervolgens moet informatie worden verzameld over de kwetsbaarheden en de dreigingen. Die informatie vormt de basis voor de uit te voeren risicoanalyse. De uitkomst van de risicoanalyse is de beslissing over de risico’s die wel en niet aanvaardbaar zijn. Voor de niet-aanvaardbare risico’s moeten beheersmaatregelen worden geïmplementeerd; allereerst in een testomgeving en vervolgens in de productieomgeving. Tot slot moet de CMDB worden bijgewerkt met de meest recente configuratie informatie.

Rollen en verantwoordelijkheden

1. 1. • De objecteigenaar is verantwoordelijk voor het object en het optimaal functioneren ervan. De objecteigenaar bepaalt welke risico’s wel en niet aanvaardbaar zijn en beslist uiteindelijk welke patches wel en niet moeten worden toegepast.
      • De beheerder/uitvoerder is verantwoordelijk voor het advies over en de beoordeling en uitvoering van alle beheerwerkzaamheden, waaronder het toepassen van patches.
      • De leverancier geeft de beheerder advies over het toepassen van patches en levert de betreffende patches.

Gezamenlijk zal er gekeken worden of de uit te voeren werkzaamheden in overeenstemming zijn met de te verwachten risico’s en de uit te voeren werkzaamheden. In onderling overleg zal er een besluit worden genomen of de maatregel, werkzaamheden, een eventueel risico of downtime acceptabel zijn en moeten worden uitgevoerd. Deze onderdelen zouden geborgd kunnen worden in diverse processen om besluitvorming te garanderen. Denk hierbij aan verandermanagement, risico-overleg, werkoverleggen, levenscyclusmanagement, etc.

Informatie over kwetsbaarheden

Voor het verzamelen van informatie over kwetsbaarheden zijn meerdere bronnen beschikbaar:

1. 1. • Abonneren op feed van leverancier/ICS-CERT/CVSS
      • Meldingen vanuit de leverancier
      • Gespecialiseerde advisering, zoals SOC-diensten en gespecialiseerde monitoringdiensten op het gebied van kwetsbaarheden en zerodays-gebruik
      • Meldingen vanuit diverse bronnen zoals Darkweb (hackersfora, bulletinboards), sociale media, internetmonitoring.
      • Mogelijk gebruikmaken van de Cyber threat intelligence (CTI) feed van Rijkswaterstaat of TIP (indien actuele CMDB beschikbaar)

Bij het verzamelen van informatie moet rekening gehouden worden met dat enerzijds informatie over het hoofd wordt gezien en anderzijds informatie wordt verstrekt die niet of niet volledig van toepassing is voor het object. Het is van belang dat de beschikbaar gekomen informatie gekoppeld wordt aan de CI’s in de CMDB als brongegeven voor de uit te voeren risicoanalyse.

Risico-analyse

Wanneer de informatie over kwetsbaarheden gecombineerd wordt met informatie over dreigingen kan een risicoanalyse worden uitgevoerd voor elk van de kwetsbaarheden. Voor elke kwetsbaarheid wordt het risiconiveau vastgesteld door het beoordelen van de kans dat deze succesvol kan worden gebruikt door een dreiging en de mogelijke consequenties van zulk onbedoeld gebruik. Als de conclusie is dat het risiconiveau hoger is dan wat aanvaardbaar is, moet een beheersmaatregel worden getroffen om het risiconiveau te verlagen. Dat kan zijn het aanbrengen van een patch, nadat deze door de leverancier beschikbaar is gesteld. Zolang die patch niet beschikbaar is, of nog niet is aangebracht, zal de beheerorganisatie extra alert moeten zijn op tekenen van gebruik van de kwetsbaarheid.

Eventueel kan gebruikgemaakt worden van een beslisboom zoals voorgesteld door Dale Peterson, in een Nederlandse vertaling beschikbaar bij Dataned. Een andere methode is het gebruik van een trade-offmatrix (TOM) waarin de gevolgen van scenario’s worden uitgewerkt ter voorbereiding van de besluitvorming.

Voor elke bekende kwetsbaarheid zal op deze wijze een beslissing worden genomen en vastgelegd of een patch wel of niet zal worden toegepast nadat deze beschikbaar is gekomen. Hieronder worden de twee situaties nader toegelicht.

6.9.5 Testen

Patchen tijdens bouw of renovatie

TIjdens een lopende test van de tunnel mag er niets worden gewijzigd, en toch willen we door middel van patching minimaal de beveiliging op peil houden. Hiervoor is een gecontroleerd proces nodig dat lijkt op het proces dat in de productiesituatie moet worden gehanteerd. Het is daarvoor wel nodig dat in de planning van de testen wordt rekening gehouden met het aanbrengen van patches en het ten gevolge daarvan uitvoeren van hertests. Het is een gezamenlijke verantwoordelijkheid van zowel de opdrachtgever als de opdrachtnemer om in de planning van een project rekening te houden met deze activiteit, omdat anders het gehele systeem verouderd en kwetsbaar zal zijn om op het moment dat een object operationeel wordt.

Patchen in productie

Voordat een patch in een productieomgeving kan worden aangebracht, moet door middel van testen worden aangetoond dat de functionaliteit van hetgeen gepatcht wordt niet nadelig wordt beïnvloed. Hiervoor dient een selectie te worden gemaakt van beschikbare testgevallen die relevant zijn voor het geraakte deel van de software. Het succesvol uitvoeren en afronden van deze test is een noodzakelijke voorwaarde om de patch in de productieomgeving te kunnen aanbrengen.

Nadat in de testomgeving is aangetoond dat de patch veilig kan worden uitgevoerd, dient te worden bepaald welke minimale subset van testgevallen noodzakelijk is om ook in de productie uit te voeren om daarmee aan te tonen dat het gedrag in de productieomgeving gelijk is aan hetgeen in de testomgeving is gezien.

6.10 Borging

Na het implementeren van de definitieve set van maatregelen is de borging van deze set essentieel. Deze set van maatregelen is bedoeld om een bepaald niveau van cybersecurity te bereiken. De kwetsbaarheden van het tunnelsysteem zijn immers bepaald op basis van een risicoanalyse van de actuele situatie. Het handhaven van dit niveau van cybersecurity betekent borging (proces) van de cybersecurity van de drie aspecten. Als voorbeeld valt hierbij te denken aan:

1. 1. • Fysieke toegangsbeveiliging tot IA-gerelateerde ruimten.
      • Het verlenen van logische toegang.
      • Het configureren van netwerkkoppelingen.
      • Procedures voor hardening en patching.
      • Procedures bij het optreden van beveiligingsincidenten.
      • Het opstellen van een incidentresponsplan.
      • Logging en monitoring van netwerkverkeer.
      • Afspraken en procedures met aannemers.
      • Het bewust maken en trainen van tunnelbeheerders en ander betrokken personeel.
      • Procedures voor het maken van back-ups.

Naast de maatregelen die voortvloeien uit de risicoanalyse is het ook nodig aandacht te besteden aan de implementatie van de beveiligingsadviezen van leveranciers en van het NCSC (Nationaal cybersecuritycentrum) van het Ministerie van Justitie en Veiligheid.

Borging in de volle omvang behelst naast het borgen ook het auditen en het afleggen van verantwoording. Het hele proces bestaat uit drie stappen: opzet, bestaan en werking. Bijvoorbeeld: Er dient een vaste procedure te worden gevolgd voor het patchen van het tunnelbesturingssysteem. Opzet, bestaan en werking betekent in dit geval dat de maatregel moet zijn vastgelegd, dat de procedure is beschreven en dat de betreffende partij de procedure ook daadwerkelijk uitvoert zoals is beschreven.

Bij alle methoden en aspecten van cybersecurity-borging is het van belang om afspraken te maken over de periodiciteit van inspecties, controles en audits. Het verdient aanbeveling om hierbij zoveel mogelijk aan te sluiten bij inspecties, controles en audits die reeds uitgevoerd (moeten) worden op basis van niet-cybersecurity-afspraken en/of wet- en regelgeving.

Borging is afhankelijk van de fase in het proces. In de ontwerpfase richt borging van de maatregelen zich met name op het implementeren van de cybersecurity-eisen in het technisch ontwerp door de opdrachtnemer en het toetsen hiervan door de opdrachtgever. Daarnaast is het van belang dat informatie die onderdeel is van het ontwerp te classificeren. Gevoelige informatie dient enkel beschikbaar te zijn in een afgeschermde omgeving met toegangsbeheer. Dit is ook het geval in de communicatie met potentiële leveranciers; denk hierbij aan afspraken over de omgang met vertrouwelijke informatie en documenten. Er kunnen audits op de documentbeheersing worden uitgevoerd.

Tijdens de bouwfase daarentegen is het van cruciaal belang om het testen en de validatie van de implementatie van cybersecurity-eisen als integraal onderdeel op te nemen in de systems engineering. De opdrachtgever kan daarnaast ook audits uitvoeren gedurende de realisatiefase. Denk hierbij aan werkplaatsbezoeken en fysieke inspecties. Aandachtspunt is toegangsbeheer van de bouwplaats en de daar aanwezige vertrouwelijke informatie.

Borging is grofweg in te delen naar:

7 Verificatie en validatie

Veiligheidsvoorzieningen moeten niet alleen aanwezig zijn, maar ook aantoonbaar correct werken. Dat geldt ook voor cybersecurity-maatregelen: ook voor dit type veiligheid is verificatie en validatie vereist. Diverse kennisdomeinen hanteren net even verschillende definities, waardoor internationaal gezien het aantal definities groot is.

Binnen de GWW-sector zijn de definities afgeleid uit de Leidraad voor systems engineering:

1. 1. • Verificatie: Bevestiging door onderzoek en verstrekking van objectief bewijs dat aan die gespecificeerde eisen is voldaan.
      • Validatie: Bevestiging door middel van objectieve bewijsvoering en daadwerkelijke beleving en gebruik dat het gerealiseerde product voldoet aan de eisen en behoeften van de klant, in aanvulling op de verificatie.

Verificatie dient dus om objectief en expliciet aan te tonen dat een oplossing voldoet aan de gestelde eisen. Validatie toont aan dat een oplossing geschikt is voor het beoogd gebruik.

Voor cybersecurity geldt daarnaast dat bij verificatie en validatie nadrukkelijk moet worden gekeken naar afwijkende situaties. Met andere woorden: niet alleen het ‘sunny day’-scenario testen, maar juist ook (meerdere) ‘rainy days’. Bijvoorbeeld: bij een eis aan de minimale lengte van wachtwoorden dient separaat te worden gevalideerd dat:

1. 1. • Een gekozen wachtwoord met die geëiste minimale lengte wordt geaccepteerd.
      • Een gekozen wachtwoord met een (willekeurige) grotere lengte wordt geaccepteerd.
      • Een gekozen wachtwoord met een lengte korter dan de minimaal toegestane lengte niet wordt geaccepteerd en leidt tot een foutmelding vanuit het systeem.

De principes voor het kunnen verifiëren en valideren zijn:

1. 1. 1. Bewijsvoeringsmethode.
      2. Criterium.
      3. Beoordelaar.
      4. Aanvullende activiteiten, criteria en beoordelaars die nodig zijn voor voldoende objectieve bewijsvoering. Denk hierbij aan het verifiëren in verschillende opeenvolgende fasen of zelfs meerdere locaties in een projectfase.
      5. Het tijdstip waarop de verificatie/validatie moet plaatsvinden.
      6. De startvoorwaarde om te kunnen beginnen met verifiëren/valideren. Bijvoorbeeld als andermans projecttaak gereed moet zijn voordat de validatie van de eigen projecttaak kan starten.
      7. De geldigheid van de gehanteerde verificatie- of validatiemethode. Bijvoorbeeld als de opdrachtnemer een bewijsvoeringsmethode voorstelt die nieuw of (nog) onbekend is bij de opdrachtgever.
      8. De risico’s van het niet voldoen aan het criterium. Bijvoorbeeld als vooraf nog niet duidelijk kan zijn of een op theoretische basis gevraagde systeemprestatie in de praktijk wel haalbaar is, kan het van belang zijn specifieke beheersmaatregelen voor sommige eisen te definiëren.

Opeenvolgende stappen in de verificatie

Opeenvolgende stappen in de validatie

Het doorlopen van de validatiestappen dient bij voorkeur zo vroeg mogelijk in het project te gebeuren omdat het ontdekken van fouten op een later moment leidt tot hogere kosten. Er bestaan vier stappen in het validatieproces:

8 Incidentrespons en herstel

“Er zijn slechts twee soorten bedrijven, zij die gehackt zijn en zij die gehackt zullen worden”, aldus Robert Mueller (speech Combating threats in the cyber world). Hoewel veel mensen instemmen met deze uitspraak, is er nog weinig besef dat dit ook voor OT-omgevingen geldt. Elke IA-omgeving met een externe netwerkverbinding is continu een potentieel doelwit. Behalve de, haast normaal geworden, incidenten door het scannen van het internet zijn er ook andere mogelijkheden om inbreuk te plegen op een IA-omgeving. Dit hoofdstuk beschrijft het detecteren, registreren, beoordelen en afhandelen van cyberincidenten in OT-systemen.

8.1 Wat is een cyberincident?

8.1.1 Definitie

‘Een beveiligingsincident is een gebeurtenis of actie waarbij de beveiliging van hardware, software, informatie, een proces of organisatie mogelijk in gevaar is gebracht of geheel of gedeeltelijk is doorbroken’, aldus het cybersecurity-woordenboek. Een beveiligingsincident kan dus ook het gevolg zijn met onbedoeld negatief effect door een vergissing, een onbewuste of goedbedoelde aanpassing.

De volgende activiteiten worden gezien als inbreuken op een beveiligingsbeleid:

1. 1. 1. Pogingen om ongeautoriseerde toegang te krijgen tot een systeem en/of gegevens.
      2. Het ongeautoriseerde gebruik van systemen voor het verwerken of opslaan van gegevens.
      3. Wijzigingen in systeemfirmware, software of hardware zonder toestemming van de systeemeigenaren.
      4. Schadelijke verstoring en/of denial of service.

Een modern systeem is een combinatie van een fysiek systeem, dat bestaat uit de civiele onderdelen en alle elektrische en mechanische onderdelen die nodig zijn om het systeem te laten functioneren, en een ‘cybersysteem’, dat bestaat uit alle computersystemen en -programmatuur die nodig zijn om het fysieke systeem te bedienen, besturen en bewaken. In het fysieke systeem kunnen fysieke incidenten optreden, evenzo kunnen in het cybersysteem cyberincidenten optreden. Dat betekent dat het falen van een systeem zowel een fysieke oorzaak als een cyberoorzaak kan hebben. Sterker, een cyberoorzaak kan gevolgen hebben in het fysieke systeem.

Cyberincidenten zijn (al dan niet merkbare) afwijkingen in de beschikbaarheid, vertrouwelijkheid en integriteit van systemen. Niet elk cyberincident hoeft te leiden tot een operationeel incident. Er is sprake van operationele incidenten als afwijkingen optreden ten opzichte van de operationele doelstellingen in bijvoorbeeld systemen. Deze kunnen leiden tot aantasting van de veiligheid, beschikbaarheid en privacy. Er kunnen meer merkbare of niet-merkbare cyberincidenten (per jaar) zijn dan operationele incidenten.

Figuur 8.1: De causaliteit tussen cyberincidenten en fysieke schade en letsel.

8.1.2 Levenscyclus

Het National Institute of Standards and Technology (NIST) hanteert het volgende model voor de levenscyclus van een incident. In dit hoofdstuk worden de verschillende fasen besproken.

Figuur 8.2: Levenscyclus van een incident. (Bron: Computer security incident handling, NIST)

8.1.3 Oorzaken en herkenning

Het Cybersecuritybeeld Nederland 2019 (CSBN2019) laat een verandering zien in de oorzaken van incidenten. Zo vermindert het aantal ‘toevallige’ inbreuken door hobbyisten (script kiddies). Daarentegen is er een toename van bewust geplande aanvallen door landen (nation states). Deze aanvallen kenmerken zich door een lange looptijd, inzet van geavanceerde middelen en gespecialiseerde medewerkers. Om deze incidenten te voorkomen, of effectief op te lossen, is een grotere inzet van middelen en medewerkers nodig, evenals een integrale aanpak op basis van een doordachte strategie. Een indringer heeft maar een klein gaatje nodig om binnen te komen. De beveiliger zal aan alle kwetsbaarheden aandacht moeten besteden om die gaatjes te dichten.

Daarnaast zal de beveiliger moeten zorgen dat hij te allen tijde weet wat zich afspeelt in het te beveiligen object en of het waargenomen gedrag, de waargenomen events, ‘normaal’ zijn. Wanneer een afwijking van ‘normaal’ wordt gesignaleerd, is dat een reden voor nader onderzoek.

In paragraaf 6.5 Risicoanalyse opstellen is een lijst van door Rijkswaterstaat geïdentificeerde bedreigingen vermeld die oorzaak kunnen zijn van veiligheidsincidenten.

8.1.4 Melden en registreren

Voor het correct kunnen afhandelen van een incident is het cruciaal incidenten onmiddellijk te melden bij de verantwoordelijke incidentmanager. De taken en verantwoordelijkheden van deze incidentmanager moeten van tevoren bekend zijn, zie hoofdstuk 4 Cybersecuritymanagement. Het melden van een incident dient ook te gebeuren bij twijfel of er sprake is van een incident. Het proces van melden dient integer te verlopen. Zo mag de melder niet onder druk worden gezet om (delen van) meldingen achterwege te laten of af te zwakken om persoonlijke, economische of andere redenen.

Bij het registeren van incidenten dient minstens vastgelegd te worden:

1. 1. • Locatie
      • Datum en tijdstip
      • Getroffen systeem
      • Bedrijfssituatie
      • Genomen maatregelen
      • Melder en getuigen
      • Eventuele overige aanwezigen

De gegevens van een melding zijn de eerste input voor het op te stellen herstelplan. Bij het vastleggen van deze gegevens is bovendien belangrijk om te beseffen dat de input naast een technische ook een juridische waarde heeft c.q. kan hebben.

Figuur 8.3: De vier fasen van incidentrespons en herstel.

8.2 Fase 1: Voorbereiding

Een goede voorbereiding zorgt ervoor dat een organisatie in de startblokken staat om alert te kunnen reageren bij het optreden van een incident. Een adequate ready for detect and respond maakt onderdeel uit van het security incident response process voor het betreffende object, de organisatie en de beheerder.

Een veiligheidsincident is niet altijd zichtbaar en is niet altijd eenvoudig als zodanig te herkennen. Daarom is bewustwording en training in het herkennen en melden van incidenten een eerste stap in de voorbereiding. Dit, in combinatie met screening van personeel en formaliseren van taken, bevoegdheden en verantwoordelijkheden, vormt de juiste voorbereiding van de menselijke kant op incidentrespons.

De organisatie dient daarnaast ook waarborgen in te bouwen ter voorkoming van incidenten veroorzaakt door mensen. Bij elke menselijke activiteit bestaat de kans op het, bewust of onbewust, veroorzaken van een incident. Naast controle op integriteit zijn het vierogenprincipe, werkvergunningen en geformaliseerde besluitvorming belangrijke instrumenten.

Ook dient informatie betreffende (toegang tot) vertrouwelijke gegevens beveiligd te zijn. Wachtwoordbeheer is daarom een belangrijk aspect. Mechanismen als multi-factor authentication zijn zeer aan te bevelen. Het moet verboden zijn dat wachtwoorden bij meerdere mensen bekend zijn. Voor een ontwerp- en testfase zijn tijdelijke wachtwoorden een prima uitkomst.

Qua techniek kan het ‘automatisch’ detecteren en loggen van incidenten worden ingebouwd. De doormelding en opvolging van de detecties is dan onderdeel van het incidentrespons-proces. Een nieuwe kwetsbaarheid in technische systemen kan leiden tot misbruik, maar is op zich nog geen veiligheidsincident. Een andere technische maatregel is patching. Ter voorkoming van incidenten is het adequaat en tijdig uitvoeren van patching of patchanalyses een belangrijk instrument. Het ongepatcht laten van eenmaal opgeleverde systemen, zoals tot voor kort zeer gebruikelijk was, voldoet tegenwoordig echt niet meer.

Kaders en plannen

Onderdeel van een goede voorbereiding is het maken (en oefenen!) van diverse plannen. Hierin wordt de structuur en de werking van de organisatie bij noodsituaties beschreven. Vanuit de kaders (wetten en regels) is in de diverse plannen het handelingsperspectief beschreven om de continuïteit te waarborgen. Zeker wanneer zich een crisis voordoet waarbij het object of proces wordt verstoord, c.q. uitvalt. Daarbij zijn de volgende plannen te onderkennen:

8.3 Fase 2: Detectie en analyse

Deze fase dient om vast te stellen of er inderdaad sprake is van een veiligheidsincident, en zo ja, hoe ernstig het incident is. Een classificatiematrix is een uitstekend hulpmiddel om de impact en het vereiste niveau van opschaling snel te kunnen vaststellen.

8.3.1 First response

De melder van het incident is vaak ook betrokken als first responder. Het is belangrijk om hierin bewust gedrag aan te leren dat gericht is op het voorkomen van escalatie van het incident en het veiligstellen van beschikbaar bewijsmateriaal. Een ander aspect dat hier uiteraard van belang is, is het veiligstellen van het betreffende object, zodat de veiligheid gewaarborgd is. Een voorbeeld hiervan is het afsluiten van de tunnel. Ook belangrijk hierin is de rol van de forensisch onderzoeker en de afweging tussen het zo spoedig mogelijk herstellen van de functie van het object (bijvoorbeeld images terugzetten op systemen) en bewijs verzamelen voor vervolging (waardoor herstel langer kan duren).

8.3.2 Classificatie

Classificatie kan gebeuren aan de hand van de impact (ligt het hele systeem eruit, is er data gelekt, etc.) en het soort incident. Een typische indeling is: kritiek, significant, gering en verwaarloosbaar. Classificering dient om incidenten te prioriteren.

Het is belangrijk om onderscheid te maken tussen de tijd wanneer een incident gemeld wordt, en de prioritering in de afhandeling van incidenten en escalatie. Dit is van belang om onderscheid te kunnen maken tussen verschillende niveaus van opschaling en dus het vervolg van het incidentresponsproces vast te stellen. Voor methodes voor classificering zie:

1. 1. • Federal incident notification guidelines .
      • Computer security incident handling guide, pagina 33
      • Cyber security incident response guide, pagina 36.

Classificatie en escalatie zijn nodig omdat het er niet alleen om gaat dat technisch gezien het systeem weer gaat werken, maar ook dat de juiste personen/partijen worden betrokken en geïnformeerd. Daarom is een standaard communicatieplan op basis van de classificatie noodzakelijk. Hierin moet ook staan welke incidenten direct worden gemeld naar de Autoriteit Persoonsgegevens (AP), het NCSC en/of de opdrachtgever.

8.3.3 Incidentanalyse

Na classificatie en prioritering volgt de toewijzing van incidenten aan een responsteam. De samenstelling van het responsteam is afhankelijk van de classificatie en van de fase van het project. Een typische samenstelling van een team:

1. 1. • Vertegenwoordiging van de beheerder (object, systeem).
      • Serviceorganisatie (verantwoordelijk voor deelsysteem).
      • Cybersecurity-experts intern (bv. het betrokken SOC).
      • Cybersecurity-experts extern (bv. van de service-organisatie).
      • Vertegenwoordiging communicatie.
      • Vertegenwoordiging juridische afdeling.

Cruciaal voor het responsteam is dat er volledig en juist inzicht moet zijn in de bestaande configuratie en de operationele processen. Daarnaast moet voldoende kennis beschikbaar zijn van de kwetsbaarheden en de mogelijke impact hiervan. De technische gegevens en operationele kennis komen vanuit ontwerpgegevens, CMDB, bedrijfsproces en kennis van IT/OT.

Een analyse volgt uit een grafisch overzicht van betrokken systemen, applicaties, personen en bedrijfsprocessen. Deze analyse zal een iteratief karakter hebben. Een eerste versie beschrijft de functionele impact op het bedrijfsproces. Een verdieping van deze analyse geeft inzicht op technisch niveau. De analyse houdt ook rekening met een mogelijke escalatie van het incident, waardoor de impact uitbreidt, en het gegeven dat het selecteren van corrigerende maatregelen ook weer impact kan hebben op andere delen.

8.4 Fase 3: Correctie

Nadat het responsteam het incident heeft geanalyseerd, bepaalt dit team corrigerende maatregelen. Dit vraagt om een gestructureerde aanpak aan de hand van een herstelplan. Dit plan is gericht op het selecteren en implementeren van de corrigerende maatregelen. Inhoudelijk begint het plan met de gegevens van de melding en volgt zo verder het proces van afhandeling tot en met de geleerde lessen en de rapportage van het incident. Wat de vorm betreft, kan een herstelplan variëren van een ‘simpele’ registratie in een Excel-formulier tot een compleet boekwerk met analyse van systemen en logbestanden in belang van een forensisch onderzoek. Het is aan het responsteam de vorm te kiezen.

Een herstelplan bestaat uit de volgende onderdelen:

Afronding van het incident

Na het uitvoeren van het herstelplan is het belangrijk dat het incident ook formeel en administratief af te sluiten. Dit zal per project op een verschillende manier zijn. Vaak is een incidentendatabase aanwezig om de melding en de stappen in de afwikkeling van het incident vast te leggen. Afhankelijk van de contractvorm kan, op basis van de registratie van binnengekomen en afgeronde incidenten, een verrekening plaatsvinden tussen opdrachtgever en opdrachtnemer. Het herstelplan is tevens input voor een eventueel forensisch onderzoek en kan daardoor juridische waarde krijgen.

8.5 Fase 4: Evaluatie

8.5.1 Eenmalige of structurele incidenten

Het is belangrijk om te leren van veiligheidsincidenten. Het is daarbij van essentieel belang informatie over het incident te delen met andere organisaties via bijvoorbeeld de ISAC’s binnen Nederland en daarbuiten. Incidentregistratie en periodieke rapportage over opgetreden incidenten horen thuis in een goed informatiebeveiligingsbeleid. Na het afronden van het incident wordt het herstelplan dan ook afgerond met de hoofdstukken ‘Verbetering’ en ‘Communicatie’.

Een eenmalige gebeurtenis kan de oorzaak zijn van het optreden van een incident. Een evaluatie na herstel van het incident moet vaststellen of dit incident nog vaker kan voorkomen. Als het antwoord ja is, dan is het nodig te zoeken naar een structurele oplossing. Als het een te accepteren restrisico oplevert, dan is geen verdere actie nodig en verandert er niets. Bijvoorbeeld: het risico dat ontstaat door het vergeten om een pc te locken is te verkleinen door de pc zo in te stellen dat deze automatisch wordt gelocked na een bepaalde tijd van inactiviteit. De wachttijd moet dan uiteraard afhankelijk zijn van het normale operationele proces.

Structurele incidenten worden niet opgelost met alleen een herstel van het opgetreden incident. De kwetsbaarheid van het gehele object is te verlagen door de corrigerende maatregelen ook toe te passen op andere, vergelijkbare systemen. Het is dan wel van belang om precies te weten wat de bestaande configuratie is.

Preventieve maatregelen worden uitgevoerd op basis van een regelmatige (jaarlijkse?) update van de risicoanalyse. Nieuw ontdekte kwetsbaarheden kunnen immers leiden tot extra beveiligingsmaatregelen of tot de keuze om systemen toe te voegen c.q. te vervangen.

8.5.2 Rapportages en communicatie van incidenten

De opdrachtgever moet inzicht krijgen in de opgetreden incidenten en de afhandeling daarvan. De security-contactpersoon bij de opdrachtgever krijgt urgente en kritieke incidenten direct gemeld. Een standaardrapportage geeft inzicht in de opgetreden incidenten en de genomen maatregelen. De periodieke rapportage (eens per kwartaal is een goede maatstaf hiervoor) is dan een management-samenvatting van deze standaardrapportage en zal niet alle details van het incident bevatten. Zo behoren in de samenvatting geen vertrouwelijke gegevens te staan. Het is goed om met de opdrachtgever het format en de diepgang af te stemmen. De opdrachtgever krijgt daarbij inzicht in de aard en de impact van de opgetreden incidenten en krijgt informatie over het voorkomen van vergelijkbare incidenten. Op verzoek kan de opdrachtgever inzicht krijgen in het opgestelde herstelplan. Ook als er in de rapportageperiode geen incidenten zijn geweest, moet een rapportage verschijnen.

Tot slot: als de maatregelen hebben geleid tot aanpassingen in systemen is verwerking hiervan in de as-built projectdocumentatie en in de CMDB noodzakelijk!

8.6 Praktijk: typische incidenten in verschillende projectfasen

Het online artikel Triton is the world’s most murderous malware, and it’s spreading geeft een aardig beeld van de manier waarop aanvallers te werk gaan, en langzaam via de ‘defense in depth’-lagen afzakken naar het engineeringsstation in het OT-netwerk en daar een zero-day kwetsbaarheid gebruiken.

Wat ook tot een incident kan leiden, is dat documentatie van de huidige objecten verspreid ligt bij de verschillende partijen die eraan gewerkt hebben. Hierin staat gevoelige informatie, zoals ip-adressen, firewallregels, softwarebesturing, configuraties, etc. In de praktijk deelt assetmanagement deze documentatie met nieuwe projecten, waarbij niet (altijd) wordt gekeken naar de gevoeligheid van de inhoud en relevantie voor de ontvangende partij. De persoon die de informatie deelt, is zich er niet van bewust dat hij hiermee een deur openzet voor toegang tot andere projecten. De ontvanger heeft wellicht geen intenties om de informatie verkeerd te gebruiken, maar de informatie is op deze manier veel breder beschikbaar dan gewenst. Alle partijen betrokken bij een project, dienen zich bewust te zijn dat informatie ook na afloop van het project vertrouwelijk moet blijven. Overdracht van documenten en processen als een template kan alleen na anonimiseren en verwijderen van alle inhoudelijke informatie.

9 Bedrijfszekerheid (business continuity)

9.1 Weerbaarheid van de bedrijfsvoering

Bedrijfszekerheid heeft betrekking op het geheel van organisatie, processen en systemen die al de kritische processen in de bedrijfsvoering mogelijk maken. Bedrijfszekerheidmanagement is het proces waarin een organisatie:

1. 1. • potentiële bedreigingen identificeert voor het bestaansrecht van de organisatie, zoals een natuurramp of een groot cybersecurity-incident;
      • bepaalt wat deze bedreigingen voor gevolgen kunnen hebben op de bedrijfsvoering en daarmee inzicht verkrijgt in welke systemen kritisch zijn voor de bedrijfsvoering;
      • een handelingsperspectief bepaalt waarmee de weerbaarheid van de bedrijfsvoering van de organisatie is gewaarborgd en actueel blijft;
      • vaststelt welke mensen en middelen daarvoor nodig zijn en hoe dat te organiseren is.

Een onderdeel van bedrijfszekerheidmanagement is het bedrijfszekerheidmanagementplan (business continuity plan, BCP). Het BCP is een document (of een set van documenten) waarin:

1. 1. • benoemd is bij welke scenario’s het plan in werking treedt. Voorbeelden van scenario’s zijn onbeschikbaarheid van (een deel van) de gebouwen, de uitval van kritieke ICT-infrastructuur, uitval van de energievoorziening, overstroming/brand (natuurrampen), enz. Relevante scenario’s zijn scenario’s die de operatie(s), belanghebbenden, vertrouwen en/of strategische/bedrijfsdoelen zodanig verstoren, dat daardoor de bedrijfszekerheid ernstig in gevaar komt.
      • wordt beschreven wat er van de organisatie verwacht wordt voor het herstel van de ‘verkeersdoorstroming’ en afhandeling van het incident.
      • is vastgelegd welke relevante eisen van toepassing zijn. Deze eisen bepalen het minimaal aanvaardbare operationele niveau en de toegestane hersteltijd.

Relatie tussen documenten

Het BCP heeft een sterke relatie met risicomanagement en de bedrijfsimpactanalyse (BIA). De BIA bevat de analyse en evaluatie van de potentiële risico’s die van invloed zijn, of kunnen zijn, op het operationele proces. Tevens worden hier de IT/OT-systemen/services geclassificeerd naar de mate van hun bijdrage aan het risico van het lokale verkeersmanagementsysteem en de bijbehorende operationele processen.

In het BIA-document dienen voor IT/OT-cybersecurity en informatiebeveiliging alle mogelijke cybersecurityrampscenario’s/incidenten beschreven te zijn. Enkele voorbeelden:

1. 1. • Aanval van buitenaf of van binnen uit de organisatie, gericht op de interne tunnel IT/OT-systemen en de applicaties waarbij veel systemen tegelijk ‘besmet’ zijn, zodat de beschikbaarheid/betrouwbaarheid/integriteit faalt met als gevolg dat de verkeersdoorstroming ernstig gehinderd wordt of volledig stopt.
      • Herstel van hardware/applicaties is niet mogelijk door verlies/corruptie van de back-up’s en/of de back-uplocaties/media zijn onbereikbaar. Denk hierbij aan het niet meer toegankelijk zijn van opslaglocaties (back-up-filesysteem is ‘gelocked’).
      • Documenten (informatie) zijn niet meer toegankelijk doordat IT/OT-systemen zijn ‘gelocked’ (inclusief back-upsystemen).
      • Verlies van kritische data, gegevens, informatie over een bepaalde periode.

In onderstaand figuur is schematisch weergegeven welke relatie er is tussen de verschillende processen en documenten. Het DRP wordt later in een aparte paragraaf toegelicht.

Figuur 9.1: Verband tussen BIA, BCP en DRP

In een BCP wordt voor elk concreet (ramp)scenario beschreven op welke wijze er gereageerd moet worden, zoals het betrekken van de stakeholders, opzetten van de communicatie, vrijmaken van financiën, bepalen van het besluitvormingsproces, inzet van middelen, etc. Het BCP beschrijft, op basis van de uitgangspunten in de BIA, de kritische functies en de maximale hersteltijden hiervoor, inclusief de randvoorwaarden waarbinnen de tunnel operationeel mag/kan blijven. Tevens dient er beschreven te worden (zoveel mogelijk in detail) welke stappen er door de beheerorganisatie gezet moeten worden om het verkeersmanagement in dat scenario (zo snel mogelijk weer) te kunnen continueren. In de tunnelbeheerorganisatie dienen dan ook processen ingericht te worden gericht op rampscenario’s. De organisatie dient bij een incident/ramp zodanig georganiseerd te zijn dan alle middelen zodanig dienen te worden ingezet dat de maximaal toelaatbare downtime (MTD) niet overschreden wordt.

Figuur 9.2: KPI’s voor incidentrespons.

Voor het BCP zijn uitsluitend de kritieke systemen en processen van belang die noodzakelijk zijn om de tunnel ‘operationeel te houden’. Alle overige systemen/processen zijn minder belangrijk en dus niet kritisch. Dit betekent niet dat deze systemen geen onderhoudsplan en een incidentmanagementproces hebben.

Onderstaande tabel geeft een voorbeeld van een classificatie met de daarbij behorende tijden. De weergegeven tijden zijn indicatief en dienen per tunnel bepaald te worden. Die moeten in overeenstemming zijn met de waarden uit de RAMS-analyses en de uitgangspunten van de BIA.

Enkele kritieke IT/OT-systemen voor een tunnel zijn: 3B-systeem, videomanagement en de lokale netwerken.

VOORBEELD:

Figuur 9.3: Voorbeeld tabel met BCP-classificaties

Noot: Voor een tunnel kunnen meerdere BCP’s aanwezig zijn. Naast het BCP voor de tunnelsystemen zijn er bijvoorbeeld ook het BCP voor herstel van de energievoorziening en een BCP voor de bovenliggende centrale IT-systemen met hun (externe) netwerken.

9.2 Inhoudsopgave BCP (m.b.t. cybersecurity)

In een BCP worden de volgende vragen beantwoord: wat moet er gedaan worden bij een crisis, hoe ziet de crisisorganisatie eruit, hoe is het crisisteam ingevuld (namen/rollen/functies met bijbehorende verantwoordelijkheden en bevoegdheden), hoe worden budgetten vrijgemaakt en wat is de planning van de uit te voeren activiteiten? De antwoorden op deze vragen worden in detail beschreven in de BCP-hoofdstukken:

1. 1. • Identificeren van essentiële kritische functies incl. bijbehorende noodvereisten.
      • Bepaal hersteldoelstellingen, herstelprioriteiten en meetpunten (zie tabel hierboven).
      • Beschrijft onvoorziene rollen, verantwoordelijkheden en contactgegevens van (toegewezen) personen.
      • Beschrijft hoe de essentiële/kritische functies zoveel mogelijk gehandhaafd kunnen worden ondanks dat de systemen niet werken (alternatieven).
      • Beschrijft op welke wijze informatie over de onvoorziene gebeurtenissen gedeeld wordt.

Het BCP dient goedgekeurd te worden door de eigen organisatie en de stakeholders dienen hierover uitvoerig geïnformeerd te worden. Daarnaast dient het plan periodiek getest te worden.

Naast het BCP dient er ook een rampherstelplan (disaster recovery plan, DRP) geschreven te worden. Dat plan wordt geactiveerd bij specifieke verstoringen van de bedrijfszekerheid.

9.3 Disaster recovery plan (DRP, ramp/noodherstel)

9.3.1 Doelstelling van het DRP

Disaster recoveryis een onderdeel van bedrijfszekerheidmanagement. Het BCP en DRP liggen in elkaars verlengde en zijn gericht op dezelfde IT/OT-systemen/applicaties en -processen. Doel van disaster recoveryis een heldere gecoördineerde strategie ondersteund met plannen, procedures en technische maatregelen die het (functioneel) herstel van IT/OT systemen, applicaties, data, netwerken en operaties mogelijk maken na een (cybersecurity-)incident of een crisis.

9.3.2 Beschrijving van incidenten

Het DRP beschrijft het proces dat een organisatie moet volgen om de normale bedrijfsvoering te hervatten na een ontwrichtende gebeurtenis of crisis (major incident). Het proces richt zich primair op de IT/OT-systemen met de classificatie ‘bedrijfskritisch’ en hoger (zie tabel hierboven). Dit proces dient zodanig efficiënt en effectief beschreven en ingericht te zijn dat de doelstelling die bepaald is in het BCP-plan gehaald wordt.

Om te komen tot een antwoord op de vraag wanneer het DRP wordt geactiveerd (zie ook de paragraaf hierna), is het noodzakelijk een duidelijk beeld te hebben van wat nu een cybersecurity-incident is. Over deze definitie leven twee visies die elkaar aanvullen, maar wel voor verwarring zorgen:

1. 1. 1. Elke optredende afwijking van een vastgestelde cybersecuritymaatregel is een incident. Dit wordt onder andere aangehouden in de CSIR van Rijkswaterstaat. Een voorbeeld is dan het niet-locken van het operatorbedienstation door de operator indien hij/zij de werkplek verlaat, of het niet tijdig wijzigen van de operatorwachtwoorden. Onder deze vorm vallen ook openstaande deuren van technische ruimten.
      2. Er is pas sprake van een incident wanneer er met gebruik van IT/OT daadwerkelijk een geslaagde aanval is uitgevoerd op een object waarbij systemen zijn gemanipuleerd, gegevens zijn verdwenen, gestolen of gelekt.

In hoofdstuk 8 Incidentrespons en herstel wordt verder ingegaan op de definitie en afhandeling

Voor disaster recovery mag het duidelijk zijn dat het alleen gaat om grote incidenten die de bedrijfszekerheid verstoren. Bij dit soort incidenten is mogelijk de integriteit van (veiligheids)functies aangetast. Openstellen van de tunnel mag niet plaatsvinden voordat herstel van de veilige situatie is vastgesteld.

Grote incidenten en crisissen kunnen zich in verschillende vormen voordoen: cyberaanvallen, uitval van apparatuur, ransomware, stroomuitval, natuurrampen en zelfs menselijke fouten. Om een ​​adequate reactie op noodsituaties voor te bereiden, moeten de mogelijke IT/OT-bedreigingen (zie BIA- en BCP-documenten) geanalyseerd en geëvalueerd worden en dienen DRP-plannen opgesteld te worden. Dit kan worden bereikt door potentiële gebeurtenissen op te splitsen in twee categorieën: voorspelbaar en niet-voorspelbaar.

Voorspelbare gebeurtenissen zijn verstoringen die redelijkerwijs te verwachten zijn. Een geïdentificeerde bedreiging voor een organisatie/proces kan worden beschouwd als een voorspelbare verstoring en de impact ervan kan worden verminderd door proactieve planning. Veelal wordt dit al door de reguliere onderhoudsplannen afgedekt. Onvoorziene gebeurtenissen komen voort uit de kansverdeling en de daarbij behorende impact. Voorbeelden hiervan zijn een externe cyberaanval of een ransomware-incident die meerdere IT/OT-systemen ‘besmet’. Zie de figuur hieronder waarbij voor voorspelbare incidenten tijdig maatregelen getroffen kunnen worden versus onvoorspelbare incidenten waarbij de kans daarop klein is en de impact niet altijd vooraf te bepalen is.

Figuur 9.4: Risicomatrix en voorspelbaarheid van incidenten.

Kosten-batenafwegingen bepalen in grote mate wat de scope is/wordt van de onderhoudsplannen en de mate van beveiligheidsmaatregelen die worden meegenomen in nieuwbouw- en bij (grote) renovatie­projecten. Er zal altijd een cybersecurityrisico (restrisico) blijven. Om het herstel te bespoedigen van de gevolgen bij het restrisico, dient een effectief DRP opgesteld te worden.

Figuur 9.5: De plaats van het BCP en DRP in de PDCA-cyclus.

9.3.3 Activering van het DRP

Activering van het DRP verloopt altijd via het proces voor afhandeling van storingen. De eerste melding wordt gedaan bij een contactpersoon of meldcentrale. Na een quickscan kan worden besloten om het DRP te activeren. De juiste personen worden geïnformeerd en het proces van de DRP wordt doorlopen. Na afronding van het DRP, inclusief afronding van de bijbehorende testen, wordt de melding afgesloten.

Het DRP dient geactiveerd te worden vanuit het BCP bij de volgende grote incidenten:

1. 1. • Uitval van primaire energievoorziening (inkoopzijde).
      • Uitval van energievoorziening van IT/OT-systemen in het object (achter de meter).
      • Uitval van communicatie naar extern (bv. verbinding naar een centrale bediening).
      • Uitval bedienmogelijkheden voor verkeersleiders.
      • Uitval van kritische onderdelen van OT-systemen waardoor bediening onmogelijk wordt.
      • Uitval van bewakings- of monitoringssystemen zoals camerasystemen.
      • Besmetting met malware, ransomware (middels detectie op beheersysteem).

Om de quickscan mogelijk te maken voor een niet-inhoudelijk deskundige, dienen eenduidige criteria opgeschreven te worden, bijvoorbeeld in de vorm van een checklist. Hierbij kunnen standaardvragen helpen om tot een snelle besluitvorming te komen.

9.3.4 Opbouw en inhoud van het DRP

In het DRP staan de middelen, acties, taken, standaard werkprocedures/werkinstructies, contactenlijst, organisatieschema, etc. vermeld die nodig zijn om applicatie- en serviceherstelprocessen te beschrijven in het geval van een crisis of een ramp. Het DRP beschrijft dus in detail welke maatregelen genomen moeten worden om systemen te herstellen en data te beschermen, tezamen met wie waarvoor verantwoordelijk is en wat daarvoor nodig is.

In onderstaand figuur zijn de thema’s van een DRP schematisch weergegeven.

Figuur 9.6: De thema’s van het DRP.

Een korte beschrijving van ieder thema:

1. Assemble plan

Hiermee worden de ontwerpdocumenten van het systeem bedoeld. Dit kan een beschrijving zijn van de plek waar de laatste ontwerpdocumenten staan, maar ook een fysieke kopie van de laatste ontwerpdocumenten.

2. Identify scope

Dit document geeft een globale omschrijving en/of schema van het systeem weer. In principe staat hierin alles wat hersteld moet gaan worden en hoe het verbonden is aan andere systemen. Er kan beschreven worden waar de laatste schema’s staan, maar het kan ook een fysieke kopie van de laatste schema’s zijn.

3. Appoint emergency contacts

Dit is een overzicht met de contacten om het systeem te herstellen. Dit kan een leverancier zijn, maar ook een systeemintegrator of een ICT-afdeling. Een contactenlijst met namen, telefoonnummers en e-mailadressen is noodzakelijk om te voorkomen dat er tijdens een herstelpoging naar telefoonnummers gezocht moet worden.

4. Designate disaster recovery team

Een noodherstelteam bestaat uit een aantal personen die zich richten op het plannen, implementeren, onderhouden, controleren en testen van de procedures van een organisatie voor bedrijfszekerheid en -herstel. Het hebben van een team dat zich richt op herstel na calamiteiten zorgt ervoor dat reactietijden en schade aan resources tot een minimum worden beperkt. Afhankelijk van het type incident worden er technische specialisten, externe (contract)partijen, etc. aan het team toegevoegd om het herstelproces en de herstelactiviteiten zo spoedig mogelijk te laten verlopen.

Een noodherstelteam wordt doorgaans samengesteld uit de bestaande werknemers van een bedrijf, van de CIO tot de IT-afdeling tot belanghebbenden van verschillende operationele eenheden. Geborgd moet worden dat er voldoende bevoegdheden aan het team zijn toegekend en dat specialistische kennis van de systemen en algemene kennis van de specifieke tunnel worden samengebracht.

5. Assign roles and responsibilities

Specifieke rollen binnen een noodherstelteam kunnen zijn:

1. 1. • Hoofd herstelteam – Dit kan een CIO, senior IT-manager of lid van het uitvoerend managementteam zijn. Het is zijn taak om toezicht te houden op het hele team, de inspanningen van elk lid te coördineren en ervoor te zorgen dat er een efficiënt BC/DR-plan is.
      • Crisisbeheercoördinator – Deze medewerker houdt toezicht op het beheer van gegevensherstel en initieert procedures wanneer zich een probleem of ramp voordoet.
      • Expert bedrijfscontinuïteit – Dit teamlid richt zich op de strategie die nodig is om de activiteiten voort te zetten of te herstellen in geval van een ramp. Ze moeten er ook voor zorgen dat DR-plannen aansluiten bij de zakelijke behoeften.
      • Effectbeoordeling en hersteladviseur – Deze rol wordt meestal vervuld door meerdere medewerkers met verschillende expertise in verschillende componenten van technologie. Wanneer zich een ramp voordoet, zijn zij verantwoordelijk voor het beoordelen van de hoeveelheid schade in hun specifieke gebied en de manieren om deze te herstellen. Voorbeelden van expertisegebieden zijn netwerken, servers, opslag en databases.
      • Bewaking van IT-toepassingen – Deze persoon is verantwoordelijk voor het bewaken van alle technologie op een mogelijke ramp en zorgt ervoor dat alle afzonderlijke componenten samenwerken zodra ze zijn hersteld.

6. Restore technology functionality

Hierin staat beschreven hoe en in welke volgorde herstel plaatsvindt. Ook is hierin vaak beschreven hoe systemen eerst helemaal schoongemaakt kunnen worden.

Onderstaande procedures worden beschreven:

1. 1. • Hoe vindt herstel plaats nadat het systeem gehackt of geïnfecteerd is met een virus?
      • Hoe vindt herstel plaats na bijvoorbeeld brand of waterschade?
      • Hoe vindt herstel plaats na een netwerkstoring, LAN en WAN?

Elke procedure wordt als volgt opgebouwd:

1. 1. • Activering van de procedure.
      • Beschrijving van hersteltijden, betrokken personen en contactgegevens.
      • Beschrijft alle betrokken systeemcomponenten, waaronder PLC’s, computers (cliënts en servers), routers, etc.
      • Beschrijving van de organisatie. Hoe komt de melding binnen en wie communiceert met wie?
      • Ontwerpgegevens en systeeminstellingen. Waar zijn de back-ups?
      • Het borgen en terugzetten van versies (roll-back na wijziging).
      • Beschrijving van de verificatie- en validatiemethode. Welke testen worden er uitgevoerd nadat het systeem hersteld is, voordat het systeem weer vrijgegeven wordt?
      • Afmelden en afronden van de procedure.
      • CMDB en eventueel de documentatie aanpassen
      • Evaluatie en actualisatie van de procedure.

7. Data and back-ups location

Hierin staat beschreven welke data/applicaties er teruggezet dient te worden en waar de laatste data/applicaties staan. In sommige omgevingen, die van nature vrij stabiel zijn qua configuratie, zo ook bij tunnelobjecten, kan ervoor gekozen worden om de laatste systeemback-up direct te plaatsen in de DRP.

8. Testing and maintenance

Hierin staat beschreven hoe je het DRP test, bijvoorbeeld in een aparte omgeving, en hoe je het DRP onderhoudt. Het doel is dat bij eventuele uitval, de DRP actueel is, zodat het herstel spoedig verloopt.

9.4 Borgen en testen van BCP en DRP

Het borgen en het communiceren van beide plannen dient de nodige aandacht te hebben binnen de organisatie. De betrokken medewerkers en externe partijen dienen correct en volledig geïnformeerd te worden over het BCP en DRP, zodat in geval van een crisis de betrokkenen weten wat van hen verwacht wordt en welke processen gevolgd moeten worden. Doordat het aantal crisissen zeer beperkt zal zijn, maar de impact wel zeer groot kan zijn, is het des te noodzakelijker om regelmatig de uitvoering van de plannen te testen.

10 Assetmanagement

10.1 Inleiding

Het traditionele onderhoudsmanagement is te omschrijven als ‘het garanderen dat een bedrijfsmiddel bij voortduring doet dat wat de gebruiker wil dat het doet, binnen een gegeven bedrijfsomgeving’. ‘Dat wat de gebruiker wil dat het doet’ betekent niet veel anders dan het optimum zoeken tussen de gewenste prestatie, de kosten voor het garanderen van de prestatie en het beheersen van risico’s. Kortom, het traditionele onderhoudsmanagement is het in balans houden van prestaties, kosten en risico’s tijdens de gebruiksfase van een installatie.

Bij assetmanagement gaat het om het managen van assets (‘bedrijfsmiddelen’), zoals het begrip al aangeeft. Assetmanagement voegt echter twee belangrijke fasen toe aan het traditionele onderhoudsmanagement: de ontwerpfase en de sloopfase. In de De Succesfactor op RTL7 gaat CMS-directeur Luc de Laat uitvoerig in op wat assetmanagement inhoudt.

Bij assetmanagement zijn kosten, prestaties en risico’s al vóór de ontwerpfase een belangrijk gegeven. Alvorens te starten met het ontwerp of aankoop van de installatie, moet eerst onderzocht zijn wat de mogelijke effecten zijn op de directe en indirecte kosten tijdens de gehele levensduur. Bij assetmanagement wordt echter ook verder gekeken dan de gebruiksfase: in de totale kosten wordt meegenomen wat de kosten en risico’s zijn voor het ontmantelen van de asset na het bereiken van de economische of technische levensduur. Daarnaast kijkt assetmanagement ook naar de waardecreatie door het asset. Bij assetmanagement kijkt men dus over de bedrijfsmuren heen naar de totale levenscyclus van een asset.

Assetmanagement onderscheidt de volgende fasen voor elke asset:

1. 1. • Planfase en aanbesteding
      • Realisatie
      • Exploitatie
      • Sloop

Daarnaast is er een onderscheid te maken voor nieuwbouw en renovatie. Kenmerkend voor nieuwbouw is dat er eerst een ontwerp wordt gemaakt, vervolgens dit ontwerp wordt gerealiseerd, waarna de openstelling volgt. Hierna volgt de exploitatiefase door het in gebruik nemen van de asset.

Kenmerkend bij renovatie is dat de asset reeds in gebruik is en moet blijven. Renovatie vindt dus plaats tijdens de exploitatiefase. Voor cybersecurity is het belangrijk dit onderscheid te maken, omdat de uitgangspunten verschillen. Zo zijn bij nieuwbouw alle maatregelen van begin af aan te implementeren, terwijl er bij renovatie sprake is van een vaststaande situatie. Tijdens de renovatie zal het nodig zijn nieuwe maatregelen te implementeren en bestaande aan te passen of te verwijderen. Echter, de belangrijke randvoorwaarde is dat tijdens deze renovatie de veiligheid van de asset moet zijn gewaarborgd.

Onderstaande figuur geeft de volgorde van fasen weer. Zoals de figuur laat zien, is bij nieuwbouw de realisatiefase opgedeeld in ‘Ontwerp’, ‘Nieuwbouw’ en ‘Openstelling’. Allerlei maatregelen zijn dan nieuw te implementeren. Daarentegen is tijdens renovatie het object – al dan niet geheel – in gebruik, waardoor er enerzijds sprake is van een bestaande situatie maar anderzijds nieuwe maatregelen moeten worden geïmplementeerd.

Figuur 10.1: Fasen in een project.

TIjdens of aan het einde van elke fase is het noodzakelijk de genomen maatregelen te borgen in de organisatie. Ook is er sprake van specifieke rollen in elke fase. Een overzicht van voorkomende rollen is opgenomen in 4.4 Basis-organisatiemodel voor cybersecurity. Hieronder komen per fase een aantal taken, bevoegdheden en verantwoordelijkheden aan de orde.

10.2 Planfase en aanbesteding

De planfase is de ruimtelijke fase die wordt afgesloten met een ruimtelijk besluit, zoals een tracébesluit, provinciaal inpassingsplan of bestemmingsplan. Tijdens deze fase wordt ook een tunnelveiligheidsplan opgesteld. De uitgangspunten van het cybersecuritybeleid kunnen hierin worden opgenomen en zijn dan formeel onderdeel van het vastgestelde wettelijke plan en daarmee verplichte kost voor de aanbesteding.

Aanleiding voor aanbestedingen zijn toevoegingen aan of vervangingen van bestaande infrastructuur, zowel op civiel- als installatietechnisch gebied. Levenscyclus-overwegingen, beheer en onderhoud en veranderende wet- en regelgeving zijn hierbij vaak de drijvende krachten. OT speelt voor de besturing van infrastructurele objecten een belangrijke rol. Vanwege de verdere digitalisering komt op dit gebied steeds nieuwe functionaliteit beschikbaar. Bediening op afstand is een mooi voorbeeld van zo’n nieuwe mogelijkheid. ‘Verbonden zijn’ wordt steeds belangrijker, zowel vanuit operationeel als vanuit beheer-en-onderhoud. Echter, het eenvoudig beschikbaar zijn van informatie zorgt op zichzelf vaak al voor vele belangstellenden. Het biedt voordelen, maar leidt ook tot nieuwe risico’s, waaronder op het gebied van cybersecurity.

Om cybersecurity te borgen in de hele levenscyclus van een object moet daarom de opdrachtgever bij de contractvoorbereiding nadenken over het contractueel borgen van cybersecurity. Het doel hiervan is dat een opdrachtnemer een systeem kan opleveren en beheren dat voldoet aan de cybersecurity-kaderstelling van de organisatie. Zie hiervoor ook hoofdstuk 4 Cybersecuritymanagement.

10.2.1 Overwegingen voorafgaand aan aanbesteding

De opdrachtgever moet ter voorbereiding op de aanbesteding nadenken over cybersecurity. HIeronder volgt een aantal aandachtspunten.

Bewustwording

Voor een breder veiligheidsbesef moet bewustwording ontstaan over cybersecurity binnen alle deelnemende organisaties. Cybersecurity moet uiteindelijk bij zowel de opdrachtgever als de opdrachtnemer ‘in de genen’ zitten. Zoals ook bekend is uit het algemene veiligheidsbesef, is het nemen van allerlei maatregelen alleen niet voldoende is: zonder een echt veiligheidsbesef is iedere maatregel te omzeilen.

Levenscyclus

Cybersecurity kent een eigen levenscyclus die vaak niet overeenkomt met de technische levenscyclus van het betreffende OT-systeem. Bedreigingen komen en gaan in de huidige tijd sneller dan dat een systeem veroudert. De mogelijkheid bestaat dat voordat de technische levensduur is verstreken, vervanging van een systeem noodzakelijk is vanwege cybersecurity. Vaak zijn er echter tijdens de technische levensduur nog wel maatregelen te bedenken die de levensduur kunnen rekken.

Integraal ontwerp

Cybersecurity vraagt om een integraal, discipline-overstijgend ontwerp met focus op life cycle costing (LCC). Alleen dan is een gedegen keuze te maken van te nemen technische of organisatorische maatregelen. LCC is van belang omdat cybersecurity-maatregelen gedurende de hele verdere levenscyclus van het systeem aandacht vragen. Daarom is de beschikbaarheid van het systeem ook zeer de aandacht waard. Overigens is bij OT een nachtelijke update zoals in de KA-omgeving niet altijd acceptabel.

Beheer en onderhoud

Cybersecurity vraagt om beheer en onderhoud. De bijbehorende activiteiten zijn van een andere orde dan de reguliere beheer- en onderhoudsactiviteiten voor het object. Ze vereisen andere kennis en expertise en staan soms ook op gespannen voet met de gevraagde beschikbaarheid.

Onderhoud op het gebied van cybersecurity uitbesteden, is een cybersecurity-risico op zichzelf. Het is begrijpelijk vanuit kostenperspectief en vanwege de benodigde kennis, maar het vraagt om een heel duidelijke begeleiding.

Informatiebeveiliging

Cybersecurity vraagt om een goede informatiebeveiliging omdat het onbedoeld vrijkomen van informatie al een cybersecurity-risico op zichzelf is. Tijdens de aanbesteding moet dit een punt van aandacht zijn, omdat het dan juist noodzakelijk is informatie te delen met potentiële opdrachtnemers. Alleen openheid over de bestaande situatie kan dan leiden tot de juiste oplossingen.

Nieuwbouw of renovatie?

Nieuwbouw en renovatie hebben een totaal verschillende dynamiek. Bij renovatie kan de bestaande situatie al een aantal beperkingen opleggen en het onmogelijk maken om tegen acceptabele kosten een bepaald weerstandsniveau te bereiken. Vaak geldt bij renovatie de randvoorwaarde dat de beschikbaarheid tijdens renovatie zo groot mogelijk moet zijn. Bij nieuwbouw daarentegen is cybersecurity vaak nog volledig vrij in te vullen op basis van het gewenste weerstandsniveau.

Bij renovatie geldt ook dat veel objecten stammen uit een tijd dat cybersecurity niet aan de orde was. Het is dan in het kader van integraliteit te overwegen een functie-reconstructie uit te voeren dat leidt tot een nieuw ontwerp en dat vervolgens weer de basis vormt om verder te bouwen.

Weerstandsniveau in de totale keten

Uitgangspunt voor het ontwerp is het te bereiken weerstandsniveau van cybersecurity. Dit geldt zowel voor een bepaald object, maar ook voor de keten waarin dit zich bevindt. Immers, elke keten is zo sterk als zijn zwakste schakel. Het is te overwegen het weerstandsniveau zelf te bepalen of dit door andere partijen te laten uitvoeren.

10.2.2 Tijdens de aanbesteding

Tijdens het doorlopen van de aanbesteding verdienen de volgende punten aandacht.

Informatievoorziening

Het beschikbaar stellen van gevoelige informatie betreffende cybersecurity verdient speciale aandacht. Denk bijvoorbeeld aan informatie over inbraakbeveiliging, toegangscontrole en datanetwerken, documentsystemen/-shares en CAD/BIM-omgevingen: wie mag deze informatie zien en hoe is dit afgeschermd? Dit geldt zowel tijdens het aanbestedingsproces, maar ook daarna: er zullen immers gegadigden zijn die de opdracht niet hebben gescoord.

Cybersecurity als selectiecriterium

Kennis en ervaring, zowel van proces als techniek, met het omgaan met objecten van een bepaald weerstandsniveau kan zowel in (pre-)selectie als in de kwalitatieve uitvraag van belang zijn. Het opvragen van referenties dan wel een plan van aanpak zijn hierbij mogelijkheden.

Project- c.q. tendermanagement

Cybersecurity speelt vanaf het moment van gunning van een project en dus niet pas vanaf het moment van oplevering. Sterker nog: aandacht voor cybersecurity is wellicht tijdens de de ontwerp- en realisatiefase misschien nog wel belangrijker dan na oplevering. Tijdens de ontwerpfase gebeurt namelijk het meeste preventieve werk. Herstel nadien is bovendien veel kostbaarder.

De opdrachtgever dient in voorbereiding op de aanbesteding na te denken over de eisen waaraan de op te leveren (technische) infrastructuur dient te voldoen om voldoende weerbaar te zijn tegen cybersecuritydreigingen. Daarnaast moet de opdrachtgever ook nadenken over de eisen waaraan de aanbieder moet voldoen op het gebied van cybersecurity, zowel tijdens de projectfase als de exploitatiefase.

10.2.3 Taken, bevoegdheden en verantwoordelijkheden

Tijdens de aanbesteding is er een opdrachtgever en doen marktpartijen een aanbieding. Er is in deze fase een focus op informatiemanagement (bv. documentmanagementsysteem, DMS) en screening van personeel.

Taken opdrachtgever:

1. 1. • Opnemen cybersecuritybeleid in contract.
      • Classificatie van documenten en systeem voor informatie-uitwisseling tussen partijen.
      • NDA (geheimhoudingsverklaring) opvragen voordat stukken worden verstuurd.
      • Toezien op verwijdering van aangeleverde informatie door (niet aangewezen) aanbieders.

Taken aanbieder:

1. 1. • NDA (geheimhoudingsverklaring) aanleveren en opvragen bij derden.
      • Inrichten vertrouwelijke documentomgeving.
      • Indien vereist: inrichten fysiek afgeschermde projectomgeving.
      • Cybersecurity-maatregelen opnemen in aanbieding (voor alle projectfasen).

10.2.4 Borging

Cybersecurity-maatregelen maken integraal deel uit van de aanbieding. Dit geldt voor alle drie de aspecten: techniek, mens, organisatie. Deze aspecten moeten dus aanwezig zijn in de uit te vragen eisen. Systems engineering kan helpen deze eisen in de volgende fasente valideren, waardoor het mogelijk is de vereiste maatregelen te borgen.

Daarnaast is het van belang dat informatie die onderdeel is van de uitvraag te classificeren. Zo mag gevoelige informatie enkel beschikbaar zijn in een afgeschermde omgeving pas na het tekenen van een geheimhoudingsverklaring. Ook moet in deze verklaring zijn opgenomen dat gevoelige informatie na de aanbesteding wordt vernietigd of geanonimiseerd.

Voor de algemene aspecten rondom borging, zie 6.10 Borging.

10.3 Realisatiefase

De realisatiefase van een tunnel bestaat uit de volgende deelfasen:

1. 1. • 10.3.1 Ontwerp
      • 10.3.2 Nieuwbouw
      • 10.3.3 Openstelling

Het is belangrijk zich te realiseren dat alle informatie uit een project op een enig moment interessant kan zijn voor iemand die kwade bedoelingen heeft. Daarom dient men vanaf het allereerste begin – dus reeds bij de inrichting van het project! – regels op te stellen voor het kwalificeren en behandelen van alle informatie en documentatie die het project voortbrengt.

Alle deelnemers aan het project dienen zich dan ook bewust te zijn van de risico’s op het gebied van cybersecurity. Daarom moet iedereen weten hoe men dient te handelen om de kans op het in verkeerde handen komen van de (ontwerp)informatie en documentatie zo klein mogelijk te maken.

10.3.1 Ontwerp

Cybersecurity heeft gevolgen voor nagenoeg alle aspecten van het ontwerp. Daarom dient cybersecurity als een integraal thema in het ontwerp terug te komen in plaats van het als aandachtspunt bij de verschillende specialisten van de deelsystemen te beleggen.

Het afgesloten contract bevat het uitgangspunt voor de documentatie van de ontwerpfase. Het contract bevat dan ook een veelheid aan eisen voor de opdracht. Het gros van die eisen gaat over de functionaliteit van het te realiseren object. Maar het contract zal ook niet-functionele eisen bevatten, waaronder die voor cybersecurity.

De opdrachtgever kan in het contract al bepaalde risico’s hebben onderkend. Voor risico’s waarvan de gevolgen niet acceptabel zijn, is het noodzakelijk beheersmaatregelen te formuleren. Heeft de opdrachtgever nog geen risico’s geïdentificeerd, dan moet een van de eerste activiteiten van de opdrachtnemer zijn om samen met de opdrachtgever een risicoanalyse uit te voeren. HIerbij kan IEC 62443-3-2 als leidraad dienen. Uit de ISO 27000-reeks kan eventueel ISO 27005 geschikt zijn. Deze standaard is echter vooral gericht op de KA-omgeving.

Noot: Waren IT en OT traditioneel gezien gescheiden werelden, tegenwoordig zijn steeds meer fabrieksprocessen afhankelijk van IT-oplossingen. Om beide werelden correct te beveiligen, is een geïntegreerde IT/OT-aanpak van cybersecurity noodzakelijk.

Cybersecurity in het ontwerpproces, bij nieuwbouw en tijdens onderhoud

Cybersecurity is idealiter een regulier onderdeel van het ontwerpproces van een OT-systeem en behoort tot het Safety-aspect van RAMSSHEEP. Bij veel OT-systemen in Nederland is tegenwoordig een inhaalslag nodig om het weerstandsniveau aan te passen aan de cyberdreigingen van deze tijd. In dat geval is er sprake van cybersecurity-renovatie. Het is dan mogelijk om (by-the-book) de cybersecurity-eisen in kwalitatieve en kwantitatieve termen op te stellen. Dit kan op basis van de operationele doelstellingen van het OT-systeem en een structurele risicoanalyse (dreiging, kwetsbaarheden). Dit levert dan de juiste specifieke cybersecurity-maatregelen op, en aanwijzingen om deze te implementeren. In geval van regulier onderhoud aan OT-systemen is vaak een minimale cybersecurity-eis dat een wijziging het huidige cybersecurity-niveau niet mag verminderen.

Van belang voor het ontwerp is dat het op te leveren object ‘cyberveilig’ is. Dit geldt niet alleen op het moment van oplevering, maar ook voor daarna. Het ontwerp dient daarom zoveel mogelijk rekening te houden met het kunnen uitvoeren van wijzigingen die nodig zijn om het object gedurende de levensduur cyberveilig te houden. Dit heeft impact op zowel het ontwerp van de techniek als op het ontwerp van de processen en organisatie van het beheer en onderhoud.

Tijdens de deelfase ‘Ontwerp’ is er een opdrachtgever en een opdrachtnemer. De opdrachtnemer moet zorgen voor een ontwerp dat aantoonbaar voldoet aan de geëiste regelgeving. Er is in deze fase bovendien een focus op informatiemanagement (DMS), security-by-design en screening van personeel.

Tot de taken van de opdrachtgever behoren:

1. 1. • Beoordelen cybersecurity-plannen en risicoanalyses.
      • Toetsen van ontwerpen, zowel op de bouwkundige aspecten als de operationele technologie.
      • Borgen van cybersecurity bij inzet van externen en onderaannemers.
      • Afstemmen van aanpak en invulling met beleidsbepalende instanties.
      • Bespreken van cybersecurity in MT-overleggen.

Tot de taken van de opdrachtnemer behoren:

1. 1. • Opstellen risicoanalyse en kiezen beheersmaatregelen.
      • Opstellen cybersecurity-managementplan.
      • Opstellen cybersecurity-beveiligingsplan(nen).
      • Opstellen van cybersecurity-procedures.
      • Doorzetten van cybersecurity-eisen naar andere externe partijen, zoals adviesbureaus en onderaannemers.
      • Bespreken van cybersecurity in MT-overleggen.

10.3.2 Nieuwbouw

Tijdens de uitvoering (bouwen) van een infrastructureel project speelt het onderwerp cybersecurity een belangrijke rol. Er is in deze fase een focus op veilige toegang, netwerkbeveiliging en screening van personeel (van derden).

Voor deze deelfase moet men zich bewust zijn de volgende aandachtspunten en risico’s:

1. 1. • Het organiseren van de fysieke toegangsbeveiliging tot locaties en werkplekken.
      • De toegang tot informatie-opslag: wie heeft welke bevoegdheden en hoe is een en ander afgeschermd voor onbevoegden?
      • Het opstellen en hanteren van communicatierichtlijnen intern en extern.
      • Review en goedkeuringsproces (wie mag wat zien en hoe is dit geborgd, zowel voor opdrachtgever, opdrachtnemer als bevoegd gezag).
      • Het organiseren van de beveiliging van computersystemen.
      • Enkel geautoriseerde personen mogen testen uitvoeren en hebben inzage in de testresultaten.

Tot de taken van de opdrachtgever behoren:

1. 1. • Bewustwording en training van toekomstige bedienaars.
      • Bewustwording en training van eigen personeel.
      • Toetsen van de uitvoering van cybersecurity-maatregelen.

Tot de taken van de opdrachtnemer behoren:

1. 1. • Opstellen risicoanalyse cybersecurity.
      • Vastleggen bevoegdheden van cybersecurity-functionarissen.
      • Vaststellen onder welke voorwaarden (incident) de uitvoering stil te leggen.
      • Realiseren van een beveiligde testomgeving.
      • Organiseren toegangsbewaking en -registratie.
      • Realiseren van toegangsbewaking op elke ruimte met actieve apparatuur.
      • Opstellen werkinstructie voor cybersecurity.
      • Verifiëren en valideren van gebruikersaccounts en logbestanden.
      • Doorvoeren hardening van alle IT en OT.
      • Penetratietesten (laten) uitvoeren.
      • Doorzetten van cybersecurity-vereisten naar externe partijen (leveranciers, onderaannemers).
      • Beveiligen van informatie op de bouwlocatie.

10.3.3 Openstelling

De openstelling is het moment van overdracht door de projectorganisatie aan de organisatie die de exploitatie gaat uitvoeren. Projectmatig gezien is dit een ‘moment’, een faseovergang. Vanuit het oogpunt van cybersecurity is de openstelling echter méér dan een moment: het projectteam dient zich er rekenschap van te geven dat het moment van openstelling en overdracht aan de beheer- en exploitatie-organisatie alleen kan slagen als dat goed voorbereid is. Bij de openstelling starten ook de processen die onderdeel zijn van exploitatie en van beheer. Dit betekent dat er onder andere aandacht moet zijn voor de volgende onderwerpen:

Voor het goed verlopen van de openstelling zijn de juiste voorwaarden vereist voor de faseovergang van nieuwbouw naar opstelling. Deze moeten daarom ook als deliverable van de realisatiefase zijn vastgelegd. Het project dient de projectresultaten over te dragen aan de beheerorganisatie, zodat het beheer technisch-operationeel kan starten. Op soortgelijke wijze kan het projectresultaat ook overgedragen worden aan de cybersecurity-beheersorganisatie. Zie hoofdstuk 4 Cybersecuritymanagement.

De genoemde maatregelen zijn ook te beschouwen vanuit de drie aspecten:

Om cybersecurity te borgen, dient cybersecurity in het DNA van de organisatie aanwezig te zijn en een vast onderdeel zijn tijdens elke bespreking over het onderhoud van het object. Een frequente update van het object-risicorapport maakt inzichtelijk waar en welke aandacht nodig is om de cybersecurity op het juiste niveau te brengen en te houden.

10.4 Exploitatiefase

De exploitatiefase volgt op de openstelling van het tunnelsysteem voor gebruik conform bestemming en openstellingsvergunning. In deze fase vinden bediening en bewaking plaats volgens standaardprocedures waarin ook cybersecurity is geborgd.

De tunnel is operationeel als het tunnelsysteem in gebruik is (operationele fase). Een specifieke activiteit binnen de exploitatiefase is het onderhoud: de activiteit om het tunnelsysteem ongewijzigd in conditie te houden, bijvoorbeeld door een-op-een vervanging van slijtdelen, smeren en reinigen, patchen, logbestanden uitlezen, afstellingen en instellingen controleren. Voor herhaaldelijk terugkerende activiteiten is het wenselijk volgens procedures te werken, en in die procedures kan (dient) de cybersecurity geborgd te zijn. Voor incidentele (niet-procedureel vastgelegde) onderhoudsactiviteiten kan de borging van cybersecurity maatwerk vergen.

Tijdens de exploitatiefase kan er ook renovatie plaatsvinden. Dit omvat de activiteit om (delen van) het tunnelsysteem:

1. 1. 1. opnieuw te ontwerpen, opdat die delen na aanpassing de oorspronkelijke bestemming weer ondersteunen en weer met regulier onderhoud in conditie te houden zijn;
      2. grootschalig opnieuw te ontwerpen in verband met een nieuwe bestemming.

In dit document worden twee vormen van renovatie onderscheiden; de situatie dat de tunnel korte perioden geheel gesloten en/of deels in gebruik is en de situatie dat de tunnel gedurende langere tijd geheel is afgesloten (denk aan de Velsertunnel en de Koningstunnel). Er is geen definitie te geven van ‘kort’ en ‘lang’: dit is projectspecifiek. Langdurige afsluiting van de tunnel komt qua aanpak overeen met nieuwbouw, zie paragraaf 10.3.2 Nieuwbouw.

10.4.1 Operationele fase

In deze fase ligt een focus op fysieke en logische toegangsbeheer, auditing en evaluatie, en screening van personeel.

Tot de taken van de opdrachtgever behoren:

1. 1. • Beoordelen cybersecurity-risico-analyses en cybersecurity-rapportages.
      • Houden van een jaarlijkse audit.
      • Uitvoeren netwerkmonitoring.
      • Organiseren van incidentrespons.

Tot de taken van de opdrachtnemer behoren:

1. 1. • Opstellen risicoanalyse cybersecurity.
      • Eenduidig vastleggen van bevoegdheden cybersecurity-functionarissen. Bijvoorbeeld: onder welke voorwaarden kan bij een incident een object worden stilgelegd?
      • Het registreren en bewaken van fysieke en logische toegang.
      • Realiseren van netwerkmonitoring en rapportering.
      • Organiseren en uitvoer van Incidentrespons.
      • Organiseren van patching.
      • Aandacht voor o.a. langlopende processen, documentatie, incidenten, logbestanden, rapportages opstellen/beoordelen, risico-inschattingen herzien, etc.
      • Testen van back-up- en herstelprocedures.
      • Jaarlijkse evaluatie en rapportage.

Te nemen maatregelen in deze fase zijn onder te verdelen op basis van de drie aspecten:

De exploitatiefase duurt over het algemeen het langst. Het is van belang dat er duidelijke afspraken zijn tussen en met alle betrokken partijen met concreet belegde verantwoordelijkheden. Voor de borging van maatregelen dienen continue beheerprocessen te bestaan, zoals het rapporteren (van voorgevallen incidenten, status toegangsbeheer, etc.) en overlegstructuren. Daarnaast is van belang met regelmaat de cybersecurity-risico-inschatting en het cybersecurityplan en -maatregelen te controleren en zonodig te herzien. Ook draagt het monitoren van systemen en netwerken en interne/externe audits bij aan de continue borging van maatregelen. Vanzelfsprekend moeten zowel de opdrachtgever als opdrachtnemer voor deze activiteiten beschikken over voldoende kennis en budget.

Een aantal cruciale aspecten voor de exploitatiefase is al genoemd onder ‘Openstelling’, zoals de opleiding van personeel, de uitvoering en uitvoerbaarheid van wachtwoord- en cybersecurity-beleid en de inrichting van de beheerorganisatie. Voor de exploitatiefase komt daar het uitvoeren van het opleidingsplan bij. Ontwikkelingen op gebied van cybersecurity die werkprocessen raken of beïnvloeden, moeten meegenomen worden in het lesmateriaal voor de opleidingen en trainingen.

10.4.2 Renovatie

Er is sprake van renovatie indien (delen van) het tunnelsysteem korte perioden geheel zijn gesloten en/of deels in gebruik. Langdurige afsluiting valt onder 10.3.2 Nieuwbouw. Afhankelijk van de aard van de renovatie is de renovatiefase onder te verdelen in een ontwerp-, realisatie- en sloopfase. Het is echter niet nodig hier verder op in te gaan. Wat wel van belang is, is dat er tijdens de renovatie specifieke aandacht moet zijn voor het gelijktijdig bestaan van het nieuwe en het oude systeem.

De opdrachtgever heeft bij renovatie de volgende taken:

1. 1. • Opstellen risicoanalyse.
      • Eenduidig vaststellen wie verantwoordelijk is voor de beveiliging van de bestaande situatie (in de verschillende faseringen).

De opdrachtnemer heeft bij renovatie de volgende taken:

1. 1. • Eveneens uitvoeren van een risicoanalyse.
      • Opstellen en valideren faseovergangen van oude naar nieuwe systemen.
      • Veilige afvoer van bestaande informatiedragende componenten.

Focus op: veilige toegang, netwerkbeveiliging, screening van personeel (van derden).

De start van een renovatie is identiek aan nieuwbouw: klanteisen vaststellen, inventarisatie van dreigingen uitvoeren, V-model doorlopen. Bij een renovatie zijn er aan de inventarisatie echter nog twee aspecten toe te voegen:

1. 1. • De mogelijkheid dat niet alle systeemdelen worden vervangen.
      • Bepaalde risico’s laten zich niet (makkelijk) verkleinen vanwege eerdere ontwerpkeuzes die niet (makkelijk) meer zijn aan te passen.

Bij renovatie moet er dan ook speciale aandacht zijn voor de (deels) te vervangen installaties en de beperkingen door de bestaande situatie voor de gewenste nieuwe situatie. Hier zijn bijzondere maatregelen vereist. De tijdsduur van de tunnelsluiting heeft hier bovendien ook invloed op. Veelal is dit dan ook maatwerk omdat het meer en complexere risico’s introduceert dan nieuwbouw of sloop.

Per aspect zijn er nog meer specifieke aandachtspunten te noemen.

Het bepalen welke wijzigingen aan welke systemen en installaties plaatsvinden, gebeurt in de renovatiefase. Deze wijzigingen kunnen upgrades inhouden of de complete vervanging van systemen, maar ook uitbreidingen hiervan. De uitvoering volgt de systems engineering, waarbij de (nieuwe) veiligheidseisen van toepassing zijn en integraal in het gehele renovatieproces inclusief systeem- en netwerkarchitectuur moeten worden meegenomen. Voor specifieke (nieuw)bouwaspecten zie paragraaf 10.3.2 Nieuwbouw.

Voor alle vrijgekomen systemen/installaties dient gelet te worden op bedrijfs- en persoonsgevoelige informatie. Deze systemen/installaties dienen (in ieder geval voor rijkstunnels) ter vernietiging te worden aangeboden aan Domeinen Roerende Zaken (DRZ). Een kwalitatief goed onderhouden IT/OT/applicatie-configuratiemanagementsysteem ondersteunt dit proces. Voor specifieke sloopfase aspecten zie de volgende paragraaf, 10.6 Sloop.

Veiligheidsaudits gedurende de renovatiefase (bijvoorbeeld werkplaats- en werkplekbezoeken door opdrachtgever) zullen het veiligheidsbewustzijn vergroten.

10.5 Renoveren

10.5.1 Cybersecurity is topeis bij renovatie

Cybersecurity begint bij een renovatieproject al voordat er daadwerkelijk gestart wordt met (het ontwerp van) de renovatie. Het bepalen welke wijzigingen aan welke systemen en installaties plaatsvinden, gebeurt namelijk al voorafgaand aan de daadwerkelijke renovatie. Deze wijzigingen kunnen upgrades inhouden of de complete vervanging van systemen, maar ook uitbreidingen hiervan. De uitvoering van de renovatie volgt de aanpak systems engineering, waarbij de (nieuwe) veiligheidseisen van toepassing zijn en integraal in het gehele renovatieproces inclusief systeem- en netwerkarchitectuur moeten worden meegenomen.

De initiële scope van een renovatie bestaat vaak uitsluitend uit de te renoveren systeemdelen die vanuit een levenscyclusperspectief aan vervanging toe zijn. Vanuit het oogpunt van cybersecurity van de tunnel dienen ook de systeemdelen beschouwd te worden die initieel níet bij de renovatie horen. Cybersecurity moet daarom een topeis worden bij de renovatie. Dat betekent echter wel dat er sprake is van scope-uitbreiding. Wie vanuit levenscyclusmanagement de eerste plannen voor een renovatie schrijft, loopt het risico dat onder invloed van de topeis voor cybersecurity de scope significant wijzigt, met dito gevolgen voor de begroting. Echter: zonder het hanteren van de topeis voor cybersecurity is integraal ontwerpen voor de renovatie niet daadwerkelijk ‘integraal’: de (digitale) tunnelveiligheid is niet geborgd.

Cybersecurity als topeis stellen, heeft directe invloed op techniek, organisatie en processen.

1. 1. • Kijk bij de bepaling van de technische scope niet alleen vanuit levenscyclusperspectief, maar maak cybersecurity onderdeel maken van de maatstaf voor het bepalen van de scope. Er zijn drie verschillende situaties:
        • Controle of systemen die buiten de initiële scope vallen tóch aangepast moeten worden.
        • Uitvoeren van een impactanalyse bij een een-op-een vervanging om te controleren of de functionaliteit hetzelfde blijft of dat de functie van het vervangen component wijzigt.
        • Toepassen van security-by-design bij het ontwerp van nieuwe functionaliteit.

Het verdient aanbeveling aan te haken bij het onderhoudsproces van de organisatie voor cybersecurity, daar waar het gaat over het toepassen van de topeis op de scope van de renovatie.

1. 1. • Een renovatie van een tunnel kan betekenen dat de organisatie ook gerenoveerd moet worden. Zowel in de project- als beheerorganisatie dient cybersecurity ingebed te zijn; dit is wettelijk verplicht. Vanuit de beheerverantwoordelijkheid moet een organisatie groeien naar het niveau waarop deze gestructureerd werkt aan cybersecurity. Het verhogen van de volwassenheid op cybersecuritygebied is een continu proces. De inrichting van de organisatie dient zodanig te zijn dat voor alle medewerkers de cybersecurity-strategie duidelijk is en er heldere beleidsregels en procedures ontwikkeld zijn of worden. De diverse rollen dienen gedefinieerd te zijn met ieders taken, bevoegdheden en verantwoordelijkheden.
      • Bestaande lopende processen moeten worden aangepast en herzien vanuit het perspectief van de continu veranderende dreigingen. Zit cybersecurity voldoende in de bestaande processen en wat als die bestaande processen veranderen? Het ‘fit for purpose’ houden van de processen heeft een sterke analogie met de inspecties die voor de technische installaties op regelmatige basis worden uitgevoerd. De cyclus voor de procesverbetering ligt in ordegrootte van weken tot maanden.

10.5.2 Nalatenschap in renovatieproject

De start van een renovatie is identiek aan nieuwbouw: klanteisen vaststellen, inventarisatie van dreigingen uitvoeren, V-model doorlopen. Bij een renovatie zijn er aan de inventarisatie echter nog aspecten toe te voegen, omdat er een nalatenschap is vanuit de bestaande situatie:

1. 1. • De mogelijkheid dat niet alle systeemdelen worden vervangen.
      • Bepaalde risico’s laten zich niet (makkelijk) verkleinen vanwege eerdere ontwerpkeuzes die niet (makkelijk) meer zijn aan te passen.
      • Onbekendheid met de status van de cyberweerbaarheid van de bestaande tunnel. Het uitvoeren van de quickscan kan hier inzicht in geven.

De nalatenschap zorgt ervoor dat cybersecurityrisico’s bij een renovatie anders worden beheerst dan in een nieuwbouwproject. Voor het mitigeren van deze cybersecurityrisico’s betekent dit dat beveiligingsmaatregelen uit andere ‘lagen’ van het ‘defense in depth’-model (zie hoofdstuk 6.2 van het groeiboek) gekozen moeten worden.

Voor alle vrijgekomen systemen/installaties dient gelet te worden op bedrijfs- en persoonsgevoelige informatie. Deze systemen/installaties dienen (in ieder geval voor rijkstunnels) ter vernietiging te worden aangeboden aan Domeinen roerende zaken (DRZ). Een kwalitatief goed onderhouden IT/OT/applicatie-configuratiemanagementsysteem ondersteunt dit proces. Het volgende deel van het hoofdstuk gaat in op de cruciale rol die configuratiemanagement in renovatieproject vervult.

10.5.3 Configuratiemanagement is kritisch voor het succes

Kenmerk van een renovatie is dat (delen van) het tunnelsysteem tijdelijk geheel zijn gesloten en/of deels in gebruik blijven. Tijd is voor cybersecurity bij renovatie een kritisch aspect. Onder hoge tijdsdruk worden veel en grote veranderingen in de systemen doorgevoerd. De transitieperiode vraagt in hoge mate maatwerk. Dit heeft mogelijk tot gevolg dat:

1. 1. • er (tijdelijk) meer en complexere risico’s worden geïntroduceerd;
      • veranderingen veel minder gecontroleerd plaatsvinden dan in normale situaties.

Het is essentieel dat er tijdens de renovatie te allen tijde goed zicht is op de actuele status van systemen, omdat oude en nieuwe systemen goed met elkaar samen dienen te werken:

1. 1. • zodat de (complexere) cybersecurityrisico’s effectief gemitigeerd worden tijdens de transitieperiode;
      • zodat er een actueel beeld is van de relevante kwetsbaarheden voor de tunnelsystemen op cybersecuritygebied.

Tijdens de renovatie moet er dus specifieke aandacht zijn voor het gelijktijdig bestaan van het nieuwe en het oude systeem. Goed ingericht configuratiemanagement is daarom kritisch voor een succesvol renovatieproject vanuit het oogpunt van cybersecurity.

10.5.4 Wie doet wat in een cyberveilig renovatieproject?

Allereerst is het van belang de rollen en verantwoordelijkheden te benoemen bij renovatie.

1. 1. • De opdrachtgever voor de renovatie is verantwoordelijk voor het opstellen van een risicoanalyse. Daarnaast dient hij eenduidig vast te stellen wie verantwoordelijk is voor de beveiliging van de bestaande situatie en de beoogde fasen uit de fasering van de renovatie.
      • De opdrachtnemer voert eveneens een risicoanalyse uit. Aanvullend daarop draagt de opdrachtnemer zorg voor het opstellen en valideren van faseovergangen van oude naar nieuwe systemen en een veilige afvoer van bestaande informatiedragende componenten. Aanvullende focusgebieden voor de opdrachtnemer zijn veilige (fysieke en logische) toegang, netwerkbeveiliging en screening van personeel (van derden).

Het is essentieel dat alle betrokken medewerkers en stakeholders zich bewust zijn van de cyberrisico’s tijdens de renovatie. Het risico bestaat dat het bewustzijn en het handelen ernaar onder druk komt te staan door bijvoorbeeld de planning of activiteiten die niet goed op elkaar zijn afgestemd. Door het niet-operationeel zijn van de tunnel bestaat het risico van verlaging van het veiligheidsniveau. Veiligheidsaudits gedurende de renovatiefase (bijvoorbeeld werkplaats- en werkplekbezoeken door opdrachtgever) zullen het veiligheidsbewustzijn vergroten. Dit risico (verminderd bewustzijn) kan ook beheerst worden door cybersecurity op te nemen als onderdeel/criterium op de werkvergunning en er in het startwerk-overleg aandacht aan te besteden.

10.5.5 Welke technische maatregelen vormen de basisvoorwaarden?

Door technische maatregelen is het mogelijk risico’s te verkleinen. Deels betreffen die het beschermen van vertrouwelijke informatie door bijvoorbeeld de inzet van een beveiligde data- en netwerkinfrastructuur, het classificeren van informatie en het inrichten en onderhouden van bijvoorbeeld een beveiligde file sharing-server en mailencryptie. Informatie en data overbrengen naar de tunneltechnische installaties dient op een vooraf vastgestelde wijze plaats te vinden door middel van bijvoorbeeld beveiligde notebooks/engineeringstations of geselecteerde (beveiligde) USB-apparaten. Ook is het mogelijk een stepstone/jumpserver toe te passen om hierop de patches ‘van buiten’ te screenen en te distribueren naar de doelomgeving. Een belangrijke activiteit is het maken van back-ups, zowel voor de kantooromgeving als voor de on-site systemen. Ook moeten roll-backscenario’s beschikbaar en getest zijn. Daarnaast behoren ook andere technische maatregelen tot de mogelijkheden (zie hiervoor de ringen van het ‘defense in depth’-model).

10.5.6 Gevolgen van de gekozen renovatiestrategie

Tot slot zijn er enkele risico’s die een relatie hebben met de toestandswijzigingen van de tunnel als onderdeel van de renovatiestrategie: de detectie van abnormaal gedrag wordt door technische wijzigingen bemoeilijkt, en de controleerbaarheid van de aanwezigen in de tunnel tijdens de uitvoering van de renovatie-werkzaamheden vraagt extra aandacht. Als een renovatie uitgevoerd wordt in de vorm van een langdurige volledige sluiting voor het verkeer, kan er makkelijker een goed sluitend toegangsbeleid en omgeving gecreëerd worden voor personeel en medewerkers. Denk aan een toegangspoort waar gecontroleerd kan worden op het alleen betreden door geregistreerde bezoekers en personeel. Als een renovatie wordt uitgevoerd in een vorm waarbij de tunnel bijvoorbeeld steeds overdag open is voor het publiek, wordt het lastiger om in de gesloten toestand goed beeld te houden over wie er in de tunnel aanwezig is.

10.6 Sloop

Bij de sloop van een infrastructureel object richt de cybersecurity zich met name op de vernietiging of opslag van informatie. Als af te danken informatie of informatiedragers veiligheidsgegevens bevatten, is dit een risico. Anderzijds hebben bedrijven en overheden ook een wettelijke bewaarplicht (zie regels voor overheidsarchieven en de toelichting van de Belastingdienst), waardoor niet alles mag worden vernietigd.

Er geldt dan ook voor deze fase een focus op veilige afvoer van informatiedragende componenten en het opheffen van externe transmissieverbindingen.

De taken van de opdrachtgever zijn voor deze fase:

1. 1. • Het opheffen van alle transmissieverbindingen.
      • Het ontvangen en schonen of vernietigen van netwerkapparatuur.
      • Het veilig archiveren van alle projectinformatie.
      • Het vernietigen van alle niet-gearchiveerde informatie (documentatie, backups, persoonsgegevens, logbestanden).

Voor de opdrachtnemer gelden dan de volgende taken:

1. 1. • Het classificeren van alle apparatuur in het project.
      • Het schonen of vernietigen van gegevensdragers.
      • Het overdragen aan opdrachtgever van alle apparatuur.
      • Het verwijderen van alle documentatie die op het object is aangetroffen en deze vernietigen of overdragen aan opdrachtgever.

Bij de start van de sloopfase is bepaald welke systemen te verwijderen zijn. Het ‘ontmantelen’ hiervan dient op een professionele wijze plaats te vinden. Dit houdt in dat er wordt gewerkt volgens een sloop/ontmantelingsplan dat door alle betrokken partijen is goedgekeurd. In een dergelijk plan zijn onder andere de volgende onderwerpen uitgewerkt:

1. 1. • De omvang van de sloop: welke (sub)systemen moeten weg en welke moeten tijdelijk of permanent nog blijven werken?
      • Assetlijsten van de te slopen systemen.
      • De wijze van het loskoppelen en afvoeren van de vrijkomende systemen.
      • Het beoordelen welke vrijgekomen systemen/installaties bedrijfs- en persoonsgevoelige informatie bevatten. Tevens het (in ieder geval voor rijkstunnels) ter vernietiging aanbieden hiervan aan Domeinen roerende zaken (DRZ). Denk hier aan datadragers, documentatie (opdrachtnemer en onderaannemer), switches, firewalls, instellingen in OT-apparatuur en PLC’s, enz.
      • De planning (start en tijdsduur, autorisatie betrokken personeel): hoe moet de sloopfase verlopen?
      • Het regelen van toezicht zowel op de fysieke locatie (loskoppelen en vervoer) als tijdens het logistieke proces tot en met verschrotting.
      • Het valideren van dit plan d.m.v. het opstellen van een eindrapportage.

11 Businesscase

11.1 Het hoe en waarom van een businesscase

Een veel gehoorde stelling ‘Wat wordt ik als beheerder wijzer van een businesscase cybersecurity? Ik ben ervan overtuigd dat mijn object niet getroffen kan worden’. Deze stelling is echter onjuist, want het recente dreigingsbeeld van het NCSC geeft duidelijk aan dat de kans op een digitale inbraak, juist ook op operationele bedienings- en bewakingssystemen, door criminelen of statelijke actoren uit verschillende delen van de wereld met de dag toeneemt. Het is inmiddels niet meer de vraag óf een object getroffen wordt door een cybersecurity-incident, alleen nog wannéér en in welke vorm. Op het moment dat de gevolgen zich openbaren, zal het zijn weerslag hebben op beschikbaarheid en integriteit van het object. Beide aspecten kunnen direct leiden tot veiligheids- en beschikbaarheidsrisico’s, beide behorend tot de primaire verantwoordelijkheid van de beheerder van het object.

Het doorworstelen van allerlei normen en het begrijpen van veelal onbekende termen is niet voor iedereen weggelegd. Een herkenbaar cybersecurity-incident in de context van het te beheren object kan dan enorm helpen in het nadenken over de mogelijke gevolgen voor de veiligheid en beschikbaarheid van het object. Een daaruit volgende risicoanalyse geeft inzicht in de dreigingen, kwetsbaarheden, risico’s, te accepteren restrisico’s en te nemen maatregelen. Een businesscase maakt vervolgens de kosten van de te nemen maatregelen ten opzichte van de te nemen risico’s inzichtelijk. Het afwegen van de kosten van de maatregelen tegen de aanwezige risico’s helpt in het selecteren van, ook kostentechnisch, geschikte maatregelen.

Het is goed te bedenken dat cybersecurity feitelijk risicomanagement is. Cybersecurity voorziet in het reduceren van de kans op schade en letsel door een cyberincident en het snel kunnen herstellen daarna. Voor de businesscase betekent dit dat de risico’s die gemitigeerd worden door cybersecurity bestaan uit de kans op schade en letsel en een gevolg van het niet-halen van de doelstellingen (KPI’s) voor veiligheid, beschikbaarheid en privacy. Ook kunnen boetes als gevolg van handhaving op contract of wet, de risico’s zijn waarvan de kans verlaagd moet worden.

De kostenkant van de businesscase betreft dan:

1. 1. • De kosten voor preventieve maatregelen voor de bescherming tegen dreigingen op kwetsbaarheden in het systeem, ter voorkoming van een incident.
      • De kosten voor preventieve maatregelen in geval van analyse en herstel van het systeem en de operatie, als gevolg van een incident.

Aan de batenkant van de businesscase staan dan de te mitigeren risico’s in termen van %-kans x type en omvang (euro) zoals:

1. 1. • Fysieke schade (fysieke incident door het cyberincident, zoals een meervoudige botsing omdat de tunnelverlichting op afstand plots wordt uitgezet).
      • Financiële schade (bijvoorbeeld zoals economische en maatschappelijke schade door dagen of wekenlange onbeschikbaarheid en eventuele boetes).
      • Letsel(schade) (bijvoorbeeld een fietser die van de roltrap valt omdat die op afstand plots wordt omgedraaid *).
      • Imagoschade (inclusief communicatiekosten).

Restrisico’s en de businesscase

Daarnaast is het van belang vast te stellen welke restrisico’s te accepteren zijn. In dat geval wordt bewust niet geïnvesteerd in de preventieve maatregelen voor een zeker risico (of type dreiging), maar worden de schade en letsel bij dat risico als een gecalculeerd restrisico geaccepteerd. Het is goed om die gecalculeerde restrisico’s ook op te nemen in de businesscase.

11.2 Fasen in cybersecuritybeleving

Om de ontwikkeling van een beheerorganisatie in haar cybersecurity beleving te analyseren en te blijven volgen, kan onderstaand schema zeer behulpzaam zijn. Door hiermee de mate van volwassenheid te bepalen worden ook de te nemen stappen duidelijk.

Figuur 10.1: Volwassenheidsfasen cybersecurity

11.2.1 Ontkenning

In deze fase overheerst de gedachte dat cybersecurity geen bedreiging vormt voor de operationele activiteiten. De redenen kunnen divers zijn: ‘wij hebben nooit incidenten gehad’, ‘onze systemen zijn niet verbonden aan internet’. De beheerder wordt er niet op geattendeerd, omdat de medewerkers dit risico (ook) niet zien, cybersecurity voegt niets toe aan het operationele resultaat (beschikbaarheid en veiligheid) en wordt met name gezien als een extra kostenpost.

Deze ontkenningsfase kan doorbroken worden door:

1. 1. 1. Feiten en informatie te verzamelen door de interne organisatie of door derden (consultants, verkopers, overheden, …),
      2. Informatie te presenteren in voor het management begrijpelijke termen.
      3. Indien mogelijk voorbeelden uit de eigen organisatie aan te dragen.

Communicatie, gesprekken en discussies zijn nodig om naar de fase ‘Erkenning’ te kunnen gaan.

11.2.2 Erkenning

In deze fase beseft de beheerder dat cybersecurity een risico is voor de dagelijkse operatie en bedrijfsvoering waarvan de impact enorm kan variëren. Intern wordt dit onderwerp op de agenda gezet. Andere afdelingen zoals IT, automatisering, health safety environment, etc. worden betrokken in de beeldvorming voor het het verder onderzoeken van dit thema. Het draagvlak binnen de organisatie gaat groeien, waarmee de volgende fase wordt geïnitieerd.

11.2.3 Verkenning

De beheerder geeft de opdracht (een deel van het budget wordt vrijgemaakt) aan de interne organisatie (eventueel aangevuld met een of meer externe consultants) om een onderzoek op te starten. De doelstelling van dit team is om vast te stellen waar de risico’s liggen, wat het geaccepteerde restrisico is en welke delen van de organisatie onderzocht worden; is dit het enterprise netwerk (IT), de operationele systemen, facility management systemen (brandmeldcentrale tunnel/gebouwen), energiemonitoringsysteem, fysieke beveiligingssystemen, energievoorziening installaties (middenspanning/laagspanning/NSA), … Elk deel dient nader onderzocht te worden om de risico’s en mogelijke gevolgen in kaart te brengen met een eerste inschatting van het te verwachte benodigde budget. Meestal betekent dit voor de verouderde systemen dat deze gemoderniseerd of zelfs vervangen moeten worden. Tevens dient er een ‘high level’ planning te worden gemaakt. Vervolgens worden risico, scope, kosten en planning met het management besproken. Bij een positief besluit zal het initiatief gegeven worden voor het maken van een businesscase en zal de volgende fase gaan starten.

11.2.4 Actie

In deze fase wordt de opdracht gegeven voor het schrijven van de businesscase. Hierin worden er diverse scenario’s beschreven en wordt het ‘beste’ scenario verder uitgewerkt. De opzet van de businesscase is organisatie-afhankelijk. Verderop is een businesscase uitgewerkt in een bepaald format. De businesscase wordt intern besproken en bij goedkeuring zal het project (programma) opgestart worden. Een projectorganisatie zal worden ingericht met als doel om de (diverse) doelstellingen binnen de scope, het budget en de planning in relatie tot het gewenste cybersecurity te realiseren. Na het afronden van het project dienen de organisatie, de interne (en externe) processen en de techniek zodanig ingericht te zijn dat het cybersecurityniveau gehandhaafd blijft.

11.2.5 Volhouden

In deze fase is het van groot belang dat de organisatie en de externe partijen (zoals bedrijven die onderhoud plegen) zich bewust blijven van de cybersecurity én er ook naar blijven handelen. Terugval ligt op de loer; oude en vertrouwde gewoontes komen weer terug met als gevolg dat het cybersecurityrisico weer gaat toenemen. Continue aandacht is noodzakelijk in de vorm van kwaliteitsbewaking en borging. Periodieke controles, assessments en het continu monitoren zal nodig zijn. Cybersecurity moet een onderdeel worden van het life cycle management proces.

In het proces zijn verschillende lussen mogelijk:

1. 1. • De ideale lus is van verkennen naar actie naar volhouden. Indien de organisatie zich in deze loop bevindt, zal het cybersecurityniveau continu bewaakt en bijgesteld worden. De installed base vormt een belangrijke basis, op deze database zal filtering (policies) plaatsvinden, zoals het signaleren van niet-ondersteunde besturingssystemen (Windows XP, Windows 7, …), systemen die security-incidenten veroorzaken (kwetsbaarheden), netwerkincidenten, etc. Op basis van de filterresultaten wordt een lijst samengesteld van systemen die geupgrade/vervangen moeten worden. Tevens dienen de processen, nieuwe technieken en de potentiële bedreigingen en risico’s opnieuw bekeken te worden. Het beleid wordt hierop weer aangepast.
      • De lus van erkenning naar verkenning naar erkenning. In de erkenningsfase is de overtuiging aanwezig om een onderzoek op de starten (verkenning). Uit dit onderzoek kan naar voren komen dat er geen/weinig risico’s zijn (kans x impact) en zal er geen businesscase opgesteld worden. Een memo kan volstaan dat er een risico-inventarisatie, -analyse en -evaluatie heeft plaatsgevonden met als resultaat een beperkt risicoprofiel.
      • Terugval-lus: terugvallen naar ontkenning Na het uitvoeren van de risicoanalyse en het implementeren van de geselecteerde maatregelen kan een (vals) gevoel van veiligheid ontstaan (‘Ik heb alles geregeld’) met een terugval naar oud gedrag. Dat gaat voorbij aan de mogelijkheid dat nieuwe dreigingen ontstaan of nieuwe kwetsbaarheden bekend worden die mogelijk nieuwe maatregelen vereisen.

11.3 Aspecten van een businesscase in relatie tot cybersecurity

In onderstaande figuur worden, in algemene zin, verschillende aspecten van een businesscase getoond.

Figuur 10.2: De aspecten van een businesscase

In onderstaande toelichting gaat het specifiek over een businesscase voor het uitvoeren van maatregelen op het gebied van cybersecurity in de (kritieke) infrastructuur. Het gaat hier niet om een businesscase voor het realiseren van een nieuwe dienst of een nieuw product.

1. Achtergrond

In een businesscase moet altijd aandacht worden besteed aan de achtergrond waartegen de businesscase is opgesteld. In het geval van een object in de infrastructuur is dat de bediening, besturing en bewaking van die infrastructuur en het ervoor zorgen dat de gebruikers van die infrastructuur erop kunnen vertrouwen dat het gebruik veilig is.

2. Toegevoegde waarde

In dit deel van een business case wordt vaak gesproken in kwalitatieve termen. Het nemen van maatregelen op het gebied van cybersecurity levert vaak geen direct meetbare waarde op in termen van opbrengsten. De waarde zit hem echter in het verkleinen van de waarschijnlijkheid dat zich een incident met grote gevolgen voordoet. Ook kan de waarde (deels) bestaan uit het voldoen aan (wettelijke) kaders die van toepassing zijn en opleggen dat risicomitigerende maatregelen nodig zijn. Deze kunnen dan, soms direct, zijn gerelateerd aan cybersecurity (zoals de Wbni), maar ook, soms indirect, betrekking hebben op de veiligheid.

3. Alternatieven

In een goede businesscase worden, naast de ‘aanbevolen’ maatregel, een of meerdere alternatieven voorgesteld. Een van die alternatieven hoort gebaseerd te zijn op het scenario ‘niets doen’. Daardoor wordt het mogelijk een afweging te maken tussen ‘niets doen’ en maatregelen implementeren. Van elk van die maatregelen zijn dan ook de voor- en nadelen, de kosten en de opbrengsten in kaart gebracht waarop de besluitvormers hun keuze kunnen baseren. In een businesscase voor cybersecurity-maatregelen zijn de alternatieven te vinden in het accepteren van een hoger of lager risiconiveau met bijbehorende gevolgen. Een hoger risiconiveau accepteren betekent minder maatregelen realiseren en dus minder investeren, maar met een kans op hoge kosten als het risico zich voordoet. Een lager risiconiveau accepteren betekent hogere investeringen (eventueel gefaseerd) en een kleinere kans op hoge kosten op termijn. Dit principe kan worden gepresenteerd als een trade-offmatrix (TOM) waarin de verschillende aspecten naast elkaar worden uitgewerkt.

4. Opbrengst

Dit deel van de businesscase beschrijft wat het voorgestelde gaat opleveren. Hierbij wordt vaak zoveel mogelijk gesproken in kwantitatieve termen, bij voorkeur in geld. Bij cybersecurity gaat het enerzijds om het verlagen van de waarschijnlijkheid dat zich een incident voordoet bij een digitale inbraak (met maatregelen gericht op identificatie, preventie en detectie) en anderzijds om het verkleinen van de gevolgen van een dergelijk incident (maatregelen gericht op correctie en herstel; zie hiertoe ook het NIST Cybersecurity Framework, The five functions). Daarbij kunnen de gevolgen financieel zichtbaar worden gemaakt door de kosten van eventueel aangerichte schade aan object en/of apparatuur (herstelkosten) te combineren met de kosten van de impact op de operationele (kosten van niet-beschikbaarheid, extra personeel, etc).

5. Bedrijfsdoelstellingen versus risico’s

Dit deel van de businesscase plaatst het voorstel tegen het licht van de doelstellingen van het bedrijf (waaronder de veiligheid en beschikbaarheid). De risico’s die met cybersecurity worden gemitigeerd, zijn de afwijkingen op die bedrijfsdoelstellingen. Daarnaast is aandacht nodig voor de (expliciet te accepteren) restrisico’s; immers, alle risico’s uitsluiten is onmogelijk. In het geval van infrastructuur is een bedrijfsdoelstelling bijvoorbeeld het ‘vlot, veilig en betrouwbaar kunnen gebruiken van de beschikbaar gestelde infrastructuur voor het vervoer van mensen en goederen’. Hier kan dan worden beargumenteerd dat de opbrengst uit het onderdeel ‘Opbrengst’ een bijdrage levert aan die doelstelling. Veiligheid en beschikbaarheid dienen bij voorkeur gekwantificeerd te worden in termen van bijvoorbeeld het aantal slachtoffers per jaar met lichte verwondingen, of aantal uren uit bedrijf per jaar.

6. Tijd

Dit deel van de businesscase benoemt de tijd die nodig is om het voorgestelde te realiseren en de tijd (manuren) die nodig is om de maatregel uit te voeren tijdens de operatie, zowel door gebruikers als door onderhouders. Voor cybersecurity zal bijvoorbeeld ook een afweging gemaakt kunnen worden in welke volgorde de maatregelen moeten worden gerealiseerd.

7. Risico’s

In dit deel wordt ingegaan op de risico’s die verbonden zijn aan het uitvoeren van het voorgestelde plan, en aan de maatregelen om die risico’s te beheersen. Dat is ook nodig bij het realiseren van maatregelen op het gebied van cybersecurity, want hieraan zijn ook risico’s verbonden die beheerst moeten worden.

8. Investering

Tot slot wordt uiteengezet welke investering nodig is om het voorgestelde te realiseren. Daarbij dient ook rekening gehouden te worden met het effect van de te nemen maatregelen op de operationele kosten. In een businesscase voor het realiseren van cybersecurity-maatregelen zal de investering deels in geld zijn uit te drukken en deels in tijd van medewerkers (maar die kosten ook geld), aangezien beheersmaatregelen op het gebied van cybersecurity altijd gevolgen hebben voor techniek, mensen (houding, gedrag, bewustzijn) en processen.

Zoals in de inleiding al is aangegeven, en ook duidelijk in dit groeiboek tot uiting komt, kent het onderwerp cybersecurity meerdere aspecten; mens, organisatie en techniek. Het nemen van maatregelen moet altijd gezien worden als een balans tussen die verschillende aspecten. Als zwaar wordt ingezet op technische oplossingen, maar de mensen die ermee moeten werken niet worden geholpen in hun taak en hen niet wordt uitgelegd waarom de maatregelen zijn genomen zoals ze zijn, zullen die mensen wegen gaan zoeken (en vinden) om zichzelf het leven makkelijker te maken. Een alom bekend voorbeeld is het opschrijven van wachtwoorden op een geeltje dat onder het toetsenbord wordt geplakt. In een wat uitgebreidere vorm is de ondergang van het bedrijf Diginotar aan deze onbalans te wijten (zie het boek Het is oorlog maar niemand die het weet van Huib Modderkolk).

Bijlage 1 Ervaringen uit de praktijk

In deze bijlage zijn bevindingen uit de praktijk opgenomen die aangetroffen kunnen worden bij inspecties en na evaluaties van incidenten. Bij de bevindingen worden voorbeelden genoemd van beheersmaatregelen om weerbaar te zijn tegen cyberrisico’s.

Zie voor actuele hacks de meldingen de site van het Nationaal cybersecuritycentrum (NCSC).

B1.1 Gelaagde beveiliging

Bij het beveiligingen van een infra-object wordt gewerkt volgens het principe van gelaagde beveiliging:

Figuur B1.1: Het principe van gelaagde beveiliging.

Als eerste moet het een hacker lukken toegang te krijgen tot de systemen. Dit kan via het netwerk of door zichzelf fysiek toegang te verschaffen tot de ruimtes waar de systemen staan. Eenmaal bij de systemen, kan worden geprobeerd toegang te krijgen tot de systemen of deze te beïnvloeden. Dit kan door accounts en wachtwoorden te misbruiken of door gebruik te maken van software, virussen, aanwezige kwetsbaarheden, enz. Voor de tunnelbedienaar, -beheerder of onderhoudsmedewerkers is het belangrijk dat zij dit signaleren en herkennen. Vervolgens moeten ze weten wat ze moeten doen. Als het onverhoopt fout gaat, moet de bedienaar weten hoe te handelen om de impact en verdere schade te beperken.

B1.2 Fysieke toegangsbeveiliging

Bevindingen

1. 1. • Onderhoudsmedewerkers zijn vaak onaangemeld op locatie, de tunnelbedienaar heeft geen beveiligingstaak en laat de mensen binnen. Risico: een hacker komt zo binnen.
      • Toegangsprocedure ontbreekt waar dat nodig is, maar ook gewoon hang- en sluitwerk voldoet vaak niet aan de eisen op het gebied van inbraakwering. Risico: een hacker kan eenvoudig inbreken en zich toegang verschaffen tot ruimtes waarin de systemen staan.

Maatregelen

1. 1. • Sleutel- of toegangsprocedure invoeren/actualiseren/naleven.
      • Altijd aanmelden op een locatie, geldt met name voor de opdrachtnemers.
      • Kwaliteit van hang- en sluitwerk op orde brengen en houden.
      • Werken met beveiligingszonering (op terreinen en in gebouwen).

B1.3 Netwerkbeveiliging

Bevindingen

1. 1. • Het onterechte geloof in de isolatie van het SCADA-systeem van andere netwerken maakt dat mensen onvoldoende maatregelen treffen op andere vlakken. Risico: risicobewustzijn neemt af waardoor het systeem kwetsbaar wordt.
      • Er zijn directe (internet)verbindingen met de tunnelsystemen. Risico: malware-besmetting van SCADA of open toegang tot SCADA door onbevoegden.
      • Er zijn verschillende verbindingen tussen kantoorautomatisering en het SCADA-netwerk. Risico: malware-besmetting van SCADA of toegang tot SCADA vanuit kantoorautomatisering.
      • Er zijn verschillende modems en open poorten die voorheen gebruikt werden om toegang te krijgen tot SCADA vanaf internet. Risico: misbruik van het netwerk wordt hierdoor heel eenvoudig voor een hacker.

Maatregelen

1. 1. • Het SCADA-systeem isoleren van andere netwerken.
      • Monitoring en controle op de verbindingen met het tunnelsystemen.
      • Verwijderen van verbindingen tussen kantoorautomatisering en tunnelsysteem.
      • Verwijderen van openstaande poorten en modems (zonder functie).
      • Authenticatie en encryptie.
      • Realiseer een gecontroleerde route om ‘van buiten naar binnen’ te kunnen komen met behulp van bijvoorbeeld een jumpserver waarop de security goed is geregeld en waarop permanent gemonitord wordt.

B1.4 Logische toegangsbeveiliging

Bevindingen

1. 1. • Functionele accounts in plaats van persoonlijke accounts. Risico: niet te achterhalen wie wat gedaan heeft als er iets misgaat.
      • Wachtwoorden worden vrijwel nooit gewijzigd. Risico: iedereen die ooit met de tunnel te maken had, kan inloggen.
      • Wachtwoorden staan vrijwel altijd in de handreiking ter plaatse. Risico: niet-geautoriseerde mensen kunnen ook inloggen.

Maatregelen

1. 1. • Actualiseren en aanscherpen wachtwoordbeleid.
      • Actualiseren en aanscherpen inlogprocedures, bijvoorbeeld het toepassen van multi-factorauthenticatie.
      • Zodra procedures zijn ingevoerd, wachtwoordwijzigingen doorvoeren.
      • Locken van beheer- en bedienwerkplekken na gebruik en bij afwezigheid.

B1.5 Anti-malware en patchen

Bevindingen

1. 1. • Mogelijk malware gevonden in SCADA-netwerk. Het ontbreken van anti-malwarevoorzieningen. Risico: malware kan het systeem ongewenst beïnvloeden of toegang op afstand mogelijk maken.
      • Er wordt niet gepatcht, alleen als SCADA niet werkt. Ook wordt nog vaak hele oude software gebruikt. Risico: via een kwetsbaarheid in het systeem kan de hacker de logische toegang omzeilen of kan malware een DoS veroorzaken of toegang openzetten.

Maatregelen

1. 1. • Verbod op aansluiten ongescande USB-sticks of laptops.
      • Verwijderen van de gevonden malware en toepassen van anti-malwarevoorzieningen rond de tunnelsystemen.
      • Onderhoudscontracten aanpassen met maatregelen tegen malware.
      • Vervanging van niet meer door de leverancier ondersteunde software (geen beveiligingsupdates).
      • Gecontroleerde securitypatches via een portal door een systeembeheerder laten plaatsen.

B1.6 Signalering

Bevindingen

1. 1. • Bedienaars zien alle vreemde meldingen als een technische storing van de SCADA-systemen. Risico: als er echt wordt gehackt, dan wordt dit niet meer als afwijking herkend, met als gevolg dat de kwetsbaarheid waar de hacker gebruik van heeft gemaakt niet gezocht of ontdekt wordt en de hacker, na functieherstel door een onderhoudsmedewerker, weer verder kan gaan.
      • De onderhoudspartij zoekt niet naar kwetsbaarheden of malware. Risico: er kunnen, zonder dat het bekend is, kwetsbaarheden of malware aanwezig zijn, waardoor een hacker zijn gang kan (blijven) gaan.
      • Niet alle tunnelsystemen schrijven loggegevens weg of deze worden niet bewaard. Risico: er kan niet achterhaald worden wat de oorzaak van afwijkend gedrag is, waardoor een hacker zijn gang kan (blijven) gaan.

Maatregel

1. 1. • Eigen en ingehuurde medewerkers moeten voldoende bewust zijn van en bekend zijn met de gevaren (cybersecurity-bewustzijn). Dit is te bevorderen met:
        • Gerichte workshops voor tunnelbedienaars (bewustzijntraining).
        • Training (e-learning) voor onderhoudsmedewerkers en beheerders.
      • Bij het vermoeden van een cyberincident altijd een incidentmelding bij de incidentverantwoordelijke doen. Eventueel een veiligheidsspecialist inschakelen voor advies.
      • Opstellen en uitvoeren van een procedure voor cyberincidenten.
      • Inrichten van actieve monitoring door een security operations center (SOC).
      • Loggegevens van alle tunnelsystemen bijhouden en opslaan.

B1.7 Handelingsperspectief

Bevindingen

1. 1. • Er is geen tunnel-specifiek handelingsperspectief voor een cyberincident aanwezig. Risico: de onderhoudspartij reset het SCADA-systeem en de hacker kan opnieuw zijn gang gaan of de volgende tunnel hacken. De tunnelbeheerder is ‘blind’ voor hackers.

Maatregelen

1. 1. • Opstellen van een tunnel-specifiek handelingsperspectief voor verschillende hackscenario’s.
      • Bij ernstige verstoring van het normale (bedien)proces de noodstop gebruiken ter voorkoming van verdere schade/gevolgen.
      • Crisismanagementproces volgen.
      • Eerste reactie van de bedienaar is om de tunnel af te sluiten. Dat is goed.

B1.8 Back-ups en assetmanagement

Bevindingen

1. 1. • Schone back-ups zijn er wel, maar zijn niet altijd up-to-date of direct toegankelijk. Risico: het herstel van de functie duurt onnodig lang, en de laatste wijzigingen gaan verloren.
      • Schone en recente back-ups zijn er wel, maar het herstelproces voor de hele keten is nooit geoefend. Risico: het weer operationeel krijgen van het systeem duurt onnodig lang.
      • Het assetmanagement is onvoldoende op orde. Documenten worden ad hoc soms wel en soms niet bijgewerkt en verspreid. Risico’s: 1) als herstel of herbouw nodig is, is onvoldoende betrouwbare documentatie beschikbaar. 2)Als niet bekend is welke versies van software zijn geïnstalleerd, kan niet gereageerd worden op meldingen van een CERT over nieuwe kwetsbaarheden of hacks.

Maatregelen

1. 1. • Regelmatig maken of updaten van back-ups en testen of terugzetten lukt.
      • Registratie van de software en de documentatie bijwerken.
      • Verbeteren van het beheerproces voor software- en documentatiebeheer.
      • Verbeteren van het wijzigingsproces.
      • Met onderhoudspartij contractueel borgen dat documentatie up-to-date blijft.

Bijlage 2 OT vs. IT

De IEC 62443-standaarden zijn geschreven vanuit de industriële omgeving (operationele technologie, OT). OT-systeem zijn opgebouwd uit ICS-, SCADA- en PLC- en IO-systemen en omvatten software, firmware en hardware. Binnen OT zijn confidentiality (vertrouwelijkheid), integrity (integriteit) en availability (beschikbaarheid) meer volgend: een tunnel moet operationeel blijven om te voorkomen dat er een verkeersinfarct ontstaat, waarbij informatie breder beschikbaar is dan vanuit vertrouwelijkheid gewenst is.

De ISO 27000-standaard is vooral gericht op kantooromgevingen gebaseerd op informatietechnologie (IT), zoals kantoorautomatisering (SAP, Microsoft Office, e.d.). Binnen IT is vertrouwelijkheid het belangrijkst, gevolgd door integriteit en beschikbaarheid: wie heeft bijvoorbeeld toegang tot welke (vertrouwelijke) bedrijfsgegevens?

Onderstaande tabel laat de verschillen tussen IT- en OT-systemen zien (bron: Applied Control Solutions).

Noot:

Waren IT en OT traditioneel gezien gescheiden werelden, tegenwoordig zijn steeds meer fabrieksprocessen afhankelijk van IT-oplossingen. Een gevolg hiervan is dat de OT-omgeving vaker getroffen wordt door malware vanuit de IT-omgeving. Sterker nog, in de praktijk blijkt dat meer dan de helft van de malware-problemen in een OT-omgeving voortkomt uit de eigen IT-systemen. De ontwikkeling van Internet of Things (IoT) heeft inmiddels de OT-wereld bereikt. Om beide werelden correct te beveiligen, ligt een geïntegreerde IT/OT-aanpak van cybersecurity voor de hand.

Bijlage 3 Cybersecurity en tunnelveiligheid

B3.1 Aanleiding

Na de lancering van het vernieuwde groeiboek Cybersecurity tunnels in 2019 werd al vrij snel helder dat het aspect cybersecurity door de verantwoordelijken voor tunnelveiligheid niet als kritisch onderdeel van de tunnel werd gezien. Reden hiervoor leek het feit dat de Tunnelwet (2013), Wet aanvullende regels veiligheid wegtunnels (2020) en de Regeling aanvullende regels veiligheid wegtunnels (2020) geen harde relatie legt tussen cybersecurity en tunnelveiligheid. Cybersecurity is hierdoor ook niet opgenomen in het Toetsingskader Tunnelveiligheid en wordt nog niet meegenomen als potentieel risico in de risicobeoordeling. Tegelijkertijd is het evident dat cyberincidenten de oorzaak kunnen zijn van fysieke incidenten. Bovendien is met de Wet beveiliging netwerk- en informatiesystemen (Wbni) voor aanbieders van essentiële diensten (waaronder tunnelbeheerder) de wettelijke verplichting ontstaan om ICT-systemen meer en beter tegen de risico’s van cyberincidenten te beveiligen.

Vanuit dit oogpunt heeft de werkgroep in 2020 in aanvulling op het groeiboek de ‘memo Cybersecurity en tunnelveiligheid‘ opgesteld waarin de relatie wordt gelegd tussen cybersecurity en tunnelveiligheid en gepleit wordt om cybersecurity als expliciet aspect mee te nemen in het tunnelveiligheidsdossier.

Hierop voortbordurend is in 2021 gewerkt aan het concreet maken van de meetbaarheid van tunnelveiligheid met het oog op cybersecurity. In feite is een combinatie gemaakt van de memo en de Quickscan cybersecurity tunnels.

B3.2 Inleiding

Tunneloperators, tunnelbeheerders en hun veiligheidsbeambte, bevoegd gezagen en alle andere stakeholders zijn er bij gebaat dat de tunnel, met de aangebrachte tunnelinstallaties, betrouwbaar is en daarmee beschikbaar en veilig is voor exploitatie én dat ook in de toekomst blijft. Als tunnelinstallaties niet betrouwbaar (blijken te) zijn, moet de vraag worden gesteld of de tunnel wel veilig is en dus, volgens de Warvw, wel open mag blijven.

Cybersecurity is voor het merendeel van de verantwoordelijke functionarissen voor tunnelveiligheid een duister en moeilijk te bevatten ontwikkeling waaraan helaas niet te ontkomen valt. Cyberincidenten hebben zich de afgelopen jaren veelvuldig voorgedaan en het is dan ook niet de vraag óf er een cyberincident gaat plaatsvinden maar vooral wanneer dit gebeurt.

Waar constructieve, werktuigbouwkundige en elektrotechnische risico’s zich over het algemeen helder en zichtbaar voordoen en zich redelijk langzaam ontwikkelen, is dat voor cyberrisico’s niet het geval. Een cyberincident kan zich in heel korte tijd ontwikkelen zonder dat er vooraf heldere, en vanaf de buitenkant direct waarneembare, signalen zijn. Het wordt pas zichtbaar wanneer zich er fysieke incidenten en/of niet verklaarbare storingen gaan voordoen. De oorzaak kan al geruime tijd in de vorm van een ongewenste indringer of ‘slapend’ virus in het systeem aanwezig zijn zonder dat dit eerder is opgevallen. Dat zoiets niet is geconstateerd, komt doordat er geen actieve monitoring- en bewakingsfuncties zijn opgenomen in het ICT-/OT-netwerk van de tunnel.

B3.3 Projectfase

Omdat cyberincidenten kunnen leiden tot fysieke (veiligheids)incidenten, zullen, in de projectfase van een nieuwe of te renoveren tunnel, cyberrisico’s opgenomen moeten worden in het risicodossier, op basis waarvan eisen gesteld kunnen worden aan de cybersecurity. De aannemer kan vervolgens de expertise inschakelen om ervoor te zorgen dat de tunnelbeheerder aan zijn zorgplicht kan voldoen. De werkzaamheden voor de aannemer bestaan uit het ontwerpen, bouwen, testen, inbedrijfstellen, overdragen en opleveren van een integraal werkend tunnelveiligheidssysteem. Bij overdracht van de projectorganisatie naar de beheerorganisatie, dient te worden aangetoond dat de tunnel ‘veilig’ is en veilig kan worden gebruikt. Om ook na oplevering door de aannemer en ingebruikname door de gebruiker, de betrouwbaarheid, beschikbaarheid en veiligheid van de tunnel tegen kwaadaardige digitale invloeden van buitenaf te beveiligen, worden cybersecuritymaatregelen getroffen.

B3.4 Exploitatiefase

Voor (bestaande) tunnels die in gebruik zijn en waarvoor in de projectfase geen bijzondere aandacht is gegeven aan de digitale beveiliging, is het raadzaam om cyberrisico-analyse uit te voeren. Een cyberrisico-analyse geeft inzicht in de digitale kwetbaarheden, dreigingen en de operationele risico’s die er zijn voor de veiligheid, de beschikbaarheid en de privacy. Er is in de meeste gevallen een inhaalslag nodig om de toenemende dreigingen door kwaadwilligen (hackers) en de daaruit voortvloeiende risico’s voor de veiligheid, privacy en beschikbaarheid het hoofd te kunnen bieden.

Bewustwording ten aanzien van tunnelveiligheid en cybersecurity is echter iets dat moet groeien en waarvoor dus tijd nodig is. In dat kader is het gewenst om te starten met een cybersecurityscan, zodat helder en aantoonbaar is, op welk niveau de organisatie staat. Voor het bepalen van het gewenste niveau van cybersecuritymaatregelen zal door de opdrachtgever moeten worden bepaald wat het cybersecurity-weerstandsniveau van de tunnel is of moet zijn. Hiermee wordt feitelijk het ambitieniveau bepaald dat uiteindelijk bereikt moet worden. Dit ambitieniveau is deels afhankelijk van de risico’s die moeten worden afgedekt.

B3.5 Achtergronden

Voor wegtunnels geldt dat primair de Tunnelwet, Wet aanvullende regelgeving veiligheid wegtunnels (Warvw) en Regeling aanvullende regelgeving veiligheid wegtunnels (Rarvw) van toepassing zijn. Voor overheidsinstelling gelden ook de Algemene verordening gegevensbescherming (AVG) en Baseline informatiebeveiliging overheid (BIO). De gemeentelijke, provinciale en rijkstunnels vallen volledig onder deze wet- en regelgeving.

De BIO is gebaseerd op de norm ISO 27001 en beschrijft hoe procesmatig moet worden omgegaan met het beveiligen van informatie, met als doel om de vertrouwelijkheid, beschikbaarheid en integriteit van informatie binnen een organisatie zeker te stellen. Denk hierbij aan het beschermen van persoons- en/of bedrijfsgegevens én de bescherming tegen hackers en inbraak. De eisen die in deze ISO 27001 gesteld worden, zijn opgesteld vanuit het perspectief van een generieke ICT-omgeving (lees: kantoorautomatisering, KA en software). Systemen in tunnels hebben echter een ander doel dan generieke ICT-systemen, namelijk een veilige passage van het verkeer. In een tunnel wordt dan ook gebruikgemaakt van andersoortige technische oplossingen. Zo zijn de toegepaste netwerktechnieken en softwareapplicaties wezenlijk anders van opzet; het doel is hier de betrouwbaarheid, beschikbaarheid en servicebaarheid te bieden die nodig is om de veiligheid van het passerende verkeer in alle situaties van de exploitatie (juist bij ongevallen en bij brand) te garanderen.

De netwerk- en bediening-, besturings en bewakingsfuncties toegepast in tunnels laten zich niet vatten onder de generieke ICT-norm: om deze reden heeft Rijkswaterstaat de Cybersecurity implementatierichtlijn (CSIR) ontwikkeld. Hierin zijn de specifieke risico’s en eisen gesteld ten aanzien van de cybersecurity van tunnelsystemen en de gekoppelde exploitatie/operatie.

Naast de genoemde wetgeving voor tunnels, is in 2018 de Wet beveiliging netwerk- en informatiesystemen (Wbni) in werking getreden. De Wbni geldt voor ‘aanbieders van essentiële diensten’ (AED’s), de rijksoverheid en digitale dienstverleners. Deze wet geldt inmiddels ook voor het rijkswegen en -spoornetwerk, en dus ook voor veel tunnels.

In B3.7 Totaaloverzicht toezicht staat een schematische weergave waaruit de complexiteit van het vraagstuk tunnelveiligheid-cybersecurity blijkt.

Opmerking:

Voor spoorwegen (zowel light als heavy rail) geldt dat het aspect cybersecurity al expliciet is meegenomen in een zogeheten integral safety case (ISC). Deze ISC wordt opgesteld vanuit de eis, opgenomen in de Spoorwegwet en Wet lokaal spoor, waarin moet worden aangetoond dat het vaste infrastructurele deel van een specifiek deel van het spoorwegnet veilig is en op welke wijze hiervan veilig gebruik kan worden gemaakt.

B3.6 Vragen en mogelijke antwoorden t.a.v. cybersecurity en veiligheid

De hoofdvragen waarvoor de tunnelorganisatie zich gesteld ziet vanuit de wisselwerking tussen cybersecurity en tunnelveiligheid zijn als volgt samen te vatten:

1. 1. • Hoe kan een tunnelbeheerder aantonen dat de ‘zorgplicht’ voor cybersecurity voor de veiligheid, beschikbaarheid en privacy in voldoende mate is geborgd?
      • Is cybersecurity geborgd bij oplevering van de aanleg, alsmede ook na openstelling in de exploitatiefase en dus voor het regulier beheer?

Cybersecurity is geen éénmalige actie van het afvinken van een normenkader als verificatie van een project. Ontwikkelingen in de buitenwereld gaan zo snel dat incidenten rondom cybersecurity bijna dagelijks in het nieuws zijn. In plaats van één meting is een cyclisch PDCA-proces nodig om voortdurend de risico’s te evalueren en eventueel te mitigeren. Deze cyclus zal een hogere herhalingsfrequentie moeten hebben dan de bekende tunnelinspectie die minimaal eens per zes jaar wordt uitgevoerd. Immers, cybersecurityrisico’s volgen elkaar in hoog tempo op. Een jaarlijkse evaluatie van maatregelen en het uitvoeren interne en/of externe audits is wel het minimale.

De oplossing voor de tunnelbeheerder moet dus gezocht worden in het inrichten van verschillende instrumenten om deze toetsing periodiek te kunnen uitvoeren. In de paragrafen ‘5.1 De doelen van cybersecurity voor de OT’ en ‘5.2 Hoe cybersecurity past in de tunnelveiligheidsaanpak’ wordt hiertoe een voorstel gedaan.

B3.6.1 De doelen van cybersecurity voor OT

Het doel van de cybersecurity voor OT is het het faciliteren van de operationele doelen van de tunnel, te weten:

1. 1. 1. V: fysieke veiligheid van gebruikers en onderhouders
      2. ter voorkoming van persoonlijk letsel(schade) en voldoen aan vigerende regelgeving op het gebied van veiligheid (uit te drukken in de kpi’s voor de veiligheid)
      3. B: de operationele beschikbaarheid van de tunneloperatie
      4. voldoen aan de gestelde operationele beschikbaarheidseisen (kpi’s) bedoeld voor een doelmatig en efficiente operatie voor weggebruikers en onderhouders (uit te drukken in de kpi’s voor de beschikbaarheid)
      5. P: privacy van gebruikers en onderhouders
      6. ter voorkoming van datalekken van persoonsgegevens (zoals camerabeelden en intercomstreams) en voldoen aan de AVG (uit te drukken in de kpi’s voor de privacy).

Werken aan deze V, B, P-doelen is bedoeld ter voorkoming van schade en letsel:

1. 1. 1. • Schade betreft alle vormen van schade, te weten: zakelijke en persoonlijke, materiële en immateriële en direct of indirect schade, zoals maatschappelijke schade, financiële schade, imagoschade, enzovoort.
         • Letsel betreft direct of indirecte lichamelijk letsel van alle typen gebruikers en beheerders, zoals weggebruikers, bedienaars en onderhoudspersoneel.

Ter illustratie twee voorbeelden van manieren waarop een cyberincident een risico kan worden voor de operatie van een tunnel:

1. 1. 1. • De onderhoudsmedewerker van een tunnelbesturingssysteem heeft een 4G-modem aangesloten op een PLC om op afstand updates te kunnen doen. De onderhoudsmedewerker laat zijn laptop in de trein liggen en een informaticastudent kan de verleiding niet weerstaan en deactiveert via de laptop op afstand de waterpompen van de tunnel midden in de spits, midden in een plensbui. Auto’s komen in de tunnel onder water te staan. Niet alle inzittenden kunnen op tijd wegkomen. De calamiteitenorganisatie wordt gestart volgens plan en de hulpdiensten rukken uit. Via sociale media verneemt de student het effect van zijn daad, poetst zijn vingerafdrukken van de laptop en gooit de laptop in een container op straat.
         • In oktober 2013 is er een cybersecurity-incident in Israëlische tunnels uitgevoerd en gepubliceerd. Aanvallers wisten de camera’s uit te schakelen via een kwetsbaarheid van de fabrikantcredentials. Daarna moesten meerdere tunnels sluiten omdat zicht vanuit de bediencentrale was weggevallen. De storing en het oplossen ervan heeft zo’n acht uur gekost waarin de tunnels ook daadwerkelijk dicht waren.

Van operationele doelen naar systeemdoelen

De bedienings- en bewakingssystemen van de tunnel (‘tunnelinstallaties’) faciliteren de tunneloperatie. Anders gezegd, de tunnelsystemen staan in dienst van de tunneloperatie. Dat betekent dat de doelen voor de systemen afgeleid dienen te worden van de doelen van de operatie.

Figuur B.3.1: De driehoek beschikbaarheid, vertrouwelijkheid en integriteit

De doelen voor de tunnel-installatie/-systemen (die betrekking hebben op de cybersecurity) zijn:

In de memo ‘Cybersecurity en tunnelveiligheid’ is de relatie beschreven tussen het falen van systemen enerzijds en het falen van de operatie anderzijds. Falen als gevolg van een kwaadwillige hack of een digitale besmetting in een tunnelsysteem kan leiden tot merkbaar operationeel falen, maar systeemfalen kan ook niet merkbaar zijn in de operatie (onmerkbaar systeemfalen).

B3.6.2 Hoe past cybersecurity in de tunnelveiligheidsaanpak?

Het is essentieel dat de tunnelbeheerder en de veiligheidsbeambte beseffen dat cyberrisico’s heden ten dage niet genegeerd kunnen worden. Ondermeer de regering, de AIVD, de MIVD, de NCTV/NCSC, de WRR en de Algemene rekenkamer hebben de afgelopen jaren op allerlei manieren en indringend aandacht gegeven aan het onderwerp en er aandacht voor gevraagd. Bovendien kunnen de berichten in de media over de vele hacks niet worden genegeerd. De werkgroep stelt dat zowel de tunnelbeheerder als de veiligheidsbeambte als ‘goed huisvader’ rekening moet houden met actuele ontwikkelingen en zich niet kan verschuilen achter het feit dat de tunnelregelgeving nog niet expliciet is op dit onderwerp.

Goed huisvaderschap

De juridische betekenis van het begrip ‘goed huisvader’ geeft tunnelbeheerder en de veiligheidsbeambte de verantwoordelijkheid (én aansprakelijkheid) om cybersecurity serieus te nemen. De bovenstaande paragrafen maken duidelijk dat cyberfalen direct de veiligheid kan belemmeren met gewonden (en wellicht doden) tot gevolg. Het ontbreken van (financiële) middelen mag geen reden zijn om cybersecurity niet te agenderen. Het is aan te bevelen om – daar waar de veiligheidsbeambte onvoldoende kennis heeft van cybersecurity – hem/haar tijdelijk te ondersteunen met deze kennis en dan de stappen te zetten zoals hieronder gegeven.

Autoriteit persoonsgegevens (AP) 

De AP deelt boetes uit aan organisaties die bij een datalek onvoldoende kunnen aantonen dat ‘goed huisvaderschap’ is georganiseerd; ook wel de ‘zorgplicht’ volgens AVG artikel 32. De boetebedragen kunnen fors oplopen. Hoogst uitgedeelde boete bedraagt 830.000 euro aan het BKR in Tiel. Dus ongewenste deling van camerabeelden zou flinke kosten kunnen opleveren.

Art 5. van de Warvw, Veiligheidsbeambte

…De veiligheidsbeambte coördineert voor de organisatie van de tunnelbeheerder alle preventieve en veiligheidsmaatregelen ter verzekering van de veiligheid van de tunnelgebruikers en het tunnelpersoneel….

In het licht van de steeds vaker optredende cyberincidenten en de algemene maatschappelijke bewustwording horen bij ‘alle preventieve en veiligheidsmaatregelen’ ook cybersecurity-maatregelen. Immers, een hack op een operationeel bedieningssysteem kan leiden tot fysieke onveiligheden. De beheerder en de veiligheidsbeambte dienen als een ‘goed huisvader’ aandacht te hebben voor actuele dreigingen. Cyberdreigingen behoren momenteel tot reële dreigingen waaraan een tunnel bloot staat.

Art 6.1 van de Warvw, risicoanalyse: kansen klein, impact groot, betekent risico’s middengroot

Hoewel de kans op cyberincidenten (nog) relatief klein is, zijn de (landelijke) impact (in de media) en de persoonlijke gevolgen voor de betrokkenen groot. Daarmee zijn de risico’s voldoende groot om zeer serieus te nemen. In de risicoanalyses van de tunnel dienen cyberrisico’s dan ook te worden opgenomen. Hierboven zijn reeds enkele als voorbeelden gegeven.

Voor de risicoanalyse dient in het tunnelveiligheidsplan ook een verwijzing te zijn opgenomen naar een specifiek cyberdreigingsbeeld voor en het, door de eigenaar bepaalde, weerstandsniveau van de tunnel. De risicogestuurde aanpak voor de cyberrisicoanalyse is elders beschreven in dit groeiboek. Hiermee worden cyberrisico’s een normaal onderdeel van het risicomanagementproces van de tunnel. De cyberrisico’s kunnen worden gemitigeerd met maatregelen zoals beschreven in dit groeiboek, de maatregelen uit de CSIR van RWS, de IEC62443, de ISO27002 of de NIST-directives.

Art 6.2 van de Warvw, tunnelveiligheidsplan voor een nieuwe tunnel

De adviezen uit de risicoanalyse hebben effect op de projectfase, maar zeker ook op de beheerfase. De technische en organisatorische maatregelen kunnen worden opgenomen in het tunnelveiligheidsplan (of er wordt een verwijzing opgenomen naar het cybersecuritydossier van de tunnel).

Art 10 van de Warvw, tunnelveiligheidsdossier voor een nieuwe tunnel

Bij de overdracht naar de beheerorganisatie wordt het tunnelveiligheidsplan aangepast en geactualiseerd naar een tunnelveiligheidsdossier. De cybermaatregelen – niet alleen de technische, maar vooral ook de organisatorische – dienen onderdeel te zijn van het tunnelveiligheidsdossier. Door een jaarlijkse update van de risicoanalyse en het cybersecurityplan (bv. met gebruikmaking van de COB-quickscan) kan een indicatie worden gegeven van het groeipad dat de tunnelbeheerorganisatie doormaakt.

Art 10 van de Warvw, tunnelveiligheidsdossier voor een bestaande tunnel

De tunnelbeheerder en de veiligheidsbeambte, die beiden verantwoordelijk zijn voor een operationele tunnel, dienen een cyberrisicoanalyse te (laten) uitvoeren op de bestaande situatie. De cyberrisicoanalyse geeft inzicht in de kwetsbaarheden in de systemen en processen en laat zien welke risico’s de tunneloperatie loopt in relatie tot cybersecurity. De aanbevelingen uit de cyberrisicoanalyse kunnen in een meerjaren-cybersecurityplan worden opgepakt. Het meerjaren-cybersecurityplan is dan een logisch en natuurlijk onderdeel van het onderhoudsbeheerdossier en/of het tunnelveiligheidsdossier.

Het meerjarenplan is een uitstekend instrument waarmee het verbeterproces beheersbaar en inzichtelijk wordt gemaakt voor alle stakeholders. Het op niveau krijgen van cybersecurity kan meerdere jaren in beslag nemen. Dit wordt duidelijk aan de hand van een meerjaren(implementatie)plan. Door dit meerjarenplan op te stellen, kan ook de budgettering ervoor worden georganiseerd, wat verder los staat van het feit of de financiering ervoor wordt verkregen. Een meerjarenplan helpt, omdat de investering over meerdere jaren kan worden gespreid. Door een jaarlijkse update van de risicoanalyse en het cybersecurityplan (bv. met gebruikmaking van de COB-quickscan) kan een indicatie worden gegeven of het meerjarenplan nog effectief is of dat er een aanpassing nodig is.

B3.7 Totaaloverzicht toezicht

Bijlage 4 Overzicht werkgroep deelnemers

Leen van Gelder (COB/Soltegro) was voorzitter van de ISAC Tunnels en coördinator van de werkgroep in de eerste en tweede fase (en uitgave van het groeiboek). Jasper Kimstra (COB/Kimpro) is projectleider van de werkgroep in fasen drie en vier (en uitgaven 3.0 en 4.0 van het groeiboek). Tom van Tintelen (COB/DON Bureau) is de huidige voorzitter van de ISAC Tunnels. De groepen worden vanuit het COB ondersteund door Cindy Peek.

Bijlage 5 Afkortingen

Bijlage 6 Normen en richtlijnen

Overzicht van de in het groeiboek aangehaalde op 5 november 2020 vigerende normen en richtlijnen.