Productieomgevingen worden steeds sterker verbonden met kantoor-IT, cloudplatformen, leveranciers en remote-accessoplossingen. Daardoor kunnen aanvallen die in de IT-omgeving beginnen uiteindelijk ook PLC’s, SCADA-systemen, HMI’s en andere operationele technologie bereiken. Een SOC voor OT helpt deze dreigingen continu te signaleren en te onderzoeken, zonder de beschikbaarheid en veiligheid van industriële processen uit het oog te verliezen.
Een traditioneel Security Operations Center kan hiervoor niet zonder meer worden gekopieerd. OT vraagt om andere databronnen, andere kennis en vooral andere afspraken over incident response. Waar een IT-team een laptop relatief eenvoudig kan isoleren, kan het uitschakelen van een OT-asset een productielijn stilleggen of een onveilige situatie veroorzaken.
Wat is een SOC voor OT?
Een SOC voor OT, ook wel OT-SOC of IT/OT-SOC genoemd, is een Security Operations Center dat operationele technologie continu monitort op cyberdreigingen. Het SOC combineert mensen, processen en technologie om verdachte activiteiten te detecteren, te onderzoeken en volgens vooraf afgesproken procedures op te volgen.
De monitoring kan onder andere betrekking hebben op industriële netwerken, SCADA-omgevingen, PLC’s, HMI’s, engineering workstations, historians, remote-accessverbindingen en de koppelingen tussen IT en OT. Het doel is niet alleen om een cyberaanval te herkennen, maar ook om de mogelijke gevolgen voor productie, veiligheid en continuïteit correct in te schatten.
Waarom is een regulier IT-SOC niet voldoende?
IT en OT hebben verschillende prioriteiten. Binnen traditionele IT-security staan vertrouwelijkheid, integriteit en beschikbaarheid centraal. In OT wegen veiligheid en beschikbaarheid vaak nog zwaarder. Een onjuiste responsactie kan immers niet alleen data of systemen raken, maar ook fysieke processen beïnvloeden.
Een effectief SOC voor OT houdt rekening met onder meer:
- Lange levenscycli: industriële systemen blijven soms tientallen jaren actief en kunnen niet altijd worden gepatcht.
- Productiecontinuïteit: onderhoud en wijzigingen moeten vaak binnen beperkte onderhoudsvensters plaatsvinden.
- Legacy-systemen: oude besturingssystemen en protocollen ondersteunen moderne beveiligingsmaatregelen niet altijd.
- Industriële protocollen: verkeer via bijvoorbeeld Modbus, OPC UA, Profinet of DNP3 vraagt gespecialiseerde interpretatie.
- Veiligheidsrisico’s: isolatie of uitschakeling kan gevolgen hebben voor medewerkers, machines en omgeving.
- Leverancierstoegang: externe partijen hebben regelmatig remote access nodig voor onderhoud.
Een generieke alert is daarom onvoldoende. Een analist moet begrijpen om welk asset en proces het gaat, welke communicatie normaal is en welke actie veilig kan worden uitgevoerd.
Welke onderdelen monitort een OT-SOC?
Goede OT-monitoring begint met zichtbaarheid. Veel organisaties hebben geen volledig actueel overzicht van alle industriële assets, firmwareversies, verbindingen en afhankelijkheden. Het SOC moet daarom niet alleen alerts verzamelen, maar ook voldoende context opbouwen om afwijkingen te kunnen beoordelen.
Veelgebruikte databronnen zijn:
- passief verzameld netwerkverkeer uit OT-segmenten;
- industriële firewalls en netwerkcomponenten;
- jumpservers en remote-accessplatformen;
- engineering workstations en beheersystemen;
- identity- en authenticatielogs;
- EDR-telemetrie van geschikte Windows- en Linux-systemen;
- SIEM-data uit de IT-omgeving;
- cloud- en leveranciersverbindingen;
- assetinventarisaties en configuratiewijzigingen.
Daarmee kan het SOC bijvoorbeeld onverwachte verbindingen tussen IT en OT, nieuwe apparaten, mislukte inlogpogingen, afwijkend protocolgebruik, ongeautoriseerde configuratiewijzigingen en verdachte remote-accesssessies detecteren.
Waarom passieve monitoring belangrijk is
In kantooromgevingen worden kwetsbaarheidsscans en actieve netwerkdetectie breed toegepast. In OT kan actief scannen echter ongewenste belasting of storingen veroorzaken, vooral bij oudere of gevoelige apparatuur. Daarom wordt vaak gestart met passieve monitoring.
Bij passieve monitoring wordt bestaand netwerkverkeer geobserveerd zonder de industriële assets zelf actief te benaderen. Hierdoor ontstaat inzicht in apparaten, communicatiepatronen en afwijkingen, terwijl de impact op het productieproces beperkt blijft. Actieve validatie kan nog steeds nodig zijn, maar gebeurt gecontroleerd en in overleg met OT-verantwoordelijken.
Lees voor de bredere beveiligingsmaatregelen ook de uitleg over OT-security.
IT- en OT-signalen moeten samenkomen
Een aanval op een productieomgeving begint lang niet altijd direct bij een PLC. Aanvallers kunnen binnenkomen via phishing, gestolen accounts, een kwetsbare VPN, een leverancier of een onvoldoende beveiligd endpoint. Vervolgens proberen zij zich vanuit IT richting OT te bewegen.
Wanneer IT- en OT-monitoring volledig gescheiden zijn, ontbreekt een deel van het aanvalspad. Een mislukte inlogpoging in de OT-omgeving lijkt op zichzelf misschien onschuldig. In combinatie met een gecompromitteerd beheerdersaccount, verdachte endpointactiviteit en verkeer richting een OT-jumpserver ontstaat een ander risicobeeld.
Een geïntegreerd IT/OT-SOC correleert daarom identity-, endpoint-, firewall-, cloud- en OT-netwerkdata. Zo krijgen analisten niet alleen een losse melding, maar de context die nodig is om een incident te prioriteren.
Praktische detectiescenario’s voor een OT-SOC
Detectieregels moeten aansluiten op de processen en risico’s van de specifieke omgeving. Een standaardset met IT-use-cases is niet voldoende. Relevante OT-use-cases zijn bijvoorbeeld:
- een nieuw of onbekend apparaat binnen een OT-zone;
- communicatie tussen netwerksegmenten die normaal niet met elkaar praten;
- een engineering workstation dat buiten een onderhoudsvenster verbinding maakt;
- een onverwachte wijziging aan PLC-logica of configuratie;
- remote access vanuit een ongebruikelijk land, tijdstip of account;
- gebruik van industriële protocollen door een onbekende bron;
- laterale beweging vanaf een IT-systeem richting de OT-DMZ;
- malware of ransomware op een systeem met toegang tot productie;
- plotselinge veranderingen in netwerkgedrag of datavolume;
- pogingen om logging, beveiligingssoftware of accounts uit te schakelen.
De kwaliteit van een use-case hangt af van de context. Het SOC moet weten welke assets kritiek zijn, welke leveranciers toegang hebben, wanneer onderhoud plaatsvindt en welke verbindingen bij het normale proces horen.
Hoe werkt incident response in een OT-omgeving?
Detectie heeft weinig waarde wanneer onduidelijk is wat er na een bevestigde dreiging moet gebeuren. Tegelijkertijd kan een standaard IT-respons, zoals direct isoleren of uitschakelen, in OT te risicovol zijn. Daarom moeten technische en operationele teams vooraf gezamenlijke playbooks vastleggen.
Een OT-incident wordt doorgaans in deze volgorde behandeld:
- Valideren: controleer of de melding werkelijk verdacht is en welke systemen betrokken zijn.
- Context bepalen: breng het productieproces, de kritikaliteit en mogelijke veiligheidsimpact in kaart.
- OT-verantwoordelijken betrekken: stem af met operations, proceseigenaren en waar nodig de leverancier.
- Veilige containment kiezen: beperk de aanval zonder ongecontroleerde productieverstoring.
- Bewijs veiligstellen: verzamel relevante logs, netwerkdata en systeeminformatie.
- Herstellen en monitoren: herstel gecontroleerd en bewaak de omgeving op terugkeer van de dreiging.
- Evalueren: verbeter detectieregels, segmentatie en procedures op basis van het incident.
Voor iedere kritieke use-case moet duidelijk zijn wie beslissingsbevoegd is. Een SOC-analist kan een dreiging vaststellen en een maatregel adviseren, maar het stilleggen van een productieproces vraagt meestal toestemming van de verantwoordelijke organisatie.
De rol van segmentatie en het Purdue-model
Monitoring werkt het beste wanneer de OT-architectuur logisch is ingericht. Segmentatie beperkt welke systemen met elkaar kunnen communiceren en maakt afwijkend verkeer beter herkenbaar. Veel industriële organisaties gebruiken hiervoor zones en conduits, vaak in combinatie met het Purdue-model.
Een Industrial DMZ vormt daarbij een gecontroleerde laag tussen kantoor-IT en productie. Systemen zoals jumpservers, updatevoorzieningen en data-uitwisseling kunnen hier worden geplaatst. Het SOC bewaakt vervolgens de verkeersstromen tussen de zones en signaleert wanneer verbindingen afwijken van het ontwerp.
Segmentatie en monitoring versterken elkaar: segmentatie verkleint het aanvalsvlak, terwijl monitoring zichtbaar maakt of de ingestelde grenzen worden omzeild of misbruikt.
Helpt een OT-SOC bij NIS2 en IEC 62443?
Een OT-SOC maakt een organisatie niet automatisch compliant. Continue monitoring, incidentdetectie, logging, escalatie en rapportage ondersteunen echter wel verschillende eisen rond risicobeheersing en incidentafhandeling.
Voor organisaties die onder NIS2 vallen, helpt een SOC om incidenten sneller te herkennen en informatie voor onderzoek en melding beschikbaar te maken. IEC 62443 biedt daarnaast een belangrijk raamwerk voor cybersecurity binnen industriële automatiserings- en besturingssystemen, waaronder zones, toegangsbeveiliging en continue verbetering.
Governance, risicobeoordelingen, leveranciersbeheer, businesscontinuïteit en formele meldplicht blijven verantwoordelijkheden van de organisatie zelf. Lees ook hoe een SOC NIS2-compliance ondersteunt.
Wanneer heeft een organisatie een OT-SOC nodig?
Een OT-SOC is vooral relevant wanneer uitval of manipulatie van operationele technologie grote gevolgen heeft. Denk aan productiebedrijven, logistieke omgevingen, energie, water, infrastructuur en andere organisaties met kritieke fysieke processen.
Signalen dat aanvullende monitoring nodig is:
- er is geen actueel overzicht van OT-assets en verbindingen;
- IT en OT zijn gekoppeld, maar securitymonitoring is alleen op IT gericht;
- leveranciers hebben regelmatig toegang op afstand;
- alerts worden uitsluitend tijdens kantooruren beoordeeld;
- er bestaan geen geoefende OT-incidentresponseplaybooks;
- productie is sterk afhankelijk van legacy-systemen;
- NIS2, klantvereisten of audits vragen om aantoonbare detectie en opvolging.
Hoe kies je een geschikte OT-SOC-provider?
Niet iedere SOC-provider heeft voldoende ervaring met industriële processen. Vraag daarom verder dan algemene termen als 24/7-monitoring en realtime detectie.
Beoordeel een provider onder andere op:
- kennis van industriële protocollen en OT-architecturen;
- ervaring met passieve asset discovery en monitoring;
- mogelijkheden om bestaande IT- en OT-tooling te integreren;
- afspraken over dataopslag, toegang en eigenaarschap;
- OT-specifieke detectieregels en threat intelligence;
- veilige playbooks voor containment en herstel;
- samenwerking met operations en externe leveranciers;
- heldere SLA’s, escalatiepaden en rapportages;
- ondersteuning bij oefeningen en continue verbetering.
Van eerste inventarisatie naar 24/7 OT-monitoring
Een OT-SOC hoeft niet in één keer voor de volledige omgeving te worden ingevoerd. Een gefaseerde aanpak beperkt risico’s en maakt het mogelijk om eerst ervaring op te bouwen.
- Inventariseer kritieke locaties, processen, assets en verbindingen.
- Bepaal de belangrijkste aanvalspaden en ongewenste gebeurtenissen.
- Kies geschikte databronnen en start met passieve zichtbaarheid.
- Leg verantwoordelijkheden, escalaties en veilige responsacties vast.
- Sluit IT- en OT-signalen aan op gezamenlijke monitoring.
- Test playbooks met tabletop-oefeningen en technische scenario’s.
- Meet detectiedekking, responstijden en terugkerende verbeterpunten.
Aumatics kan binnen het Security Operations Center signalen uit IT- en OT-omgevingen combineren. Zo ontstaat 24/7 zicht op dreigingen, terwijl incidentrespons wordt afgestemd op de veiligheid en continuïteit van het operationele proces.