Cybersecurity
De filterfunctionaliteit is nog in ontwikkeling. Laat het weten als u hierover wilt meedenken!
Filteren
Onderwerp
Cybersecuritymanagement
Logging en monitoring
Risicogestuurde aanpak
Verificatie en validatie
Incidentrespons en herstel
Assetmanagement
Businesscase
Sluit filters

PDF-versie

Om dit groeiboek offline te bekijken, kunt u via de link hieronder een pdf-versie (3-5 MB) downloaden. Deze pdf wordt dagelijks geactualiseerd, maar blijft een momentopname: na verloop van tijd kan de gedownloade pdf afwijken van het online groeiboek.


Download pdf-versie

Participeren?

Het groeiboek heet niet voor niets groeiboek: de inhoud kan à la minute bijgewerkt worden om het boek beter te laten aansluiten bij de praktijk. Daar hebben we wel uw hulp voor nodig. Als u iets ziet wat niet klopt, of als u aanvullingen heeft, kunt u via onderstaand formulier contact opnemen. Na overleg kunt u dan rechten krijgen om het groeiboek aan te passen. De aanpassingen worden altijd nog even nagekeken voordat ze online komen.

De velden met * zijn verplicht.

Inhoudsopgave

    Geleerde lessen:
    Geleerde lessen

    Cybersecurity tunnels

    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.
    Downloads
    Groeiboek versie 1 Groeiboek versie 2 Enkele belangrijke aandachtspunten uit dit groeiboek zijn samengevat in een factsheet en op de posters ‘Handreiking cybersecurity voor (tunnel)beheerders’ en ‘Relatieschema cybersecurity en organisatie’. U kunt de producten gratis downloaden. >> Factsheet behorende bij het groeiboek versie 1 (pdf, 525 KB) >> Handreiking cybersecurity voor (tunnel)beheerders (pdf, 133 KB) >> Factsheet behorende bij het groeiboek versie 2 (pdf, 555 KB) >> Relatieschema cybersecurity en organisatie (pdf, 85 KB)

    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. Met de filters bovenin kunt u direct de juiste selectie van hoofdstukken maken. De hoofdstukken over de aspecten en wet- en regelgeving zijn in alle gevallen relevant; hier zijn dan ook geen filters voor, en deze hoofdstukken blijven altijd zichtbaar. Maar voor bijvoorbeeld assetmanagement is het niet noodzakelijk om het hoofdstuk over verificatie en validatie te lezen. Daarom wordt bij toepassing van de filter ‘Assetmanagement’ het hoofdstuk over verificatie en validatie onzichtbaar gemaakt. 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.
    Interactief
    Om alle informatie leesbaar te houden, is een aantal interactieve elementen beschikbaar. De hoofdtekst is bondig en compact van opzet. Via buttons en links kan extra informatie worden opgeroepen of worden selecties van teksten gepresenteerd.

    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 rapport Cybersecuritybeeld Nederland 2020 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.
    Cybersecurity businesscase
    Bij het opstellen van een businesscase voor cybersecurity is het van belang om vast te stellen welke cybersecurity-maatregelen (kosten) leiden tot een reductie van maatschappelijke, financiële, veiligheids- en privacy-risico’s (baten) . Baten zijn te vinden in de reductie van de potentiële schade en letsel, en de directe herstelkosten. Ter illustratie: de schade van de (not)Petya-aanval in 2017 in Nederland, beter bekend als de Maersk-case, bedraagt meer dan 300 miljoen euro.
    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 fasenbeschreven. In de huidige, derde editie 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.

    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 OT-omgeving; 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 3 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 operationele technologie (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:
    Partijen / rollenBelang / doelstelling
    Tunnelbeheerder (TB), in Warvw gedefinieerde rolVerantwoordelijk voor veilige exploitatie van de tunnel, hiermee verantwoordelijk voor veiligheidsdocumentatie (TVP, Bouwplan, VBP), voor een technisch functionerend tunnelsysteem en voor een getrainde beheer- en calamiteitenorganisatie.
    Tunnelpersoneel, gelieerd aan tunnelbeheerderBijvoorbeeld bedieningspersoneel en weginspecteurs. Bedieningspersoneel zorgt voor bediening en bewaking van de tunnel en speelt een essentiële rol bij het verkeersmanagement en de calamiteitenafhandeling. Weginspecteurs ondersteunen het bedieningspersoneel op locatie (weg).
    Veiligheidsbeambte (VB), in Warvw gedefinieerde rolLevert gevraagd en ongevraagd advies aan de tunnelbeheerder inzake de tunnelveiligheid. Heeft hierbij nadrukkelijk ook aandacht de controle op opleiding, training en oefening van de beheer- en calamiteitenorganisatie en is betrokken bij de evaluatie van incidenten. Bij de aanvraag van tunnelveiligheid-gerelateerde vergunningen moet wettelijk een advies van de VB gevoegd zijn.
    Bevoegd college van BenW, in Warvw gedefinieerde rol, ook wel bevoegd gezag(BG) genoemdVerantwoordelijk voor verlening van de diverse tunnelveiligheid-gerelateerde vergunningen (omgevingsvergunning en openstellingsvergunning), op basis van een toets aan de wettelijke kaders. Daarnaast verantwoordelijk voor handhaving van de wettelijke kaders, met als ultiem middel het intrekken van de vereiste vergunningen voor bouw en gebruik van de tunnel.
    Brandweer/hulpdienstenDe brandweer of veiligheidsregio fungeert als adviseur van het bevoegd gezag bij de beoordeling van de aangevraagde vergunningen. Daarnaast is het calamiteitenbestrijdingsplan het resultaat van samenwerking tussen de brandweer, TB en overige partijen die een rol hebben bij calamiteitenbestrijding (waaronder de andere hulpdiensten).
    Toezichthoudende ambtenarenAmbtenaren die belast zijn met het toezicht op de naleving van de regels uit de Woningwet, het Bouwbesluit, de Warvw en de Rarvw worden door het bevoegd college van burgemeester en wethouders aangewezen. Hiernaast wordt er namens de Minister van IenW toezicht uitgeoefend door de Inspectie Leefomgeving en Transport op de tunnel- en wegbeheerders en de weggebruikers.
    Bevoegd gezag
    Behalve in de Warvw komt ook in overige wet- en regelgeving het begrip ‘bevoegd gezag’ voor. Het gaat daarbij om het bestuursorgaan dat bevoegd is om bepaalde besluiten te nemen. De minister van Infrastructuur en Waterstaat is bijvoorbeeld het bevoegd gezag voor het vaststellen van een tracébesluit. De gemeenteraad en Provinciale Staten zijn bevoegd om een bestemmingsplan respectievelijk provinciaal inpassingsplan vast te stellen. Het college van burgemeester en wethouders is het bevoegd gezag voor het verlenen van een omgevings- en openstellingsvergunning. Hiernaast is het bestuur van de veiligheidsregio verantwoordelijk voor de veiligheidseisen die voortkomen uit de Wet op de veiligheidsregio’s.
    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

    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), Interprovinciale Baseline Informatiebeveiliging (IBI), Baseline Informatiebeveiliging Gemeenten (BIG) en de Baseline Informatiebeveiliging Waterschappen (BIWA). Die BIO is gebaseerd op de internationale norm ISO/IEC 27001 en ISO/IEC 27002 (zie 3.5.1 ISO/IEC 27000-serie).

    3.3.2 Wet beveiliging netwerk- en informatiesystemen

    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’. 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. Begin 2020 is een voorgenomen besluit bekend geworden waarin de deelsectoren weg- en spoorvervoer (hoofdwegennet) ook als vitaal worden aangemerkt. Verwacht wordt dat in het najaar van 2020 dit besluit definitief is en AED’s zullen worden aangewezen. Deze herbeoordeling betekent naar alle waarschijnlijkheid dat ook een beheerder van tunnels in het hoofdwegennet onder de werking van de Wbni gaat vallen. 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.
    Functionaris gegevensbescherming (FG)
    Organisaties zijn in bepaalde situaties verplicht een functionaris gegevensbescherming (FG) aan te stellen. Dit is iemand die binnen de organisatie toezicht houdt op de toepassing en naleving van de AVG. Dit betekent dat de FG bij alle mogelijke processen waar persoonsgegevens worden gebruikt betrokken zou moeten zijn. Overheidsinstanties en publieke organisaties zijn altijd verplicht om een FG aan te stellen, ongeacht het type gegevens dat ze verwerken. Organisaties moeten hun FG aanmelden bij de Autoriteit Persoonsgegevens. >> Lees meer
    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 moet eind 2020 verschijnen.

    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 & Control Systems) in plaats van de de term operationele technologie (OT). Figuur 3.1: Overzicht van de IEC 62443 normenreeks. (Bron: IEC) De normreeks kent vier ‘lagen’ die gericht zijn op verschillende doelgroepen:
      1. IEC 62443-1-x General – Deze vier delen bevatten 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 technisch 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 technisch 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 technisch 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 technisch 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. 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. 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 fasenals 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.
    RolTaken en verantwoordelijkheden
    TunnelbeheerderVanuit zijn/haar wettelijke taken eindverantwoordelijk voor de cybersecurity van zijn/haar tunnel(s).
    Bevoegd gezagVanuit zijn/haar wettelijke taken verantwoordelijk voor de toets op de tunnelveiligheid en daarmee ook voor de cybersecurity-aspecten en de handhaving daarvan.
    VeiligheidsbeambteVanuit zijn/haar wettelijke taken levert de veiligheidsbeambte gevraagd en ongevraagd advies aan de tunnelbeheerder inzake de tunnelveiligheid en daarmee ook over de cybersecurity-aspecten en handhaving daarvan.
    Operationeel-/ assetmanagementVoert het dagelijks beheer uit tijdens de exploitatiefase. Stelt eisen op voor de beheer- en onderhoudsfase. Bewaakt de beheersbaarheid. Voert van onderhoud uit op basis van cybersecurity-procedures. Voert periodieke testen/audits/risicoanalyses uit.
    TunnelpersoneelMeldt, registreert en rapporteert cyberincidenten.
    Projectmanagement/-directieIs verantwoordelijk voor de cybersecurity-aspecten naar de tunnelbeheerder en opdrachtgever. (Commitment van de organisatie met cybersecuritybeleid is hierbij een vereiste!)
    Proces- en kwaliteitsmanagementVoert document control uit. Coördineert en initieert cybersecurity-audits. Coördineert en registreert risicoanalyses.
    Securitymanagement – Incidentmanager – Security-architect – Cybersecurity-coördinator – Cybersecurity-auditorMeldt, registreert en rapporteert cyberincidenten. Voert inspecties uit op naleving integrale veiligheid.
    Systeem-/applicatiebeheerBewaakt accounts en toegangsrechten. Richt werkplekbeheer en servicedesk in. Zorgt voor vrijgave ICT-middelen voor werknemers. Voert applicatiebeheer uit.
    Ontwerpteam Civiel/VTTI Cybersecurity-engineer NetwerkspecialistOntwerpt fysieke toegang en gebouwinstallaties en OT-systemen (hardware en software).
    ContractmanagementVerantwoordelijk voor de contractuele aspecten en het doorzetten van cybersecurity-maatregelen naar onderaannemers.
    Realisatieteams Civiel/VTTIInkoop en bouw van systemen. Conformiteit aan cybersecurity-maatregelen door leveranciers. Zowel technisch als organisatorisch dient een veilige levering geborgd te zijn. Veilige overdracht van ontwerpgegevens (bv. software). Doorzetten van cybersecurity-maatregelen naar onderaannemers.
    IBS-/testteamRegistreert en bewaakt fysieke en logische toegang tot OT-systemen. Controleert op naleving cybersecurity-maatregelen door personeel. Verantwoordelijke voor patches, hardening en viruschecks en backups, het vullen van de CMDB. Uitlezen lokale logbestanden.
    HRMProjectintroductie/geheimhoudingsverplichting. Registreert en houdt persoonsgegevens bij. Naleving op cybersecurity-screening als voorwaarde voor inhuur van personeel.
    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.
    RolPlanfase en aanbestedingRealisatiefase – OntwerpRealisatiefase – RealisatieOperationele fase – Beheer en onderhoudOperationele fase – ExploitatieOperationele fase – RenovatieSloop
    Incident- managerXXXXX
    Cybersecurity-coördinator/ adviseurXXXXXX
    Cybersecurity-auditorXX
    Security engineers/ specialistenXXXX
    Netwerk- specialist(en)XXXX
    Applicatie- beheerder(s)XXXX
    Security- architectXXXX
    Tunnel- personeelX

    4.5 Tips voor een geoliede samenwerking

    Organiseer commitment van directie
    Combineren van rollen of juist gescheiden houden?
    Schat de workload op de juiste waarde
    Organiseer de communicatie
    Implementeer escalatiemodellen
    Werk samen in de hele keten
    Klap uit Klap in

    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. 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.
    Incidentdetectie
    Volgens de NCSC-rapportages bedroeg het gemiddelde aantal dagen tussen het moment van inbraak en het moment van ontdekking wereldwijd:
        • in 2014: 205 dagen,
        • in 2017: 101 dagen,
        • in 2018 78 dagen,
        • in 2019 56 dagen.
    De trend is dus dalende, maar niet snel genoeg.
    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:
        • 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.
    Medewerkers toetsen
    Social engineering is een van de vormen van cybercrime. Menselijke eigenschappen zoals nieuwsgierigheid, vertrouwen en hebzucht worden hierbij misbruikt om informatie te verkrijgen. Het kan waardevol zijn om te meten in welke mate de medewerkers hiervoor ‘vatbaar’ zijn. Met ‘phishing as a service’ (PhaaS) wordt phishing gesimuleerd door het verspreiden van gecontroleerde nep-phishingberichten in de organisatie.
    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.
    OT-systeemlogging (informatieverwerkende omgeving)
    Logging van activiteiten van beheerders en operators
    Logging van netwerkapparatuur
    SOC en SIEM
    Monitoring van netwerkapparatuur
    Kloksynchronisatie
    Klap uit Klap in

    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:
        • 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. De inventarisatie dient voor het vastleggen van:
        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 (Engelstalig: 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.
    Beveiligingsincident
    ‘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 van een vergissing, een onbewuste/goedbedoelde aanpassing met onbedoeld negatief effect. Over het algemeen zijn soorten activiteiten die worden erkend als inbreuken op een beveiligingsbeleid:
        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.
    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. 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.
    Risicobepaling Rijkswaterstaat
    Rijkswaterstaat hanteert ‘risico = dreiging x kwetsbaarheid x impact’ om het risico voor cybersecurity te bepalen, zie de afbeelding hieronder (Bron: presentatie cybersecurity voor ISAC, door Turabi Yildirim, Rijkswaterstaat). Figuur 6.3: Invulling risicobepaling door Rijkswaterstaat.
    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:
        • 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:
    Voor OT-systemen is de IEC 62443-3-2 van toepassing. Deze norm beschrijft het ‘security risk assessment and system design’.
        • 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 31000, Risicomanagement
        • Handreikingen en leidraden ProRail en Rijkswaterstaat
    Geen gescheiden werelden
    Waren IT en OT traditioneel gezien gescheiden werelden, tegenwoordig zijn steeds meer fabrieksprocessen afhankelijk van IT-oplossingen. Dit heeft grote gevolgen. Zo blijkt de OT-omgeving vaker getroffen 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. Daarnaast heeft de ontwikkeling van Internet of Things (IoT) inmiddels ook de OT-wereld bereikt. Dat biedt natuurlijk veel nieuwe mogelijkheden, maar helaas ook nieuwe security-uitdagingen; een toename van het aantal sensoren binnen een fabriek of object betekent immers ook een grotere ‘attack surface’. Om de cybersecurity van beide werelden met elkaar te verenigen, is specifieke kennis en kunde nodig en een goed begrip van de impact van een cyberaanval en zijn verdediging.
    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.
    De operatie
    De operatie behelst de dagdagelijkse werkzaamheden voor de exploitatie (normaal- en calamiteitenbedrijf) én voor het onderhoud en beheer (onderhoudsbedrijf).
    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. 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:
        • 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. 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: De balans van cybersecurity-maatregelen.   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:
        • 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.
    Ontwerpfase – Mens
    Ontwerpfase – Organisatie
    Ontwerpfase – Techniek
    Bouwfase – Mens
    Bouwfase – Organisatie
    Bouwfase – Techniek
    Klap uit Klap in
    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 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:
        • 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:
        1. Niet-technisch aspecten: organisatie en mens.
        2. Technische aspecten.
    Niet-technische aspecten Borging van de niet-technische aspecten kan op vele manieren, waarbij bovendien allerlei combinaties en varianten denkbaar zijn. Het kan bijvoorbeeld op een heel lichte manier of op een formeel zware manier. Van licht naar zwaar kan gedacht worden aan:
        1. Interne controle door eigen medewerkers in opdracht van de tunnelbeheerder.
        2. Interne controle en/of inspecties door verantwoordelijke voor informatiebeveiliging.
        3. Collegiale toetsing door een tunnelbeheerder die onder een ander bevoegd gezag valt.
        4. Audit door interne auditdienst van het bevoegd gezag.
        5. Audit door extern auditor.
    Voorafgaande aan de controle/inspectie/audit dienen afspraken te zijn gemaakt met de tunnelbeheerder over de criteria en de reikwijdte ervan. UIteraard moet de uitkomst van een uitgevoerde controle/inspectie/audit altijd worden vastgelegd in een verslag. Hierin moet minimaal zijn opgenomen:
        1. Administratieve gegevens van de uitgevoerde controle/inspectie/audit zoals: opdrachtgever, opdrachtnemer, datum, criteria, reikwijdte, etc.
        2. Resultaat van de uitgevoerde controle/inspectie/audit.
        3. Voorgestelde aanpassingen, verbeteringen op de onderzochte aspecten.
        4. Resultaten eerdere controles/inspecties/audits en voortgang acties.
        5. Globale inschatting benodigde middelen voor aanpassingen en verbeteringen.
    Technische aspecten Voor de criteria, reikwijdte en rapportage gelden voor technische aspecten dezelfde eisen zoals hiervoor beschreven. Het specifieke zit in de technische aspecten van:
        1. Patching, logging, hardening, monitoring, back-ups, toegangsbeveiliging, netwerkkoppelingen, etc.
        2. Technische middelen voor het uitvoeren inspecties, zoals detectieprogrammatuur, firewalls, antivirussoftware en penetratietesten.
        3. De uitbesteding (voorwaarden, verantwoordelijkheden, e.d.).
    Controle/inspectie/audit hiervan kan gebeuren door een extern gecontracteerd bedrijf op het gebied van cybersecurity. Het Security Operations Centre (SOC) van Rijkswaterstaat kan, als lid van het ISAC Tunnels, ook worden benaderd voor kennisdeling, advies of ondersteuning. In de rapportage moet voldoende aandacht zijn voor afwijkingen in de procedures en in de techniek van de geldende en geïmplementeerde cybersecurity. Met name de argumentatie en risico’s om af te wijken moeten goed gedocumenteerd en geautoriseerd zijn. Naast de formele rapportage is het gewenst om aangetroffen kwetsbaarheden te bespreken in het ISAC Tunnels, zodat alle tunnelbeheerders van Nederland er kennis van kunnen nemen.

    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:
        • 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:
        • 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. 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
    1. Project start-up/werkpakketanalyse
    2. Werkpakket starten: maken van een verificatieplan
    3. Uitvoering verificatie
    4. Werkpakket afronden: maken van een verificatierapport
    Klap uit Klap in
    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:
    1. Eisenvalidatie
    2. Ontwerpvalidatie
    3. Productvalidatie
    4. Functionele simulatie van het systeem
    Klap uit Klap in

    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. 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 Cybersecurity Beeld 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:
        • 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:
    Noodplan
    Crisismanagementplan (CMP)
    Calamiteitenplan of continuïteitsplan (CP)
    Incidentresponsplan (IRP)
    Fysieke-beveiligingsplan (FBP)
    Klap uit Klap in

    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:
    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:
        • 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:
    1. Beschrijving van het incident
    2. Beschrijving van functionele impact
    3. Vermoedelijke oorzaak van het incident
    4. Feitelijk herstel van het object
    5. Verbetering van de cybersecurity van het object
    6. Conclusies en communicatie
    Klap uit Klap in
    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 managementsamenvatting 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 Assetmanagement

    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 uitvoeriger 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 volgens NEN-ISO 55000
    Definitie: ‘Gecoördineerde activiteiten van een organisatie om waarde te realiseren uit assets’. ISO 55000 is gebaseerd op vier principes:
        1. Waarde: assets bestaan om waarde op te leveren voor de organisatie en haar stakeholders. Een asset is iets dat waarde voor een organisatie heeft. Wat deze waarde is, en welke vorm deze waarde heeft, is afhankelijk van de organisatie en haar stakeholders. Voorbeelden van fysieke assets zijn: een installatie, machines, voertuigen, infrastructuur, kunstwerken, gebouwen, etc.
        2. Afstemming: assetmanagement vertaalt de organisatiedoelstellingen in technische en financiële beslissingen, plannen en activiteiten.
        3. Leiderschap: leiderschap en de cultuur op de werkplek zijn bepalende factoren voor het realiseren van waarde.
        4. Waarborging: assetmanagement waarborgt dat assets aan hun vereiste doel zullen voldoen.
    Assetmanagement onderscheidt de volgende fasen voor elke asset:
        • 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 9.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.

    9.1 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.

    9.1.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.

    9.1.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.

    9.1.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:
        • 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:
        • NDA (geheimhoudingsverklaring) aanleveren en opvragen bij derden.
        • Inrichten vertrouwelijke documentomgeving.
        • Indien vereist: inrichten fysiek afgeschermde projectomgeving.
        • Cybersecurity-maatregelen opnemen in aanbieding (voor alle projectfasen).

    9.1.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.9 Borging.

    9.2 Realisatiefase

    De realisatiefase van een tunnel bestaat uit de volgende deelfasen:
    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.

    9.2.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:
        • 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:
        • 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.

    9.2.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:
        • 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:
        • 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:
        • 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.

    9.2.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:
    1. Gebruikersaccounts voor ontwikkelaars, onderhoudspersoneel en exploitatie medewerkers (operators)
    2. Wachtwoordbeheer
    3. Systeem- en fysieke toegang
    4. Het borgen en in werking treden van het cybersecurity-plan voor de exploitatiefase
    5. Het overdragen van het risicorapport uit de realisatiefase
    6. Opleidingen personeel
    7. Organisatie
    Klap uit Klap in
    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:
    Mens
    Organisatie
    Techniek
    Klap uit Klap in
    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.

    9.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. 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 9.2.2 Nieuwbouw.

    9.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:
        • Beoordelen cybersecurity-risico-analyses en cybersecurity-rapportages.
        • Houden van een jaarlijkse audit.
        • Uitvoeren netwerkmonitoring.
        • Organiseren van incidentrespons.
    Tot de taken van de opdrachtnemer behoren:
        • 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:
    Mens
    Organisatie
    Techniek
    Klap uit Klap in
    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.

    9.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 9.2.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:
        • 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:
        • 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:
        • 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.
    Mens
    Organisatie
    Techniek
    Klap uit Klap in
    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 9.2.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, 9.5 Sloop. Veiligheidsaudits gedurende de renovatiefase (bijvoorbeeld werkplaats- en werkplekbezoeken door opdrachtgever) zullen het veiligheidsbewustzijn vergroten.

    9.5 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:
        • 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:
        • 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:
        • 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.

    10 Businesscase

    10.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:
        • 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:
        • 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.
    Cybersecurity als verzekering, of cybersecurity verzekeren
    Voor de bewustwording kan cybersecurity als verzekering worden beschouwd. De premie bestaat dan uit de up-frontkosten van de preventieve maatregelen en de dekking bestaat uit de reductie van de kans op schade en herstel. Er zijn anderzijds ook verzekeraars die een cybersecurityverzekering bieden. Bedenk wel dat de verzekeraar dan wel eist dat er reeds voldoende zorg is besteed aan de bescherming tegen dreigingen en aan een snel herstel, bijvoorbeeld in de vorm van het voldoen aan de ISO 27001 of de IEC 62443. Feitelijk verwacht de verzekeraar datgene wat je zelf al zou moeten doen.

    10.2 Fasen in cybersecuritybeleving

    Om de ontwikkeling van een beheerorganisatie in haar cybersecuritybeleving 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

    10.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. 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.

    10.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.

    10.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.

    10.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.

    10.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:
        • 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.
        • Terugvallus: 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.

    10.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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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
        • 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).
    Attribuut (attribute)Prioriteit voor OTPrioriteit voor IT
    Vertrouwelijkheid (confidentiality/privacy)LaagHoog
    Data-integriteit (message integrity)Zeer hoogLaag – medium
    Systeembeschikbaarheid (system availability)Zeer hoogLaag – medium
    Authenticatie (authentication)HoogMedium – hoog
    Onweerlegbaarheid (non-repudiation)Laag – mediumHoog
    Veiligheid (safety)Zeer hoogLaag
    Tijdkritisch (time criticality)KritischVertraging getolereerd
    Systeemuitval (system downtime)OnacceptabelGetolereerd
    Veiligheidsvaardigheden/bewustzijn (skills/awareness)SlechtGoed
    Systeemlevensduur (system lifecycle)15-25 jaar3-5 jaar
    Interoperabiliteit (interoperability)KritischNiet kritisch
    Rekenkracht en opslag (computing resources)Beperkt(bijna) onbeperkt
    Standaarden (standards)IEC 62443IEC 27000
    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 Overzicht werkgroep deelnemers

    NaamOrganisatieDeelneme rv1.0Deelneme rv2.0Deelnemer v3.0
    Wim van AsperenGemeente Amsterdam, Metro en TramXX
    Ron BeijBrandweer Amsterdam-AmstellandXXX
    Jack BlokArcadisXX
    Peter BorsjeEngieX
    Johannes BraamsTEC Tunnel Engineering ConsultantsXX
    Marijn BransKienIA Industriële AutomatiseringXX
    Bob van den BoschSiemens NederlandX
    Arie BrasWegschap Tunnel Dordtse KilX
    Michiel DubbeldemanMinisterie van IenWXX
    Peter FreesenCallasXX
    Talmai GeradtsProRailXX
    René van der HelmMinisterie van IenWXXX
    Harald HofstedeSiemens NederlandX
    Erik HolleboomStrypes NederlandX
    Cuno van den HondelABBX
    Jan HouwersAntea GroupX
    Wim Jansen†RijkswaterstaatX
    Ico JacobsRijkswaterstaatX
    Erik de JongFox-ITX
    Marcel JutteHudson CybertecX
    William KaanProvincie Noord-HollandXX
    Jasper KimstraKimproXXX
    Lennart KoekHudson CybertecX
    Arnold KroonABBX
    Robert Jan de LeedeSiemens MobilityX
    Mark van LeeuwenRijkswaterstaatXXX
    Bernhard van der LindeADTS ICTX
    Sjaak MatzeImagineXX
    Marije NieuwenhuizenCOBXX
    Ron PerrierENGIE Services Infra & MobilityX
    Nick PfenningsCallasXX
    Ronald van der PoelOtis IndustryXX
    Rita PuggioniProvincie Noord-Holland/NRTXX
    Jos RenkensMovares/TripsoluteXXX
    Philip RoodzantX
    Robbert RossRijkswaterstaat WNNXX
    Pieter de RuiterProvincie Noord-HollandXX
    André StehouwerSoltegroX
    Peter StrooGemeente Den HaagX
    Tom van TintelenDON Bureau/TechnolutionXX
    René ValstarFox-ITX
    Johan van der VeldeVialisX
    Riemer te VeldeGemeente RotterdamX
    Tom VersluijsGemeente Den HaagXXX
    Erik VersteegtSiemens MobilityXX
    Erik VinkeVialisXXX
    Jaap van WissenRijkswaterstaat CIVXXX
    Gijs WithagenKienIA Industriële AutomatiseringXX
    Turabi YildirimRijkswaterstaat CIVX
    Leen van Gelder (COB/Soltegro) was voorzitter van de ISAC Tunnels en coördinator van de werkgroep in de eerste en tweede fase. De groepen worden vanuit het COB ondersteund door Caro Rietman.

    Bijlage 4 Afkortingen

    AIVDAlgemene inlichtingen- en veiligheidsdienst
    AVGAlgemene verordening gegevensbescherming
    BIGBaseline informatiebeveiliging Nederlandse gemeenten
    BIOBaseline informatiebeveiliging overheid
    BIRBaseline informatiebeveiliging Rijk
    BIWABaseline informatiebeveiliging waterschappen
    CERTComputer emergency response team
    CMDBConfiguration management database
    CSMSCybersecuritymanagementsysteem
    CIConfiguration item
    CIOChief information officer
    CSIRTComputer security incident response team
    DNSDomain name system
    DTCDigital trust centre
    FME(C)AFailure mode, effects (and criticality) analysis
    GDPRGeneral data protection regulation
    GPRSGeneral packet radio service
    HFHoogfrequent
    MAC-adresMedia access control address
    MSPManaged service providers
    NCSCNationaal cybersecuritycentrum
    NENNederlandse norm
    NIBNetwerk- en informatiebeveiliging
    NISNetwork and information systems
    NiSTNational institute of standards and technology.
    IAIndustriële automatisering
    IACSIndustrial automation and control systems
    IBIInterprovinciale baseline informatiebeveiliging
    ICSIndustrial control systems
    ICTInformation and communication technology
    IECInternational electrotechnical commission
    IPInternetprotocol
    ISACInformation sharing and analysis centre
    ITInformatietechnologie
    KAKantoorautomatisering
    OTOperationele technologie
    PCPersonal computer
    SCADASupervisory control and data acquisition
    SIEMSecurity information and event management
    SOCSecurity operations centre
    THTCTeam hightech crime
    UMTSUniversal mobile telecommunications system
    USBUniversal serial bus
    VOGVerklaring omtrent het gedrag
    VIRVoorschrift informatiebeveiliging Rijkswaterstaat
    WBPWet bescherming persoonsgegevens

    Bijlage 5 Normen en richtlijnen

    Overzicht van de in het groeiboek aangehaalde op 5 november 2020 vigerende normen en richtlijnen.
    Norm/richtlijn met hyperlinkAfkorting, indien gebruikelijk
    Cybersecurity-woordenboek
    Algemene GegevensbeschermingAVG
    Netwerk- en informatieveiligheidNIB-richtlijn
    Wet beveiliging netwerk- en informatiesystemenWbni
    Wet aanvullende regeling voor wegtunnelsWarvw
    Regeling aanvullende regeling voor wegtunnelsRarvw
    Spoorwegwet
    Wet lokaal spoor
    Systems and software engineering — System life cycle processesISO 15288
    Information security managementISO 27001
    Information technology — Security techniques — Code of practice for information security controlsISO 27002
    Information security risk managementISO 27005
    IncidentresponsISO 27035
    Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management – Requirements and guidelinesISO 27701
    RisicomanagementISO 31000
    Asset management — Overview, principles and terminologyISO 55000
    Standard specifies security capabilities for control system componentsIEC 62443
    Voorschrift informatiebeveiliging RijksdienstVIR
    Voorschrift Informatiebeveiliging Rijksdienst – Bijzondere InformatieVIR-BI
    Handreiking prestatiegestuurde risicoanalyses, RijkswaterstaatPRA
    Leidraad systems engineering
    Cybersecurity implementatierichtlijn objecten RWS, versie 1.04CSIR
    Integraal projectmanagement (IPM), Rijkswaterstaat
    Werkwijzebeschrijving 00044 – Verificatie en validatie
    Federal incident reporting guidelines
    Computer security incident handling guide
    Cyber security incident response guide
    National institute of standards and technology (NIST)
    Handreiking risicoanalyse, door Nationaal adviescentrum vitale infrastructuur (Navi)