Waarom effectieve IT-OT-monitoring draait om zicht op de volledige aanvalsketen

Een OT-sensor alleen vertelt niet het hele verhaal.

Passieve netwerkmonitoring is niet voor niets de standaard binnen industriële omgevingen. Een passieve sensor luistert mee met het netwerkverkeer, zonder zelf pakketten naar PLC’s, controllers of andere kwetsbare OT-apparatuur te sturen. Zo ontstaat waardevolle zichtbaarheid zonder het productieproces te verstoren. Maar een sensor plaatsen in het OT-netwerk is nog geen volwaardige IT-OT-monitoring.

De grootste uitdaging zit namelijk niet alleen in het herkennen van Modbus-, S7Comm- of EtherNet/IP-verkeer. De werkelijke waarde ontstaat wanneer gebeurtenissen uit het IT-netwerk, de overgangszone en het OT-netwerk met elkaar worden verbonden.
 

De belangrijkste meetpunten liggen niet alleen in OT

Veel aanvallen op industriële omgevingen beginnen aan de IT-kant. Een aanvaller compromitteert bijvoorbeeld een gebruikersaccount, laptop, VPN-verbinding of externe beheeromgeving en probeert zich vervolgens richting de productieomgeving te bewegen.

Voor gecombineerde IT-OT-monitoring zijn daarom minimaal drie meetpunten relevant:

1. Het IT-netwerk, waar de aanval vaak begint.
2. De overgangszone of industriële DMZ, met bijvoorbeeld een jumphost, historian of OPC UA-server.
3. Het OT-netwerk, waar PLC’s, controllers en andere industriële systemen actief zijn.

Deze meetpunten zijn niet alleen nodig om meer netwerkverkeer te verzamelen. Ze zijn vooral nodig om de verschillende stappen van een aanval met elkaar te verbinden.
 

Iedere sensor ziet maar één deel van de aanval

Verkeer van IT naar OT loopt vrijwel nooit rechtstreeks van een gebruikerslaptop naar een PLC. Tussen beide omgevingen staan meestal verschillende beveiligingslagen en tussensystemen, zoals een firewall, jumphost, engineering workstation, historian of OPC UA-server.

Vanuit het OT-netwerk gezien is de bron van het verkeer daarom vaak niet de oorspronkelijke laptop van de aanvaller. De OT-sensor ziet alleen de tussenliggende server die uiteindelijk met de PLC communiceert.

Die server mag onder normale omstandigheden mogelijk gewoon met de PLC communiceren. Ook de afzonderlijke stappen daarvoor kunnen legitiem lijken. Een gebruiker die op een jumphost inlogt, is niet per definitie verdacht. Een OPC UA-server die informatie bij een controller opvraagt evenmin.

De aanval wordt pas zichtbaar wanneer deze gebeurtenissen worden gecorreleerd op basis van onder andere tijd, systemen, gebruikersaccounts, netwerkverbindingen en processen.

Geen enkele afzonderlijke sensor vertelt het volledige verhaal. De aanvalsketen ontstaat pas wanneer de verschillende schakels met elkaar worden verbonden.
 

Voorbeeldscenario: van IT-account naar PLC

Stel dat een aanvaller via een phishingmail de inloggegevens van een onderhoudsmedewerker bemachtigt.

Om 09.12 uur logt de aanvaller vanaf een onbekende laptop in op de VPN-omgeving van de organisatie. Vanuit het IT-netwerk wordt vervolgens een verbinding opgezet naar een jumphost in de industriële DMZ.

Op zichzelf hoeft deze verbinding niet direct een alarm op te leveren. De onderhoudsmedewerker gebruikt de jumphost immers vaker voor beheerwerkzaamheden.

Om 09.18 uur start vanaf de jumphost een verbinding naar een OPC UA-server. Ook dit kan legitiem lijken, omdat deze systemen normaal gesproken met elkaar mogen communiceren.

Een paar minuten later wordt vanaf de OPC UA-server een afwijkende verbinding richting een PLC opgezet. Daarbij wordt een schrijfcommando verstuurd naar een register dat normaal alleen tijdens gepland onderhoud wordt aangepast.

De verschillende meetpunten zien ieder slechts een deel van de activiteit:
 

Meetpunt	Wat wordt waargenomen?
IT-netwerk	Een VPN-login en een verbinding naar de jumphost.
Industriële DMZ	Een sessie van de jumphost naar de OPC UA-server.
OT-netwerk	Een technisch geldig, maar afwijkend schrijfcommando naar de PLC.
Endpoint- en identitylogging	Het account wordt gebruikt vanaf een onbekend apparaat en op een ongebruikelijk tijdstip.

Los van elkaar lijken deze gebeurtenissen mogelijk niet ernstig genoeg voor een incident. Zodra ze op tijd, host en gebruikersaccount aan elkaar worden gekoppeld, ontstaat echter een duidelijke aanvalsketen:

Gecompromitteerd account → VPN → jumphost → OPC UA-server → PLC

De OT-sensor ziet het laatste commando, maar weet zonder aanvullende context niet wie de oorspronkelijke gebruiker was. De IT-sensor ziet de VPN-login, maar niet welke handeling uiteindelijk op de PLC is uitgevoerd. De waarde ontstaat wanneer beide werelden bij elkaar worden gebracht.
Dit maakt het mogelijk om niet alleen te melden dat er afwijkend OT-verkeer is waargenomen, maar om een veel vollediger incidentbeeld te geven:

Een onderhoudsaccount is vanaf een onbekend systeem gebruikt om via de jumphost en OPC UA-server een ongebruikelijk schrijfcommando naar een PLC te versturen. Dat is voor een SOC-analist, beheerder of incidentresponseteam aanzienlijk bruikbaarder dan een los technisch alarm.
 

Suricata detecteert, Zeek geeft context

Binnen een IT-OT-sensor hebben Suricata en Zeek verschillende, maar aanvullende rollen. Suricata is geschikt voor het herkennen van bekende aanvalspatronen, afwijkende pakketten en ongewenst netwerkgedrag. Binnen OT-omgevingen kan daarbij onder andere worden gekeken naar:

• misvormde industriële netwerkpakketten;
• illegale of ongebruikelijke commando’s;
• verkennings- en scangedrag;
• bekende ICS-malwarefamilies;
• communicatie met verdachte externe infrastructuur.

De meeste initiële aanvallen en malwareactiviteit worden vaak al aan de IT-kant zichtbaar. Daar kan Suricata bijvoorbeeld exploitverkeer, command-and-controlcommunicatie, laterale beweging en andere aanvalspatronen herkennen voordat een aanvaller de OT-omgeving bereikt.

Zeek richt zich meer op het analyseren en structureren van netwerkcommunicatie. In plaats van alleen een alarm te genereren, legt Zeek gedetailleerde metadata vast over verbindingen, systemen, protocollen en uitgevoerde handelingen.

Suricata helpt vooral bij de vraag:
Is dit verkeer verdacht?

Zeek helpt bij de vragen:
Welke systemen communiceren met elkaar, welk protocol gebruiken zij en wat gebeurt er precies?

De combinatie van beide technologieën levert aanzienlijk meer context op dan één detectiemethode afzonderlijk. Welke protocollen relevant zijn, hangt sterk af van de aanwezige apparatuur en de sector. Een Siemens-omgeving vraagt bijvoorbeeld om zicht op S7Comm en PROFINET. Bij Rockwell-omgevingen zijn EtherNet/IP en CIP belangrijk. In energieomgevingen komen protocollen zoals DNP3 en IEC 104 voor.
 

Beschikbare OT-protocolondersteuning binnen Zeek

Protocol	Ondersteuning
Modbus	Standaard beschikbaar in Zeek, met een uitgebreidere parser via CISA/INL.
DNP3	Standaard beschikbaar in Zeek, met een uitgebreidere parser via CISA/INL.
MQTT	Standaard beschikbaar in Zeek.
BACnet	Plugin van CISA/INL.
BSAP	Plugin van CISA/INL.
ANSI C12.19	Plugin van CISA/INL.
EtherNet/IP en CIP	Plugin van CISA/INL.
EtherCAT	Plugin van CISA/INL.
GE-SRTP	Plugin van CISA/INL.
Genisys	Plugin van CISA/INL.
HART-IP	Plugin van CISA/INL.
Omron FINS	Plugin van CISA/INL.
OPC UA	Plugin van CISA/INL.
PROFINET	Plugin van CISA/INL.
ROC Plus	Plugin van CISA/INL.
S7Comm en COTP	Plugin van CISA/INL.
Synchrophasor	Plugin van CISA/INL.

De aanvullende protocolparsers zijn beschikbaar via de Zeek Package Manager. De ICSNPP-plugins worden ontwikkeld en onderhouden door CISA en Idaho National Laboratory.

Voor protocollen die niet direct door deze set worden ondersteund, bepalen we per klantomgeving welke aanvullende parser of detectiecomponent nodig is.
 

OT-detectie op basis van MITRE ATT&CK for ICS

Naast protocolparsers is ook ACID beschikbaar: ATT&CK-based Control-system Indicator Detection. Deze Zeek-plugin is gericht op het detecteren van indicatoren die aansluiten op aanvalstechnieken uit MITRE ATT&CK for ICS. Daardoor kan netwerkactiviteit niet alleen technisch worden geregistreerd, maar ook worden gekoppeld aan herkenbare tactieken en technieken van aanvallers.

Ook hierbij blijft context belangrijk. Eén technisch event hoeft nog geen aanval te betekenen. De combinatie van meerdere indicatoren, systemen en tijdlijnen maakt het mogelijk om onderscheid te maken tussen normale operationele activiteit en een daadwerkelijke aanvalsketen.
 

SPAN-poort of hardware-TAP?

Een passieve sensor kan alleen analyseren wat hij daadwerkelijk ontvangt. Daarom moet bij de technische inventarisatie vroeg worden vastgesteld hoe het relevante netwerkverkeer naar de sensor wordt gekopieerd. In veel omgevingen gebeurt dit via een SPAN- of mirrorpoort op een managed switch. OT-omgevingen maken echter regelmatig gebruik van oudere of unmanaged switches. Deze beschikken niet altijd over de mogelijkheid om netwerkverkeer naar een sensor te spiegelen. In dat geval is een hardware-TAP vaak de aangewezen oplossing. Deze wordt fysiek in de netwerkverbinding geplaatst en maakt een kopie van het verkeer voor de sensor, zonder dat de sensor actief onderdeel wordt van de communicatie.

Bij een inventarisatie moeten daarom niet alleen de gebruikte protocollen en systemen worden vastgelegd, maar ook:

• het type en merk van de switches;
• de beschikbaarheid van SPAN- of mirrorfunctionaliteit;
• de fysieke locaties van netwerkverbindingen;
• de linkcapaciteit en redundantie;
• de gewenste en praktisch haalbare meetpunten.

Bescheiden hardware, veel zichtbaarheid

Een voordeel van OT-netwerken is dat de hoeveelheid verkeer vaak beperkt is. Industriële protocollen versturen doorgaans kleine hoeveelheden data en veel OT-verbindingen zijn voorspelbaar en repetitief. Daardoor kan een relatief bescheiden sensor al een groot aantal systemen en netwerkverbindingen monitoren. De schaal- en bandbreedteproblemen die we uit grotere IT-omgevingen kennen, spelen in veel OT-netwerken een veel kleinere rol. Dit maakt passieve IT-OT-monitoring niet alleen technisch effectief, maar ook praktisch en schaalbaar.
 

Van netwerkpakket naar aanvalsketen

Een goede OT-sensor herkent protocollen, systemen en afwijkende commando’s. Een goede IT-OT-monitoringoplossing gaat een stap verder. Die verbindt gebeurtenissen uit het IT-netwerk, de industriële DMZ en het OT-netwerk. Daardoor wordt zichtbaar hoe een aanvaller zich door de omgeving beweegt en welke systemen, accounts en netwerkverbindingen onderdeel zijn van hetzelfde incident.

Het onderscheid zit dus niet in het plaatsen van nóg een sensor. Het zit in het correleren van de volledige keten.

Onze IT-OT-sensor combineert passieve netwerkmonitoring, protocolanalyse en detectie met de context uit de rest van de omgeving. Zo ontstaat niet alleen een melding dat er iets afwijkends gebeurt, maar een onderbouwd beeld van wie, wat, wanneer en via welke route.