Een VLAN is geen IEC 62443-segmentatiestrategie

“We hebben IT en OT gescheiden. We gebruiken VLANs.”

Dat klinkt goed, en een VLAN kan absoluut onderdeel zijn van een goede oplossing. Maar het is niet de vraag waarmee ik zou beginnen. Ik zou eerst willen weten:

Wat proberen we hier eigenlijk te beschermen?

Waarom staat deze machine in deze zone? Welke systemen moeten ermee kunnen praten? Welke data moet daar echt tussen bewegen? Wie kan van buiten naar binnen? En wat gebeurt er met de operatie als we tijdens een incident een verbinding afsluiten?

Daar begint voor mij het echte gesprek over OT-segmentatie. Niet bij VLAN 20 of VLAN 30. Bij risico.

Een VLAN vertelt waar verkeer kan worden gescheiden. Niet waarom.

Een VLAN is een technische manier om systemen logisch van elkaar te scheiden. Dat kan nuttig zijn, vaak is het zelfs nodig. Maar een VLAN vertelt niet automatisch:

• wat de kritieke functie van een systeem is;
• welke gevolgen uitval of misbruik kan hebben;
• waarom bepaalde systemen bij elkaar horen;
• welke communicatie werkelijk noodzakelijk is;
• welke leverancier toegang nodig heeft;
• of je een verbinding veilig kunt verbreken;
• hoeveel bescherming een deel van de omgeving nodig heeft.

Dat zijn geen configuratievragen. Dat zijn risico- en architectuurvragen. En precies daar worden zones en conduits uit IEC 62443 interessant.

Denk aan een gebouw, niet aan een switch

Stel je een groot gebouw voor. Je kunt overal muren neerzetten, maar meer muren maken het gebouw niet automatisch veiliger. Je wilt eerst weten:

• wat er in iedere ruimte gebeurt;
• welke ruimtes extra belangrijk zijn;
• wie er naar binnen moet;
• welke deuren noodzakelijk zijn;
• welke deur normaal dicht hoort te zijn;
• wat er gebeurt als een deur tijdens een incident op slot gaat.

Pas daarna bepaal je waar muren, deuren, sloten en toezicht nodig zijn. Voor een industriële omgeving is het principe vergelijkbaar. Een goed ontwerp begint niet met “hoeveel VLANs zullen we maken?”, maar met “welke functies, risico's en noodzakelijke verbindingen hebben we?”

Stap 1: bepaal wat je onderzoekt

IEC 62443-3-2 begint met het afbakenen van het System under Consideration. In normale taal: over welk stuk van de werkelijkheid hebben we het? Dat kan een complete fabriek zijn, een productielijn, een energie-installatie, een waterzuivering, of één machine of skid.

Die grens is belangrijk. Als niet duidelijk is wat wel en niet bij de analyse hoort, wordt het lastig om later zinvol over zones, risico of beveiliging te praten.

Stap 2: begrijp de gevolgen

Daarna komt risico. Niet alleen “kan dit systeem gehackt worden?”, maar vooral:

“Wat gebeurt er met de organisatie als dit systeem niet meer betrouwbaar of beschikbaar is?”

In OT gaat dat vaak verder dan data. Denk aan stilstand, verlies van productie, kwaliteitsproblemen, schade aan apparatuur, milieueffecten, verlies van zicht op het proces en veiligheidsrisico's.

Twee systemen kunnen technisch sterk op elkaar lijken en toch een totaal ander risicoprofiel hebben. Dat verschil moet terugkomen in de architectuur.

Stap 3: maak zones die je kunt uitleggen

Een zone is niet simpelweg een ander woord voor VLAN of subnet. Het is een logische groep assets die vanuit cybersecurity op een vergelijkbare manier behandeld moeten worden. Daar moet dus een reden achter zitten — bijvoorbeeld omdat systemen dezelfde kritieke functie ondersteunen, vergelijkbare gevolgen hebben bij uitval, vergelijkbare toegang nodig hebben of een vergelijkbare beveiligingsbehoefte kennen.

Als iemand naar de architectuur kijkt, moet de vraag “waarom zitten deze systemen samen?” een logisch antwoord hebben. Niet: “omdat ze jaren geleden zo op de switch zijn gezet.”

Eén indeling is niet vrijblijvend: safety-gerelateerde systemen horen in hun eigen zone. 62443-3-2 behandelt die apart, en dat is geen formaliteit — een veiligheidsfunctie die afhankelijk raakt van een gewone procesverbinding is een ander soort risico dan een stilstaande lijn.

Stap 4: breng de noodzakelijke dataflows in kaart

Hier gaat het in veel netwerkdiagrammen mis. Er staat een lijn tussen twee vakken, misschien staat er zelfs een firewall tussen, maar niemand kan nog precies uitleggen waarom die lijn nodig is.

Daarom wil ik naast zones ook de noodzakelijke dataflows kennen. Voor iedere belangrijke flow wil je bijvoorbeeld weten:

• welk systeem of welke zone de communicatie start;
• waar de communicatie naartoe gaat;
• welke informatie of functie nodig is;
• in welke richting de data gaat;
• waarom de communicatie nodig is;
• wanneer of hoe vaak die nodig is;
• wat er operationeel gebeurt als de flow wegvalt.

Het verschil lijkt klein, maar is fundamenteel. Technisch: `VLAN 30 mag communiceren met VLAN 40.` Operationeel: `Production Zone A stuurt procesinformatie naar OT Operations zodat operators het proces kunnen monitoren.`

Het eerste vertelt wat technisch mogelijk is. Het tweede vertelt wat noodzakelijk is.

Een firewallregel vertelt wat mogelijk is. Een dataflow vertelt wat noodzakelijk is.

Als je dat onderscheid kent, kun je veel beter bepalen wat je wilt toestaan en wat juist niet nodig is.

Stap 5: gebruik conduits om noodzakelijke communicatie te beheersen

Zones staan bijna nooit volledig op zichzelf. Monitoring, engineering, rapportage en onderhoud vragen om communicatie tussen delen van de omgeving. IEC 62443 gebruikt hiervoor het begrip conduits: de gecontroleerde communicatie tussen zones waarvoor vergelijkbare beveiligingseisen gelden.

Een conduit is dus niet automatisch één firewall, één kabel, één VLAN of één protocol. Die technologie kan onderdeel zijn van de implementatie, maar de vraag komt eerst: welke communicatie moet bestaan en hoe willen we die beheersen?

Stap 6: bepaal hoeveel bescherming een zone nodig heeft

Hier komt 62443-3-3 binnen, en dit is de stap die in de meeste tekeningen ontbreekt. Zones en conduits zeggen wat er bij elkaar hoort en wat er tussen beweegt; ze zeggen nog niets over hoe stevig het moet zijn.

62443-3-3 beschrijft systeemeisen, gegroepeerd in zeven foundational requirements — onder andere identificatie en authenticatie, gebruikscontrole, systeemintegriteit, beperkte datastroom, tijdige respons op gebeurtenissen en beschikbaarheid van de resource. Aan die eisen hangen security levels.

Het nuttige daarvan is dat je per zone een target security level (SL-T) kunt vaststellen op basis van het risico uit stap 2, en dat vervolgens kunt afzetten tegen wat de omgeving vandaag daadwerkelijk kan. Dat verschil is je werklijst, en het is een stuk concreter dan “we moeten iets met segmentatie”.

Een zone met een stilstaande verpakkingslijn en een zone met een veiligheidsfunctie horen niet op hetzelfde niveau uit te komen. Als ze dat wel doen, is er ergens niet nagedacht — of is er te veel beveiligd op een plek waar dat alleen complexiteit oplevert.

Hoe ziet dat er dan uit?

Er bestaat geen universele IEC 62443-netwerkarchitectuur. Een fabriek, luchthaven, schip, waterbedrijf en energie-installatie hebben andere processen en andere risico's. Maar een vereenvoudigde tekening kan het principe duidelijk maken.

De pijlen tussen de zones zijn geen decoratie. Daar horen de noodzakelijke dataflows bij:

• DF-01 — procesmonitoring: productiezones naar OT Operations, en van daaruit naar de industriële DMZ;
• DF-02 — bedrijfsrapportage: industriële DMZ naar Business IT;
• DF-03 — engineering en onderhoud: OT Operations naar een geautoriseerde productiezone;
• DF-04 — leveranciersonderhoud: externe leverancier via gecontroleerde toegang naar een geautoriseerd OT-doel.

Niet omdat IEC 62443 voorschrijft dat iedere omgeving precies deze flows moet hebben. Maar omdat iedere belangrijke verbinding een duidelijke reden moet hebben.

De leverancier moet ook op de tekening staan

Remote access is geen voetnoot. Een leverancier kan noodzakelijk zijn om een installatie te onderhouden, maar remote access creëert ook een route van buiten naar binnen. Daarom is “we gebruiken MFA op de VPN” niet het einde van het gesprek. Ik wil ook weten:

• welke zone de leverancier mag bereiken;
• welke systemen bereikbaar zijn;
• wanneer toegang mogelijk is;
• wie toestemming geeft;
• hoe activiteiten zichtbaar worden;
• hoe toegang onmiddellijk kan worden ingetrokken;
• wie we bellen als er iets misgaat;
• wat we doen als de leverancier zelf niet beschikbaar is.

Als de leverancier technisch overal bij kan omdat dat ooit handig was, zegt een nette VLAN-tekening weinig over het werkelijke risico. Hoe dat in de praktijk uitpakt staat in ons artikel over de Cyberbeveiligingswet, AI en OT.

Een mooie tekening kan nog steeds een slechte architectuur beschrijven

Architectuurdiagrammen kunnen overtuigend ogen: kleurvlakken, firewalls, een DMZ, VLAN-nummers, pijlen. Maar ik zou er een paar eenvoudige vragen naast leggen. Waarom bestaat deze zone? Waarom zitten deze systemen samen? Welke data moet tussen deze zones bewegen, en waarom is die flow noodzakelijk? Welk risico beheersen we ermee? En wat gebeurt er als we die verbinding blokkeren?

Als niemand daar een goed antwoord op heeft, hebben we vooral een nette netwerkplaat. Nog geen risicogedreven security-architectuur.

Pak je huidige OT-tekening erbij

Je hoeft niet te wachten op een groot programma. Pak je huidige architectuur- of netwerkdiagram en loop er deze vragen langs:

1. Is duidelijk wat we precies proberen te beschermen?
2. Kunnen we uitleggen waarom systemen in dezelfde zone zitten?
3. Zijn IT en OT bewust van elkaar gescheiden en is noodzakelijke communicatie bekend?
4. Zitten safety-gerelateerde functies in een eigen zone?
5. Hebben we de noodzakelijke dataflows tussen zones expliciet in kaart gebracht?
6. Kunnen we voor iedere belangrijke flow uitleggen wie met wie communiceert, welke functie nodig is en waarom?
7. Weten we per zone welk beschermingsniveau we willen, en hoe ver we daarvan af zitten?
8. Is externe en leverancierstoegang zichtbaar en beheerst?
9. Weten we wat er operationeel gebeurt wanneer een verbinding wegvalt?
10. Bestaat er communicatie waarvoor niemand meer een geldige reden kan uitleggen?

Die laatste vraag levert soms het interessantste gesprek op. Historisch bestaande communicatie is niet automatisch noodzakelijke communicatie.

Het doel is niet zoveel mogelijk segmentatie

Meer zones is niet automatisch beter. Meer firewalls is niet automatisch beter. Meer regels is niet automatisch beter. Complexiteit kan zelf een risico worden.

Het doel is een omgeving ontwerpen waarin je kunt uitleggen wat je beschermt, waarom assets bij elkaar horen, welke communicatie noodzakelijk is, wat de gevolgen zijn als die communicatie wegvalt, en welke beveiliging past bij het risico.

Een VLAN kan daar uitstekend onderdeel van zijn. Een firewall ook. Een DMZ ook. Maar de technologie volgt op de risicobeslissing, niet andersom.

Dus wanneer iemand zegt: “onze OT is gesegmenteerd, we hebben VLANs”, is mijn vervolgvraag: “mooi. Kun je me uitleggen waarom de zones en dataflows zo zijn ontworpen?” Daar begint het interessante gesprek.

Over de Quick Check

De CyberBusters Zones & Conduits Architecture Quick Check is een praktische gesprekstool. Het is geen IEC 62443-certificering, geen conformiteitsbeoordeling en geen vervanging voor een formele risicoanalyse.

IEC 62443-3-2 behandelt onder andere het afbakenen van het System under Consideration, cybersecurity-risicoanalyse, het opdelen in zones en conduits, verdere risicoanalyse en het bepalen en documenteren van passende beveiligingseisen. IEC 62443-3-3 beschrijft de systeemeisen en de bijbehorende security levels.

Van architectuur naar implementatie

Zones, conduits en dataflows zijn één deel van het geheel. De volgende stap is risico, beveiligingseisen, leveranciers, governance en lifecycle samenbrengen tot een uitvoerbaar IEC 62443-programma. Wie dat gestructureerd wil leren, kan terecht bij de PECB ISA/IEC 62443 Lead Implementer.

Verder lezen

• IEC 62443-3-2 — security risk assessment for system design
• IEC 62443-3-3 — system security requirements and security levels
• ISA — ISA/IEC 62443 series of standards
• CyberBusters — De Cyberbeveiligingswet geldt. Maar weet je wat je moet doen als het misgaat?