Cybersecurity

PDF-versie

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


Download pdf-versie

Participeren?

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

De velden met * zijn verplicht.

Inhoudsopgave

    Geleerde lessen:
    Geleerde lessen

    Cybersecurity

    1 Inleiding

    Dit groeiboek richt zicht op cybersecurity in het licht van veiligheid, beschikbaarheid en privacy in de infra. Hoewel het document specifiek gericht is op tunnels, is de inhoud breed toepasbaar voor alle infrastructurele werken met industriële automatisering zoals bruggen, sluizen en stuwen.

    Downloads

    Groeiboek versie 1

    Groeiboek versie 2

    Enkele belangrijke aandachtspunten uit dit groeiboek zijn samengevat in een factsheet en op de posters “Handreiking cybersecurity voor (tunnel)beheerders” en “Relatieschema cybersecurity en organisatie“ . U kunt de producten gratis downloaden.

    >> Factsheet behorende bij het groeiboek versie 1 (pdf, 525 KB)

    >> Handreiking cybersecurity voor (tunnel)beheerders (pdf, 133 KB)

    >> Factsheet behorende bij het groeiboek versie 2 (pdf, 555 KB)

    >> Relatieschema cybersecurity en organisatie (pdf, 85 KB)

    De eerste versie van dit groeiboek is gelanceerd op 30 mei 2018, de tweede (huidige) versie op 26 november 2019. In de tweede fase is het groeiboek uitgebreid tot de gehele levenscyclus van een tunnel/object en worden de taken en verantwoordelijkheden van alle betrokken stakeholders tijdens deze projectfases beschreven.

    De handreiking beperkt zich tot aandachtspunten en geeft geen volledige uitwerkingen van systemen, ontwerpen en procedures omdat deze project-, organisatie- en systeemspecifiek zijn. In dit document worden veel overwegingen aangedragen, maar het kan en wil niet compleet zijn.

    Interactief

    Om alle informatie leesbaar te houden, is een aantal interactieve elementen beschikbaar. De hoofdtekst is bondig en compact van opzet. Via buttons en links kan extra informatie worden opgeroepen of worden selecties van teksten gepresenteerd.

    1.1 Wat is cybersecurity voor OT?

    Bij cybercriminaliteit wordt over het algemeen gedacht aan aanvallen op het bedrijfs-IT-netwerk. Denk 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 allang voorbij. Steeds vaker hebben zij het ook gemunt op de OT-omgeving; de omgeving van bijvoorbeeld energiebedrijven en fabrieken. En daar is de schade direct vele malen groter. Een kritiek OT-bedrijfsproces dat zomaar wordt stilgelegd, kan betekenen dat de productielijnen in een fabriek platliggen, terminals dichtgaan, tunnels onveilig worden en bruggen niet meer opengaan of sluiten. De gevolgen zijn dan niet te overzien.

    Om deze handreiking goed te kunnen plaatsen, definiëren we eerst wat we in dit document 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:

    Voor OT-systemen dient een informatiesysteem of computer te worden aangevuld met ICT en/of 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, bijvoorbeeld letsel (personen), een aanrijding met een onverwacht dalende slagboom voor een tunnel of brug.

    Als we spreken over cybersecurity hebben we het dus eigenlijk over de digitale weerbaarheid.

    1.2 Werkgroep cybersecurity

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

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

    Naar aanleiding van deze bijeenkomst is het initiatief ontstaan voor een ISAC gericht op cybersecurity in tunnels. De ISAC Tunnels is opgezet met de volgende taak- en doelstelling:

    1. De ISAC Tunnels biedt een veilige en vertrouwde omgeving waarbinnen partijen die onderdeel zijn van de vitale infrastructuur in de tunnel-community, samen met de met (cyber)security belastte overheidspartijen gevoelige en vertrouwelijke informatie over cyberdreigingen en best practices kunnen uitwisselen.
    2. De 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. De ISAC Tunnels draagt bij aan het versterken van de (keten)beveiliging in de sector door een permanent netwerk te vormen, waardoor partijen elkaar ook buiten het overleg om makkelijker weten te vinden.
    4. Toegevoegde waarde en onderling vertrouwen staan aan de basis van de ISAC Tunnels.

    Naast de ISAC Tunnels is een werkgroep Cybersecurity ontstaan die dit groeiboek heeft opgesteld. In de werkgroep hebben ongeveer veertig deelnemers zitting, vanuit overheden en marktpartijen zoals ingenieursbureaus, systemintegrators, leveranciers en cyberbeveiligingsbedrijven.

    De eerste versie van het groeiboek was een handreiking voor tunnelbeheerders (versie 1.0), gepubliceerd op 30 mei 2018. Tijdens de tweede fase is het groeiboek uitgebreid tot de gehele levenscyclus van een tunnel/object (de huidige versie van het groeiboek, versie 2.0).

    Overzicht werkgroep- en ISAC-deelnemers 1e en 2e fase

    Naam

    Organisatie

    Deelnemer

    v 1.0

    Deelnemer

    v 2.0

    Deelnemer

    ISAC

    Wim van Asperen

    Gemeente Amsterdam, Metro en Tram

     

    X

    X

    Ron Beij

    Brandweer Amsterdam-Amstelland

    X

    X

     

    Jack Blok

    Arcadis

    X

    Johannes Braams

    TEC Tunnel Engineering Consultants

     

    X

    Marijn Brans

    KienIA Industriële Automatisering

     

    X

    Bob van den Bosch

    Siemens Nederland

    X

     

     

    Arie Bras

    Wegschap Tunnel Dordtse Kil

    X

     

     

    Michiel Dubbeldeman

    Ministerie van IenW

     

    X

     

    Peter Freesen

    Callas

     

    X

    Talmai Geradts

    ProRail

     

    X

    X

    René van der Helm

    Ministerie van IenW

    X

    X

    X

    Harald Hofstede

    Siemens Nederland

    X

     

     

    Erik Holleboom

    Strypes Nederland

    X

     

     

    Cuno van den Hondel

    ABB

    X

     

     

    Jan Houwers

    Antea Group

    X

     

     

    Wim Jansen†

    Rijkswaterstaat

    X

     

     

    Erik de Jong

    Fox-IT

     

    X

     

    Marcel Jutte

    Hudson Cybertec

    X

    William Kaan

    Provincie Noord-Holland

    X

    X

    Jasper Kimstra

    Kimpro

    X

     

    Lennart Koek

    Hudson Cybertec

     

    X

     

    Arnold Kroon

    ABB

    X

     

     

    Robert Jan de Leede

    Siemens Mobility

     

    X

     

    Mark van Leeuwen

    Rijkswaterstaat

    X

    X

    X

    Bernhard van der Linde

    ADTS ICT

    X

     

     

    Sjaak Matze

    Imagine

     

    X

    Marije Nieuwenhuizen

    COB

     

    X

    Ron Perrier

    ENGIE Services Infra & Mobility

    X

     

     

    Nick Pfennings

    Callas

     

    X

     

    Ronald van der Poel

    Otis Industry

     

    X

    Rita Puggioni

    Provincie Noord-Holland/NRT

     X

    X

    X

    Jos Renkens

    Movares/Tripsolute

    X

    X

     

    Robbert Ross

    Rijkswaterstaat WNN

     

    X

    X

    Pieter de Ruiter

    Provincie Noord-Holland

    X

    X

    André Stehouwer

    Soltegro

    X

     

     

    Peter Stroo

    Gemeente Den Haag

    X

     

     

    Tom van Tintelen

    Technolution BV

     

    X

    Johan van der Velde

    Vialis

    X

     

     

    Tom Versluijs

    Gemeente Den Haag

    X

     X

    X

    Erik Versteegt

    Siemens Mobility

     

    X

     

    Erik Vinke

    Vialis BV

    X

    X

    Jaap van Wissen

    Rijkswaterstaat CIV

    X

    X

    X

    Gijs Withagen

    KienIA Industriële Automatisering

     

    X

    Turabi Yildirim

    Rijkswaterstaat CIV

    X

     

     

    Leen van Gelder (COB/Soltegro) is voorzitter van de ISAC en coördinator van de werkgroep in de eerste en tweede fase. De groepen worden vanuit het COB ondersteund door Caro Rietman.

    1.3 Aanleiding voor deze handreiking

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

    Cybersecurity businesscase

    Bij het opstellen van een businesscase voor cybersecurity is het van belang om vast te stellen welke maatschappelijke, financiële, veiligheids- en privacy-risico’s worden gereduceerd (baten) door de cybersecuritymaatregelen (kosten). Baten zijn te vinden in de reductie van de potentiële schade en letsel en de directe herstelkosten. Ter illustratie: de schade van een recent incident, de (not)Petya-aanval in 2017 in Nederland, beter bekend als de Maersk-case, bedraagt meer dan 300 miljoen euro.

    Het management in zowel de publieke als de private sector is voor een deel nog niet 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 cybersecurity Centrum (NCSC).

    1.4 Doelstelling

    Uit diverse onderzoeken komt naar voren dat overheid, bedrijfsleven en burgers veel stappen nemen om hun digitale weerbaarheid te vergroten. Echter, dit gebeurt niet snel genoeg en iedereen loopt nog steeds enorm achter op de ontwikkelingen. Dit blijkt onder andere uit het rapport Cybersecuritybeeld Nederland 2019 van het Nationaal cybersecurity Centrum (NCSC).

    Met deze handreiking wil 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 de verschillende aspecten van cybersecurity. Met deze kennis zijn de betrokken partijen in staat de digitale weerbaarheid van hun object te beoordelen en processen zodanig te optimaliseren dat tijdig de juiste maatregelen kunnen worden genomen om cyberincidenten te voorkomen of te beheersen. De handreiking helpt partijen ook om eventueel opgetreden effecten bij incidenten te kunnen mitigeren.

    1.5 Terminologie

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

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

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

    Figuur 1.2: Schematische voorstelling tunnelsysteem en verkeerscentrale

    Voor een verklaring van het overige jargon dat in dit document en binnen de cybersecuritysector en wordt gebruikt, kunt u het woordenboek van Cyberveilig Nederland raadplegen.

    1.6 Indeling

    Voor de toegankelijkheid en herkenbaarheid is het groeiboek ingedeeld in algemene, generieke hoofdstukken en specifieke beschrijvingen volgens de levenscyclus van een tunnel. De planfase/aanbesteding en sloop zijn beperkt behandeld omdat de cybersecurity-aspecten in deze fases beperkt en vrij overzichtelijk zijn.

    Figuur 1.3: Schematische weergave projectfases.

    In elke projectfase wordt uitgegaan van een risicogestuurde aanpak. De voordelen van een dergelijke aanpak zijn legio. Zo is de aanpak sterk gestructureerd en is het bijvoorbeeld mogelijk maatregelen te prioriteren, zodat de grootste risico’s goed herkend en alle risico’s beheerst kunnen worden.

    Om de aanpak te onderbouwen en te illustreren, zijn in hoofdstuk 13 Ervaringen uit de praktijk een aantal praktische voorbeelden beschreven. Ook dit hoofdstuk is ingedeeld per levensfase van het object.

    In de bijlagen vindt u een vergelijking tussen OT en IT Bijlage 1: OT vs. IT, een verklaring van de gebruikte afkortingen Bijlage 2: Afkortingen en een overzicht van de in het groeiboek aangehaalde op 26 november 2019 vigerende normen en richtlijnen Bijlage 3: Normen en richtlijnen.

    2 Alert en kundig

    2.1 Bewustwording (awareness)

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

    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.

    2.2 Opleiden, trainen en oefenen (OTO)

    Sommige 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 voorbereid te zijn op de stappen die moeten worden genomen. Het OTO-traject is dan ook erg belangrijk in de crisismanagementstructuur. Frequent opleiden, trainen en oefenen dient in een organisatie continu op de agenda te staan.

    In 8 Incident en herstel is meer informatie en diepgang betreffende incidenten en herstel opgenomen.

    2.2.1 Belang van OTO

    Binnen de infra neemt het bewustzijn voor cybersecurity toe. Een van de hoogste eisen, ‘een veilig object’, gaat niet alleen over de techniek en redundante oplossingen, maar ook over beleid, processen en procedures, zowel tijdens de bouwfasen als in de exploitatiefase. Honderd procent veilig bestaat niet en zou ook niet economisch te verantwoorden zijn, ook niet voor ‘cyberveilig’. Eisen dat men álles 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 pijlers dienen gezamenlijk benaderd te worden. Alleen dan kan cybersecurity op een verantwoorde wijze gemanaged worden en kunnen verantwoorde kosteneffectieve maatregelen genomen worden om aan de hoogste eisen te kunnen voldoen. Door OTO kan de juiste balans gevonden worden tussen mens, organisatie en techniek.

    Het domein van cybersecurity binnen de infra bevindt zich nog in een ontwikkelingsfase. Een ‘cyber roadmap’ met daarin de verbeteringen die men de komende jaren van plan is door te voeren, is daarbij onmisbaar.

    Meer informatie

    De website Veiligheid & Crisisbeheersing biedt veel informatie over veiligheid en crisisbeheersing in Nederland.

    Het is vanzelfsprekend dat OTO een essentieel onderdeel uitmaakt binnen de ‘cyber roadmap’. Daarmee worden immers de prestaties verbeterd en kunnen -zeker in hectische situaties- cruciale vergissingen voorkomen worden. Het hebben van, 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. Tevens zorgt dit ervoor dat fouten en omissies in de draaiboeken kunnen worden gevonden en hersteld voordat zich een echte crisis voordoet.

    2.2.2 Aandachtspunten OTO-traject

    Getraind blijven

    Een training om het bewustzijn van mensen snel op het gewenste niveau te krijgen, is erg belangrijk, maar hoe zorgen we ervoor dat betrokken personen niet net zo snel weer terugvallen in oude gewoontes? Het antwoord: 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

    Betrokkenheid en bekendheid van personeel met het crisisaspect

    Personeel in een organisatie dient zich bewust te zijn van de factoren die in het werkproces kunnen leiden tot een crisis 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.

    Risicobeoordeling

    Vanuit de inventarisatie van het werkproces wordt een risicobeoordeling opgemaakt.

    Aanvullend wordt op basis van de risicobeoordeling een maatregelenpakket uitgewerkt. Dit pakket wordt in een procesflow verwerkt, met daarin benoemd de actoren.

    Continuïteit

    De continuïteit van een bepaald werkproces is belangrijk om de maatschappelijke vitale functie te borgen, maar ook in beeld te brengen welke alternatieven er zijn om de functionaliteit op een andere wijze dan de normale structuur te kunnen voortzetten.

    Bewustwording

    Bewustwording is een belangrijk aspect in het functioneren van direct betrokkenen in het normale werkproces. Regelmatig de vinger aan de pols houden door vragen, scenario’s en oefeningen, dragen bij aan de alertheid en betrokkenheid van het personeel.

    Kaders en plannen

    Van een object dient altijd door middel van kaders en plannen inzicht te zijn in de structuur en de werking ervan bij noodsituaties. Vanuit de kaders (wetten en regels) is in de diverse plannen het handelingsperspectief beschreven om de continuïteit te waarborgen. Zeker wanneer zich een crisis voordoet waarbij het object of proces wordt verstoord, c.q. uitvalt. Daarbij zijn de volgende plannen te onderkennen:

    Noodplan

    Crisismanagementplan (CMP)

    Calamiteitenplan of continuïteitsplan (CP)

    Incidentresponsplan (IRP)

    Fysieke-beveiligingsplan (FBP)

    Klap uit Klap in

    Crisisstructuur

    De crisisstructuur is door het management vastgesteld in een document waarin op hoofdlijnen de rollen, bevoegdheden, verantwoordelijkheden en kerntaken van de belangrijkste actoren en stakeholders in de crisisorganisatie zijn opgenomen. Zaak is dat regelmatig de crisisstructuur en de rol daarin door middel van een bepaald scenario van een voorkomend incident wordt geoefend. Dit aan de hand van een draaiboek en onder begeleiding van een trainer/opleider.

    Opschalingsmodel

    Het opschalingsmodel is een nadere uitwerking van de stakeholders die in het proces volgtijdelijk moeten worden geïnformeerd over een crisis en op welke wijze vervolgens door middel van frequente rapportages informatie wordt gegeven over het managen van de crisis.

    Incidentresponsproces

    Dit proces beschrijft hoe de afhandeling gebeurt van een incidentmelding en hoe de bewaking hiervan plaatsvindt.

    Evaluatieproces

    Een belangrijk aandachtspunt na een crisis is de evaluatie. Hierbij worden door middel van een evaluatiemodel de genomen stappen en besluiten geëvalueerd om ervan te leren en eventueel het crisisproces en aanpalende zaken te verbeteren.

    3 Wet- en regelgeving

    3.1 Inleiding

    Het overgrote deel van de wet- en regelgeving die we nu kennen 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 richtlijn is door Nederland omgezet in de Wet beveiliging netwerk- en informatiesystemen (Wbni).

    De operationele veiligheidregimes zijn primair 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. In deze regelgeving wordt cybersecurity (nog) niet specifiek benoemd, maar een tunnelbeheerder kan de cybersecurityrisico’s – anno 2019 – niet negeren bij het beheersen van de veiligheidsrisico’s. De regelgeving loopt hier achter op de werkelijkheid. Het is de verantwoordelijkheid van de tunnelbeheerder om die manco’s op te vullen.

    Voor tunnels is er ook een specifieke tunnelwet. Omdat deze wet taken en verantwoordelijkheden m.b.t. veiligheid vastlegt, wordt hier verderop nader op ingegaan. De tunnelwet geldt echter specifiek voor wegtunnels. Voor spoortunnels gelden de Spoorwegwet en de Wet lokaal spoor. De organisatie, taken en verantwoordelijkheden (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 overige deel van dit groeiboek wel geheel van toepassing voor spoortunnels.

    De in dit hoofdstuk genoemde wet- en regelgeving hebben allemaal als uitgangspunt het beheersen van risico’s. Het inrichten van cybersecurity aan de hand van dit groeiboek biedt daarmee een goed startpunt om te voldoen aan de geldende wet- en regelgeving.

    3.2 Algemene verordening gegevensbescherming (AVG)

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

    3.2.1 Definitie persoonsgegeven

    De AVG geeft in artikel 4 een bijzonder ruime 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.

    3.2.2 Definitie verwerking

    De AVG hanteert niet alleen een ruime definitie van het begrip persoonsgegeven, ook het begrip ‘verwerking’ wordt ruim 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.

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

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

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

    Functionaris gegevensbescherming

    Organisaties zijn in bepaalde situaties verplicht een functionaris gegevensbescherming (FG) aan te stellen. Dit is iemand die binnen de organisatie toezicht houdt op de toepassing en naleving van de AVG. Dit betekent dat de FG bij alle mogelijke processen waar persoonsgegevens worden gebruikt betrokken zou moeten zijn. Overheidsinstanties en publieke organisaties zijn altijd verplicht om een FG aan te stellen, ongeacht het type gegevens dat ze verwerken. Organisaties moeten hun FG aanmelden bij de Autoriteit Persoonsgegevens.

    >> Lees meer

    3.3 Wet beveiliging netwerk- en informatiesystemen

    De Wet beveiliging netwerk- en informatiesystemen (Wbni) is de Nederlandse implementatie van de Europese Netwerk- en informatiebeveiligingrichtlijn (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 cyberincidenten te voorkomen. Daarnaast verplicht de wet deze aanbieders om maatregelen te nemen om, wanneer zich toch een cyberincident voordoet, de gevolgen daarvan zoveel mogelijk te beperken.

    De ratio hierachter is dat een cyberincident bij dit type organisaties tot maatschappelijk ontwrichtende gevolgen kan leiden. Het incident heeft grote nadelige gevolgen voor de veiligheid van ons land, de gezondheid van de inwoners of heeft grote economische schade tot gevolg.

    3.3.1 Aanbieders van essentiële diensten en digitale dienstverleners

    Zoals gezegd beperkt de werking van de Wbni zich tot ‘aanbieders van essentiële diensten en digitale dienstverleners’. De minister van Justitie en Veiligheid wijst de essentiële diensten aan; ze zijn te vinden in het Besluit beveiliging netwerk- en informatiesystemen. De betreffende organisaties worden door het ministerie op de hoogte gebracht dat ze zijn aangemerkt als aanbieder van een essentiële dienst.

    Noot:

    Op het moment van het schrijven van dit groeiboek zijn wegtunnels nog niet aangemerkt als een essentiële dienst en vallen daarmee niet onder de werking van de Wbni. De minister evalueert op regelmatige basis de lijst van aanbieders van essentiële diensten. Het valt daarom niet uit te sluiten dat de minister in de toekomst bepaalde tunnels gaat aanmerken als een essentiële dienst.

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

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

    3.3.2 Zorgplicht

    Over specifieke maatregelen laat de wet zich niet uit. De wet legt een zorgplicht op aan organisaties die onder de werking van de wet 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. 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 van dergelijke cyberincidenten zoveel mogelijk te beperken.

    3.3.3 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. Een organisatie moet een incident melden wanneer het 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.

    3.4 Overige wet- en regelgeving

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

    Noot:

    Per 1 januari 2020 is de Baseline Informatiebeveiliging Overheid (BIO) van kracht. De BIO vervangt de Baseline Informatiebeveiliging (BIR), Interprovinciale Baseline Informatiebeveiliging (IBI), Baseline Informatiebeveiliging Gemeenten (BIG) en de Baseline Informatiebeveiliging Waterschappen (BIWA).

    IEC 62443 en ISO 27000

    Voor cybersecurity bestaan allerlei internationale en nationale normen. Een belangrijke voor informatietechnologie (IT) is ISO 27000. Het IEC 62443-normenkader is voor de operationele technologie (OT), wat de ISO 27000 serie is voor de IT. Meer informatie over (het toepassen van) deze normen is verwezen in dit groeiboek.

    Op het moment van uitbrengen van het groeiboek (26 november 2019) werkt Rijkswaterstaat 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.

    3.5 Tunnelwet

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

    Partijen / rollen

    Belang / doelstelling

    Tunnelbeheerder (TB), in Warvw gedefinieerde rol

    Verantwoordelijk voor veilige exploitatie van de tunnel, hiermee verantwoordelijk voor veiligheidsdocumentatie (TVP, Bouwplan, VBP), voor een functionerend technisch tunnelsysteem en voor een getrainde beheer- en calamiteitenorganisatie

    Tunnelpersoneel, gelieerd aan tunnelbeheerder

    Bijvoorbeeld bedieningspersoneel en weginspecteurs. Bedieningspersoneel zorgt voor bediening en bewaking van de tunnel en speelt een essentiële rol bij het verkeersmanagement en de calamiteitenafhandeling. Weginspecteurs ondersteunen het bedieningspersoneel op locatie (weg).

    Veiligheidsbeambte (VB), in Warvw gedefinieerde rol

    Levert gevraagd en ongevraagd advies aan de tunnelbeheerder inzake de tunnelveiligheid. Heeft hierbij nadrukkelijk ook aandacht de controle op opleiding, training en oefening van de beheer- en calamiteitenorganisatie en is betrokken bij de evaluatie van incidenten. Bij de aanvraag van tunnelveiligheid-gerelateerde vergunningen moet wettelijk een advies van de VB gevoegd worden.

    Bevoegd college van BenW, in Warvw gedefinieerde rol, ook wel ‘bevoegd gezag’(BG) genoemd

    Verantwoordelijk voor verlening van de diverse tunnelveiligheid-gerelateerde vergunningen (omgevingsvergunning en openstellingsvergunning), op basis van een toets aan de wettelijke kaders. Daarnaast verantwoordelijk voor handhaving van de wettelijke kaders, met als ultiem middel het intrekken van de vereiste vergunningen voor bouw en gebruik van de tunnel.

    Brandweer/hulpdiensten

    De brandweer of veiligheidsregio fungeert als adviseur van het bevoegd gezag bij de beoordeling van de aangevraagde vergunningen. Daarnaast is het calamiteitenbestrijdingsplan het resultaat van samenwerking tussen de brandweer, TB en overige partijen die een rol hebben bij calamiteitenbestrijding (waaronder de andere hulpdiensten).

    Toezichthoudende ambtenaren

    Ambtenaren die belast zijn met het toezicht op de naleving van de regels uit de Woningwet, het Bouwbesluit, de Warvw en de Rarvw worden door het bevoegd college van burgemeester en wethouders aangewezen. Hiernaast wordt er namens de Minister van IenW toezicht uitgeoefend door de Inspectie Leefomgeving en Transport op de tunnel- en wegbeheerders en de weggebruikers.

    Bevoegd gezag

    Behalve in de Warvw komt ook in overige wet- en regelgeving het begrip ‘bevoegd gezag’ voor. Het gaat daarbij om het bestuursorgaan dat bevoegd is om een bepaald besluit te nemen. De minister van Infrastructuur en Waterstaat is bijvoorbeeld het bevoegd gezag voor het vaststellen van een tracébesluit. De gemeenteraad en Provinciale Staten zijn bevoegd om een bestemmingsplan respectievelijk provinciaal inpassingsplan vast te stellen. Het college van burgemeester en wethouders is het bevoegd gezag voor het verlenen van een omgevings- en openstellingsvergunning. Hiernaast is het bestuur van de veiligheidsregio verantwoordelijk voor de veiligheidseisen die voortkomen uit de Wet op de veiligheidsregio’s.

    Zoals eerder gezegd geldt de tunnelwet alleen specifiek voor wegtunnels. Voor spoortunnels is er andere wet- en regelgeving (zie boven).

    4 Organisatie cybersecurity

    Door taken, verantwoordelijkheden en bevoegdheden op het gebied van cybersecurity in de organisatie in te bedden, zal cybersecurity onderdeel uitmaken van de standaard processen van de organisatie. Doel is te bewerkstelligen dat:

    1. Cybersecurityrisico’s worden onderkend.
    2. Maatregelen worden geformuleerd en belegd bij personen met vakkennis, zodat deze maatregelen op een juiste wijze worden geïmplementeerd.
    3. Instandhouding en evaluatie van maatregelen wordt getoetst aan wet- regelgeving en veranderende dreigingen.

    4.1 Cybersecuritymanagementsysteem (CSMS)

    Om cybersecurity binnen de OT-organisatie te borgen, kan een cybersecuritymanagementsysteem (CSMS) worden ingezet. 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. Een CSMS helpt om cybersecurity voor de OT-omgeving op gestructureerde en valideerbare wijze te managen. Onderdeel van het CSMS is 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, afhankelijk van de contractvorm (zie 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 ISMS van kracht is, is het handiger om daar bij aan te sluiten. In organisaties waar de automatisering voornamelijk uit OT-systemen bestaan, is een CSMS conform IEC 62443 te overwegen.

    4.2 Contractvorm

    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 cybersecuritymaatregelen. Bij D&C en nog sterker bij E&C zullen de organisatorische en een deel van de technische maatregelen al bepaald zijn door de opdrachtgever. De primaire coördinatie van de cybersecurity-activiteiten ligt in dit geval bij de opdrachtgever. De uitvoering van specifiek genoemde activiteiten wordt bij de opdrachtnemer belegd. Bij DBFM en DBFMO wordt de gehele organisatie door de opdrachtnemer ingevuld. De opdrachtgever heeft een toetsende rol.

    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 minimaal de bestaande beveiligingsmaatregelen in stand te houden.

    4.3 Organisatievorm gedurende levenscyclus

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

    Figuur 4.1: organisatievormen gedurende de object life cycle

    Cybersecurity is een integraal onderdeel van al deze activiteiten en werkzaamheden. Het is van belang de overgang tussen de fases als risico te erkennen en hier tijdig op in te spelen. Laat de beheerder bijvoorbeeld vroeg in de ontwikkel- en ontwerpfase aansluiten. Om de relatie met cybersecurity op een duidelijker wijze weer te geven, is een relatieschema opgesteld, zie kader.

    Figuur 4.2: Relatiediagram cybersecurity.

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

    Rol

    Taken en verantwoordelijkheden

    Tunnelbeheerder

    Vanuit zijn/haar wettelijke taken eindverantwoordelijk voor de cybersecurity van zijn/haar tunnel(s).

    Bevoegd gezag

    Vanuit zijn/haar wettelijke taken verantwoordelijk voor de toets op de tunnelveiligheid en daarmee ook de cybersecurity-aspecten en handhaving daarvan.

    Veiligheidsbeambte

    Vanuit zijn/haar wettelijke taken levert de veiligheidsbeambte gevraagd en ongevraagd advies aan de tunnelbeheerder inzake de tunnelveiligheid en daarmee ook de cybersecurity-aspecten en handhaving daarvan.

    Operationeel-/

    assetmanagement

    Dagelijks beheer exploitatiefase.

    Opstellen eisen voor beheer- en onderhoudsfase.

    Bewaken van beheersbaarheid.

    Uitvoeren van onderhoud op basis van cybersecurity-procedures.

    Uitvoeren van periodieke testen/audits/risicoanalyses.

    Tunnelpersoneel

    Melden, registreren en rapporteren cyberincidenten.

    Projectmanagement/-directie

    Naar tunnelbeheerder en opdrachtgever verantwoordelijk voor de cybersecurity-aspecten.

    Commitment met cybersecuritybeleid is een vereiste.

    Proces- en kwaliteitsmanagement

    Document control.

    Coördinatie/initiëren van cybersecurity-audits.

    Coördinatie en registreren risicoanalyses.

    Securitymanagement

    – Incidentmanager

    – Security-architect

    – Cybersecurity-coördinator

    – Cybersecurity-auditor

    Melden, registreren en rapporteren cyberincidenten.

    Inspecties op naleving integrale veiligheid.

    Systeem-/applicatiebeheer

    Bewaken accounts en toegangsrechten.

    Inrichten werkplekbeheer.

    Servicedesk.

    Vrijgeven van ICT-middelen van werknemers.

    Applicatiebeheer.

    Ontwerpteam Civiel/VTTI

    Cybersecurity-engineer

    Netwerkspecialist

    Ontwerp fysieke toegang en gebouwinstallaties.

    Ontwerp OT-systemen (hardware en software).

    Contractmanagement

    Verantwoordelijk voor de contractuele aspecten

    Doorzetten van cybersecuritymaatregelen naar onderaannemers

    Realisatieteams

    Civiel/VTTI

    Inkoop en bouw van systemen.

    Conformiteit aan cybersecuritymaatregelen door leveranciers. Zowel technisch als organisatorisch dient een veilige levering geborgd te zijn.

    Veilige overdracht van ontwerpgegevens (bv. software).

    Doorzetten van cybersecuritymaatregelen naar onderaannemers.

    IBS-/testteam

    Registreren en bewaking van fysieke en logische toegang tot OT-systemen.

    Controle op naleving cybersecuritymaatregelen door personeel.

    Uitvoeren patching, hardening, viruscheck.

    Organiseren back-ups.

    Uitlezen lokale logbestanden.

    Vullen CMDB.

    HRM

    Projectintroductie/geheimhoudingsverplichting.

    Registreren en bijhouden persoonsgegevens.

    Cybersecurity-screening als voorwaarde voor inhuur van personeel.

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

    4.4 Basis organisatiemodel voor cybersecurity

    In onderstaand model wordt aangegeven welke cybersecurityrollen worden onderscheiden in welke fase van de levenscyclus. Afhankelijk van de omvang van het werk kunnen, in een bepaalde fase, meerdere rollen vallen onder de cybersecuritycoördinator.

    Planfase en aanbesteding

    Projectfase:

    Ontwerp

    Projectfase:

    Realisatie

    Operatiefase:

    Beheer en onderhoud

    Operatiefase:

    Exploitatie

    Renovatie

    Sloop

    ROL

    Incident- manager

    X

    X

    X

    X

    X

    Cybersecurity-coördinator/ adviseur

    X

    X

    X

    X

    X

    X

    Cybersecurity-auditor

    X

    X

    Security engineers/ specialisten

    X

    X

    X

    X

    Netwerkspecialist(en)

    X

    X

    X

    X

    Applicatiebeheerder(s)

    X

    X

    X

    X

    Security-architect

    X

    X

    X

    X

    Tunnel-

    personeel

    X

    4.5 Tips voor een geoliede samenwerking

    Organiseer commitment van directie

    Combineren van rollen of juist gescheiden houden?

    Schat de workload op de juiste waarde

    Organiseer de communicatie

    Implementeer escalatiemodellen

    Werk samen in de hele keten

    Klap uit Klap in

    4.6 Praktijkvoorbeeld: TBV-matrix voor een wegtunnel

    Onderstaande TBV-matrix (taken, bevoegdheden en verantwoordelijkheden) geeft een voorbeeld van een mogelijke 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 beiden optimaal worden ingezet.

    Drie opmerkingen vooraf:

    1. Per contract/organisatie/object zal de invulling anders zijn. 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 bijvoorbeeld 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 zullen afspraken bekend moeten zijn 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 wordt de rol van de opdrachtgever die van een ‘betrokken toetser’ en ‘adviseur met bijbehorende verantwoordelijkheden’. Door de opdrachtnemer worden in de ontwerpfase de plannen en instructies opgesteld in samenwerking met alle specialisten. Een belangrijke rol ligt bij procesmanagement en bij de ICT-inrichting van de werkomgeving van de opdrachtnemer. In de realisatie worden de technische maatregelen uitgevoerd en gevalideerd. Het proces van opstellen toestandrapportages, jaarlijks evalueren, auditen en updaten van de risicoanalyses wordt in de operationele fase uitgevoerd.

    5 Risicogestuurde aanpak

    Beveiligingsincident

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

    Over het algemeen zijn soorten activiteiten die worden erkend als inbreuken op een beveiligingsbeleid:

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

    Dit hoofdstuk beschrijft een aanpak die de stakeholders in staat stellen de digitale weerbaarheid van het object/project te beoordelen en de processen zodanig te optimaliseren dat tijdig de juiste maatregelen worden genomen om cyberincidenten te voorkomen of te beheersen en eventueel opgetreden effecten bij incidenten te mitigeren, zie ook hoofdstuk 8 Incident en herstel.

    5.1 Inleiding

    Cybersecurity kan op grofweg drie manieren worden aangepakt:

    Regelgestuurd

    Risicogestuurd

    Classificatiegestuurd

    Klap uit Klap in

    De operatie

    De operatie behelst de dagdagelijkse werkzaamheden voor de exploitatie (normaal- en calamiteitenbedrijf) én voor het onderhoud en beheer (onderhoudsbedrijf).

    In dit groeiboek wordt de risicogestuurde aanpak als aanpak uiteengezet, omdat dit de meest complete aanpak is. In de praktijk zal de aanpak altijd een samengestelde variant zijn. Vaak geldt er per organisatie of branche al een baseline of voorschrift waarmee de basismaatregelen verplicht gesteld zijn, bv. de BIO. Daar bovenop worden dan op basis van risico’s of classificering aanvullende specifieke maatregelen bepaald. Elke tunnelbeheerder kan dus varianten (laten) samenstellen.

    Figuur 5.1: Risicogestuurde aanpak in stappen.

    Risicosturing bij bestaande systemen

    De risicogestuurde aanpak bestaat – in geval van bestaande systemen die aanvulling behoeven met cybersecuritymaatregelen – uit zes stappen:

    1. Inventariseren, gericht op de thema’s mens, organisatie (processen) en techniek:
      • Huidige systeemontwerp en huidige kwetsbaarheden.
      • Huidige operatie (processen en actoren).
      • Operationele doelstellingen voor de veiligheid, beschikbaarheid en privacy en geaccepteerde restrisico’s (te accepteren incidenten per jaar).
    2. Opstellen van de risicoanalyse (dreiging/gebeurtenissen, kansen, huidige kwetsbaarheden en operationele effecten).
    3. Kiezen van de te nemen technische en organisatorische maatregelen.
    4. Evalueren van de restrisico’s en acceptatie restrisico’s.
    5. Uitvoeren van de maatregelen.
    6. Borgen van de maatregelen (inclusief verificatie en validatie).

    Risicosturing bij nieuwbouw of renovatie

    In geval van een nieuw systeem/operatie of een renovatie zijn alleen de eerste stappen anders; het accent ligt nu op het ontwerpen van cybersecuritymaatregelen en cyberveiligheid van in te kopen systemen/onderdelen in plaats van het vaststellen van de kwetsbaarheden van het bestaande systeem en organisatie.

    De aanpak bestaat dan uit de stappen:

    1. Inventariseren (over te nemen uit de operationele beschrijving van het project):
      • Beoogde operatie (processen en actoren).
      • Operationele doelstellingen voor de veiligheid, beschikbaarheid en privacy en geaccepteerde restrisico’s (c.q. aantal te accepteren operationele incidenten per jaar) als gevolg van cyberincidenten.
    2. Opstellen van de risicoanalyse (dreiging/gebeurtenissen, kansen en de operationele impact).
    3. Ontwerpen van de technische en organisatorische maatregelen.
    4. Evalueren van de restrisico’s en acceptatie restrisico’s.
    5. Uitvoeren van de maatregelen.
    6. Borgen van de cybersecurity (inclusief verificatie en validatie).

    5.2 Cybersecurityrisicomanagement

    Cybersecurityrisicomanagement beheerst de risico’s van beveiligingsincidenten over de gehele levenscyclus van een OT-systeem en begint – na het afleiden van de cybersecuritydoelstellingen uit de operationele doelstellingen van de operatie – met de cybersecurityrisicoanalyse. Deze analyse is een onderdeel van het ontwerpproces, 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.). Met de analyse worden maatregelen in kaart gebracht die aansluiten op een reëel dreigingsbeeld en/of de kwetsbaarheid van het (bestaande) systeem en organisatie. Het gaat hierbij om cybersecuritymaatregelen 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. De ontworpen maatregelen zijn zowel preventief als correctief: 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 cybersecurityrisicoanalyse maakt inzichtelijk wat de restrisico’s en de herstelmaatregelen van het systeem en de operatie zijn.

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

    Noot:

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

    5.3 Inventarisatie operationele doelstellingen

    Zowel bij bestaande systemen als bij nieuwe systemen dient vastgesteld te worden wat de bedoelde operatie (exploitatie, beheer en onderhoud) is en wat de operationele doelstellingen zijn. De bedoelde operatie kan zijn vastgesteld in de vorm van procesbeschrijvingen of ‘ConOps’. Het aantal en typen te accepteren operationele incidenten (per jaar) -af te stemmen met de gebruikers- en onderhoud- en beheerorganisaties- vormen de te accepteren restrisico’s voor cyberincidenten.

    Figuur 5.2: Operationele doelen als basis voor het cybersecurityontwerp.

    De causaliteit tussen cyberincidenten en fysieke schade en letsel

    Operationele incidenten zijn afwijkingen in de operatie ten opzichte van veiligheid, beschikbaarheid en privacy. Die kunnen een gevolg zijn van cyberincidenten in de systemen. Cyberincidenten zijn (merkbare of niet-merkbare) afwijkingen in de beschikbaarheid, vertrouwelijkheid en integriteit van systemen. Er zijn dikwijls meer merkbare of niet-merkbare cyberincidenten (per jaar) dan er operationele incidenten zijn.

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

    5.3.1 Dreigingsbeeld en -logs

    Het NCSC geeft jaarlijks een update van het algemene dreigingsbeeld van cyberincidenten in Nederland. Voor elke operatie en voor elk systeem dient een specifiek dreigingsbeeld te worden vastgesteld, voor het ontwerpproces en bij het vaststellen (en evalueren) van de specifieke cybersecuritymaatregelen.

    Een ‘cybersecuritydreiginglog’ is een middel om het dreigingsbeeld voor een specifieke operationele omgeving of systeem vast te stellen. Cybersecuritydreigingen worden dikwijls door cybersecurityexperts bepaald. Het is verstandig om deze door ‘peers te challengen’ op realiteitswaarde en door 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, omdat de restrisico’s een impact hebben op de operatie.

    Risicobepaling Rijkswaterstaat

    Rijkswaterstaat hanteert ‘risico = dreiging x kwetsbaarheid x impact’ om het risico voor cybersecurity te bepalen, zie de afbeelding hieronder (Bron: presentatie cybersecurity voor ISAC, door Turabi Yildirim, Rijkswaterstaat).

    Figuur 5.4: Invulling Rijkswaterstaat risicobepaling

    5.3.2 Bestaande operationele maatregelen

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

    Er bestaat een veelheid aan informatie over cybersecuritymaatregelen 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 cybersecuritymaatregelen, als een subset van generieke maatregelen. Zie het hoofdstuk 10.1 Ontwerp voor de typen maatregelen en de keuzes die kunnen worden gemaakt.

    Bronnen voor cybersecurityrisicoanalyse en -management:

    1. Handreiking risicoanalyse, door het Nationaal adviescentrum vitale infrastructuur (Navi)
    2. ISO 27005, Information security risk management
    3. ISO 27001, Information security management
    4. ISO 31000, Risicomanagement
    5. IEC 62443, Technical security requirements
    6. ISO 27035, Incidentrespons
    7. Handreikingen en leidraden ProRail en RWS

    5.4 Risicoanalyse opstellen en kwantificeren

    Na de inventarisatie vindt de risicoanalyse plaats. Per dreiging wordt de kans op het optreden ervan bepaald en wordt berekend wat de gevolgschade is als het daadwerkelijk misgaat. De risico’s die zijn geïnventariseerd, worden bij de risicoanalyse gekwantificeerd door de kans op optreden en de gevolgen daarvan te combineren: risico = kans x impact. Daarna wordt ook gekeken naar de mogelijk maatregelen.

    Restrisico’s

    De bedoeling van een risicoanalyse is dat er na de analyse wordt vastgesteld op welke wijze de risico’s beheerst kunnen worden, of kunnen worden teruggebracht tot een aanvaardbaar niveau. Daarbij wordt naast een risicoanalyse ook een kosten-batenanalyse uitgevoerd en een analyse tegen de operationele doelstellingen. 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 tegen de gestelde operationele (veiligheids, beschikbaarheids- en privacy-)doelstellingen, dan kan besloten worden het risico te accepteren als restrisico.

    Het is van belang dat de afdekking of acceptatie van risico’s in overeenstemming is met de risicobereidheid van de organisatie en de organisatie in staat is om operationele incidenten te kunnen absorberen. Het permanent of periodiek uitvoeren van risicoanalyses is een voorwaarde voor een goed cybersecuritybeleid en wordt risicomanagement (ook wel risk management of risk control) genoemd.

    Methoden

    Risicoanalyses kunnen op twee manieren worden uitgevoerd:

    • Kwalitatieve methode: er worden kwalitatieve schattingen van de gelopen risico’s gemaakt.
    • Kwantitatieve methode: de risico’s worden waar mogelijk gekwantificeerd in meetbare criteria, meestal uitgedrukt in de financiële gevolgen of aantal te accepteren incidenten (restrisico’s) cq. letselgevallen.

    Er bestaat een aantal methoden om risicoanalyses uit te voeren. Voor de toepassingen van industriële automatisering wordt vaak gebruikgemaakt van een fault tree analysis (foutenboom), of een failure mode, effects (and criticality) analysis, de FME(C)A. Voor OT-systemen is een nieuwe norm in de maak: de IEC 62443-3-2. Deze norm beschrijft het ‘security risk assessment and system design’ en zal waarschijnlijk in 2019 gepubliceerd worden. De ISO 27000-serie omvat verschillende informatiebeveiligingsnormen. De norm ISO 27005 gaat in op information security risk management. De ISO 27000-standaard is vooral gericht op informatietechnologieomgevingen (IT), zoals kantoorautomatisering (SAP, Microsoft Office, e.d.) en past op onderdelen niet op OT-systemen zoals de bediening, besturing en bewaking van tunnels (zie ook Bijlage 1: OT vs. IT).

    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. Dat biedt natuurlijk veel nieuwe mogelijkheden, maar helaas ook nieuwe security-uitdagingen; een toename van het aantal fabriekssensoren betekent immers ook een grotere ‘attack surface’. Om de cybersecurity van beide werelden met elkaar te verenigen, is specifieke kennis en kunde nodig en een goed begrip van de impact van een cyberaanval en zijn verdediging.

    Beschikbaarheid en integriteit staan bovenaan de OT-agenda. Enerzijds moet een cyberverdediging hier bescherming tegen bieden, anderzijds mag deze de bedrijfsprocessen niet verstoren. Tegelijkertijd moet de dreiging op de IT-omgeving tegengegaan worden, waar de prioriteit bijvoorbeeld op confidentialiteit kan liggen. Om beide werelden correct te beveiligen, ligt een geïntegreerde ‘IT/OT-aanpak’ van cybersecurity voor de hand.

    5.5 Maatregelen

    5.5.1 Typen maatregelen

    De risico-inventarisatie en -analyse richten zich globaal op drie thema’s: mens, organisatie en techniek. In onderstaand figuur zijn de drie thema’s weergegeven met hun onderlinge relaties. Hieruit volgt dat voor een gedegen cybersecuritybeheersplan alle drie de thema’s moet omvatten. Om tot een bepaald risiconiveau (classificatie) te komen, zal op ieder gebied een gewogen set aan maatregelen bepaald moeten worden.

    Figuur 5.5: De balans van cybersecuritymaatregelen.

    1. De menselijke factor: bewustzijn, taken, bevoegdheden en verantwoordelijkheden van medewerkers, beheerders, onderhoudspersoneel e.a.
    2. De organisatie: visie, strategie en beleid met betrekking tot onder andere risicomanagement, governance, standaardisatie, juridische aspecten, contracten beheer, AVG, etc.
    3. Techniek: fysieke toegangsbeveiliging, IT, OT,, hardware, software, de gebouwde omgeving.

    Op grond van een risicoanalyse kunnen de te nemen maatregelen worden bepaald. De IEC 62443 is hierbij een belangrijke richtlijn. Onderstaand een aantal voorbeelden van te nemen maatregelen:

    • Preventie: het voorkomen dat iets gebeurt of het verminderen/verkleinen van de kans dat het gebeurt.
    • Detectie: het detecteren van een (potentiële) dreiging en/of schade wanneer deze optreedt.
    • Repressie: het beperken van de schade wanneer een bedreiging optreedt.
    • Correctie: het instellen van maatregelen die worden geactiveerd zodra iets is gebeurd om het effect hiervan (deels) terug te draaien.
    • Acceptatie: geen (additionele) maatregelen, men accepteert de kans en het mogelijke gevolg van een dreiging.
    • Overdragen: financieel d.m.v. verzekeren, of operationeel d.m.v. outsourcen.[1]

    In onderstaand figuur is onderscheid gemaakt tussen proactieve- en herstelmaatregelen. Beide categorieën hebben betrekking op techniek, organisatie en menselijk gedrag. De proactieve maatregelen dienen voornamelijk om de kans op een cyberincident sterk te verkleinen. De grootte van de impact is echter niet altijd te bepalen. De proactieve maatregelen (‘staying healthy’) dienen ervoor om de asset te beschermen tegen malware en manipulatie of wijzigingen van software en/of hardware bij het falen van de fysieke toegangsbeveiliging. De maatregelen aan de rechterkant (‘healing quickly’) hebben tot doel om de impact te reduceren en na een gebeurtenis de asset zo snel mogelijk weer volledig functioneel te krijgen (validatie en verificatie). Uitgangspunt hierbij is dat de gebeurtenis wordt gedetecteerd; zonder detectie worden er geen herstelmaatregelen genomen.

    Note:

    Indien derden toegang krijgen tot de asset(s) zonder dat dit opgemerkt wordt (alle proactieve barriers hebben gefaald inclusief detectie methodes en audits) hoeft de impact niet direct zichtbaar te zijn.

    Figuur 5.6: Schematische weergave proactieve- en herstelmaatregelen.

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

    Figuur 5.7: Het Zwitserse-kaasmodel (bron: James Reason)

    5.5.2 Selectie van maatregelen

    De selectie van de 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 waarbij de leeftijd en toegepaste technologie van de bestaande installaties (onderling sterk) kunnen verschillen.

    Bij nieuwbouw is sprake van ‘security by design’, waarbij cybersecurity geïntegreerd wordt in het ontwerp van de installatie(s) en het integrale totaalontwerp. Indien het een renovatie betreft, gaat het om ‘security by customization’: maatwerk in de werkende installaties(s) en over de installaties heen (protectieschil).

    Afhankelijk van het risico moet een transparante afweging worden gemaakt en een besluit worden genomen welke combinatie van voorzorgsmaatregelen tegen cyberincidenten en welke maatregelen voor herstel minimaal nodig zijn. Maatregelen dienen een bepaald doel en dit doel moet, zolang deze maatregel van kracht is, onderhouden worden door 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) zorgt ervoor dat het risico weer toeneemt.

    Uit de risicoinventarisatie en -analyse volgt een lijst die laat zien welke gevolgen bepaalde maatregelen hebben op het optreden van gebeurtenissen. Het nemen van bepaalde maatregelen kan 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 vergt dus een zorgvuldige afweging en moet daarom bij voorkeur gebeuren door een team van de juiste deskundigen.

    Zodra de maatregelen zijn geselecteerd, wordt opnieuw per onderdeel bekeken wat de (rest)risico’s zijn als de maatregelen worden uitgevoerd. Het risicoverschil dat ontstaat door het nemen van de maatregel is dan 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. Dit restrisico moet bestuurlijk worden geaccepteerd.

    De maatregelen dienen zoveel mogelijk op elkaar afgestemd te worden waarbij alle maatregelen elkaar versterken. Uiteraard geldt hoe meer proactieve maatregelen worden genomen, hoe kleiner de kans op optreden wordt. Echter, dit heeft ook nadelen vanwege het instandhouden van de maatregelen, zoals beheerskosten en het mogelijk bemoeilijken van het onderhoud van en wijzigingen aan de installatie/systeem.

    5.5.3 De factor mens

    Het thema ‘Mens’ is voornamelijk gericht op bewustwording en training van beheerders, bedienaars, onderhoudspersoneel en andere betrokkenen die op de objecten werkzaamheden moeten verrichten. Dit betreft zowel de eigen mensen als externen. Veel bedrijfsmedewerkers zijn zich vaak niet of nauwelijks bewust van de risico’s van de manier waarop ze handelen. Inloggegevens zoals gebruikersnaam en wachtwoord worden bijvoorbeeld nog veel te vaak gedeeld met collega’s, of bij de desbetreffende installatie op een briefje geschreven. Of onderhoudspersoneel verbindt laptops zonder deze vooraf te scannen op malware met de installatie waarop ze onderhoud moeten uitvoeren. Dit zijn slechts drie voorbeelden van menselijk gedrag dat in dit digitale tijdperk als ongewenst bestempeld kan worden. Ruim zeventig procent van de gemelde veiligheidsincidenten wordt (mede) veroorzaakt door onwetendheid en onjuist handelen van mensen. Andere voorbeelden zijn het bekijken van de inhoud van ‘gevonden’ USB-sticks, het zelf 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 de financiële moeilijkheden zitten, enz. blijken een belangrijke risicofactor te vormen.

    Mensen zijn dan ook een belangrijke factor voor cybersecurity. Onveilig gedrag kan leiden tot gecompromitteerde systemen. Het is daarom van belang dat mensen worden opgeleid (kennis en bewustwording) en gefaciliteerd in veilig gedrag. Bovendien moet er bij technische en procedurele maatregelen ernstig rekening worden houden met menselijk gedrag. Als een cyberrisico technisch en/of procedureel wordt opgelost en het hindert mensen te veel in hun werkzaamheden, dan verzinnen ze een workaround. De workaround maakt het echter meestal niet veiliger. De ‘golden triangle’, de balans tussen functionaliteit, beveiliging en gebruiksgemak, is van essentieel belang.

    Andere aspecten die bij het thema ‘Mens’ horen zijn bijvoorbeeld een ontevreden medewerker, een incapabele medewerker of een ex-medewerker die zijn gram wil halen. Bij de risico-inventarisatie worden deze risico’s opgenomen. Bij de risicoanalyse wordt bekeken wat de kans is dat het risico optreedt en wat de mogelijke impact is. Het is belangrijk bewust te zijn van de mogelijke gevaren die heersen en van de te nemen maatregelen, zoals het blokkeren van accounts, regelmatig wijzigen van wachtwoorden en het opleiden van medewerkers.

    Trainingen en voldoende frequent oefenen zijn enkele maatregelen om mensen ‘cyberbewust’ te maken en te houden. Het opstellen en tekenen van een geheimhoudingsverklaring en het vereisen van een VOG richten zich op het voorkomen van ongeautoriseerd/ongewenst personeel. De investeringskosten zullen opwegen tegen de toename in kwaliteit, afname in uitval, etc.

    5.5.4 De organisatie

    Afhankelijk van de aard en omvang van het project/contract zijn zeer veel organisatievormen gangbaar, zie ook hoofdstuk 4 Organisatie cybersecurity.

    IEC-62443-2-2 en ISO 27002 geven een handreiking voor de rollen en vereisten die er voor informatiebeveiliging en cybersecurity belegd moeten worden. In onderstaande figuur staat een voorbeeld van cybersecurityrollen.

    Figuur 5.8: Voorbeeld 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.

    Door taken, verantwoordelijkheden en bevoegdheden op het gebied van cybersecurity in de organisatie in te bedden, kunnen gedetecteerde risico’s bij de juiste persoon/probleemeigenaar worden belegd. 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 Voor elke niet-standaard koppeling van apparatuur zal expliciet toestemming verleend moeten worden. De kaders voor toestemming, de registratie van te koppelen apparatuur en inzicht in de risico’s worden door de gemandateerde functionaris bepaald en toegepast.
    • Geautoriseerd personeel voor toegang tot loggegevens Voor toegang tot loggegevens worden hoge eisen gesteld voor vertrouwelijke omgang met informatie. Deze gegevens kunnen persoonsgegevens bevatten en daarmee onder de AVG vallen. Daarnaast zullen loggevens vaak informatie bevatten die kwetsbaarheden van een systeem kunnen onthullen aan een hacker, bv. versie-informatie, IP-adressen, gebruikte protocollen e.d. Aan de toegang en verwerking van de loggegevens worden daarom speciale eisen gesteld.

    Andere rollen zullen afhankelijk van de aard van het project of organisatie worden benoemd en ingevuld.

    5.5.5 Techniek

    De techniek is een belangrijke schakel voor cybersecurity en dient optimaal ingezet te worden. Echter, de techniek is niet onfeilbaar en dient periodiek geëvalueerd en, wanneer nodig, aangepast te worden. De toegepaste technologie dient passend te zijn bij de organisatie en aan te sluiten bij de kennis en ervaring van de factor ‘mens’. De driehoek dient in evenwicht te zijn.

    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 door verschillende leveranciers worden gebouwd. 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). Mogelijk heeft een deelinstallatie een (draadloze en internet)toegang voor onderhoudswerkzaamheden. Door middel van dit toegangspunt is het mogelijk dat het totale netwerk benaderbaar is. De praktijk leert dat deze risico’s niet altijd duidelijk zijn en opgemerkt worden. 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.

    5.6 Borging

    Borgen, auditen en verantwoording afleggen kunnen worden uitgevoerd in 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 procedure door de betreffende partij ook daadwerkelijk wordt uitgevoerd zoals is beschreven.

    Indien op basis van een actuele risicoanalyse de kwetsbaarheden van een tunnelsysteem bekend zijn en alle noodzakelijke maatregelen zijn genomen, is het zaak om het dan bereikte niveau van cybersecurity te handhaven. Handhaving betekent in dit geval de borging (proces) van de cybersecurity op alle aspecten: fysieke toegangsbeveiliging van IA-gerelateerde ruimten, logische toegang, netwerkkoppelingen, procedures hardening en patching, procedures beveiligingsincidenten, incidentresponsplan, logging en monitoring, afspraken en procedures met aannemers, bewustwording en trainen van tunnelbeheerders en ander betrokken personeel, procedures gecontroleerd wijzigen, procedures back-ups en mitigerende maatregelen voor andere kwetsbaarheden die voortkomen uit de risicoanalyse. Specifiek dient aandacht te worden besteed aan de implementatie van de beveiligingsadviezen van leveranciers en van het Nationaal cybersecuritycentrum van het ministerie van Justitie en Veiligheid.

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

    De borging is grofweg op te delen in twee aandachtsgebieden:

    1. Organisatorische, personele en procedurele aspecten
    2. Technische aspecten.

    5.6.1 Organisatie, personeel en procedures

    Borging van deze niet-technische aspecten kan op vele manieren, waarbij allerlei combinaties en varianten denkbaar zijn. Het kan bijvoorbeeld op een heel lichte manier of op een formeel zware manier. Van licht naar zwaar oplopend kan gedacht worden aan:

    1. Interne controle door eigen medewerkers in opdracht van de tunnelbeheerder.
    2. Interne controle en/of inspecties door verantwoordelijke voor informatiebeveiliging.
    3. Collegiale toetsing door een tunnelbeheerder die onder een ander bevoegd gezag valt.
    4. Audit door interne auditdienst van het bevoegd gezag.
    5. Audit door extern auditor.

    Voorafgaande aan de controle/inspectie/audit dienen afspraken gemaakt te zijn met de tunnelbeheerder over de criteria en de reikwijdte ervan.

    Altijd dient een verslag gemaakt te worden van de uitgevoerde controle/inspectie/audit. Hierin moet minimaal zijn opgenomen:

    1. ‘Administratieve gegevens’ van de uitgevoerde controle/inspectie/audit zoals: opdrachtgever, opdrachtnemer, datum, criteria, reikwijdte, etc.
    2. Resultaat van de uitgevoerde controle/inspectie/audit.
    3. Voorgestelde aanpassingen, verbeteringen op de onderzochte aspecten.
    4. Resultaten eerdere controles/inspecties/audits en voortgang acties.
    5. Globale inschatting benodigde middelen voor aanpassingen en verbeteringen.

    Uitbesteed werk

    Gezien het feit dat 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 volgt die voor de interne organisatie gelden. Indien het noodzakelijk is om hiervan af te wijken, zorg er dan voor dat deze afwijking gelegitimeerd is 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 hoofdelijk eindverantwoordelijk voor de veiligheid van het object.

    Hij moet zich vergewissen van de herbelegde activiteiten.

    5.6.2 Technische aspecten

    Voor de criteria, reikwijdte en rapportage gelden voor technische aspecten dezelfde zaken zoals hiervoor beschreven. Het specifieke zit in de technische aspecten van:

    1. Patching, logging, hardening, monitoring, back-ups, toegangsbeveiliging, netwerkkoppelingen, etc.
    2. Technische inspectiemechanismen, zoals detectieprogrammatuur, firewalls, antivirussoftware en penetratietesten.
    3. De uitbesteding (voorwaarden, verantwoordelijkheden, e.d.).

    Controle/inspectie/audit van deze cybersecurity-aspecten kunnen bijvoorbeeld gedaan worden door een extern gecontracteerd cybersecuritybedrijf. Het Security Operations Centre (SOC) van Rijkswaterstaat kan, als lid van het ISAC Tunnels, benaderd worden voor kennisdeling, advies of ondersteuning.

    In de rapportage moet voldoende aandacht zijn voor afwijkingen in de procedures en in de techniek van de geldende en geïmplementeerde cybersecurity. Met name de argumentatie en risico’s om af te wijken moeten goed gedocumenteerd en geautoriseerd zijn.

    Naast de formele rapportage is het gewenst om aangetroffen kwetsbaarheden te bespreken in het ISAC Tunnels, zodat alle tunnelbeheerders van Nederland er kennis van kunnen nemen.

    6 Verificatie en validatie

    Veiligheidsvoorzieningen moeten niet alleen aanwezig zijn, maar ook aantoonbaar correct werken. Dat geldt eveneens voor cybersecuritymaatregelen: ook voor dit type veiligheid is verificatie en validatie vereist. Met verificatie wordt objectief en expliciet aangetoond dat een oplossing voldoet aan de gestelde eisen. Validatie toont aan dat een oplossing geschikt is voor het beoogd gebruik. Voor cybersecurity geldt bovendien dat bij de 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’.

    De begrippen en definities voor de termen verificatie en validatie worden in diverse kennisdomeinen vaak net iets anders gedefinieerd, waardoor internationaal gezien zeer veel definities zijn ontwikkeld. De definities die zijn afgeleid van de Leidraad voor Systems Engineering binnen de GWW-sector zijn als volgt:

    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.

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

    A: Bewijsvoeringsmethode

    B: Criterium

    C: Beoordelaar

    D: 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.

    E: Het tijdstip waarop de verificatie/validatie moet plaatsvinden.

    F: 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.

    G: De geldigheid van de gehanteerde verificatie- of validatiemethode. Bijvoorbeeld als de opdrachtnemer een bewijsvoeringsmethode voorstelt die nieuw of (nog) onbekend is bij de opdrachtgever.

    H: 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.

    Stappen in het verificatietraject

    1. Project Startup/werkpakket analyse

    2. Werkpakket starten: maken van een verificatieplan

    3. Uitvoering verificatie

    4. Werkpakket afronden: maken van een verificatierapport

    Klap uit Klap in

    Validatiemomenten

    • Eisenvalidatie, validatiesessies
    • Ontwerpvalidatie, ontwerpreviews
    • Productvalidatie, keuring van het werk
    • Functionele simulatie van het systeem, of 3D-simulatie

    Validatie op de juiste momenten voorkomt faalkosten.

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

    • een wachtwoord kan worden gekozen met die geëiste lengte
    • een wachtwoord kan worden gekozen met een (willekeurige) grotere lengte
    • een wachtwoord met een kortere lengte niet kan worden gekozen en leidt tot een foutmelding van het systeem

    Bronnen:

    7 Monitoring

    7.1 Inleiding

    Ondanks alle maatregelen is het onmogelijk om cyberincidenten geheel te voorkomen. Bovendien wordt er een meestal een zeker restriciso geaccepteerd. Met de inrichting van cybersecuritymonitoring van de technische systemen wordt continu de status van de digitale veiligheid in de gaten gehouden. Zo kunnen nieuwe kwetsbaarheden gesignaleerd worden en cyberincidenten beter gedetecteerd en afgehandeld worden.

    Het doel van monitoring is, nadat het ‘normale’ gedrag is vastgesteld, het onderkennen van afwijkend gedrag voor het detecteren van een incidentdreiging, het vastleggen van eventuele cybersecurity gerelateerde gebeurtenissen en het verzamelen van bewijs. In de Baseline Informatiebeveiliging Overheid (BIO) worden voor de monitoring om maatregelen gevraagd om aan deze doelstelling te kunnen voldoen. De verantwoordelijkheid voor het voldoen aan de BIO, waaronder securitymonitoring, ligt bij de beherende partij.

    Het rapport Cybersecuritybeeld Nederland 2019 laat zien dat het gemiddeld 78 dagen duurt voordat wordt opgemerkt dat er een inbreuk is op het systeem. Het is dus noodzakelijk dat er voldoende detectiemaatregelen zijn om het systeem en de processen goed te monitoren en testen. Hierbij valt te denken aan:

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

    Medewerkers toetsen

    Social engineering is een van de vormen van cybercrime. Menselijke eigenschappen zoals nieuwsgierigheid, vertrouwen en hebzucht worden hierbij misbruikt om informatie te verkrijgen. Het kan waardevol zijn om te meten in welke mate de medewerkers hiervoor ‘vatbaar’ zijn. Met phishing as a service (PhaaS) wordt phishing gesimuleerd door het verspreiden van gecontroleerde nep-phishingberichten in de organisatie.

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

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

    7.2 Implementatie van logging en monitoren

    Voor de implementatie van logging en monitoring wordt in de hieronder staande paragrafen op hoofdlijnen een opsomming gegeven waaraan men zou kunnen denken. Daarbij geldt dat de logdata lokaal op een apparaat (computer, switch, etc.) ontstaat. Het verdient vervolgens aanbeveling deze centraal te verzamelen in een logserver. Daarnaast moeten zowel de lokale als de centrale bestanden met logdata worden beschermd tegen onbevoegd veranderen of verwijderen.

    OT-systeem (informatieverwerkende omgeving)

    Logging van activiteiten van beheerders en operators

    Logging van netwerkapparatuur

    SIEM en SOC

    Monitoring van netwerkapparatuur

    Kloksynchronisatie

    Klap uit Klap in

    8 Incident en herstel

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

    8.1 Wat is een cyberincident?

    8.1.1 Definitie

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

    Over het algemeen zijn soorten activiteiten die worden erkend als inbreuken op een beveiligingsbeleid:

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

    8.1.2 Levenscyclus

    Het National Institute of Standards and Technology (NIST) geeft een indeling en toelichting over de levenscyclus van een incident, zie onderstaand figuur. De fasen worden in de overige paragrafen van dit hoofdstuk nader toegelicht.

    Figuur 8.1: Levenscyclus van een incident (bron: Computer security incident handling, NIST).

    8.1.3 Oorzaken en herkenning

    Het Cybersecurity Beeld Nederland 2019 (CSBN2019) laat zien dat er een verschuiving is van de veroorzakers van incidenten. Het aantal ‘toevallige’ inbreuken door hobbyisten (script kiddies) vermindert. Daarentegen nemen de bewust geplande aanvallen door landen (nation states) toe. 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.

    Een veiligheidsincident is niet altijd zichtbaar en wordt niet altijd eenvoudig als zodanig herkend. Daarom is bewustwording en training in het herkennen en melden van incidenten een eerste stap in de voorbereiding.

    Mogelijke triggers voor veiligheidsincidenten (bron: Cybersecurityrichtlijn RWS):

    • Verlies van dienst, apparatuur of voorzieningen.
    • Systeemstoringen of overbelasting (o.a. verstoring van het backup proces).
    • Menselijke fouten die leiden tot functionele verstoring of uitval van systemen.
    • Inbreuk op fysieke en logische beveiligingsvoorzieningen van het object.
    • Inbreuk op de bediening en beheer.
    • Ongeautoriseerde systeemwijzigingen.
    • Niet-naleving van beleid of gedragsregels.
    • Virusmeldingen.
    • Verlies of diefstal van bedrijfsmiddelen.
    • Oneigenlijk gebruik van bevoegdheden.
    • Vandalisme, moedwillige beschadiging.
    • Aanvallen via publieke netwerken zoals internet.
    • Afwijkend systeemgedrag.
    • Ongeautoriseerd koppelen van mobiele apparatuur.
    • Ongeautoriseerd koppelen van removable media.
    • Ongeautoriseerd koppelen van netwerken.
    • Onregelmatigheden in logische toegang.
    • Verdachte of zwakke plek in systemen of netwerken.
    • Malware gedetecteerd.
    • Nieuwe kwetsbaarheden.

    8.1.4 Melden en registreren

    Voor het correct kunnen afhandelen van een incident is het cruciaal dat incidenten onmiddellijk worden gemeld bij de verantwoordelijke incidentmanager. Ook als er twijfel is of er sprake is van een incident dient een melding te worden gedaan. Deze meldingen dienen integer te geschieden. Een melder mag niet onder druk worden gezet om meldingen achterwege te laten of af te zwakken om persoonlijke, economische of andere redenen. Bij het registeren van incidenten dient vastgelegd te worden:

    • Locatie
    • Datum en tijdstip
    • Getroffen systeem
    • Bedrijfssituatie
    • Genomen maatregelen
    • Melder en getuigen
    • Zijn er overige aanwezigen?

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

    8.2 Fase 1: Voorbereiding

    Door een goede voorbereiding staat een organisatie in de startblokken 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 proces’ voor het betreffende object/de organisatie/de beheerder.

    • Door bewustwording en training is al een eerste stap gezet. Deze stap, samen met screening van personeel en formaliseren van taken, bevoegdheden en verantwoordelijkheden, vormt de voorbereiding van de menselijke kant op incidentrespons.
    • De organisatie dient 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.
    • Informatie betreffende (toegang tot) vertrouwelijke gegevens dient beveiligd te zijn. Wachtwoordbeheer is een belangrijk aspect. Mechanismen als multi-factor authentication moeten overwogen worden. Maak tijdelijke wachtwoorden voor een ontwerp- en testfase. Wachtwoorden die bij meerdere mensen bekend zijn, moeten worden verboden.
    • Op technisch gebied wordt het ‘automatisch’ detecteren en loggen van incidenten ingebouwd. De doormelding en opvolging van de detecties is onderdeel van het responsproces. Een nieuwe kwetsbaarheid in technische systemen kan misbruikt worden, maar is op zich nog geen veiligheidsincident. In dit groeiboek wordt patching ook behandeld als onderdeel van technische maatregelen. Ter voorkoming van incidenten is het adequaat en tijdig uitvoeren van patching of patchanalyses een belangrijk onderwerp. Het ongepatcht laten van eenmaal opgeleverde systemen, zoals tot voor kort zeer gebruikelijk was, voldoet tegenwoordig echt niet meer.

    Incidenten worden gemeld bij de incidentmanager. De taken en verantwoordelijkheden van de incidentmanager moeten van te voren bekend zijn, zie hoofdstuk 4 Organisatie cybersecurity en de maatregelen in de verschillende projectfasen.

    8.3 Fase 2: Detectie en analyse

    8.2.1 First response

    In deze fase gaat het erom vast te stellen of inderdaad sprake is van een veiligheidsincident, en zo ja, hoe ernstig het incident is. Een classificatiematrix is van belang om de impact en het vereiste niveau van opschaling snel te kunnen vaststellen.

    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 veilig stellen van beschikbaar bewijsmateriaal. Een ander aspect dat hier van belang is, is het veiligstellen van het betreffende object, zodat de veiligheid gewaarborgd is. Dus bijvoorbeeld: een tunnel afsluiten. Ook belangrijk hierin is de rol van 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.2.2 Classificatie

    Classificatie kan gebeuren aan de hand van de impact (ligt het hele systeem eruit, is er data gelekt, etc.) en het soort incident. Een typische indeling is Kritiek, Significant, Gering, Verwaarloosbaar. Vanuit deze classificering worden incidenten geprioriteerd. Hierin is het belangrijk onderscheid te maken in de tijd waarin een incident gemeld moet worden, en een 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:

    Classificering 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 geïnformeerd worden. Een standaard communicatieplan op basis van de classificatie is gewenst. Hierin moet ook staan welke incidenten er direct worden gemeld naar de Autoriteit Persoonsgegevens (AP), het NCSC en/of de opdrachtgever.

    8.2.3 Incidentanalyse

    Na classificering 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. Typische samenstelling van een team is:

    • 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 inzicht moet zijn in de bestaande configuratie en de operationele processen. Daarnaast moet voldoende kennis beschikbaar zijn van de kwetsbaarheden en de mogelijke impact hiervan. Technische en operationele kennis wordt samengebracht vanuit ontwerpgegevens, CMDB, bedrijfsproces en kennis van ICT/OT.

    In een grafisch overzicht wordt een analyse gegeven 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. In de analyse wordt ook rekening gehouden 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: Corrigerende maatregelen

    Het responsteam voert een analyse uit van het incident en bepaalt de corrigerende maatregelen. In dit kader is een gestructureerde aanpak van belang. Om deze structuur te krijgen, wordt een herstelplan opgesteld. Het herstelplan begint 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. Het herstelplan is gericht op het selecteren en implementeren van de corrigerende maatregelen.

    Een herstelplan kan variëren van een ‘simpele’ registratie in een Excel-formulier tot een compleet boekwerk met analyse van systemen en logbestanden t.b.v. een forensisch onderzoek. Het responsteam kiest de te gebruiken vorm van het herstelplan.

    Onderwerpen voor een herstelplan zijn:

    1. Beschrijving van het incident

    2. Beschrijving van functionele impact

    3. Vermoedelijke oorzaak van het incident
    Beschrijf hoe het incident veroorzaakt is, inclusief de aanwijzingen/bewijzen die hierop duiden. Verzamel zoveel mogelijk bewijs en analyseer dit om oorzaak, ernst en impact van het incident te bepalen. Denk hierbij ook aan bv. het tijdstip van besmetting, omdat dit mogelijk effect heeft op herstelmogelijkheden en verspreiding van de besmetting. Dit moet in overleg met de klant gebeuren, om te zien wat prioriteit krijgt: het systeem zo snel mogelijk weer beschikbaar krijgen of bewijs verzamelen. Vaak is een technische analyse noodzakelijk om te begrijpen hoe een trigger kan leiden tot het opgetreden incident.

    [/tekst]

    4. Feitelijk herstel van het object

    5. Verbetering van de cybersecurity van het object

    6. Conclusies en communicatie

    Klap uit Klap in

    Afronding van het incident

    Na het uitvoeren van het herstelplan is het belangrijk dat het incident ook formeel, administratief afgesloten wordt. Dit zal per project op een verschillende wijze georganiseerd zijn. Vaak is een incidentendatabase aanwezig waarin de melding en de stappen in de afwikkeling van het incident worden vastgelegd. Afhankelijk van de contractvorm kan, op basis van de registratie van binnengekomen en afgeronde incidenten, een verrekening plaatsvinden tussen opdrachtgever en opdrachtnemer. Het herstelplan is tevens input voor een eventueel forensisch onderzoek en heeft daarmee juridische waarde.

    8.5 Fase 4: Evaluatie en geleerde lessen

    8.5.1 Eenmalige of structurele incidenten

    Het is van belang om te leren van veiligheidsincidenten. Het delen van incidentinformatie met andere organisaties via bijvoorbeeld de ISAC’s is van essentieel belang bij het leren 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’.

    Het optreden van een incident kan veroorzaakt worden door een eenmalige gebeurtenis. Na correctie van het incident wordt met een herevaluatie bepaalt of dit incident nog vaker kan voorkomen. Als het antwoord ja is, dan wordt gezocht naar mogelijkheden voor een structurele oplossing of wordt het als restrisico beoordeeld en verandert er niets.

    Bijvoorbeeld: het risico dat onstaat door het vergeten om een pc te locken, kan worden verkleind door de pc zo in te stellen dat deze automatisch wordt gelocked na een bepaalde tijd van inactiviteit. Daarbij moet uiteraard rekening gehouden worden met het normale operationele proces voor het bepalen van de wachttijd tot het op slot gaan.

    Structurele incidenten worden niet opgelost met alleen een correctie van het opgetreden incident. Door corrigerende maatregelen ook door te trekken naar andere, vergelijkbare systemen wordt de kwetsbaarheid van het gehele object verlaagd. Het is dan wel van belang om precies te weten wat de bestaande configuratie is.

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

    8.5.2 Rapportages en communicatie van incidenten

    De opdrachtgever zal inzicht moeten krijgen in de opgetreden incidenten en de afhandeling daarvan. Urgente en kritieke incidenten worden direct doorgemeld naar de security-contactpersoon bij de opdrachtgever. Door middel van een standaard rapportage wordt inzicht gegeven in de opgetreden incidenten en de genomen maatregelen. De rapportage zal periodiek (eens per kwartaal is een goede maatstaf hiervoor) geleverd worden als een managementsamenvatting. Deze rapportage zal niet alle details van het incident bevatten, omdat hier ook vertrouwelijke gegevens bij zijn. 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 worden gegeven in het opgestelde herstelplan. Ook als er in de rapportageperiode geen incidenten zijn geweest dient de rapportage te verschijnen. Als de maatregelen hebben geleid tot aanpassingen in systemen zal dit ook verwerkt moeten zijn in de as-built projectdocumentatie en in de CMDB.

    8.6 Praktijk: typische incidenten in verschillende projectfasen

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

    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 (ip-adressen, firewalregels, 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 niet bewust dat hij hiermee een poort openzet voor toegang tot vorige 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 Planfase en aanbesteding

    Figuur 9.1: Fasen in een project.

    9.1 Inleiding

    Met de planfase wordt de ruimtelijke fase bedoeld die wordt afgesloten met een ruimtelijk besluit, zoals een tracebesluit, provinciaal inpassingsplan of bestemmingsplan. In 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.

    Aanbestedingen worden gedreven door toevoegingen aan of vervangingen van bestaande infrastructuur, zowel op civiel als installatietechnisch gebied. Levenscyclusoverwegingen, beheer en onderhoud, en veranderende wet- en regelgeving zijn hierin 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-onderhoudperspectief. Het eenvoudig beschikbaar zijn van informatie zorgt op zichzelf vaak al voor vele belangstellenden. Vele voordelen, maar ook nieuwe risico’s, waaronder cybersecurity.

    Om cybersecurity te borgen in de hele levenscyclus van een object zal bij de contractvoorbereiding door de opdrachtgever nagedacht moeten worden over het contractueel borgen van cybersecurity. Met als doel dat door opdrachtnemer een systeem wordt opgeleverd en beheerd dat voldoet aan de cybersecurity-kaderstelling van de organisatie, zie ook hoofdstuk 4 Organisatie cybersecurity.

    9.2 Taken, bevoegdheden en verantwoordelijkheden

    In deze fase 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 cybersecurityrichtlijn in contract.
    • Classificatie van documenten en systeem voor informatie-uitwisseling.
    • NDA (geheimhoudingsverklaring) opvragen voordat stukken worden verstuurd.
    • Toezien op verwijdering van aangeleverde informatie bij (niet aangewezen) aanbieders.

    Taken aanbieder:

    • NDA (geheimhoudingsverklaring) vragen aan derden.
    • Inrichten vertrouwelijke documentomgeving.
    • Eventueel inrichten fysiek afgeschermde projectomgeving.
    • Cybersecurity opnemen in aanbieding (voor alle projectfasen).

    9.3 Overwegingen voorafgaand aan aanbesteding

    Ter voorbereiding op een aanbesteding zal door opdrachtgever ook nagedacht moeten worden over het aspect cybersecurity.  De volgende aspecten zijn daarin het overwegen waard:

    Bewustwording

    In het kader van een breder veiligheidsbesef moet bewustwording ontstaan over cybersecurity. Bij zowel opdrachtgever als opdrachtnemer moet cybersecurity ‘in de genen’ gaan zitten. Eenzelfde proces is vaak doorlopen voor veiligheid in zijn algemeenheid. Daaruit kan geleerd worden dat het nemen van allerlei maatregelen alleen niet voldoende is. Zonder een echt veiligheidsbesef is iedere maatregel te omzeilen.

    Levenscyclus

    Cybersecurity kent een eigen levenscyclus die vaak niet overeenkomt met de technische levenscyclus van het betreffende OT-systeem. Bedreigingen komen en gaan in de huidige tijd sneller dan dat een systeem veroudert. De mogelijkheid bestaat dat een systeem voor einde levensduur om cybersecurityredenen vervangen moet worden. Vaak zijn er binnen de technische levensduur nog wel levenscyclusverlengende maatregelen te bedenken.

    Integraal ontwerp

    Cybersecurity vraagt om een integraal, discipline-overstijgend ontwerp met focus op life cycle costing (LCC). Alleen dan kan een gedegen keuze worden gemaakt uit de in proces of techniek te nemen maatregelen. LLC is van belang omdat cybersecuritymaatregelen gedurende de hele verdere levenscyclus van het systeem aandacht vragen. In dat kader is de beschikbaarheid van het systeem ook zeer de aandacht waard. Een nachtelijke update zoals in de ICT-wereld is niet altijd acceptabel.

    Beheer en onderhoud

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

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

    Informatiebeveiliging

    Cybersecurity vraagt om een goede informatiebeveiliging daar het onbedoeld vrijkomen van informatie al een cybersecurityrisico op zichzelf is. Tijdens de aanbesteding is dit een punt van aandacht, omdat het dan juist van belang is informatie te delen met potentiële opdrachtnemers. Alleen openheid over de bestaande situatie zal leiden tot goede oplossingen.

    Nieuwbouw of renovatie?

    Nieuwbouw en renovatie hebben een totaal verschillende dynamiek. Alleen al omdat het laatste vaak moet gebeuren onder de randvoorwaarde van een zo groot mogelijke beschikbaarheid. Daarnaast is bij nieuwbouw het cybersecurity-aspect vaak nog volledig vrij in te vullen op basis van het gewenste weerstandsniveau. Bij renovatie kan de bestaande situatie al een aantal beperkingen opleggen en het onmogelijk maken om tegen acceptabele kosten een bepaald weerstandsniveau te bereiken.

    Veel objecten zijn gebouwd in een tijd dat cybersecurity niet aan de orde was. In dit geval is het in het kader van integraliteit te overwegen een functiereconstructie uit te voeren, leidende tot een nieuw ontwerp waarop weer verder kan worden doorgebouwd.

    Weerstandsniveau in de totale keten

    Uitgangspunt voor het ontwerp is het te bereiken weerstandsniveau. Dit zal voor de betreffende infrastructuur, maar ook voor de keten waarin deze zich bevindt, moeten worden beschouwd. Immers, elke keten is zo sterk als zijn zwakste schakel. Overwogen zal moeten worden het bepalen van het weerstandsniveau zelf uit te voeren dan wel uit te vragen.

    9.4 Tijdens de aanbesteding

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

    Informatievoorziening

    Er zal goed moeten worden nagedacht over het beschikbaar stellen van gevoelige informatie betreffende cybersecurity. Tijdens het aanbestedingsproces, maar ook daarna bij gegadigden die de opdracht niet hebben gescoord. Denk bijvoorbeeld aan informatie over inbraakbeveiliging, toegangscontrole en datatransmissienetwerk(en): wie mag deze informatie zien en hoe is dit afgeschermd? Ook documentsystemen/-shares en CAD/BIM-omgevingen verdienen aandacht.

    Cybersecurity als selectiecriterium

    Zowel in (pre-)selectie als in de kwalitatieve uitvraag kan kennis en ervaring, zowel van proces als techniek, in het omgaan met objecten van een bepaald weerstandsniveau worden meegenomen. Opvragen van referenties dan wel een plan van aanpak zijn mogelijkheden.

    Project- cq. tendermanagement

    Cybersecurity speelt vanaf het moment dat een project gegund wordt, en niet pas vanaf het moment dat het object opgeleverd wordt voor gebruik. Tijdens de ontwerp- en realisatiefase is cybersecurity misschien nog wel belangrijker dan na oplevering. In deze fase kan het meeste preventieve werk worden verricht. Reparaties nadien zijn bovendien veel kostbaarder.

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

    9.5 Borging

    Cybersecuritymaatregelen dienen integraal te worden meegenomen in zowel het technische ontwerp als bij de betrokken organisaties (mensen). Het is dus van belang dat deze aspecten onderdeel zijn van de uit te vragen eisen. Met behulp van de systems engineering zullen deze eisen in volgende fases gevalideerd worden teneinde de maatregelen verder te borgen.

    Daarnaast is het van belang dat informatie die onderdeel is van de uitvraag geclassificeerd wordt. Gevoelige informatie dient enkel beschikbaar te worden gesteld in een afgeschermde omgeving na het tekenen van een geheimhoudingsverklaring. In deze verklaring dient te worden opgenomen dat gevoelige informatie na de aanbesteding wordt vernietigd of geanonimiseerd.

    Voor de algemene aspecten rondom borging, zie 5.6 Borging.

    10 Realisatiefase (nieuwbouw)

    Bij de realisatie van een tunnel onderscheiden we de volgende fase, zie onderstaande figuur:

    Figuur 10.1: Fasen in een project.

    Vanaf de start van het project moet men zich realiseren dat alle informatie die door het project wordt geproduceerd op een later moment interessant kan zijn voor iemand die kwade bedoelingen heeft. Daarom is het van belang vanaf het allereerste begin, bij de inrichting van het project, regels op te stellen voor het kwalificeren en behandelen van alle documentatie die gaat ontstaan.

    Alle medewerkers in het project dienen zich bewust te zijn van de risico’s op dit gebied en moeten weten hoe men dient te handelen om de kans op het in verkeerde handen komen van de ontwerpdocumentatie zo klein mogelijk te houden.

    10.1 Ontwerp

    Als uitgangsdocumentatie voor de ontwerpfase van een bouwproject geldt het gesloten contract. Dat contract bevat een veelheid aan eisen voor de uit te voeren opdracht. Het gros van die eisen gaat over de functionaliteit van het te realiseren object, maar het contract zal, als het goed is, ook niet-functionele eisen, onder meer op het onderwerp cybersecurity, bevatten. Zie hoofdstuk 9 Planfase en aanbesteding over de manier waarop het contract tot stand komt.

    Anders dan de functionele eisen zullen de eisen met betrekking tot cybersecurity gevolgen hebben voor nagenoeg alle aspecten van het ontwerp; daarom is het verstandig dit onderwerp als een integraal thema in het ontwerp te laten terugkomen in plaats van het als aandachtspunt bij de verschillende specialisten op de deelsystemen te beleggen.

    De opdrachtgever kan in het contract al onderkende risico’s hebben beschreven. Vanuit die risico’s worden beheersmaatregelen geformuleerd voor de risico’s waarvan de gevolgen niet acceptabel zijn. Mocht de opdrachtgever nog geen risico’s hebben geïdentificeerd dan is een van de eerste activiteiten in de ontwerpfase het, gezamenlijk met de opdrachtgever, uitvoeren van een risicoanalyse. Daarbij kan IEC-62443 3-2 als leidraad worden gebruikt. Uit de ISO 27000 reeks kan eventueel ISO 27005 gehanteerd worden, waarbij moet worden opgemerkt dat deze standaard meer gericht is op een omgeving waarin met informatie wordt gewerkt.

    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. Cybersecurity is een van de RAMSSHEEP-aspecten. Bij veel OT-systemen in Nederland is – anno 2019 – een inhaalslag nodig om het weerstandsniveau aan te passen aan de cyberdreigingen van deze tijd. In dat geval is sprake van cybersecurityrenovatie en bestaat de kans om (by-the-book) op basis van de operationele doelstellingen van het OT-systeem, de cybersecurityeisen in kwantitatieve en kwalitatieve termen op te stellen en op basis van structurele risicoanalyse (dreiging, kwetsbaarheden) de juiste specifieke cybersecuritymaatregelen te ontwerpen en te implementeren. In geval van regulier onderhoud aan OT-systemen, kan een minimale cybersecurity-eis gelden dat een wijziging het huidige cybersecurity-niveau niet mag verminderen.

    Van belang voor het ontwerp is dat het op te leveren object ‘cyberveilig’ is, niet alleen op het moment van oplevering, maar ook daarna. In het ontwerp moet zo veel als mogelijk rekening worden gehouden met het kunnen realiseren van wijzigingen die nodig zijn om het object gedurende de levensduur cyberveilig te houden. Dit uitgangspunt heeft impact op zowel het ontwerp van de techniek als op het ontwerp van de processen en organisatie van het beheer en onderhoud.

    10.1.1 Taken, bevoegdheden en verantwoordelijkheden

    In deze fase is er een opdrachtgever en een opdrachtnemer. De opdrachtnemer zorgt voor een ontwerp dat aantoonbaar voldoet aan de geëiste regelgeving. Er is in deze fase een focus op informatiemanagement (DMS), security by design en screening van personeel.

    Taken opdrachtgever:

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

    Taken opdrachtnemer:

    • Risicoanalyse cybersecurity.
    • Schrijven cybersecuritymanagementplan.
    • Schrijven cybersecuritybeveiligingsplan(nen).
    • Opstellen cybersecurityprocedures.
    • Risicoanalyse en keuze beheersmaatregelen.
    • Doorzetten van cybersecurityvereisten naar adviesbureaus en onderaannemers.
    • Bespreken van cybersecurity in MT-overleggen.

    10.1.2 Risico’s/aandachtspunten

    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 10.2: Schematische weergave beveiligingslagen.

    Een belangrijke punt om te realiseren is dat er twee soorten risico’s bestaan voor een project in de kritieke infrastructuur. Enerzijds brengt het product van het project risico’s met zich mee (bv. de geautomatiseerde bediening, bewaken en besturing van een tunnel, brug of sluis), anderzijds kent het project zelf ook risico’s. We behandelen hieronder allereerst de risico’s van het product, daarna besteden we aandacht aan de risico’s van het project.

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

    1. Niet-geautoriseerde personen hebben fysieke toegang tot bedien‐ en technische ruimten.
    2. Niet-geautoriseerde personen hebben toegang tot de ICT en OT/SCADA‐systemen en/of documentatie, zoals tekeningen, handleidingen en dergelijke.
    3. Informatie over zwakke plekken in de beveiliging en beveiligingsincidenten ontbreekt alsmede een handelingsperspectief.
    4. Niet-geautoriseerde personen hebben (via internet of draadloze toepassingen) toegang tot het datanetwerk.
    5. ICT en OT/SCADA‐systemen bevatten kwetsbaarheden en zijn vatbaar voor malware.
    6. Het niet kunnen detecteren en analyseren van afwijkend gedrag op het datanetwerk en de zich voorgedane incidenten via logging en monitoring.
    7. Risico’s geïntroduceerd door bedienend en/of onderhoudsmedewerkers. Deze zijn zich 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).
    8. Functionele wijzigingen brengen onvoorziene veiligheid‐ en beveiligingseffecten met zich mee en kunnen zelfs de functionele werking van ICT en OT/SCADA‐systemen deels of volledig doen uitvallen.
    9. De handhaving en de effectiviteit van de cybersecuritymaatregelen is niet gewaarborgd alsmede de structurele borging bij onderaannemers.
    10. Bij systeemstoringen of functionele wijzigingen is er geen terugvaloptie (geen back‐up en herstelproces).

    Op basis van deze set van tien bedreigingen kan een set van risico’s worden gedefinieerd door bij elke bedreiging een of meer zwakheden te vinden en een of meer (nadelige) gevolgen. Het mogelijk resultaat van die oefening is gegeven in onderstaande opsomming:

    1. Niet-geautoriseerde personen bemachtigen toegangsmiddelen en kunnen bedien- en technische ruimten in. Hier kunnen zij OT-systemen bedienen en uitschakelen.
    2. Niet-geautoriseerde personen komen d.m.v. social engineering binnen in de bedien- en technische ruimten (tailgating of appeal to vanity/authority). Hier kunnen zij OT-systemen bedienen en uitschakelen.
    3. Niet-geautoriseerde personen weten in te breken binnen bedien- en technische ruimten. Hier kunnen zij OT-systemen bedienen en uitschakelen.
    4. Niet-geautoriseerde personen bemachtigen andermans login-gegevens en verkrijgen toegang tot het interne netwerk. Vanuit dit netwerk kunnen OT-systemen bediend en beheerd worden.
    5. Niet-geautoriseerde personen maken gebruik van een openstaande externe verbinding om toegang te verkrijgen tot het interne netwerk. Vanuit dit netwerk kunnen OT-systemen bediend en beheerd worden.
    6. Niet-geautoriseerde personen kraken het remote access/authenticatieproces en verkrijgen direct toegang tot het interne netwerk. Vanuit dit netwerk kunnen OT-systemen bediend en beheerd worden.
    7. Kwetsbaarheden worden niet verholpen omdat verslaglegging over kwetsbaarheden niet wordt uitgevoerd of doorgevoerd.
    8. Er wordt niet tijdig of adequaat gereageerd op beveiligingsincidenten, waardoor afhankelijke systemen ook onbeschikbaar wordt.
    9. Niet-geautoriseerde personen weten de beveiliging van het bedien- of beheernetwerk te omzeilen en kunnen OT-apparatuur in het netwerk bedienen.
    10. Malware dringt binnen vanuit externe bron en vergrendelt geïnfecteerde systemen.
    11. Malware dringt binnen vanuit externe bron en verzamelt gegevens van geïnfecteerde systemen.
    12. Gerichte malware dringt vanuit externe bron binnen tot PLC’s en voert commando’s uit die leiden tot fysieke schade.
    13. Incidenten worden niet tijdig gedetecteerd, waardoor meerdere deelsystemen beïnvloed worden door een cyberincident.
    14. Informatie over incidenten wordt niet vastgelegd, waardoor systeemherstel en extra beveiliging wordt bemoeilijkt.
    15. Bedien- of onderhoudsmedewerkers lekken met opzet vertrouwelijke informatie.
    16. Bedien- of onderhoudsmedewerkers gaan slordig met informatie om en lekken per abuis vertrouwelijke informatie.
    17. Bedien- of onderhoudsmedewerkers sluiten geïnfecteerde apparatuur aan op het interne ICT- of OT/SCADA-netwerk, waardoor OT-apparatuur wordt uitgeschakeld.
    18. Bedien- of onderhoudsmedewerkers herkennen signalen van een incident niet, of negeren deze, waardoor het incident niet (tijdig) gestopt wordt.
    19. Een niet-gecontroleerde wijziging in software of apparatuur is niet compatibel met de rest van het systeem. Hierdoor worden enkele OT-systemen niet bestuurbaar.
    20. Een niet-gecontroleerde wijziging in software of apparatuur reageert anders op verwachte (handmatige) commando’s. Hierdoor gedraagt het systeem zich anders dan de intentie van operators, wat leidt tot fysieke schade.
    21. Een niet-gecontroleerde wijziging in software of apparatuur introduceert malware of een backdoor in het systeem. Hierdoor kan OT-apparatuur door derden worden bestuurd of uitgeschakeld.
    22. Maatregelen worden intern niet voldoende nageleefd, waardoor andere risico’s worden vergroot.
    23. Maatregelen worden niet opgenomen in contracten met onderaannemers, waardoor geleverde apparatuur en stuurprogramma’s niet het vereiste beveiligingsniveau hanteren.
    24. Maatregelen worden niet nageleefd door onderaannemers, waardoor geleverde apparatuur en stuurprogramma’s niet het vereiste beveiligingsniveau hanteren.
    25. Omdat er geen terugvaloptie is, moeten systemen handmatig worden hersteld, waardoor het systeem langer onbeschikbaar is
    26. De terugvaloptie is niet voldoende beveiligd en wordt na activatie ook geïnfecteerd.
    27. De terugvaloptie is niet actueel bijgewerkt en zorgt bij activatie voor ongecontroleerde functionele wijzigingen.

    NB. Bovenstaande opsomming is bedoeld als voorbeeld en niet bedoeld om volledig te zijn.

    Op basis van bovenstaande lijst van risico’s wordt het mogelijk op basis van IEC-62443-3-2 een zogeheten nulmeting te doen en de omvang van het risiconiveau te schatten zonder het realiseren van beheersmaatregelen. Op basis van die nulmeting wordt 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 bepaald worden door de organisatie die het te realiseren object gaat beheren. Zij zullen namelijk geconfronteerd worden 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 de mogelijke maatregelen aan de orde.

    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 kwaadwillende derden. Daarin kan dan weer onderscheid gemaakt worden 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 kunnen op andere plaatsen voldoende handreikingen worden gevonden.

    De ontwerpdocumentatie (in de volle breedte en diepte) kan, als die in de verkeerde handen terecht komt, gebruikt worden om in alle rust te onderzoeken of het ontwerp zwakke plekken kent en hoe de verdediging tegen aanvallen is gerealiseerd. Daarom is het van belang om met name voor deze documentatie ook een risicoanalyse uit te voeren (en daarvoor kan dan ISO 27005 worden gehanteerd). Onderwerpen die daarbij aan de orde dienen te komen:

    • Afdoende fysieke toegangsbeveiliging van de ontwerplocaties en de werkplekken ter plekke. Met andere woorden: alleen mensen die er werken hebben toegang, anderen niet. Er zijn maatregelen getroffen die toegang van 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 op welke wijze 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 die gebruikt worden bij het maken van de ontwerpdocumentatie beveiligd?

    10.1.3 Maatregelen

    Bij het definiëren van beheersmaatregelen is het van belang altijd drie specten in het oog te houden, namelijk Mens, Organisatie en Techniek. Maatregelen hebben vaak impact op meer dan een van die aspecten, en dienen, voor het beoogde effect, in balans te 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 die sterke wachtwoorden op een briefje worden geschreven en op de monitor of onder het toetsenbord worden geplakt, waarmee de maatregel teniet wordt gedaan en het risico in feite is toegenomen.

    Mens

    Organisatie

    Techniek

    Klap uit Klap in

    10.1.4 Borging

    Borging van de maatregelen in de ontwerpfase richt zich met name op het implementeren van de cybersecurityeisen 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 geclassificeerd wordt. Gevoelige informatie dient enkel beschikbaar te zijn in een afgeschermde omgeving met toegangsbeheer. Dit is ook het geval indien er wordt gecommuniceerd met potentiële leveranciers; denk hierbij aan afspraken over de omgang met vertrouwelijke informatie en documenten. Er kunnen audits op de documentbeheersing worden uitgevoerd. Voor de algemene aspecten rondom borging, zie hoofdstuk 5.6 Borging.

    10.2 Bouw

    Deze paragraaf beschrijft op welke wijze het onderwerp cybersecurity aan de orde komt tijdens de uitvoering (bouwen) van een infrastructureel project.

    10.2.1 Taken, bevoegdheden en verantwoordelijkheden

    In deze fase is er een opdrachtgever en een opdrachtnemer. Er is in deze fase een focus op veilige toegang, netwerkbeveiliging en screening van personeel (van derden).

    Taken opdrachtgever:

    • Bewustwording en training van toekomstige bedienaars.
    • Bewustwording en training van eigen personeel.
    • Toetsen van de uitvoering van cybersecuritymaatregelen.

    Taken opdrachtnemer:

    • Risicoanalyse cybersecurity
    • Vastleggen duidelijke bevoegdheden van cybersecurityfunctionarissen. Onder welke voorwaarden kan bij een incident de uitvoering worden stilgelegd?
    • Mogelijk bouwen beveiligde testomgeving
    • Toegangsbewaking en registratie.
    • Toegangsbewaking op elke ruimte waar actieve apparatuur opgesteld staat.
    • Opstellen werkinstructie voor cybersecurity.
    • Verifiëren en valideren van gebruikersaccounts en logbestanden.
    • Doorvoeren hardening van alle IT en OT.
    • Penetratietest (laten) uitvoeren.
    • Doorzetten van cybersecurityvereisten naar leveranciers en onderaannemers.
    • Beveiligen van informatie op de bouwlocatie.

    10.2.2 Risico’s/aandachtspunten

    • Fysieke toegangsbeveiliging ontwerplocaties en werkplekken.
    • Informatie-opslag (locatie en beveiliging (wie mag wat en hoe is dit afgeschermd?).
    • Communicatierichtlijnen intern en extern.
    • Review en goedkeuringsproces (wie mag wat zien en hoe is dit geborgd, zowel voor opdrachtgever, opdrachtnemer als bevoegd gezag).
    • Beveiliging computersystemen.
    • Scheiding operationele en nieuwe situatie
      • Nieuwbouw: bijvoorbeeld verkeerscentrale en operationeel datatransmissienetwerk.
      • Renovatie/ombouw: bijvoorbeeld operationele lokale systemen.
    • Wie mag wat en hoe is dit geborgd, zowel voor inzage in als uitvoering van de testen.

    10.2.3 Maatregelen

    Mens

    Organisatie

    Techniek

    Klap uit Klap in

    10.2.4 Borging

    Tijdens de bouwfase 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 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.

    10.3 Openstelling

    In deze paragraaf wordt ingegaan op de openstellingsfase. Met ‘openstelling’ wordt bedoeld: het moment van overdragen door de projectorganisatie aan de organisatie die de exploitatie uitvoert. Projectmatig gezien gaat het over een ‘moment’, een faseovergang. Met het oog op cybersecurity wordt de openstelling als méér dan een moment gezien, omdat het projectteam zich er rekenschap van dient te geven dat het moment van openstelling en overdracht aan de beheer- en exploitatie-organisatie alleen kan slagen als dat goed voorbereid is. Voor die voorbereiding op de openstelling worden navolgend de aandachtspunten beschreven.

    10.3.1 Risico’s/aandachtspunten

    Bij de openstelling vindt de overdracht van realisatie naar exploitatie plaats, en starten ook de processen die onderdeel zijn van exploitatie en van beheer. Dit betekent dat er onder andere aandacht moet zijn voor de volgende onderwerpen:

    1. Gebruikersaccounts voor ontwikkelaars, onderhoudspersoneel en exploitatie medewerkers (operators)

    2. Wachtwoordbeheer

    3. Systeem- en fysieke toegang

    4. Het borgen en inwerking treden van het cybersecurityplan voor de exploitatiefase

    5. Het overdragen van het risicorapport uit de realisatiefase

    6. Opleidingen personeel

    7. Organisatie

    Klap uit Klap in

    10.3.2 Maatregelen

    Om de openstelling goed te laten verlopen, moet de faseovergang (van realisatie naar openstelling) zijn voorzien van de juiste voorwaarden en moeten deze als deliverable van het realisatieproject zijn vastgelegd. Een realisatieproject dient de projectresultaten in de regel over te dragen aan een beheerorganisatie, zodat het beheer kan starten op technisch-operationeel vlak. Op soortgelijke wijze kan het projectresultaat ook overgedragen worden aan de cybersecurity-beheerorganisatie. Zie hoofdstuk 4 Organisatie cybersecurity

    Mens

    Organisatie

    Techniek

    Klap uit Klap in

    10.3.3 Borging

    Cybersecurity moet in het DNA van de organisatie gaan zitten en vast onderdeel zijn van elke bespreking over het onderhoud van het object. Door een frequente update van het object-risicorapport te laten maken, wordt inzichtelijk gemaakt waar de aandacht nodig is om de cybersecurity op niveau te houden.

    11 Exploitatiefase

    Figuur 11.1: Fasen in een project.

    11.1 Inleiding

    Exploitatie

    De exploitatie is de fase na openstelling van het tunnelsysteem voor gebruik conform bestemming en openstellingsvergunning, waarin bediening en bewaking worden uitgevoerd volgens standaard procedures waarmee ook cybersecurity wordt geborgd.

    Operationeel

    De tunnel is operationeel als het tunnelsysteem in gebruik is. Een specifieke activiteit binnen de gebruiksfase 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 kan (dient) in die procedures de cybersecurity geborgd te zijn. Voor incidentele (niet-procedureel vastgelegde) onderhoudsactiviteiten dient per geval de cybersecurity geborgd te worden.

    Renovatie

    Renovatie 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 onderscheiden we twee vormen van renovatie; 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. Indien de tunnel voor langere tijd wordt afgesloten, komt de aanpak overeen met de realisatie van nieuwbouw, zie hoofdstuk 10 Realisatiefase (nieuwbouw).

    11.2 Operationele fase

    In deze paragraaf wordt ingegaan op de operationele fase van het object: de fase waarin het tunnelsysteem in gebruik is. Een specifieke activiteit binnen de gebruiksfase is het onderhoud.

    11.2.1 Taken, bevoegdheden en verantwoordelijkheden

    In deze fase is er een opdrachtgever en en een opdrachtnemer. Er is in deze fase een focus op fysieke en logische toegangsbeheer, auditing en evaluatie, en screening van personeel.

    Taken opdrachtgever:

    • Beoordelen cybersecurity-risico-analyses en cybersecurity-rapportages.
    • Jaarlijkse audit.
    • Netwerkmonitoring.
    • Incidentrespons.

    Taken opdrachtnemer:

    • Risicoanalyse cybersecurity
    • Vastleggen duidelijke bevoegdheden van cybersecurityfunctionarissen. Onder welke voorwaarden kan bij een incident een object worden stilgelegd?
    • Registreren en bewaking van fysieke en logische toegang.
    • Netwerkmonitoring, rapportage.
    • Incidentrespons.
    • Patching.
    • Aandacht voor o.a. langlopende processen, documentatie, incidenten, logbestanden, rapportages opstellen/beoordelen, risico-inschattingen herzien, etc.
    • Testen van back-up- en herstelprocedures.
    • Jaarlijkse evaluatie en rapportage.

    11.2.2 Maatregelen

    Mens

    Organisatie

    Techniek

    Klap uit Klap in

    11.2.3 Borging

    De exploitatiefase is over het algemeen de langste fase. Het is van belang dat er een duidelijke verstandhouding is tussen de betrokken partijen met concreet belegde verantwoordelijkheden. Continue beheersprocessen voor de borging van maatregelen bestaan onder andere uit rapporteren (van voorgevallen incidenten, status toegangsbeheer, etc.) en overlegstructuren. Daarnaast is van belang frequent de cybersecurity risico inschatting en het cybersecurityplan en -maatregelen te herzien. Ook kan het monitoren van systemen en netwerken en interne/externe audits op techniek en organisatie bijdragen aan de continue borging van maatregelen. Vanzelfsprekend dient voor deze activiteiten voldoende budget en kennis beschikbaar te zijn bij zowel de opdrachtgever als opdrachtnemer.

    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. Tijdens exploitatie komt daar de uitvoeren van het opleidingsplan bij. Daar waar ontwikkelingen op gebied van cybersecurity de werkprocessen raken of beïnvloeden, moet dit meegenomen worden in het lesmateriaal voor het opleidings- en trainingsplan. Voor de algemene aspecten rondom borging, zie hoofdstuk 5.6 Borging.

    11.3 Renovatie

    Deze paragraaf beschrijft de aanpak van cybersecurity indien (delen van) het tunnelsysteem korte perioden geheel gesloten en/of deels in gebruik is (zijn). Indien de tunnel voor langere tijd wordt afgesloten komt de aanpak overeen met de realisatie van nieuwbouw, zie hoofdstuk 10 Realisatiefase (nieuwbouw)

    Eerder is al aangegeven dat het realiseren van cybersecurity van een object begint met een risicoinventarisatie. Welke risico’s zijn er, welke bedreigingen, wat zijn er de consequenties als het risico optreedt, kunnen we de oorzaak wegnemen, moeten we de gevolgen beperken, enz.

    Een renovatie start in dit opzicht net zo als een nieuwbouwproject: klanteisen vaststellen, risicoinventarisatie uitvoeren, V-model doorlopen. Bij een renovatieproject komen er bij de risico-inventarisatie nog twee aspecten bij: enerzijds kan het zijn dat niet alle systeemdelen vervangen worden en anderzijds kan het zijn dat bepaalde risico’s zich niet (makkelijk) laten verkleinen vanwege ontwerpkeuzes die vroeger zijn gemaakt en nu niet (makkelijk) meer zijn aan te passen.

    11.3.1 Taken, bevoegdheden en verantwoordelijkheden

    In deze fase is er een opdrachtgever en een opdrachtnemer. Afhankelijk van de aard van de renovatie kent deze fase ook een ontwerp- en een realisatiefase, en daarnaast een te slopen deel. Er is in deze fase specifieke aandacht voor de ingewikkelde hybride situatie oud systeem/nieuw systeem.

    Taken opdrachtgever:

    • Risicoanalyse.
    • Duidelijk vaststellen wie verantwoordelijk is voor de beveiliging van de bestaande situatie (in de verschillende faseringen).

    Taken opdrachtnemer:

    • Eveneens uitvoeren van een risicoanalyse.
    • Opstellen en valideren faseovergangen van oude naar nieuwe systemen.
    • Veilige afvoer van informatiedragende componenten.
    • Focus op: veilige toegang, netwerkbeveiliging, screening van personeel (van derden).

    11.3.2 Maatregelen

    Bij renovatie zijn er twee situaties waar rekening gehouden moet worden:

    • De installaties die (deels) vervangen worden en
    • De bestaande situatie die (mogelijk) beperkingen geeft m.b.t. de gewenste nieuwe situatie.

    De te nemen maatregelen worden ook bepaald door de tijdsduur van de tunnelsluiting. Veelal is dit maatwerk en dit zal dan ook meer en complexere risico’s introduceren dan bij nieuwbouw en bij sloop.

    Mens

    Organisatie

    Techniek

    Klap uit Klap in

    11.3.3 Borging

    In de renovatiefase wordt bepaald welke systemen/installaties moeten worden gewijzigd. Veelal betreft het hier upgrades of complete vervanging van systemen. Ook uitbreidingen behoren tot de scope in deze fase.

    Tijdens deze fase wordt gewerkt volgens 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 hoofdstuk 10.2 Bouw.

    Vrijgekomen systemen/installaties dienen te worden beoordeeld op bedrijfs- en persoonsgevoelige informatie en moeten (in ieder geval voor rijkstunnels) ter vernietiging worden aangeboden aan Domeinen Roerende Zaken (DRZ). Een kwalitatief goed onderhouden IT/OT/applicatie-configuratiemanagementsysteem bevordert dit proces. Voor specifieke sloopfase aspecten zie hoofdstuk 12 Sloop.

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

    12 Sloop

    Als een infra-object wordt gesloopt, richt de cybersecurity zich met name op de wijze waarop informatie wordt vernietigd/bewaard. Als er informatie of informatiedragers worden afgedankt die veiligheidsgegevens bevatten, betekent dat een cyberrisico. Anderzijds kan ook niet alles zomaar vernietigd worden: bedrijven en overheden hebben een zekere bewaarplicht (zie regels voor overheidsarchieven en de toelichting van de Belastingdienst).

    12.1 Taken, bevoegdheden en verantwoordelijkheden

    In deze fase is er een opdrachtgever en een opdrachtnemer. Er is in deze fase een focus op veilige afvoer van informatiedragende componenten en afsluiten van externe verbindingen naar het gesloopte object.

    Taken opdrachtgever:

    • Afsluiten verbindingen naar het object.
    • Ontvangen en schonen of vernietigen van netwerkapparatuur.
    • Veilig archiveren van alle projectinformatie.
    • Verwijderen alle niet-gearchiveerde informatie (documentatie, backups, persoonsgegevens, logbestanden).

    Taken opdrachtnemer:

    • Apparatuur van het project classificeren.
    • Gegevensdragers schonen of vernietigen.
    • Apparatuur van opdrachtgever overdragen.
    • Verwijderen van alle documentatie die op het object wordt aangetroffen en deze documentatie vernietigen of overdragen aan opdrachtgever.

    12.2 Maatregelen en borging

    In (het begin van) de sloopfase is bepaald welke systemen moeten worden verwijderd. Deze systemen dienen op een professionele wijze te worden ‘ontmanteld’. Dit ontmantelen houdt in dat er een sloop/ontmantelingsplan opgesteld dient te worden dat de betrokken partijen goedkeuren. In het plan worden o.a. de volgende onderwerpen uitgewerkt.

    • Wat is 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.
    • Definieer welke onderdelen/equipment/producten (data) bedrijfs/persoonsgevoelige informatie bevatten.
    • Bepaal op welke wijze de vrijkomende materialen losgekoppeld en afgevoerd moeten worden.
    • Vrijgekomen systemen/installaties dienen beoordeeld te worden op bedrijfs- en persoonsgevoelige informatie en moeten (in ieder geval voor rijkstunnels) ter vernietiging worden aangeboden aan Domeinen Roerende Zaken (DRZ). Denk hier aan datadragers, documentatie (opdrachtnemer en onderaannemer), switches, firewalls, instellingen in OT-apparatuur en PLC’s, enz.
    • Planning (start en tijdsduur, autorisatie betrokken personeel).
    • Toezicht zowel op de fysieke locatie (loskoppelen en vervoer) en tijdens het logistieke proces t/m verschrotting.
    • Validatie d.m.v. opstellen eindrapportage.

    13 Ervaringen uit de praktijk

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

    Zie voor actuele hacks de meldingen de site van het Nationaal cybersecurity Centrum (NCSC). Ook een infographic van Indegy bevat actuele informatie.

    13.1 Gelaagde beveiliging

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

    Figuur 13.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.

    13.2 Fysieke toegangsbeveiliging

    Bevindingen

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

    Maatregelen

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

    13.3 Netwerkbeveiliging

    Bevindingen

    • Het onterechte geloof in de isolatie van het SCADA-systeem van andere netwerken maakt dat mensen onvoldoende maatregelen treffen op andere vlakken. Risico: bewustzijn 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 verbindingen tussen kantoorautomatisering en tunnelsysteem.
    • Verwijderen 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.

    13.4 Logische toegangsbeveiliging

    Bevindingen

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

    Maatregelen

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

    13.5 Anti-malware en patchen

    Bevindingen

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

    Maatregelen

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

    13.6 Signalering

    Bevindingen

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

    Maatregel

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

    13.7 Handelingsperspectief

    Bevindingen

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

    Maatregelen

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

    13.8 Back-ups en assetmanagement

    Bevindingen

    • Schone back-ups zijn er wel, maar zijn niet altijd up-to-date of direct toegankelijk. Risico: het herstel van de functie duurt onnodig lang, en de laatste wijzigingen gaan verloren.
    • Schone en recente back-ups zijn er wel, maar het herstelproces voor de hele keten is nooit geoefend. Risico: het weer operationeel krijgen van het systeem duurt onnodig lang.
    • Het assetmanagement is onvoldoende op orde. Documenten worden ad hoc soms wel en soms niet bijgewerkt en verspreid. Risico’s:
    • Als herstel of herbouw nodig is, is onvoldoende betrouwbare documentatie beschikbaar.
    • 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 1: OT vs. IT

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

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

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

    Attribuut (attribute)

    Prioriteit voor OT

    Prioriteit voor IT

    Vertrouwelijkheid (confidentiality/privacy)

    Laag

    Hoog

    Data-integriteit (message integrity)

    Zeer hoog

    Laag – medium

    Systeembeschikbaarheid (system availability)

    Zeer hoog

    Laag – medium

    Authenticatie (authentication)

    Hoog

    Medium – hoog

    Onweerlegbaarheid (non-repudiation)

    Laag – medium

    Hoog

    Veiligheid (safety)

    Zeer hoog

    Laag

    Tijdkritisch (time criticality)

    Kritisch

    Vertraging getolereerd

    Systeemuitval (system downtime)

    Onacceptabel

    Getolereerd

    Veiligheidsvaardigheden/bewustzijn (skills/awareness)

    Slecht

    Goed

    Systeemlevensduur (system lifecycle)

    15-25 jaar

    3-5 jaar

    Interoperabiliteit (interoperability)

    Kritisch

    Niet kritisch

    Rekenkracht en opslag (computing resources)

    Beperkt

    (bijna) onbeperkt

    Standaarden (standards)

    IEC 62443

    IEC 27000

    Noot:

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

    Bijlage 2: Afkortingen

    AIVD

    Algemene inlichtingen- en veiligheidsdienst

    AVG

    Algemene verordening gegevensbescherming

    BIG

    Baseline informatiebeveiliging Nederlandse gemeenten

    BIO

    Baseline informatiebeveiliging overheid

    BIR

    Baseline informatiebeveiliging Rijk

    BIWA

    Baseline informatiebeveiliging waterschappen

    CERT

    Computer emergency response team

    CMDB

    Configuration management database

    CSMS

    Cybersecuritymanagementsysteem

    CI

    Configuration item

    CIO

    Chief information officer

    CSIRT

    Computer security incident response team

    DNS

    Domain name system

    DTC

    Digital trust centre

    FME(C)A

    Failure mode, effects (and criticality) analysis

    GDPR

    General data protection regulation

    GPRS

    General packet radio service

    HF

    Hoogfrequent

    MAC-adres

    Media access control address

    MSP

    Managed service providers

    NCSC

    Nationaal cybersecuritycentrum

    NEN

    Nederlandse norm

    NIB

    Netwerk- en informatiebeveiliging

    NIS

    Network and information systems

    NiST

    National institute of standards and technology.

    IA

    Industriële automatisering

    IACS

    Industrial automation and control systems

    IBI

    Interprovinciale baseline informatiebeveiliging

    ICS

    Industrial control systems

    ICT

    Information and communication technology

    IEC

    International electrotechnical commission

    IP

    Internetprotocol

    ISAC

    Information sharing and analysis centre

    IT

    Informatietechnologie

    KA

    Kantoorautomatisering

    OT

    Operationele technologie

    PC

    Personal computer

    SCADA

    Supervisory control and data acquisition

    SIEM

    Security information and event management

    SOC

    Security operations centre

    THTC

    Team hightech crime

    UMTS

    Universal mobile telecommunications system

    USB

    Universal serial bus

    VOG

    Verklaring omtrent het gedrag

    VIR

    Voorschrift informatiebeveiliging Rijkswaterstaat

    WBP

    Wet bescherming persoonsgegevens

    Bijlage 3: Normen en richtlijnen

    Overzicht van de in het groeiboek aangehaalde op 26 november 2019 vigerende normen en richtlijnen.

    Naam

    Toelichting en link

    Cybersecurity-woordenboek

    AVG

    Algemene Gegevensbescherming

    NIB-richtlijn

    Netwerk- en informatieveiligheid

    Wbni

    Wet beveiliging netwerk- en informatiesystemen

    VIR

    Voorschrift informatiebeveiliging Rijksdienst

    VIR-BI

    Voorschrift Informatiebeveiliging Rijksdienst – Bijzondere Informatie

    Warvw

    Wet aanvullende regeling voor wegtunnels

    Rarvw

    Regeling aanvullende regeling voor wegtunnels

    Spoorwegwet

    Wet lokaal spoor

    ISO 15288

    Systems and software engineering — System life cycle processes

    Integraal projectmanagement (IPM), Rijkswaterstaat

    ISO 27001

    Information security management

    ISO 27002

    Information technology — Security techniques — Code of practice for information security controls

    Handreiking risicoanalyse, door Nationaal adviescentrum vitale infrastructuur (Navi)

    ISO 27005

    Information security risk management

    ISO 27035

    Incidentrespons

    ISO 27701

    Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management – Requirements and guidelines

    ISO 31000

    Risicomanagement

    ISO 55000

    Asset management — Overview, principles and terminology

    IEC 62443

    Standard specifies security capabilities for control system components

    Handreiking prestatiegestuurde risicoanalyses (PRA), Rijkswaterstaat

    Leidraad systems engineering

    CSIR

    Cybersecurity implementatierichtlijn objecten RWS, versie 1.04

    Werkwijzebeschrijving 00044 – Verificatie en validatie

    Federal incident reporting guidelines

    Computer security incident handling guide

    Cyber security incident response guide

    National institute of standards and technology (NIST)