1 Inleiding [link id=”lbx3p”]

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 infrastructurele werken en objecten, met (industriële) automatisering, waaronder bruggen, sluizen, stuwen en stormvloedkeringen.

1.1 Leeswijzer [link id=”p3th1″]

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 bovenaan 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. Voor bijvoorbeeld assetmanagement is het niet noodzakelijk om het hoofdstuk over verificatie en validatie te lezen. Daarom wordt bij toepassing van het filter ‘Assetmanagement’ het hoofdstuk over verificatie en validatie onzichtbaar gemaakt.

Figuur 1.1: De onderdelen in het groeiboek.

1.2 Aanleiding en doel [link id=”zvw5k”]

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

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

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

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

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

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

Bovendien schrikken de kosten van beveiligingsmaatregelen menig organisatie af.

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

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

1.3 Scope [link id=”q6pp1″]

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

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

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

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

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

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

In de nu voor u liggende vijfde uitgave zijn nog enkele handige uitbreidingen gedaan:

• Er is aandacht besteed aan het herkennen van een cyberincident en het handelingsperspectief, in de vorm van een aantal scenario’s.
• Er is kennis toegevoegd over het effect van legacy-systemen en hoe daarmee omgegaan kan worden.
• Er is een kenniswijzer ontwikkeld en toegevoegd: welke informatie is er te vinden, hoe verhouden de verschillende bronnen (waaronder dit groeiboek) zich tot elkaar, wat zou je moeten weten voor de rol die je vervult in relatie tot een tunnel en waar kun je die kennis vinden?

Met deze vijfde uitgave wordt een project van vele jaren afgerond (we zijn al in 2014 begonnen met de eerste ideeën en schetsen). We verwachten pas weer een volgende uitgave te maken als wezenlijke wijzigingen in de van toepassing zijnde wetgeving of regelgeving zijn gepubliceerd. Ook wanneer zich bijvoorbeeld een belangrijke nieuwe wending in instrumentarium of in bedreigingen aandient, kan dat aanleiding zijn voor een nieuwe editie. Met tussenpozen zal het huidige boek onderhouden worden, en dat zal op deze pagina te lezen zijn.

1.4 Wat is cybersecurity voor OT? [link id=”vglnk”]

Bij cybercriminaliteit denken de meeste mensen al snel aan aanvallen op de bedrijfs-IT-omgeving. Denk bijvoorbeeld aan een DDoS-aanval die een dienst platlegt, malware die bedrijfsinformatie steelt of een database die met foutieve data wordt vervuild. Echter, de tijd dat hackers het alleen hadden voorzien op traditionele IT-omgevingen is voorbij. Steeds vaker hebben zij het ook gemunt op de operationele technologie (OT); de omgeving van bijvoorbeeld energiebedrijven en fabrieken. En daar is de schade direct vele malen groter. Een kritiek OT-bedrijfsproces dat zomaar wordt stilgelegd, kan betekenen dat de productielijnen in een fabriek plat liggen, 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 [link id=”tvtgp”]

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.2: 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 7 Overzicht werkgroep deelnemers is een overzicht opgenomen van de deelnemers van de werkgroep.

1.6 Terminologie [link id=”88f35″]

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

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

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

Figuur 1.3: Schematische voorstelling tunnelsysteem en verkeerscentrale.

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

2 De aspecten van cybersecurity [link id=”s6pcq”]

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 van 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 geüpgraded 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 dat 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 [link id=”r42h9″]

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 tenietdoen. 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) [link id=”l837d”]

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) [link id=”3n04k”]

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 zetten 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 [link id=”2t5fd”]

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 [link id=”lknc9″]

Het aspect ‘techniek’ betreft alle aanwezige apparatuur, onderdelen, voorwerpen, software, enz. en al datgene dat hier direct mee te maken heeft. Dit zijn dus ook onderhoudscontracten, onderhoudsschema’s, enz. De techniek is een belangrijk 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 [link id=”wn93s”]

3.1 Overzicht [link id=”htpq8″]

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 [link id=”q5sv6″]

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

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

3.3 Informatiebeveiliging [link id=”63qqq”]

3.3.1 Baseline informatiebeveiliging overheid (BIO) [link id=”f55kx”]

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

3.3.2 Wet beveiliging netwerk- en informatiesystemen (Wbni) [link id=”c9d84″]

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

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

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

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

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

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

Zorgplicht

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

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

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

Meldplicht

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

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

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

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

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

3.3.3 Algemene verordening gegevensbescherming (AVG) [link id=”rrwrr”]

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

Definitie persoonsgegeven

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

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

Definitie verwerking

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

Doel en grondslag

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

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

Beveiliging van persoonsgegevens

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

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

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

Meldplicht datalekken

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

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

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

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

3.4 Overige regelgeving [link id=”b1fb4″]

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 (2) is in 2021 verschenen. Op basis van versie 2 is in samenwerking met het Waterschapshuis een meer algemene versie 3 ontwikkeld die door een toenemend aantal overheden als standaard wordt gehanteerd.

3.5 Internationale normen [link id=”5gbkc”]

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 [link id=”909fr”]

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, en 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 [link id=”sgb76″]

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

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

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

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

3.6 Cybersecurity en tunnelveiligheid [link id=”v1dc9″]

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 [link id=”rhvth”]

De asset owner is eindverantwoordelijk voor de veiligheid in de tunnel, en daar is cybersecurity een van de belangrijkste onderdelen van. Dus ook voor cybersecurity is de asset owner verantwoordelijk.

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- en regelgeving en veranderende dreigingen van de instandhouding en evaluatie van maatregelen.

4.1 Cybersecuritymanagementsysteem (CSMS) [link id=”k3z5k”]

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 bestaat, is een CSMS conform IEC 62443 te overwegen.

4.2 Contractvormen [link id=”34dvw”]

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 [link id=”sdnpz”]

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

Figuur 4.1: Organisatievormen gedurende de levenscyclus van een object.

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

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

Figuur 4.2: Relatieschema cybersecurity.

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

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

4.4 Basis-organisatiemodel voor cybersecurity [link id=”wbrr1″]

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

4.5 Tips voor een geoliede samenwerking [link id=”mq12v”]

4.6 Praktijkvoorbeeld: TBV-matrix voor een wegtunnel [link id=”6hgf1″]

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 [link id=”gk503″]

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’ [link id=”7d93g”]

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 [link id=”t1rts”]

5.1 Waarom logging en monitoring? [link id=”vfdn1″]

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

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

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

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

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

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

5.2 Implementatie van logging en monitoring [link id=”rkhvx”]

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

6 Risicogestuurde aanpak [link id=”pdbcq”]

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 [link id=”nfzbd”]

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 [link id=”bslp6″]

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 [link id=”l2s04″]

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

6.4 Inventarisatie van dreigingen [link id=”vwml3″]

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

De inventarisatie dient om 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 [link id=”hx09g”]

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 kunnen helpen bij het opstellen van zo’n lijst.

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

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

Methoden

Globaal bestaan er twee methoden voor het opstellen van risicoanalyses:

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

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

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

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

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

Zwakheden en gevolgen vinden

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

1. 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 [link id=”gm8sh”]

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 onderstaande figuur zijn de drie aspecten weergegeven met hun onderlinge relaties. Een gedegen beheersplan moet alle drie de aspecten adresseren. Om een bepaald risiconiveau (classificatie) te bereiken, is daarom een zorgvuldig afgewogen set aan maatregelen vereist.

Figuur 6.4: Aspecten cybersecurity.

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

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 [link id=”fr3l3″]

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 [link id=”gkh7d”]

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

6.9 Patching en servicing [link id=”t72pv”]

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

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

6.9.1 Inleiding [link id=”h6nt7″]

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

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

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

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

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

Er kunnen in principe twee soorten patches worden onderscheiden:

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

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

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

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

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

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

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

6.9.2 Vertrekpunt [link id=”zw1z2″]

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

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

6.9.3 Processen rond patching [link id=”z62sc”]

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

• Behoefte
• Selectie
• Pilot
• Aanschaf
• Onderhoud
• Afvoer

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

• Verandermanagement
• Beheer
• Assetmanagement
• Configuratiemanagement
• Contractmanagement

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

• Software
• Firmware
• Hardware

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

• Procesbeschrijvingen
• Werkinstructies
• Rapportage

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

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

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

6.9.4 Effectief patchmanagement [link id=”srr8v”]

Uitgangspunten en voorwaarden

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

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

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

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

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

Inrichting

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

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

Figuur 6.7 De stappen in een patchproces.

Rollen en verantwoordelijkheden

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

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

Informatie over kwetsbaarheden

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

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

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

Risico-analyse

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

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

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

6.9.5 Testen [link id=”sq0fp”]

Patchen tijdens bouw of renovatie

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

Patchen in productie

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

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

6.10 Borging [link id=”l119p”]

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:

7 Verificatie en validatie [link id=”vf5tq”]

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

Opeenvolgende stappen in de validatie

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

8 Incidentrespons en herstel [link id=”wqk3f”]

“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? [link id=”x82qz”]

8.1.1 Definitie [link id=”scn7v”]

‘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 [link id=”hxk2l”]

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 [link id=”wnrtn”]

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

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

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

8.1.4 Melden en registreren [link id=”n401l”]

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 [link id=”h1drm”]

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

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

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

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

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

Kaders en plannen

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

8.3 Fase 2: Detectie en analyse [link id=”h92kh”]

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 [link id=”pnf4p”]

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 [link id=”txklg”]

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:

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

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

8.3.3 Incidentanalyse [link id=”gkwvc”]

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 over 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 [link id=”8bxbk”]

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

Een herstelplan bestaat uit de volgende onderdelen:

Afronding van het incident

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

8.5 Fase 4: Evaluatie [link id=”wlpl3″]

8.5.1 Eenmalige of structurele incidenten [link id=”6t5v6″]

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 [link id=”04ngx”]

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 [link id=”lpbf5″]

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

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

9 Bedrijfszekerheid (business continuity) [link id=”qqrks”]

9.1 Weerbaarheid van de bedrijfsvoering [link id=”rknkz”]

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

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

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

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

Relatie tussen documenten

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

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

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

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

Figuur 9.1: Verband tussen BIA, BCP en DRP.

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

Figuur 9.2: KPI’s voor incidentrespons.

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

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

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

VOORBEELD:

Figuur 9.3: Voorbeeld BCP-classificaties.

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

9.2 Inhoudsopgave BCP (m.b.t. cybersecurity) [link id=”zzz45″]

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

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

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

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

9.3 Disaster recovery plan (DRP, ramp/noodherstel) [link id=”0x4pv”]

9.3.1 Doelstelling van het DRP [link id=”1bb9h”]

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

9.3.2 Beschrijving van incidenten [link id=”0hqtt”]

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

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

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

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

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

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

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

Figuur 9.4: Risicomatrix en voorspelbaarheid van incidenten.

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

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

9.3.3 Activering van het DRP [link id=”krpnp”]

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

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

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

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

9.3.4 Opbouw en inhoud van het DRP [link id=”pqd57″]

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

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

Figuur 9.6: De thema’s van het DRP.

Een korte beschrijving van ieder thema:

1. Assemble plan

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

2. Identify scope

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

3. Appoint emergency contacts

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

4. Designate disaster recovery team

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

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

5. Assign roles and responsibilities

Specifieke rollen binnen een noodherstelteam kunnen zijn:

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

6. Restore technology functionality

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

Onderstaande procedures worden beschreven:

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

Elke procedure wordt als volgt opgebouwd:

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

7. Data and back-ups location

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

8. Testing and maintenance

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

9.4 Borgen en testen van BCP en DRP [link id=”c2cnc”]

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

10 Assetmanagement [link id=”6363p”]

10.1 Inleiding [link id=”43wx1″]

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

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

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

Assetmanagement onderscheidt de volgende fasen voor elke asset:

• Planfase en aanbesteding
• Realisatie
• Exploitatie
• Sloop

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

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

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

Figuur 10.1: Fasen in een project.

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

10.2 Planfase en aanbesteding [link id=”1sl78″]

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

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

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

10.2.1 Overwegingen voorafgaand aan aanbesteding [link id=”cl31w”]

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

10.2.2 Tijdens de aanbesteding [link id=”wv30g”]

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

10.2.3 Taken, bevoegdheden en verantwoordelijkheden [link id=”05mc1″]

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

10.2.4 Borging [link id=”455lg”]

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 fasen te valideren, waardoor het mogelijk is de vereiste maatregelen te borgen.

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

Voor de algemene aspecten rondom borging, zie 6.10 Borging.

10.3 Realisatiefase [link id=”twtw6″]

De realisatiefase van een tunnel bestaat uit de volgende deelfasen:

• 10.3.1 Ontwerp
• 10.3.2 Nieuwbouw
• 10.3.3 Openstelling

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

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

10.3.1 Ontwerp [link id=”0dz8m”]

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.

10.3.2 Nieuwbouw [link id=”2lx7b”]

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.

10.3.3 Openstelling [link id=”79nn5″]

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

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

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

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

10.4 Exploitatiefase [link id=”6p88q”]

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 10.3.2 Nieuwbouw.

10.4.1 Operationele fase [link id=”11gzw”]

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

Tot de taken van de opdrachtgever behoren:

• Beoordelen van 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 uitvoeren van incidentrespons.
• Organiseren van patching.
• Aandacht voor onder andere langlopende processen, documentatie, incidenten, logbestanden, rapportages opstellen/beoordelen, risico-inschattingen herzien, etc.
• Testen van back-up- en herstelprocedures.
• Jaarlijkse evaluatie en rapportage.

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

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

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

10.4.2 Renovatie [link id=”d84lv”]

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

De opdrachtgever heeft bij renovatie de volgende taken:

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

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

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

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

10.5 Renoveren [link id=”cc9f3″]

10.5.1 Cybersecurity is topeis bij renovatie [link id=”9tdtb”]

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

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

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

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

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

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

10.5.2 Nalatenschap in renovatieproject [link id=”30qs3″]

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

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

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

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

10.5.3 Configuratiemanagement is kritisch voor het succes [link id=”2zq46″]

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

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

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

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

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

10.5.4 Wie doet wat in een cyberveilig renovatieproject? [link id=”9l3lx”]

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

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

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

10.5.5 Welke technische maatregelen vormen de basisvoorwaarden? [link id=”39wth”]

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

10.5.6 Gevolgen van de gekozen renovatiestrategie [link id=”3v7nl”]

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

10.6 Sloop [link id=”pkz4v”]

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, back-ups, 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.

11 Legacymanagement [link id=”qr5v0″]

11.1 Inleiding [link id=”d0bxp”]

Voor de bediening en besturing van een tunnel zijn tunneloperators afhankelijk van (complexe) procesautomatiseringssystemen, ook wel industrial automation control systems (IACS) genoemd.

Deze systemen zullen (cyber)veilig gehouden moeten worden. Dit kan een lastige taak zijn, want het komt regelmatig voor dat (deel)systemen niet (gemakkelijk) vervangen of geüpgraded kunnen of (zelfs) mogen worden bij een tunnelobject. Als deze situatie zich voordoet, wordt er gesproken over het hebben van ‘legacysystemen’. Een nadere toelichting op deze definitie volgt in paragraaf 11.2 Definitie.

Aangezien tunnelobjecten voor langere tijd operationeel zijn, is de kans groot dat zij beschikken over legacysystemen. Dit hoofdstuk beoogt betrokken object- c.q. tunnelbeheerders, technisch specialisten en security-adviseurs te ondersteunen met praktische handvatten en tips bij het vraagstuk hoe om te gaan met legacysystemen in het licht van de beschikbaarheid en veiligheid van een tunnelobject. Het geeft inzicht in de keuze ‘vervangen of verlengen’ van hard/softwaresystemen vanuit cybersecurityperspectief.

De reden dat er een specifieke handreiking geschreven is voor het omgaan met legacysystemen, is dat deze systemen vanuit security-oogpunt een aantal specifieke risico’s en handelwijzen met zich meebrengen.

Legacymanagement kan niet worden gezien als een losstaand onderdeel van de bedrijfsvoering of IT-servicemanagement. Het is onderdeel van het overkoepelende proces assetlevenscyclusmanagement (asset life cycle management, LCM). Voor meer informatie over assetmanagement verwijzen we u graag naar het hoofdstuk 10 Assetmanagement.

11.2 Definitie [link id=”bpq8f”]

Een eenduidige definitie is lastig te geven. De Britse overheid definieert een systeem of technologie als ‘legacy’ wanneer het aan een of meerdere van onderstaande punten voldoet:

• Het is te beschouwen als een end-of-lifeproduct.
• Het heeft geen ondersteuning meer van de leverancier.
• Het is onmogelijk om bij te werken (te updaten).
• Het is niet langer kosteneffectief.
• Het risico van niet meer op te lossen kwetsbaarheden wordt beoordeeld als hoger dan het geaccepteerde risiconiveau (acceptable level of risk).

Een andere definitie, die wat meer op het onderwerp security ingaat, is de volgende:

A legacy environment is a custom environment containing older systems or applications that may need to be secured to meet today’s threats, but often use older, less secure communication mechanisms and need to be able to communicate with other systems.

In de context van deze handreiking hanteren we de hierboven genoemde Britse definitie. Of, en zo ja op welke wijze, legacysystemen beschermd moeten worden tegen eventuele dreigingen is iets wat in de risicoafweging bepaald zal worden.

11.3 Risico’s [link id=”9sp9t”]

De risico’s van legacysystemen vereisen een andere aanpak dan risico’s van niet-legacysystemen. De mogelijke cybersecurityrisico’s die legacysystemen met zich meebrengen, zijn onder andere:

• Misbruik van kwetsbaarheden in hardware en software.
• Geen up-to-date virusscanner.
• Geen vervangende hardware verkrijgbaar.
• Benodigde kennis is niet meer aanwezig zowel in de eigen organisatie als daarbuiten.
• Geen updates/patches verkrijgbaar.
• Geen support meer op:
  • Hardware
  • Firmware
  • Software
  • Besturingssysteem
  • Applicaties
  • Databases

11.4 Praktische handvatten om met legacy aan de slag te gaan [link id=”9v8gr”]

Deze paragraaf beoogt een stappenplan te geven zodat de lezer zich bewust wordt van mogelijke oplossingsrichtingen om de risico’s die legacysystemen met zich meebrengen, te beheersen. Het stappenplan dient als een ‘stepping stone’ gezien te worden. Het is een voorbeeld van een mogelijke aanpak aangezien de context waarin de legacy zich bevindt van invloed kan zijn op de aanpak ervan.

11.4.1 Stap 1: Inzicht krijgen in de problematiek en context [link id=”9kvsm”]

Met deze stap wordt beoogd een aantal cruciale vragen te beantwoorden:

1. Over welke systemen praten we?
2. Wat is de context van deze omgeving?
3. Zijn er verzwarende of verzachtende omstandigheden?

Om deze vragen te beantwoorden, is het van belang om over de juiste informatie te beschikken. Een deel van de informatie is te achterhalen uit documentatie, het merendeel zal beschikbaar (moeten) zijn in een ‘asset inventory’ of configuratiemanagementdatabase (CMDB). In de praktijk blijkt een CMDB vaak aanwezig, maar niet van het juiste detailniveau. Componenten uit de industriële omgeving zijn door overwegingen uit het verleden vaak (nog) niet in de CMDB te vinden.

Om legacysystemen effectief aan te pakken, wordt hieronder een aanzet gegeven voor de minimale informatiebehoefte. Deze lijst geeft een richting en kan afhankelijk van de problematiek verder uitgebreid of geminimaliseerd worden.

• Hardwarecomponenten (fabrikant, productlijn, etc.)
  • PC/workstation/serversystemen
  • Bedien- en engineeringsystemen
  • PLC’s
• Softwarecomponenten (naam, versienummers, patch levels, etc)
  • Firmware
  • Besturingssysteem
  • Applicatie
  • Database
• Context
  • Connectiviteit; verbindingen met andere systemen, domeinen, omgevingen.
  • VLANs; aparte verkeersstromen voor bv. beheer, SCADA, PLC.
  • Fysieke beveiliging; gebouwzonering, ruimtecompartimenten, sloten op kasten.
  • Configuratie.
  • Overige securityaspecten (logische beveiliging, malware detectie, etc.)

Het verkrijgen van inzicht in deze aspecten is de eerste stap en een vereiste om de volgende stappen te kunnen doorlopen. Het kiezen van een methode hiervoor is aan de lezer. Binnen diverse organisaties is hier ervaring mee opgedaan en de werkzaamheden bestaan vaak uit een mix van bureaustudie, expert meetings en geautomatiseerde datacollectie.

Aandacht is vereist voor het uitvoeren van scan-software (asset discovery) in een legacyomgeving. Sommige systemen reageren onvoorspelbaar (bv. trip mode PLC) als een sweep-pakket draait om assetinformatie te inventariseren. Doe dit daarom bij voorkeur in een testomgeving of duplicaat van de productieomgeving die vanuit een back-up is hersteld.

11.4.2 Stap 2: Risicoafweging [link id=”vkklr”]

Een volgende stap is, aan de hand van het verworven inzicht over de omgeving, een inschatting te maken van wat de daadwerkelijke risico’s zijn. Daarmee wordt een aanzet gegeven om de volgende vragen te beantwoorden:

• Hoe groot is mijn probleem eigenlijk?
• Op welk deelgebied zitten mijn risico’s?
• Welke maatregelen zijn het meest effectief?
• Welke risico’s wil ik aanpakken, welke accepteer ik (tijdelijk)? Ofwel, wat is de ‘risk-appetite’ van mijn organisatie en wat is daarvan het gevolg voor mijn geïdentificeerde risico’s? Dit kan eventueel ook betekenen: acceptabele uitval/stilstand van het object, acceptabele financiële schade, tot zelfs tolerantie van ongevallen.

Om een goede risicoanalyse uit te voeren, is een aantal ingrediënten nodig (zie ook 6 Risicogestuurde aanpak):

1. Een idee van de ‘belangrijkheid’ van een object:
   • Wat is het effect van falen op de functie van het object?
   • Wat is het effect van uitval van het object op de omliggende keten?
2. Een gekozen risicoanalysemethodiek met vastgestelde categorieën. Hiervoor zijn verschillende methodes beschikbaar. De meeste simpele vorm is ‘risico = kans * impact’, waarbij ‘kans’ bijvoorbeeld ‘verwaarloosbaar’ t/m ‘waarschijnlijk’ is in diverse stappen, en voor impact gekozen kan worden voor categorieën zoals RAMSSHEEP, BIV, etc.
3. Een schatting wanneer het risico mogelijk kan optreden. Morgen? Of over een jaar?
4. Indien er een vergelijking met andere objecten of andere risico’s nodig is: een uniforme scoringsmethodiek. Hiermee kunnen de juiste beslissingen gemaakt worden over het inzetten van een beperkt budget.
5. Een realistische dreigingen/kwetsbaarhedenlijst waarop gescoord kan worden.
6. Een groep experts uit diverse onderdelen binnen en eventueel buiten de organisatie. De groep moet een voldoende spreiding kennen, maar niet een open gesprek in de weg staan. Het is daarom aan te raden niet gelijk juridisch experts te laten aansluiten aangezien de discussie dan niet het gewenste karakter krijgt. Te denken valt aan:
   • Een procesbegeleider.
   • Een beheerder/assetmanager.
   • Een IA/OT/ICS-expert met technisch inhoudelijke kennis.
   • Een (industriële) cybersecurityexpert.
   • De marktpartij indien onderhoud uitbesteed wordt.

Tijdens de risicosessie is het verkrijgen van context van belang:

• Wat is mijn externe exposure (ben ik aan een ander netwerk/het internet gekoppeld?)
• Wat is mijn vervlechting met de kantooromgeving (segmentering) c.q. andere industriële toepassingen?
• Welke datastromen zijn er en hoe lopen ze?
• Etc.

Een goed uitgevoerde risicoanalyse levert een lijst op met realistische risico’s die van belang zijn voor de omgeving. Dit inzicht is van belang om tot een onderbouwde aanpak van legacysystemen te komen. Een resultaat kan ook zijn dat een legacysysteem in de organisatie geen daadwerkelijk risico vormt vanwege zijn context, of dat beperkte middelen effectiever ingezet kunnen worden op andere onderdelen dan initieel verwacht zou worden.

11.4.3 Stap 3: Aandachtspunten (horizon, contractvormen, etc.) [link id=”zcltn”]

Voordat een selectie van maatregelen kan worden gemaakt, moet nog een aantal aandachtspunten meegenomen worden. Eerder is vermeld dat legacysystemen vaak voorkomen in kritische omgevingen waarvan continue beschikbaarheid verwacht wordt. Daarnaast zijn er vaak een aantal specifieke karakteristieken:

• Zeer beperkt aantal onderhoudsmomenten, meestal een beperkt aantal per jaar. Deze zijn daarnaast vaak al ‘volgepland’.
• Renovatiehorizon in de orde van tientallen jaren.
• De systemen voor de besturing zijn niet ontworpen met de mogelijkheid eenvoudig aanpassingen door te voeren.
• Vaak geen degelijke testomgeving beschikbaar.
• Beperkte (technische) prestaties/capaciteit voor extra technische maatregelen (malwarescanning, etc.).

Dit leidt ertoe dat, bijvoorbeeld, een maatregel als patching vaak een uitdaging – zo niet onmogelijk – of niet effectief is.

Er dient dus allereerst gekeken te worden naar wat de mogelijkheden wél zijn, en tevens dienen de maatregelen zo gepland te worden dat ze op de juiste momenten uitgevoerd kunnen worden. Daarmee kan een (tijdelijke) situatie ontstaan waarin andere maatregelen of risico’s geaccepteerd worden:

• Onderhoudsmomenten: hoeveel onderhoudsmomenten heb ik per jaar, welke ruimte heb ik om maatregelen in te voeren?
• Vervanging en renovatie: het moment om ook systeem technische maatregelen toe te passen. Tot dit moment alternatieve maatregelen? Extra aandacht voor ‘hygiëne’ (USB-sticks schonen, oppassen met laptop koppelen, etc).
• Contractvormen, zoals:
  • Prestatiecontracten: ongeveer om de 5-10 jaar wisseling van contractpartij. Op deze momenten kunnen vaak contractueel proceseisen (maatregelen) ingevoerd worden. Qua systeemtechnische eisen zijn er minder kansen.
  • DBFM: uitgangspunt is vaak 20+ jaar legacysystemen voeren waarbij alle defecte onderdelen een-op-een vervangen worden met reservedelen die voor die periode op de plank liggen. Aan het einde van deze contractperiode zal mogelijk een sterk verouderd systeem aangetroffen worden.
  • Noorse systematiek: contracten sluiten voor de duur van 10/15 jaar en na een nieuw afgesloten contract de systemen totaal vernieuwen en volledig onderhouden.
  • Etc.

Het resultaat van deze analyse is het identificeren van kansen en momenten om maatregelen(pakketten) door te voeren. Het kan ook leiden tot het inzicht dat bewust meer kansen gecreëerd moeten worden, bijvoorbeeld een specifiek onderhoudsweekend voor het doorvoeren van vervanging en cyberweerbaarheidmaatregelen.

Afhankelijk van de mogelijkheden ontstaat een bepaalde ruimte tot het nemen van een mix van maatregelen. Deze mix kan meer op preventie, detectie of juist respons leunen. Tevens kan een keuze en afweging worden gemaakt voor technische, procedurele en/of organisatorische maatregelen.

Vanaf een bepaald moment zal een kans ontstaan om het volledige legacysysteem te kunnen vervangen voor een nieuw systeem. Duidelijkheid over dit moment geeft een onderbouwing voor de keuze van maatregelen en/of het accepteren van risico’s.

Gevisualiseerd ziet het bovenstaande er als volgt uit:

Figuur 11.1 Legacy-levenscyclus van IT en OT assets.

11.4.4 Stap 4: selectie van maatregelen [link id=”51970″]

In deze paragraaf wordt een aantal mogelijkheden aangedragen om legacysystemen enigszins te beschermen tegen cybercalamiteiten. Voor legacysystemen zijn er altijd minder keuzes in maatregelen dan voor courante systemen die in een andere fase zitten van hun levensduur.

In de basis zijn drie beginselen van toepassing:

• Nemen van maatregelen – technisch, organisatorisch en mensgericht.
• Detectie – monitoring van de legacysystemen.
• Herstel – veelal technisch van aard.

De keuze aan maatregelen hangt ook af van de cyberrisicoinschatting, de kosten, doorlooptijd van het project en het moment wanneer de noodzaak ontstaat om het legacysysteem daadwerkelijk te migreren.

Elke situatie zal uniek zijn en hierdoor ook de keuzes die gemaakt worden. Dit betekent dat men op de hoogte is van het risico en de gevolgen accepteert. Geen keuzes maken of geen besluiten nemen is ook een daaraan verbonden besluit.

Als voorbeeld is dit weergegeven de figuur hieronder. Dit project kan gezien worden als een VTW, zoals in het eerdere figuur hierboven is weergegeven.

1. Men erkent het cyber security risico.
2. De inschatting is dat de gevolgen (te) groot zijn.
3. De renovatieplannen zijn te onzeker.
4. De tijdsduur tussen niets-doen en de renovatie is te lang of te onzeker.
5. Men besluit om een project te starten om het risico zo veel mogelijk te verkleinen.

Figuur 11.2 Besluitvorming over (tijdelijke) risicoreductiemaatregelen.

Voor het beheersen van de risico’s kan gedacht worden aan de volgende typen maatregelen (conform het ‘defense in depth’-model):

1. Organisatie en factor mens: beide zijn de meest zwakke maatregelen, maar het aanscherpen van beleid en toezicht hierop kan veel voorkomen.
2. Fysieke en logische toegangscontrole: bescherm het legacysysteem zo veel mogelijk tegen fysieke en logische toegang. Daarbij behoeft de logische toegang de meeste aandacht. Hierbij kan worden gedacht aan:
   1. Het beperken van het aantal dataverbindingen indien mogelijk.
   2. Het afsluiten dan wel blokkeren van poorten die niet gebruikt worden (hardening).
   3. Het migreren van de dataverbinding naar een verbinding die wel cyberveilig gemaakt kan worden.
   4. Het plaatsen van een additionele gateway of een controller vóór het legacysysteem.
   5. Het controleren ook of nog een oude modemverbinding aanwezig is en die verwijderen.
3. Netwerk/systeemsegmentatie: bekijk of het legacysysteem op microniveau gesegmenteerd kan worden van de overige systemen door bijvoorbeeld het systeem in een apart VLAN te plaatsen in combinatie met firewalls of speciale gateways.
4. Accountmanagement: veelal zijn legacysystemen ingericht met generieke accounts waarbij in de loop van de jaren veel mensen zowel intern als extern weten hoe zij moeten inloggen. Door regelmatig de toegangscodes te wijzigen, wordt het aantal mensen dat daadwerkelijk toegang heeft beperkt tot degenen die dat daadwerkelijk nodig hebben.
5. Antivirus/malware: deze maatregel is veelal niet uitvoerbaar omdat het gedrag van legacysystemen in combinatie met antivirussoftware niet in te schatten is. De leverancier van het legacysysteem zal waarschijnlijk geen ondersteuning (meer) bieden en het risico ligt geheel bij de eindgebruiker. Daarnaast vergt antivirussoftware rekencapaciteit en geheugen die veelal onvoldoende zullen zijn bij legacysystemen.
6. Patchen: dit is de meest effectieve maatregel. Echter is deze maatregel veelal niet uitvoerbaar als de ondersteuning op systemen is gestopt (securitypatches worden niet meer uitgegeven). Soms kunnen, tegen hoge kosten, met de leverancier afspraken gemaakt worden om toch deze patches te blijven ontvangen. Deze worden dan specifiek voor de klant ontwikkeld.
7. Eindpuntbescherming, hierbij hoort:
   1. Whitelisting. Deze vorm van protectie is zeer effectief en vraagt relatief weinig processorcapaciteit.
   2. Niet-gebruikte software verwijderen.
   3. Niet-gebruikte drivers en interfaces blokkeren.
8. Back-up en herstel: een goed back-up-en-herstelbeleid en -strategie zijn belangrijk. Dit is het laatste redmiddel om uiteindelijk weer naar een vast gedefinieerde situatie te komen.

Extra aandacht is nodig voor het gebruik van monitoring en vroegtijdige detectie. Systemen die het netwerkverkeer analyseren en vroegtijdig waarschuwen en alarmeren, kunnen de impact van een cyberincident verkleinen of in het gunstigste geval voorkomen. Deze systemen controleren niet alleen de legacysystemen, maar ook alle andere assets die in de netwerken zijn opgenomen.

Ten slotte is er nog een aantal mogelijkheden die het onderzoeken waard zijn:

1. Bij verouderde hardware:
   • Opkopen reserveonderdelen bij leverancier of zoeken op de tweedehandsmarkt of refurbishment.
   • Re-host (‘lift and shift’): verplaats OS en applicatie naar nieuwe hardware (of virtualiseer). Er dient vroegtijdig onderzocht te worden of deze oplossing technisch zal gaan werken met volledig behoud van de functie (applicatie). Met deze oplossing wordt uitsluitend het risico m.b.t. de hardware opgelost.
2. Bij verouderd besturingssysteem: re-platform (‘lift and shape’). Migreer naar een courant besturingssysteem. Kwetsbaarheden op het nieuwe besturingssysteem worden door middel van courante securitypatches verholpen. De applicatie dient wel compatibel te zijn met het nieuwe besturingssysteem.
3. Bij verouderde applicatie zijn de mogelijkheden zeer beperkt. Indien de leverancier de huidige applicatie niet meer ondersteunt, is de enige mogelijkheid te migreren naar een functioneel gelijkwaardige applicatie.
4. Volledige vervanging (‘retire’): dit is vaak de duurste optie en komt in de praktijk neer op vervanging door een geheel nieuw (deel)systeem om de betreffende functionaliteit in te vullen. Dit nieuwe systeem dient dan opgezet te worden volgens het security-by-designprincipe.

11.5 Het voorkomen van legacy [link id=”st4sm”]

Het managen van legacysystemen zou geen enkele organisatie moeten willen. Vanuit cybersecurityoogpunt moet het hebben en gebruiken van legacysystemen zoveel mogelijk worden voorkomen en dient men een actief beleid te voeren om dit te bereiken. Uiteraard is legacy niet altijd te voorkomen, zie figuur 11.1 als voorbeeld.

11.5.1 Techniek, assetmanagementstrategie en proces [link id=”8slrw”]

Om legacy zo goed mogelijk te voorkomen, kan tijdens de ontwerpfase (security-by-design) rekening gehouden worden met cybersecurityrisico’s en ruimte gecreëerd worden voor de mogelijkheid tot het nemen van maatregelen. Denk daarbij aan het eenvoudiger maken van patching, onderhoud, upgrades, vervangen van (deel)systemen, etc. Dit kan bijvoorbeeld door standaardisatie, gebruik van open standaarden, protocollen en API’s. Hiermee kan functionaliteit modulair worden opgebouwd, wat de afhankelijkheid tussen systemen vermindert door goed afgebakende koppelvlakken. Daarnaast bieden virtualisatieplatformen een goede basis om afhankelijkheden tussen hardware, software en besturingssystemen te verkleinen.

Verder valt te denken aan:

• Goede testomgeving of liever nog een volledige failover-omgeving (omgeving waarnaar overgeschakeld kan worden bij problemen). Dit verhoogt de mogelijkheid tot het uitvoeren van updates/upgrades aan de systemen terwijl er minimaal ingeboet hoeft te worden op onderhoudstijd.
• Assetmanagement, levenscyclusmanagement:
  • Het plannen van updates/upgrades van de systemen in de toekomst, en daarvoor ook het budget beschikbaar stellen.
  • Afstemmen met onderhoud, vervanging en renovatie
  • Kansen tijdens wisseling onderhoudscontracten
• CMDB: het inzichtelijk hebben en daarmee het kunnen identificeren van componenten die dreigen te verouderen, is een voorwaarde voor het kunnen uitvoeren van goed assetmanagement.
• Afspraken met leveranciers, inzicht in ondersteuningstermijnen.

11.5.2. PDCA [link id=”dp20k”]

Een plan-do-check-act-strategie (PDCA) wordt veel bij cybersecurity gebruikt voor het onderhouden en (continu) verbeteren van securityprocessen en -maatregelen. Cybersecurity bedreigingen veranderen continu door veroudering van de eigen installaties, technologische ontwikkelingen, kwaadwillenden en kennis die steeds meer toegankelijk wordt. Door minimaal jaarlijks een risicoinventarisatie en -evaluatie (RI&E) op legacysystemen uit te voeren, wordt getoetst of aan het minimale risicoprofiel voldaan wordt. Tevens wordt naar de toekomst gekeken, zoals naar een eventuele overbruggingsperiode en eventuele andere thema’s die spelen (conjuncturele ontwikkelingen, beschikbaarheid van budget, contractperiodes en contractvormen etc.).

11.5.3 Aanvullende bronnen [link id=”53g72″]

Het NCSC en Rijkswaterstaat hebben het onderwerp legacy vanuit hun expertise als visie en aanbeveling belicht in de wijze waarop men met legacysystemen moet omgaan.

• Het NCSC heeft in 2022 een whitepaper uitgebracht m.b.t. legacysystemen
• Rijkswaterstaat heeft in de door hen opgestelde Cybersecurity implementatierichtlijn (CSIR) het legacy-aspect geëvalueerd en waar van toepassing specifiek gemaakt en gedefinieerd voor het gebruik binnen de beheerprocessen van een tunnelobject.

12 Businesscase [link id=”2b7rg”]

12.1 Het hoe en waarom van een businesscase [link id=”8m7sn”]

Een veel gehoorde stelling ‘Wat word 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 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.

12.2 Fasen in cybersecuritybeleving [link id=”8256v”]

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 12.1: Volwassenheidsfasen cybersecurity

12.2.1 Ontkenning [link id=”5h7fd”]

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.

12.2.2 Erkenning [link id=”76s3s”]

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.

12.2.3 Verkenning [link id=”6xzbp”]

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

12.2.4 Actie [link id=”n0prx”]

In deze fase wordt de opdracht gegeven voor het schrijven van de businesscase. Hierin worden 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.

12.2.5 Volhouden [link id=”11sds”]

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 cybersecurity risico 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 te starten (verkenning). Uit dit onderzoek kan naar voren komen dat er geen/weinig risico’s zijn (kans x impact) en zal er geen businesscase opgesteld worden. Een memo kan volstaan dat er een risico-inventarisatie, -analyse en -evaluatie heeft plaatsgevonden met als resultaat een beperkt risicoprofiel.
• Terugval-lus: terugvallen naar ontkenning Na het uitvoeren van de risicoanalyse en het implementeren van de geselecteerde maatregelen kan een (vals) gevoel van veiligheid ontstaan (‘Ik heb alles geregeld’) met een terugval naar oud gedrag. Dat gaat voorbij aan de mogelijkheid dat nieuwe dreigingen ontstaan of nieuwe kwetsbaarheden bekend worden die mogelijk nieuwe maatregelen vereisen.

12.3 Aspecten van een businesscase in relatie tot cybersecurity [link id=”ft2w0″]

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

Figuur 12.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 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-off matrix (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 aspecten (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 [link id=”hcp10″]

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 [link id=”tvtr4″]

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 [link id=”641s3″]

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 [link id=”bvz06″]

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 [link id=”vtn6k”]

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 [link id=”l60v0″]

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 [link id=”678fg”]

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 [link id=”h2q80″]

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 [link id=”vnkxn”]

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 [link id=”lndn7″]

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

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

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

Noot:

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

Bijlage 3 Cybersecurity en tunnelveiligheid [link id=”t8qm3″]

B3.1 Aanleiding [link id=”vlsh5″]

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

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

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

B3.2 Inleiding [link id=”x96bc”]

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

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

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

B3.3 Projectfase [link id=”b252p”]

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

B3.4 Exploitatiefase [link id=”96hr0″]

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

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

B3.5 Achtergronden [link id=”5g6vc”]

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

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

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

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

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

Opmerking:

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

B3.6 Vragen en mogelijke antwoorden t.a.v. cybersecurity en veiligheid [link id=”6ltzt”]

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

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

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

De oplossing voor de tunnelbeheerder moet dus gezocht worden in het inrichten van verschillende instrumenten om deze toetsing periodiek te kunnen uitvoeren. In de volgende paragrafen wordt hiertoe een voorstel gedaan.

B3.6.1 De doelen van cybersecurity voor OT [link id=”rfp2l”]

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

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

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

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

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

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

Van operationele doelen naar systeemdoelen

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

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

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

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

B3.6.2 Hoe past cybersecurity in de tunnelveiligheidsaanpak? [link id=”2r6c6″]

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

Goed huisvaderschap

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

Autoriteit persoonsgegevens (AP) 

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

Art 5. van de Warvw, Veiligheidsbeambte

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

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

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

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

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

Art 6.2 van de Warvw, tunnelveiligheidsplan voor een nieuwe tunnel

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

Art 10 van de Warvw, tunnelveiligheidsdossier voor een nieuwe tunnel

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

Art 10 van de Warvw, tunnelveiligheidsdossier voor een bestaande tunnel

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

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

B3.7 Totaaloverzicht toezicht [link id=”s2f3l”]

Bijlage 4 Kenniswijzer [link id=”qn6tv”]

B4.1 Inleiding [link id=”f8sk6″]

Tunneloperators, tunnelbeheerders en hun veiligheidsbeambte, bevoegde gezagen en alle andere stakeholders zijn verantwoordelijk voor de betrouwbaarheid en beschikbaarheid van een tunnel, met de aangebrachte tunnelinstallaties, opdat de tunnel veilig is voor exploitatie én dat ook in de toekomst blijft. Als de tunnelinstallaties niet betrouwbaar (blijken te) zijn, moet de vraag worden gesteld of de tunnel wel veilig is en dus, volgens de Warvw, wel open mag blijven.

Bij de betrouwbaarheid hoort zeker ook de bekwaamheid van het personeel rond de tunnel. Zij maken deel uit van het tunnelsysteem en zijn nodig om de betrouwbaarheid van de systemen te kunnen beoordelen en dus een gefundeerde conclusie te kunnen trekken.

Ook moet, vanwege de toenemende automatisering, aandacht besteed worden aan de ‘cyberveiligheid’. Binnen de cybersecuritywereld is een veelheid aan specialisten werkzaam die elk één of meerdere van kennisvelden beheersen. De verwevenheid tussen informatiebeveiliging, privacy en cybersecurity maakt het vrijwel onmogelijk om delen van informatie af te snijden als ‘niet relevant’. De technische overlapping van IT- en OT-systemen zorgt ervoor dat eisen uit beide werelden meegenomen moeten worden.

Het groeiboek Cybersecurity geeft een handvat voor het implementeren en beheersen van cybersecurity in tunnels. In het groeiboek is aangegeven wie de stakeholders zijn voor een tunnelproject en wat de rollen en taken zijn in het kader van cybersecurity. Een van de belangrijkste maatregelen ligt op het terrein van training en bewustwording. Mensen die werken aan de tunnel zullen cybersecurity-bewust moeten zijn, en zijn opgeleid voor hun taak. Daarbij kunnen vragen ontstaan:

• Wat wordt van mij verwacht in het cybersecuritydomein?
• Wat zou ik moeten weten voor mijn werk in/met de tunnel?
• Waar haal ik die kennis vandaan?

Deze kenniswijzer geeft een antwoord op deze vragen. De vragen kunnen op individueel niveau opkomen, en kunnen ontstaan bij het projectteam dat verantwoordelijk is voor de samenstelling van de organisatie van de tunnel. Op basis van deze vragen wordt een aanzet gedaan voor een te volgen spoor voor uitbreiding en verdieping van kennis op het gebied van cybersecurity bij de doelgroep.

B4.1.1 Doelstelling [link id=”3dh50″]

Doelstelling van dit document is een tunnelmedewerker een hulpmiddel te bieden om zelfstandig tot een oordeel te komen over de situatie van de cybersecurity in zijn werkomgeving in relatie tot zijn taken en verantwoordelijkheden. De volgende vragen worden beantwoord:

• Welke doelgroepen op het gebied van cybersecurity zijn er voor personeel van tunnelorganisaties?
• Welke kennisbehoefte is er bij de verschillende stakeholders in de tunnelorganisatie?
• Wat zou iemand die zich wil verdiepen in cybersecurity in welke volgorde moeten lezen?
• Is er een spoor door de informatie te trekken waarbij inzicht en zelfstandige oordeelsvorming mogelijk wordt en geen dwingende aanpak wordt opgelegd zonder te weten waarom?

Wie op zoek gaat naar informatie over cybersecurity en informatiebeveiliging wordt het al gauw duidelijk dat er voor IT-omgevingen vele malen meer documentatie is dan voor de OT-omgevingen. Hierdoor ontstaat het risico dat iemand in een doolhof van niet-relevante bronnen verzandt. Een gevolg is dat men elkaar met meer of minder relevante lijsten om de oren slaat.

In het groeiboek is gewezen op het feit dat de beveiliging van de operationele systemen in de OT-omgeving afhankelijk is van de beveiliging van de IT-omgeving. Door de gedeeltelijke verwevenheid tussen beide omgevingen mag een zekere kennis van IT-beveiliging dus niet ontbreken. Maar hoever gaat dat dan? En kan ik op de beveiliging van de IT-omgeving vertrouwen?

B4.1.2 Doelgroep [link id=”ct4bx”]

De doelgroep voor deze kenniswijzer bestaat uit de stakeholders die een verantwoordelijkheid hebben in de exploitatiefase van de tunnel. De doelgroep is beperkt tot de exploitatiefase omdat deze periode de langst durende periode is van de levenscyclus van een tunnel. De volgende vragen zijn meegenomen voor het bepalen van de doelgroep:

1. Hoe wordt een overzicht van cybersecuritystakeholders gemaakt?
2. Voor wie van deze stakeholders is (welke) cybersecurity-kennis relevant?
3. En als cybersecurity relevant is, gaat het dan alleen om bewustwording of meer dan dat? En wat dan?
4. Is relevante cybersecuritykennis voor een tunnel te clusteren naar de tunnelrollen? Oftewel: kijken we naar rollen of naar individuele stakeholders?
5. Dienen er stakeholders en rollen toegevoegd te worden voor niet-rijkstunnels? Of is dat eenvoudig te vertalen?

B4.1.3 Achtergrond [link id=”d185c”]

In de wetgeving rond tunnels zijn stakeholders en rollen benoemd, echter is er (nog) geen echte aandacht voor de digitale bedreigingen en de daaruit voortkomende risico’s. Om deze reden is niet goed belegd wat van wie verwacht wordt. Wat is voor welke functie interessant of nodig? En moet je gecertificeerd zijn, een certificaat halen of is het voldoende om er eens wat over te lezen?

Wie zich gaat verdiepen in de thematiek stuit al snel op termen als: CSMS, ISMS, NCSC, NEN-ISO-27001, IEC-62443, CSIR, AVG, GDPR, Wbni/Bbni, NIS/NIS2, OSI-model, BIO, NIST, SOC, COBIT, ANSI, CVE, CIS etc. En wie het dan nog niet duizelt, kan nog wel even doorgaan. Een deel van die termen wordt in dit groeiboek behandeld en toegelicht. De hier opgesomde afkortingen horen bij heel verschillende zaken. Het betreft bijvoorbeeld:

• Standaarden (ISO-270xy, IEC-62443) en afgeleiden daarvan (BIO, CSIR)
• Organisaties (NCSC, NIST, ISA, ANSI, SOC)
• Frameworks (COBIT, CIS)
• Regelgeving (GDPR/AVG, NIS/NIS2 geïmplementeerd in de Wbni en het Bbni)

Een voorbeeld

Wat te denken van onderstaande tekst uit een vacatureomschrijving waarin, voor een beheerder van operationele systemen in de OT-omgeving, gevraagd wordt naar:

• Ervaring met beheer-, beveiligings- en projectmethodieken (ITIL, ISO-27001/2 en PRINCE2) en kennis van ICS-componenten/systeemdelen zoals PLC’s, HMI’s.
• Een of meerdere securitycertificeringen zoals GIAC GICSP, GRID, GCIH, GMON.

De verwarring tussen proces en techniek in de IT-omgeving (kantoor) en de OT-omgeving (operationele processen) is hier groot. Het is totaal onduidelijk of hier nu een procesmanager of een technisch beheerder wordt gevraagd. Waarschijnlijk is voor de opsteller nog niet duidelijk welke rol er voor de vacature is bedacht. Het werkgebied van informatiebeveiliging en cybersecurity, verdeeld over de aspecten mens, proces en techniek, is te groot om in een eenvoudig schema te vatten. Als je werkgebied ligt in de tunnelwereld met de bijbehorende OT-omgeving dan kun je wel gemak hebben van kennis uit het IT-domein, maar dat maakt je nog niet een goede systeembeheerder in een tunnelsysteem.

B4.2 Stakeholderanalyse [link id=”bsvqr”]

Voor de stakeholderanalyse zijn de rollen zoals die in 4.4 Basis-organisatiemodel voor cybersecurity zijn opgenomen, als uitgangspunt gebruikt. Bij de analyse zijn twee opmerkingen vooraf van belang:

• Bijlage 5 Analyse tunnelstakeholders en cybersecuritybelangen, bevat een meer uitgebreide analyse van stakeholders vanuit de Warvw en de LTS. Omdat de cybersecurityrollen niet voorkomen in deze twee bronnen is de koppeling tussen rollen en stakeholders niet een-op-een te maken. Dit zal per tunnelsysteem expliciet gemaakt moeten worden, waarbij de hier gegeven informatie goed kan helpen.
• De doelgroep is beperkt tot de operationele fase. Deze fase bestaat uit exploitatie en (regulier) beheer en onderhoud. De analyse kan wel uitgebreid worden tot de andere fasen uit de levenscyclus. Voor de planfase begint het dan bijvoorbeeld met de beleidsmakers ten behoeve van aanbestedingen. Dan is het al belangrijk de conflicten tussen de normen, kaders en standaarden in relatie tot cybersecurity te bespreken.

De bedoelde rollen zijn in onderstaande tabel weergegeven:

Allereerst wordt vastgelegd wie voor welke cybersecurityaspecten verantwoordelijk zijn. Hierbij zijn de volgende aspecten als selectiecriteria zijn aangenomen:

• Verantwoordelijk vanuit (wettelijke) aansprakelijkheid (zie ook werkgroep tunnelveiligheid en safety)
• Technisch specialisten tunneltechnische installaties (TTI)
• Risicobeoordeling en risicomanagement
• Fysieke toegang tot technische ruimtes
• Netwerkbeheerders

De stakeholders worden gezocht onder:

• Beheerders
• Asseteigenaren
• Technisch beheerders
• Testers
• Onderhoudsaannemers
• Landelijke diensten
• Hulpdiensten

De tabel moet per tunnelsysteem worden uitgebreid, zie ook de informatie in B.4.B Analyse tunnelstakeholders en cybersecurity belangen. Voor de tunnels zal de lijst specifiek worden voor:

• Rijkstunnels
• Provinciale tunnels
• Gemeentelijke tunnels
• Private tunnels (bv. bedrijven)
• Spoortunnels (trein, metro)

Vanuit het vastleggen van de verantwoordelijkheden ontstaat de vraag naar welke kennis en kunde verwacht wordt op het gebied van cybersecurity. Hierover gaat de volgende paragraaf.

B4.3 Benodigde kennis en kunde [link id=”2kmv6″]

Vervolgens is bekeken welke kennis en kunde (betreffende cybersecurity) per stakeholder nodig is voor het vervullen van zijn verantwoordelijkheid. Die kennis en kunde kan op veel manieren worden verkregen. Om hier enige structuur in aan te brengen, is het belangrijk onderscheid te maken met de volgende criteria:

• Onderscheid tussen IT- en OT-omgeving. De meeste kennis wordt aangeboden vanuit een IT-achtergrond. Zie elders in het groeiboek voor het verschil en het belang van het onderscheid tussen beide omgevingen.
• Wetten, normen en richtlijnen: weet waar je aan moet voldoen, een norm zal veelal verplicht gesteld zijn, een richtlijn is een keuze.
• Begin met het bevorderen van bewustwording, vervolg daarmee en blijf volhouden met bewustwording.

B4.3.1 Onderwerpen en aspecten [link id=”c1c78″]

Bewustwording

Met betrekking tot bewustwording is onderscheid te maken in de doelen:

• Algemeen
• Functiegericht
• Kaderstellend

Het bewustzijn van het belang van cybersecurity vanuit een kaderstellende rol kan heel goed beginnen met het lezen van het document Cybersecuritybeeld Nederland 2022. Binnen de organisatie van een tunnelsysteem is het van belang een awareness-programma op te stellen en te volgen waarbij minimaal jaarlijks wordt getoetst of er voldoende bewustzijn is op de cybersecurityaspecten. Awareness richt zich primair op het herkennen van risicovolle situaties door het herkennen van incidenten en daaruit op het aanleren van gewenst gedrag.

Cybersecuritykaders en -organisatie

• Kennis van wet- en regelgeving op het gebied van informatiebeveiliging, cybersecurity en privacy.
• Kennis van de organisatie en de processen.
• Kennis van de afhankelijkheden van derden (leveranciers etc.).

Kennis in het managen van cybersecurityrisico’s

De vraag ‘Welke risico’s loopt een organisatie/object eigenlijk?’ kan alleen beantwoord worden vanuit het kennen van de waarde van de organisatie/object. Het accepteren of verminderen van risico’s is een formeel proces (risicomanagement) dat door de organisatie ingericht moet zijn.

• BIA voor het bepalen van wat de kroonjuwelen zijn.
• Risico-assessment en risicomanagement: risico-eigenaarschap is key! Wie is de ‘eigenaar’ van een risico?
  • Een persoon en geen afdeling… degene die de impact voelt.
  • Zo laag mogelijk in de organisatie, maar niet lager dan dat besluiten genomen kunnen worden en de impact van maatregelen overzien kan worden.
  • Is gemandateerd en heeft budget voor maatregelen.
  • Heeft voldoende procuratie om de restrisico’s te accepteren.
  • Kan de maatregelen delegeren, maar blijft de risico-eigenaar.
  • Legt verantwoording af over de restrisico’s.

Cybersecuritybeleid

Om aantoonbaar te voldoen en te blijven voldoen is kennis en kunde nodig op het gebied van:

• Beleid voor patchen en updates.
• Leveranciers en onderaannemers relaties.
• Documentmanagement met oog voor vertrouwelijkheid van (ook technische) informatie.
• Bedrijfsmatige certificering en standaardisering (ISO 27001 en NEN-EN-ISO 9001).
• Evaluatie, auditing en stand van zaken cybersecurity.
• Screening van personeel.
• Incidentbewustzijn.
• Incidentrespons- en bedrijfscontinuïteitsplannen.
• Compliancy en borging.

Technische kaders

Voor de operationele omgeving is er veel technische kennis nodig. Voor een tunnelsysteem is deze kennis opgeslagen in een tunnelveiligheidsdossier. In de praktijk wordt voor het gebruik en onderhoud van systemen teruggegrepen op de kennis van fabrikanten/leveranciers en/of de onderhoudsaannemer. Voor elk tunnelsysteem is er een specifieke projectorganisatie en zijn er specifieke afspraken met onderaannemers, vastgelegd in SLA’s. In deze SLA’s worden de taken en de randvoorwaarden voor cybersecurity vastgelegd.

Voor het aantonen van technische maatregelen betreffende cybersecurity zal in het tunnelveiligheidsdossier informatie opgeslagen moeten zijn over:

• Security architectuur en security-by-design
• Assetinformatie en -configuratie
• Dienstenleveranciers en SLA’s
• Netwerkanalyse, -indeling en -beveiliging
• Kwetsbaarheden en risico’s
• Accountmanagement (IAA)
• Logging en monitoring
• Software security
• Cybersecurity technical framework(s)
• Back-ups en herstel
• Securityassessment; pentesten of laten pentesten

B4.3.2 Bronnen [link id=”1fn18″]

Trainingsoverzichten op websites

Er zijn veel bedrijven werkzaam op het gebied van cybersecuritytrainingen. Op verschillende websites worden opleidingen op een rijtje gezet. Dit laat vooral zien hoe breed het spectrum is en dat er altijd mogelijkheden zijn om door training de kennis te verbreden of te verdiepen.

We willen één site eruit lichten. Dat is een overzicht gericht op de Amerikaanse markt, waarbij IT en OT door elkaar staan, maar wat toch een prachtige indruk geeft van wat er op cybersecuritygebied aangeboden wordt. Het is misschien wel het meest complete overzicht van securitygerelateerde certificaten met bij elk certificaat de afkorting uitgeschreven en de prijs van het examen (dus niet van de soms verplichte training) en een linkje naar een verdere beschrijving. De ontwikkeling van dit overzicht is te volgen op de bijbehorende GitHub-repository. Het overzicht geeft een spoor voor beginners, gevorderden en experts op technische en organisatorische aspecten.

Organisaties

• NEN. Voor alle normen zoals 2700x en de 62443 serie. Kennis wordt aangeboden via bijvoorbeeld het Industrieel platform cybersecurity (IPCS). Binnen dit platform is ook een korte handleiding geschreven die aangeeft wat er in een 62443-normdeel staat. Tevens wordt er een training en examen IEC 62443 aangeboden. Het belang van het IPCS is dat zij veel kennis geeft op het gebied van de OT-omgeving. Voor informatie vanuit NEN is het van belang te bepalen welk kader van toepassing zal (kunnen) zijn. Welke kaders/normen zijn er en waar zitten de verschillen? Normen moet je veelal kopen.
• NCSC. Het Nationaal cybersecuritycentrum is onderdeel van het ministerie van Justitie en Veiligheid. Doelstelling is, voornamelijk vanuit een IT-bril, Nederland digitaal veiliger maken. Het NCSC biedt veel informatie ter ondersteuning van overheidsorganisaties o.a. door Basismaatregelen cybersecurity en de cybercrisisoefening ISIDOOR.
• CIP. Het centrum informatiebeveiliging en privacybescherming is een publiek-private netwerkorganisatie met participanten en kennispartners. Participanten zijn medewerkers uit de overheid, semi-overheid en zorg. Kennispartners zijn medewerkers van marktpartijen. CIP levert veel informatie op de twee gebieden 1) veilige software en 2) ethiek en regels rond databescherming. Voor het gebruik binnen tunnels is vooral het eerste onderdeel interessant. Het geeft een kader om de cyberveiligheid van software te toetsen.
• IBD. De Informatiebeveiligingsdienst, uitgaande aan de Vereniging van Nederlandse gemeenten (VNG) geeft vooral informatie over de BIO en de wijze waarop deze in te zetten in gemeenten. De IBD is het sectorale computer emergency response team/computer security incident response team (CERT / CSIRT) voor alle Nederlandse gemeenten en ondersteunt bij incidenten op het gebied van informatiebeveiliging.
• DTC. Het Digital trust center deelt voor ondernemers relevante algemene informatie over cyberdreigingen of kwetsbaarheden via haar nieuwskanalen en de DTC Community.

Kader

De Nederlandse overheid referentiearchitectuur (NORA) geldt als norm voor de overheid als geheel. Dit geeft vooral de veiligheid in communicatie tussen organisaties binnen en buiten de overheid aan. O.a. in Ketens de baas wordt duidelijk aangegeven dat de ‘hardware’ binnen ketens niet gevormd wordt door computers, maar door de ‘soft skills’ van de ketenspelers.

B4.4 Aanpak per stakeholder en werkzaamheden [link id=”8nqtv”]

Hieronder is een schematisch overzicht weergegeven (ook te downloaden als pdf: Kennis en kunde cybersecurity tunnels) van informatiebronnen, trainingen en certificeringen die worden aanbevolen voor de verschillende rollen. Nadere toelichting volgt in de paragrafen eronder.

B4.4.1 Belangrijke kanttekeningen [link id=”0kx6h”]

• Het overzicht is bedoeld ter bewustwording van de cybersecuritykennis. Er is geen pretentie om volledig te zijn.
• Uitgangspunt is een opgeleverde tunnel waarin een volledig cybersecuritydossier aanwezig is. Kennis is gericht op het doorgronden en gebruiken van de geleverde productinformatie en cybersecurityprocedures.
• Er wordt een enkele specifieke opleiding vermeld die verwijst naar een opleidingsinstituut of certificeringsinstantie. Dit is gedaan omdat deze opleidingen algemeen bekend zijn en dit is uitdrukkelijk niet bedoeld als reclame. De genoemde opleidingen zijn vrij breed en ook te vervangen door andere, meer in detail tredende opleidingen.
• Het overzicht is ingevuld door de auteurs op basis van hun ervaring en kennis. Elk ander team van auteurs zou met andere voorbeelden komen.
• Het overzicht is ingevuld met een beeld van de taken, verantwoordelijkheden en bevoegdheden van de rolhouders. In elke tunnelorganisatie kan dit net wat anders liggen en is dit ook afhankelijk van de persoonlijkheden en werkelijk aanwezige kennis en ervaring.
• Het overzicht is een momentopname. Met name op het gebied van beveiliging van de OT-omgeving worden veel meer opleidingen verwacht. Een update zal te zijner tijd nuttig zijn.

B4.4.2 Legenda [link id=”4bhk7″]

• Verticaal zijn de verschillende cybersecurityrollen uitgezet met bovenaan een algemeen geldende regel.
• De rij ‘algemeen’ is voor iedereen van toepassing. Deze kennis kan het beste geborgd worden door gezamenlijke kennissessies, zoals toolboxes of veiligheidsprogramma’s.
• Horizontaal is eerst ‘bewustwording’ weergegeven, en vervolgens de soorten werkzaamheden die uitgevoerd worden.
• Met de kolom ‘beleidsbepalend’ wordt geduid op het ontwikkelen en instandhouden van een langetermijnvisie door het reflecteren op de huidige situatie en nieuwe ontwikkelingen binnen techniek en maatschappij.
• Lege vakken zijn voorzien van een arcering zodat duidelijk is dat er geen expliciete rol is. Het is echter bijvoorbeeld niet zo dat een tunneloperator niet mag meepraten bij evaluatie en auditing, maar er zal van hem geen specifieke kennis verwacht worden.
• Blauw wordt gebruikt voor algemene onderwerpen of projectdossier. Transparant voor opleidingen of documenten van derden.
• De symbolen geven documenten aan of acties cq. onderwerpen. Voor een deel van deze onderwerpen wordt een presentatie in het kader van bewustwording aanbevolen.
• Dit icoon geeft een opleiding aan met certificaat. De overige iconen zijn als illustratie gekozen en hebben geen specifieke betekenis.

B4.4.3 Groeimodel [link id=”88txf”]

Partijen/stakeholders/rollen die zich met de veiligheid van een tunnel bezighouden, doen dat met het gezamenlijke doel van een veilige doorstroming van verkeer. Wat de impact is van cybersecurity wordt veelal gevoelsmatig bepaald. Door toename in bewustwording, kennis en tooling wordt cybersecurity meetbaar gemaakt. Om dit voor een tunnel te bereiken, wordt geadviseerd om vooral te werken aan een gezamenlijke bewustwording en daarnaast specifieke specialistische kennis op (te laten) doen. Zolang deze kennis nog onvoldoende aanwezig is, zal gebruikgemaakt moeten worden van externe adviseurs.

Bewustwording wordt bevorderd door gezamenlijke sessies te houden, bijvoorbeeld in de vorm van een rollenspel. Kruip eens in de huid van bijvoorbeeld een monteur en bespreek de begrenzingen en onzekerheden die worden ervaren door cybersecurity. In deze sessies moeten in ieder geval de drie aspecten mens, techniek en proces aan de orde komen. Voorbeelden zijn:

• Onderscheid tussen OT en IT.
• Kwetsbaarheden in een tunnel, waar liggen de risico’s?
• Organisatiemodel van de tunnelomgeving in relatie tot cybersecurity.

In alle opleidingen wordt steeds weer teruggegrepen op de basisuitgangspunten en cybersecurityrisico’s. Deze continue herhaling vanuit verschillende invalshoeken is een krachtig middel om te komen tot inzicht en ervaring. Met name dit bevordert het vormen van een eigen visie en aanpak voor cybersecurity in de lastige OT-omgeving in de tunnels.

B4.4.4 Tips bij toepassing [link id=”rzk9c”]

• Grijp elke gelegenheid aan om cybersecuritykennis op te doen. Praat erover en deel meningen en inzichten.
• Reflecteer steeds weer naar de basisuitgangspunten en cybersecurityrisico’s. Herhaling is ook hier de beste leermeester. Door er steeds met een iets andere bril naar te kijken, groeit begrip van de lastige OT-omgeving in tunnels. Met name dit bevordert het vormen van een eigen visie en aanpak.
• Volg je eigen spoor. Het kennisnemen van normen en regels is belangrijk om te kunnen toetsen. Voor de dagelijkse praktijk is het ontwikkelen van een eigen intuïtief gevoel en onafhankelijk oordeel belangrijk.

Bijlage 5 Analyse tunnelstakeholders en cybersecuritybelangen [link id=”k4225″]

Deze bijlage geeft een overzicht van de rollen en stakeholders voor een tunnelsysteem en een aanzet voor de koppeling met cybersecurityaspecten. Het overzicht gaat uit van de Warvw en gebruikt de stakeholder-overzichten uit de LTS. Een aanvulling voor rollen en stakeholders voor spoortunnels en niet-rijkstunnels is op basis van dit overzicht relatief eenvoudig te maken.

B5.1 Vanuit wet- en regelgeving [link id=”r2k2r”]

De Warvw geeft in verschillende artikelen aanwijzingen over de rollen die wettelijk verplicht zijn voor een tunnelorganisatie:

• Artikel 5.1: “Voor elke tunnel, alsmede voor elke tunnel ten aanzien waarvan de bouw overwogen wordt of die in aanbouw is, is er één tunnelbeheerder en één veiligheidsbeambte.”
• In artikel 6 is sprake van iemand die een risicoanalyse uitvoert en onafhankelijk is van de tunnelbeheerder.
• Artikel 7.1 noemt dan nog enkele partijen: “Voor de openstelling van een tunnel stelt de tunnelbeheerder na overleg met de veiligheidsbeambte en de burgemeester van de gemeente of van elk van de gemeenten waarin de tunnel is gelegen een veiligheidsbeheerplan op. Het plan omvat ten minste de organisatie van het tunnelbeheer, de afstemming van dit beheer met de hulpverleningsdiensten, de verkeersbegeleiding, de instandhoudingsactiviteiten en de bestrijding van rampen of andere gebeurtenissen in of bij een tunnel die een mensenleven, het milieu of de tunnel in gevaar kunnen brengen. Het plan omvat tevens een analyse van scenario’s van ongevallen. Bij ministeriële regeling worden nadere regels gesteld met betrekking tot de inhoud van het veiligheidsbeheerplan en wordt de methode voor het uitvoeren van de analyse van scenario’s van ongevallen vastgesteld. De in de derde volzin bedoelde analyse kan, met redenen omkleed, achterwege blijven.”
• Artikel 8.1: “Het is verboden een tunnel voor het verkeer open te stellen zonder daartoe strekkende vergunning van het bevoegd college van burgemeester en wethouders.”

De LTS (release 1.2 SP2 B3) definieert en beschrijft, in aansluiting op de Warvw, de belangen van de diverse stakeholders rondom het tunnelsysteem vanuit het kader van de rijkswegtunnels. Dit overzicht is voor de niet-rijkstunnels toepasbaar door hernoemen en/of combineren van de genoemde stakeholders. De LTS heeft de rollen en stakeholders in verschillende hoofdstukken opgenomen. Eerst worden in H4.3 de rollen benoemd. In de rollen wordt de analyse van de huidige processen vertaald naar de organisatie van Rijkswaterstaat wat betreft verkeersmanagement en beheer en onderhoud van de tunnels. Onderscheiden worden de rollen zoals weergegeven in onderstaande figuur.

Figuur B.4.B.1 Rollen rondom het RWS Tunnelsysteem

Vervolgens wordt in hoofdstuk 5 van de LTS een nadere relatie gelegd tussen de rollen en de betreffende stakeholders die deze rollen invullen:

“Stakeholders stellen eisen aan het RWS Tunnelsysteem en vervullen rollen in het RWS Tunnelsysteem. In de onderstaande tabel worden de rollen rondom het RWS Tunnelsysteem gekoppeld aan de diverse stakeholders uit de stakeholder analyse van de LTS. De reden hiervoor is dat stakeholders in de onderliggende specificaties en ontwerpen op basis van hun rol t.a.v. het tunnelsysteem kunnen worden uitgewerkt. De uiteindelijk gedefinieerde rollen zijn afhankelijk van de verdere inrichting van het systeem.”

In de LTS worden dus rollen en stakeholders onderscheiden. Alle stakeholders vervullen een rol. De LTS is niet volledig consistent in de toekenning van rollen aan stakeholders, er ontstaan nieuwe rollen en niet alle rollen worden door stakeholders ingevuld. Per tunnelsysteem zullen de uiteindelijke rollen en stakeholders gedefinieerd moeten worden.

Gezien de hoeveelheid rollen, stakeholders en de bijbehorende taken en verantwoordelijkheden is het nog niet eenvoudig om de cybersecuritywerkzaamheden te beleggen bij één specifieke stakeholder. Een belangrijk aspect hiervan is dat er verschillende lagen van verantwoordelijkheid zijn. Uiteindelijk blijft het bevoegd gezag verantwoordelijk, maar de dagelijkse praktijk ligt bij operationele- en onderhoudsmedewerkers.

B5.2 Belangen per rol en stakeholder [link id=”hk59x”]

Voor deze bijlage is gekozen om uit te gaan van de cybersecurityrollen zoals beschreven in het groeiboek. Bij de invulling van de stakeholders op een specifiek tunnelsysteem zullen de cybersecuritytaken expliciet belegd moeten worden. Hiervoor is het nodig om alle stakeholders te benoemen met hun rol binnen het cybersecuritydomein. Om hiervoor een richting te bieden, geeft onderstaande tabel een aanzet voor een volledige analyse van cybersecuritybelangen gekoppeld aan de stakeholderstabel. Hierbij is de tabel uit hoofdstuk 5 van de LTS uitgebreid met een letter volgens de RASCI-matrix en een beschrijving van het cybersecuritybelang van de betreffende stakeholder.

Directe gebruikers/betrokkenen:

Rijkswaterstaat:

Markt:

Andere overheden:

Onafhankelijk:

Overig:

In bovenstaande tabellen is een aantal stakeholders benoemd waarvan niet direct te zien is wat het belang voor de tunnelomgeving is van hun inbreng. Om dit belang te bepalen en in te schatten wat dit voor de cybersecurity betekent, is gebruikgemaakt van onderstaande omschrijvingen:

• Directe gebruikers/ betrokkenen
  • Bewonersgroepen: inbreng omgevingswensen.
  • Weggebruikers: gebruikers van de tunnel.
• Rijkswaterstaat
  • Landelijke diensten: verantwoordelijkheid aanleveren juiste functionele en technische specificaties aan RWS-projectorganisatie GPO. GPO: meestal opdrachtgever/schrijver DBFM. CIV: technisch beheerder. VWM/regio: functioneel beheerder
  • Operationeel verkeersmanagement (OVM) zijnde de verkeerscentrales Invulling aan verkeersmanagement vanuit de verkeerscentrales. Hierbinnen zijn de volgende rollen te onderkennen: verkeerskundige, wegverkeersleider/tunneloperator, technisch/functioneel beheer.
  • Weginspecteur (WIS), officier van dienst (OvD): voert operationeel verkeersmanagement uit op de weg.
  • Dynamisch verkeersmanagement (DVM) vanuit verkeerscentrale, wegverkeersleider/tunneloperator: voert operationeel verkeermanagement uit vanuit de verkeerscentrale.
  • HID RWS-GPO: bepaalt de organisatie en het beleid van GPO.
  • Steunpunt Tunnelveiligheid (STV): kennis- en adviescentrum binnen RWS op het gebied van tunnelveiligheid; ontwikkelt en beheert de veiligheidskaders voor tunnels; bewaakt dat RWS- tunnels aan deze kaders voldoen; treedt daarbij in opdracht van de HID RWS-GPO (en SDG) regisserend op o.a. via betrokkenheid bij tunnelprojecten, advisering van tunnelbeheerders, enz.; stemt kaders af met (B)VB; geeft beleidsadviezen aan DGMo.
  • RWS-(S)DG: bepaalt de wijze waarop het agentschap RWS uitvoering geeft aan haar opdracht.
  • Verkeerscentrum Nederland (VCNL): verantwoordelijk voor de verkeersinformatie en het landelijk verkeersmanagement.
  • Landelijk Tunnelregisseur: nationale afspraken/kaders bepalen; verantwoordelijkheid projectmanagement en bouwtechnologie tunnelprojecten; bevoegd om namens RWS bindende voorstellen te doen voor tunnelontwerp en tunnelveiligheid.
  • Regionale dienst: voert de tunnelstandaard uit, zowel in aanleg, operatie als beheer en onderhoud.
  • HID van directie waaronder een tunnel gaat vallen: verantwoordelijkheid beheerder borgen.
  • RWS-projectorganisaties tunnels: contract verantwoordelijk opdrachtgever; verantwoordelijk voor realisatie nieuwbouwtunnel resp. renovatie bestaande tunnel, incl. ontwerp, uitvoering en testen technische veiligheidsvoorzieningen.
• Markt
  • Telefoonmaatschappijen (KPN, Vodafone, etc.): faciliteren mobiele telefonie.
  • Fabrikanten en installateurs TTI: verantwoordelijk voor realisatie, instandhouding.
• Andere overheden
  • Overige Nederlandse tunnelbeheerders; namelijk…(gemeentes): exploitatie verantwoordelijke.
  • Gemeenten (burgemeester en wethouders): bevoegde gezagen bij verstrekken bouwvergunning, openstellingsvergunning e.d. als sluitstuk van het betreffende besluitvormingsproces; burgemeester is bovendien verantwoordelijk voor rampenbestrijding.
  • Waterschap: vergunningverlenend.
  • Gemeentelijke dienst(en) milieu en bouwtoezicht: adviseren bevoegd gezag om vergunningen te verlenen aan tunnelbeheerder (bv. bouwaanvraag).
  • Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (welke afdeling?): verantwoordelijk voor (regelgeving op het gebied van) hulpverlening en crisisbestrijding (b.v. brandweerwet en Arbowet); vertegenwoordigt belangen bestuurders en hulpverleners op ministerieel niveau.
  • Hulpverleningsdiensten: verantwoordelijk voor hulpverlening bij incidenten, calamiteiten e.d.
  • Brandweer: adviserend naar bevoegd gezag; verantwoordelijk voor hulpverlening bij incidenten, calamiteiten e.d.
  • 25 veiligheidsregio’s (burgemeesters, brandweer, ambulances, hulpverleners): verantwoordelijk voor (coördinatie van) hulpverlening bij incidenten, calamiteiten e.d. (preparatie, repressie).
  • Voormalig Ministerie van VROM: verantwoordelijk voor bouwregelgeving en daarmee een groot deel van de regelgeving op het gebied van tunnelveiligheid (woningwet, bouwbesluit, regeling bouwbesluit, gebruiksbesluit).
  • Ministerie I&M/DGMo: verantwoordelijk voor (voorbereiding) beleid, wet- en regelgeving; adviseert minister over beleidskwesties; neemt namens minister initiatief bij formele evaluatie tunnelwet.
  • Lokale politiek: verantwoordelijke voor lokale politieke besluitvormingsproces.
  • Provinciaal verantwoordelijke bestuurder in provincie waar tunnel wordt aangelegd: evt. medeverantwoordelijk voor bestuurlijke convenanten.
• Onafhankelijk
  • Bureau Veiligheidsbeambte (BVB): controleren, adviseren, coördineren m.b.t. veiligheid. Zwaarwegend advies t.a.v. openstellingsvergunning; onafhankelijke veiligheidsadviseur van alle RWS- tunnelbeheerders; verantwoordelijkheden en bevoegdheden zijn verankerd in de wet; bewaakt veiligheid.
• Overig
  • Brandweeracademie NIFV: opleiden eventueel medeverantwoordelijk voor bestuurlijke convenanten
  • Brandweerkorpsenvereniging NVBR: vertegenwoordigt brandweerkorpsen
  • Belangengroepen/tegenstanders (veiligheid en luchtkwaliteit): vertegenwoordigen anderen.
  • Transporteurs (vertegenwoordigers): transporteren goederen, mensen en gevaarlijke stoffen
  • Verzekeraars: risicoafdekking binnen aanleg en life cycle
  • Pers: publieke meningsvorming

Bijlage 6 Cybersecurityscenario’s [link id=”10sdw”]

B6.1 Voorwoord [link id=”707kh”]

Deze bijlage bij het groeiboek Cybersecurity van het COB bevat scenario’s op basis van cybersecuritygebeurtenissen in de automatisering en gerelateerde IT-systemen van tunnels. Men kan deze scenario’s inzetten voor trainingsdoeleinden en bewustwording.

Tot nu toe is tunnelautomatisering geen voor de hand liggend doelwit van gerichte cyberaanvallen gebleken. Toch kan een al dan niet gerichte cyberaanval tot veel economische schade en zelfs onveilige situaties leiden. Veel organisaties hebben maatregelen getroffen en procedures ingericht aan de hand van standaarden als de BIO, ISO27001 of IEC62443, of met behulp van best practices zoals dit groeiboek. Deze maatregelen en procedures zijn erop gericht om cybersecurity-incidenten te voorkomen of zo goed mogelijk af te handelen. Het in de praktijk beproeven van deze maatregelen is essentieel om aan te tonen dat de maatregelen afdoende zijn. Een praktijkoefening leidt bovendien tot meer bewustwording en waardevolle inzichten die de maatregelen en processen verder kunnen verbeteren.

B6.2. Aanpak [link id=”vlhkg”]

Om de scenario’s voor verschillende organisaties herkenbaar te houden, worden deze op een zo generiek mogelijke manier beschreven met de volgende onderdelen:

• Gebeurtenis – Wat is er precies aan de hand en hoe komt dit aan het licht?
• Gevolgen – Wat zijn de gevolgen voor het (veilig) kunnen bedienen van de tunnel en de achterliggende organisatie?
  • Escaleren – Hoe kunnen de gevolgen verergeren?
  • De-escaleren – Hoe kan men de gevolgen reduceren of beheersen?
• Betrokkenen – Welke interne en externe rollen zijn er betrokken?
• Thema’s groeiboek – Welke onderwerpen in het groeiboek sluiten aan bij dit scenario?
  • Preventie – Hoe kan de gebeurtenis in de toekomst worden voorkomen?
  • Reactie – Hoe kunnen de gebeurtenis en de nadelige effecten die hierdoor ontstaan worden bestreden?

B6.3 Scenario’s [link id=”6z0f4″]

1: Kwaadwillende beïnvloedt bediensysteem [link id=”lq8lm”]

2: Bediensysteem gesaboteerd [link id=”x83r6″]

3: Malware-infectie [link id=”1h490″]

4: SOC doet een constatering [link id=”4lw1q”]

Bijlage 7 Overzicht werkgroep deelnemers [link id=”m866m”]

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

Bijlage 8 Afkortingen [link id=”09t9r”]

Bijlage 9 Normen en richtlijnen [link id=”3xnz6″]

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