Wat is een SOC voor OT? Securitymonitoring voor industriële systemen

Of je nu een productielocatie, een drinkwaterbedrijf, een waterschap of een energienet beheert: een SOC voor OT brengt securitymonitoring naar de procesautomatisering, zonder de veiligheid of de productie in gevaar te brengen.

Wat doet een SOC voor OT?

Een SOC voor OT doet hetzelfde werk als elk security operations center (zien, detecteren, reageren en verbeteren), maar in een omgeving waar de “endpoints” PLC’s, RTU’s, HMI’s, engineeringwerkstations en historians zijn.

1. Zicht. Bouw en onderhoud een inventaris van OT-assets, hun firmware en hun communicatierelaties, grotendeels op basis van passief afgeluisterd netwerkverkeer.
2. Detectie. Herken gedrag dat wijst op een aanval of een gevaarlijke wijziging: een nieuwe engineeringverbinding naar een PLC, een onverwachte programmadownload, een schrijfactie op een veiligheidsrelevante parameter of een bekend patroon van ICS-malware.
3. Respons. Beoordeel alerts met kennis van het proces, schaal op naar de controlekamer en coördineer beheersmaatregelen die de veiligheid en de productie niet in gevaar brengen.
4. Verbetering. Vertaal lessen terug naar segmentatie, regels voor remote access, detectie-use-cases en het risicoregister van de organisatie.

Welke systemen bewaakt een OT-SOC?

De scope beschrijf je meestal met het Purdue-model. Een OT-SOC richt zich vooral op niveau 1 tot en met 3 en op de industriële DMZ: daar wordt een aanval op besturingssystemen zichtbaar in het netwerk.

Typische bronnen van telemetrie zijn:

• Passieve netwerksensoren op SPAN-poorten of netwerk-TAPs tussen niveau 1–2, 2–3 en bij de industriële DMZ. Ze decoderen industriële protocollen zoals Modbus/TCP, S7comm, PROFINET, EtherNet/IP, DNP3, IEC 60870-5-104, IEC 61850 en OPC UA.
• Logs van Windows-systemen in het OT-netwerk: HMI’s, engineeringwerkstations, historians en domeincontrollers in het OT-domein.
• Firewalls, datadiodes en remote-access-gateways die de verbindingen tussen zones bewaken (in termen van IEC 62443: de conduits).
• Wijzigings- en onderhoudsinformatie van de procesvoering, zodat een geplande PLC-download niet wordt aangezien voor een aanval.

Hoe verschilt een OT-SOC van een IT-SOC?

De tooling lijkt op elkaar (een SIEM, casemanagement, threat intelligence), maar de prioriteiten zijn omgekeerd. In IT staat vertrouwelijkheid meestal voorop en wordt een besmette laptop binnen enkele minuten geïsoleerd. In OT gaan beschikbaarheid en veiligheid voor, en het isoleren van de verkeerde controller kan een productielijn stilleggen of een gevaarlijke situatie veroorzaken.

De verschillen werken we verder uit in IT-SOC vs OT-SOC.

Wat detecteert een OT-SOC?

Goede OT-detectie combineert drie benaderingen: baselines van assets en gedrag (wat praat normaal met wat, en hoe), dreigingsgestuurde use-cases die zijn gekoppeld aan MITRE ATT&CK for ICS, en bekende indicatoren uit ICS-specifieke threat intelligence. Voorbeelden van use-cases met veel waarde:

• T0843 Program Download naar een PLC buiten een onderhoudsvenster.
• T0836 Modify Parameter op setpoints of alarmgrenzen.
• T0855 Unauthorized Command Message, zoals een stopcommando vanaf een onverwacht systeem.
• T0886 Remote Services die een leveranciersaccount op een ongebruikelijk tijdstip gebruikt.
• T0846 Remote System Discovery: netwerkscans binnen het besturingsnetwerk.

Hoe werkt incidentrespons in OT?

Incidentrespons in OT volgt dezelfde levenscyclus als in IT (voorbereiden, identificeren, beheersen, verwijderen, herstellen, leren), maar elke stap stem je af met de mensen die het proces draaien. Het DFIR-raamwerk voor OT van NIST (NISTIR 8428) is een bruikbare referentie.

In de praktijk betekent dit: per locatie een vast aanspreekpunt in de controlekamer, vooraf afgesproken beheersopties per zone (bijvoorbeeld de remote-accessverbinding dichtzetten in plaats van een controller isoleren), communicatie via een alternatief kanaal en geverifieerde back-ups van PLC-programma’s en configuraties.

Welke SOC-modellen zijn er voor OT?

Onderzoekers van SINTEF en NTNU onderscheiden vijf modellen: een geïntegreerd IT/OT-SOC, een apart OT-SOC, een intern SOC, een uitbesteed (managed) SOC en een SOC dat wordt beheerd door de leverancier van de automatisering. Veel organisaties combineren modellen, bijvoorbeeld een intern IT-SOC met een managed OT-detectiedienst. De juiste keuze hangt af van het aantal locaties, de beschikbare OT-kennis en de wettelijke verplichtingen.

Welke wetten en normen vragen om OT-monitoring?

• De Cyberbeveiligingswet (Cbw), de Nederlandse invulling van NIS2, verplicht essentiële en belangrijke entiteiten tot een zorgplicht met onder meer incidentafhandeling, en tot het melden van significante incidenten met een vroegtijdige waarschuwing binnen 24 uur. Lees wat de Cyberbeveiligingswet betekent voor OT-monitoring.
• NIS2 (Richtlijn (EU) 2022/2555) is de Europese basis onder de Cbw en de vergelijkbare wetten in andere lidstaten.
• IEC 62443-3-3 bevat systeemeisen voor auditlogs en continue monitoring (SR 6.1 en SR 6.2).
• NIST SP 800-82 Rev. 3 beveelt continue monitoring en een OT-specifieke incidentresponscapaciteit aan.

Hoe begin je met een SOC voor OT?

1. Maak afspraken over scope en eigenaarschap tussen IT-security en de procesvoering, inclusief wie beslist over beheersmaatregelen.
2. Breng het netwerk in kaart volgens de Purdue-niveaus en de zones en conduits van IEC 62443, en kies de sensorlocaties.
3. Zet passieve monitoring in, eerst op de meest kritieke verbindingen, en bouw de asset-inventaris op.
4. Definieer een eerste set use-cases (10–20) gekoppeld aan MITRE ATT&CK for ICS, met responsplaybooks per locatie.
5. Kies een operating model (intern, managed of hybride) en test het met een tabletop-oefening waar de controlekamer aan meedoet.