📊 SIEM and SOC Operations for OT/IT Environments

What a SIEM Does and Why It Matters for OT

A Security Information and Event Management (SIEM) platform performs three core functions: log aggregation (collecting events from disparate sources into a central repository), correlation (applying detection rules that match patterns across multiple events in time), and alerting (notifying analysts when a correlation rule fires). Without a SIEM, an analyst investigating a suspected intrusion must manually query firewall logs, Active Directory event logs, and historian alarm logs separately — a process that takes days. A SIEM makes cross-source queries instantaneous and enables automated detection of multi-stage attack sequences that no single log source would reveal.

In OT environments, SIEM adoption has historically been low: PLCs generate minimal syslog, HMIs run on Windows but are rarely integrated with Active Directory event collection, and industrial protocol traffic has no native logging. This visibility gap is why nation-state actors dwell in OT networks for months without detection — the 2016 Ukraine power grid attack (Industroyer/CRASHOVERRIDE) went undetected in the operational network for months before the actors activated the payload. Modern OT security programs close this gap by feeding OT network sensors (Claroty, Dragos, Nozomi) into the SIEM alongside IT telemetry.

Key Log Sources for an OT/IT SIEM Deployment

An effective OT/IT SIEM deployment ingests the following sources: Windows Event Logs from HMIs, engineering workstations, and jump servers — Event IDs 4624/4625 (logon/logon failure), 4688 (process creation), 4648 (explicit credential use), and 7045 (service installation) are the highest-signal events. Firewall logs from the IDMZ firewalls, capturing all flows between IT and OT zones — connection denied events and unexpected allowed flows are both high-value signals. Active Directory logs (if OT systems are domain-joined or a separate OT AD forest exists): privileged group changes, account lockouts, Kerberoasting artifacts (Event 4769 with RC4 encryption type). Syslog from network infrastructure: managed switches, industrial firewalls, and routers. OT network sensor events: Dragos Platform and Nozomi export alerts via CEF/syslog about anomalous PLC command sequences, new device appearances, and protocol violations. Historian alarm logs: SCADA alarm floods can indicate a cyberattack manipulating process setpoints. Netflow/IPFIX from OT core switches: traffic volume baselines and anomaly detection at the network layer.

SIEM Platforms: Splunk, Microsoft Sentinel, and IBM QRadar

Splunk Enterprise Security (ES) is the market leader for large OT/IT SOC deployments. Its industrial add-ons (Splunk Add-on for Dragos, Claroty app for Splunk) normalize OT sensor data into Splunk's Common Information Model (CIM) for cross-source correlation. Splunk ES includes pre-built risk-based alerting (RBA) that scores entities over time rather than firing on individual events, reducing alert fatigue. Microsoft Sentinel, a cloud-native SIEM, is gaining adoption because it integrates natively with Microsoft Defender for Endpoint, Azure AD, and Microsoft Defender for IoT (formerly CyberX, which provides OT network monitoring). Sentinel's UEBA (User and Entity Behavior Analytics) detects anomalous account activity across IT and OT data connectors. IBM QRadar with its ICS/SCADA content pack is common in industrial organizations that also use IBM security tools. All three platforms support SPL (Splunk), KQL (Sentinel), or AQL (QRadar) query languages for threat hunting.

Detection Use Cases for OT/IT Environments

Effective detection requires purpose-built use cases tuned to the OT environment. Key examples: Brute force against jump server: more than 5 failed authentication attempts (Event 4625) from a single source IP against the RDP gateway within 5 minutes triggers an alert and blocks the source IP. Lateral movement via PsExec: Event 7045 (service installation) combined with process creation (4688) of psexesvc.exe on an engineering workstation. Anomalous PLC write command: Dragos alert for a Modbus Write Multiple Registers command sent to a PLC from a source IP that has never previously communicated with that PLC — a high-fidelity indicator of unauthorized control. Unauthorized remote access: RDP session to an HMI from an IP not in the approved vendor allowlist, outside business hours. Historian query from unknown host: a PI AF query from a host with no previous PI interaction — potential indication of attacker reconnaissance of process data. Each use case must be tuned against baseline to minimize false positives before being promoted to production alerting.

Alert Triage, MTTD, and MTTR

When a SIEM alert fires, the SOC analyst follows a structured triage workflow: (1) Validate — is this a true positive or a false positive? Pull the raw logs, check the timeline, verify the asset is expected in the environment. (2) Scope — what is the extent of the activity? Check for lateral movement indicators, look back 72 hours for precursor events. (3) Escalate — if confirmed malicious, escalate to L2/L3 analyst and initiate IR procedures. Mean Time to Detect (MTTD) measures the average time from when an attack begins to when it is detected by the SOC. Industry benchmarks for mature SOCs are under 24 hours for endpoint compromise, though OT environments often exceed this due to limited visibility. Mean Time to Respond (MTTR) measures from detection to containment. In OT, MTTR is complicated by the safety constraint that you cannot simply isolate a PLC mid-process — OT-safe containment options must be pre-defined in the IR playbook.

SOC Tiers, Threat Hunting, and Managed SOC Options

SOC analyst tiers reflect skill and responsibility: L1 analysts handle initial alert triage, validate true/false positive determinations, and escalate per runbook. L2 analysts perform deeper investigation, correlate across data sources, scope the incident, and own containment actions. L3 analysts handle complex incidents, perform threat hunting (proactive search for attacker TTPs not caught by detection rules), develop new detection content, and conduct post-incident reviews. Threat hunting in OT contexts uses frameworks like MITRE ATT&CK for ICS — which maps adversary techniques to OT-specific tactics such as Inhibit Response Function, Impair Process Control, and Impact — to formulate hypotheses and query the SIEM for evidence. For organizations without in-house SOC capacity, Managed Detection and Response (MDR) providers (Dragos OT Watch, Claroty Managed Threat Detection, CrowdStrike Falcon Complete) provide 24/7 monitoring with OT-specialized analysts. The key evaluation criterion for an OT-focused MDR is whether their analysts have genuine ICS expertise or are IT SOC analysts with thin OT cross-training.