Wat is firewallregelbeheer?
Firewallregelbeheer is het proces waarmee een organisatie de regels van haar firewalls ontwerpt, documenteert, wijzigt, periodiek herbeoordeelt en opruimt, zodat alleen het verkeer wordt doorgelaten dat aantoonbaar nodig is. In een OT-omgeving gaat het vooral om de regels op de grenzen tussen zones: tussen kantoornetwerk en IDMZ, tussen IDMZ en procesnetwerk, en tussen productiecellen onderling. Een firewall is maar zo sterk als zijn regelset; een slecht beheerde regelset maakt van een dure industriële firewall een open deur.
🧠 Waarom vervallen firewallregels in de loop der tijd?
Een regelset begint meestal overzichtelijk, maar groeit met elk project, elke storing en elke leverancier die “even” toegang nodig heeft. Na vijf tot tien jaar telt een OT-firewall vaak honderden regels waarvan niemand meer weet waarom ze bestaan. Veelvoorkomende oorzaken:
- Regelwildgroei (rule bloat) — nieuwe regels worden toegevoegd, oude worden nooit verwijderd
- Any-any-regels — tijdens inbedrijfname of een storing wordt “alles open” gezet om snel verder te kunnen
- Tijdelijke regels die blijven — een regel voor een leverancier of FAT krijgt geen einddatum en wordt vergeten
- Ongedocumenteerde regels — geen eigenaar, geen ticket, geen reden; niemand durft ze te verwijderen
- Overschaduwde en dubbele regels — een bredere regel hoger in de lijst maakt een specifiekere regel overbodig
Het gevolg is een groter aanvalsoppervlak, trage audits en een regelset die bij een incident niet meer te doorgronden is.
🎯 Welke principes gelden voor een goede regelset?
| Principe | Betekenis in de praktijk |
|---|---|
| Default deny | Alles is geblokkeerd tenzij een regel het expliciet toestaat; de laatste regel is altijd deny all met logging |
| Least privilege | Zo specifiek mogelijk: vaste bron- en doel-IP, één poort, één richting, waar mogelijk één functie |
| Per conduit | Regels worden gegroepeerd per conduit uit het zones-en-conduits-model, niet per firewall-interface |
| Zakelijke rechtvaardiging | Elke regel heeft een beschrijving, een eigenaar, een wijzigingsnummer en zo nodig een vervaldatum |
| Geen directe IT-naar-OT-verbindingen | Verkeer tussen kantoor en proces loopt altijd via een DMZ of IDMZ |
Deze principes zijn geen modegril, maar staan in de normen. IEC 62443-3-3 eist in SR 5.2 zone boundary protection, met als verplichte uitbreiding (RE 1) deny by default, allow by exception vanaf security level 2. NIST SP 800-41 Rev. 1 (2009) beveelt default deny al jaren aan voor elke firewall, en NIST SP 800-82 Rev. 3 (2023) adviseert een DMZ-architectuur zodat verkeer nooit rechtstreeks tussen kantoor- en OT-netwerk loopt.
🏭 Wat is er anders aan firewallregels in OT?
In IT volstaat een regel op poortniveau vaak. In OT niet: één open poort kan het hele proces raken. Wie TCP 502 openzet voor Modbus TCP, staat zowel het uitlezen van registers als het schrijven van setpoints toe. Daarom gebruikt OT steeds vaker protocolfiltering met deep packet inspection:
- Modbus — alleen leesfuncties (functiecode 01–04) toestaan vanuit de historian, schrijffuncties (05, 06, 15, 16) alleen vanaf het engineeringstation
- OPC UA — standaard TCP 4840, bij voorkeur alleen met versleutelde sessies en vaste client-certificaten
- S7comm — TCP 102; een DPI-firewall kan functies als CPU stop of het downloaden van programmablokken blokkeren voor alles behalve het engineeringstation
Daarnaast speelt beschikbaarheid. Een te strenge regel die een SCADA-poll blokkeert, stopt de productie. Wijzigingen worden daarom vaak eerst in monitor mode (alleen loggen) getest voordat ze blokkeren. Een next-gen firewall of industriële firewall met OT-protocolkennis is hiervoor nodig; een klassieke stateful firewall ziet alleen adressen en poorten.
🔧 Hoe ziet een regeltabel per conduit eruit?
Hieronder een voorbeeld voor de conduit tussen de IDMZ en zone Productielijn 2:
| # | Bron | Doel | Service | Actie | Rechtvaardiging | Eigenaar | Vervalt |
|---|---|---|---|---|---|---|---|
| 1 | Historian-replica (IDMZ) | SCADA-server L2 | TCP 4840, OPC UA, alleen lezen | Toestaan | Procesdata naar kantoorrapportage | OT-architect | — |
| 2 | Jumpserver (IDMZ) | Engineeringstation L2 | TCP 3389 | Toestaan | Onderhoud op afstand, met MFA | OT-beheer | — |
| 3 | Engineeringstation L2 | PLC’s lijn 2 | TCP 102, S7comm incl. download | Toestaan | Programmawijzigingen via MOC | Procestechnoloog | — |
| 4 | Leverancier-VPN (IDMZ) | PLC 2.4 | TCP 502, Modbus FC 03 | Toestaan | Inbedrijfname nieuwe dosering | Projectleider | 31-12-2026 |
| 5 | Any | Any | Any | Weigeren + loggen | Default deny | — | — |
Regel 4 laat zien hoe een tijdelijke regel hoort: smal, met een eigenaar en met een vervaldatum.
🛠️ Hoe richt u een periodieke review in?
- Inventariseer — exporteer alle regels per firewall en koppel ze aan de conduits uit uw risicobeoordeling volgens IEC 62443-3-2
- Verzamel treffertellers (hit counts) — kijk over minimaal 90 dagen; in OT liefst langer, omdat sommige verbindingen alleen bij een jaarlijkse stop voorkomen
- Analyseer — markeer ongebruikte, overschaduwde, dubbele en te ruime regels (any-bron, any-poort)
- Hercertificeer — leg elke regel voor aan de eigenaar: nog nodig, aanpassen of verwijderen? Regels zonder eigenaar worden kandidaat voor verwijdering
- Verwijder gefaseerd — eerst uitschakelen of op loggen zetten, pas na een veilige periode echt verwijderen
- Rapporteer — leg de uitkomst vast als bewijs voor audits onder NIS2 en de Cyberbeveiligingswet, die sinds 15 augustus 2026 van kracht is
Ter vergelijking: de betaalkaartnorm PCI DSS 4.0.1 eist in eis 1.2.7 een review van de configuratie van netwerkbeveiligingsmaatregelen minstens elke zes maanden. Voor OT is geen vaste termijn voorgeschreven, maar minimaal jaarlijks reviewen is gangbare praktijk, plus een extra review na elke grote ombouw.
🔄 Hoe hangt firewallregelbeheer samen met change management?
Elke nieuwe of gewijzigde regel loopt via change management, in de procesindustrie vaak via Management of Change (MOC). Een goed wijzigingsverzoek bevat bron, doel, service, conduit, rechtvaardiging, eigenaar, einddatum en een terugvalplan. De OT-verantwoordelijke beoordeelt de impact op het proces, security beoordeelt het risico. Na uitvoering wordt de regelset als nieuwe baseline opgeslagen in het configuratiebeheer, zodat afwijkingen later direct opvallen. Wijzigingen buiten het proces om, bijvoorbeeld ‘s nachts tijdens een storing, worden achteraf alsnog als noodwijziging geregistreerd.
🧰 Welke tools en metrieken helpen?
| Toolcategorie | Wat het doet |
|---|---|
| Firewall policy management | Regelsets van meerdere merken centraal analyseren, wijzigingen automatiseren en auditrapporten maken |
| Analyse van treffertellers | Laat zien welke regels nooit verkeer zien |
| Detectie van overschaduwde en dubbele regels | Vindt regels die door een andere regel overbodig zijn |
| Logging naar SIEM | Geweigerd verkeer en wijzigingen zichtbaar maken voor het OT SOC |
Bruikbare metrieken zijn: het aantal regels per conduit, het percentage regels met eigenaar en rechtvaardiging (doel: 100%), het aantal any-regels (doel: nul), het aantal verlopen tijdelijke regels en het percentage regels dat binnen de reviewtermijn is hercertificeerd.
❓ Veelgestelde vragen
Hoe vaak moet u firewallregels in OT reviewen?
Gangbare praktijk is om firewallregels in OT minimaal eenmaal per jaar te reviewen, en daarnaast na elke grote wijziging van de installatie. De betaalkaartnorm PCI DSS schrijft zelfs elke zes maanden voor. IEC 62443 schrijft geen vaste termijn voor, maar verwacht wel dat zonegrenzen aantoonbaar beheerd worden.
Wat is een any-any-regel en waarom is die gevaarlijk?
Een any-any-regel staat verkeer toe van elke bron naar elk doel op elke poort. Zo’n firewallregel heft de segmentatie tussen zones volledig op. In OT ontstaan ze vaak tijdelijk tijdens inbedrijfname en blijven ze daarna onopgemerkt staan.
Wat is een overschaduwde firewallregel?
Een overschaduwde firewallregel staat lager in de regelset dan een bredere regel die hetzelfde verkeer al afhandelt. Daardoor wordt de overschaduwde regel nooit geraakt. Zulke regels vervuilen de regelset en kunnen bij herschikking onverwacht actief worden.
Kan een gewone firewall Modbus-schrijfopdrachten blokkeren?
Nee, een gewone stateful firewall ziet alleen IP-adressen en poorten en kan Modbus-lezen niet van Modbus-schrijven onderscheiden. Daarvoor is een industriële firewall met deep packet inspection nodig. Die kan per functiecode, bijvoorbeeld 03 lezen of 16 schrijven, verkeer toestaan of weigeren.
Wie is eigenaar van een firewallregel?
De eigenaar van een firewallregel is de persoon of afdeling die de zakelijke behoefte aan de verbinding heeft, niet de netwerkbeheerder die de regel invoert. De eigenaar bevestigt bij elke review dat de regel nog nodig is. Regels zonder eigenaar zijn kandidaat voor verwijdering.
Mag het kantoornetwerk rechtstreeks met het OT-netwerk communiceren?
Nee, goede praktijk volgens IEC 62443 en NIST SP 800-82 is dat er geen directe verbindingen tussen kantoor- en OT-netwerk bestaan. Al het verkeer eindigt in een DMZ of IDMZ, bijvoorbeeld op een historian-replica of jumpserver. De firewallregels dwingen deze scheiding af.
📌 Samengevat
Firewallregelbeheer zorgt dat elke regel tussen OT-zones smal, gedocumenteerd, eigenaar-gebonden en periodiek hercertificeerd is. Met default deny, regels per conduit, protocolfiltering en een vast reviewproces blijft de segmentatie uit IEC 62443 ook na jaren effectief.