The False Promise of Unified SOCs for IT/OT

By Muhammad Ali Khan ICS/ OT Cybersecurity Specialist — AAISM | CISSP | CISA | CISM | CEH | ISO27001 LI | CHFI | CGEIT | CDCP
Why One SOC to Rule Them All Isn’t the Panacea the Industry Believes It Is
The concept of a single, centralized Security Operations Center (SOC) responsible for both IT and Operational Technology (OT) environments has become something of an industry rallying cry. Vendors, consultants, and even some CISOs champion the “Unified SOC” as a strategic evolution, promising consolidated tooling, streamlined workflows, and an end to silos. Yet for many industrial organizations, particularly those managing critical infrastructure, this promise is fundamentally flawed.
A unified SOC, in theory, dissolves the distinction between IT and OT security functions. It brings together one set of analysts, one SIEM, one alerting platform, and one escalation chain. In marketing slides, it looks efficient, modern, and cost-effective. But hiding underneath are profound operational, technical, and risk management gaps that can degrade security posture, increase risk, and put production safety at stake.
This article explains why a truly unified IT/OT SOC is an unrealistic goal for most industrial environments, the structural gaps that persist today, and what realistic alternatives security leaders should pursue.
1. IT and OT Are Fundamentally Different Domains
At the highest level, IT and OT share a security goal — protect data, systems, and people, but the realities of how they operate differ radically.
Key Distinctions
- Objectives:
IT prioritizes data confidentiality and integrity. OT prioritizes safety and availability above all else. - Risk Tolerance:
An IT outage is inconvenient. An OT outage can cause plant shutdowns, public safety events, or environmental disasters. - Engineering Culture:
IT is software-centric and resilient to patch cycles. OT often runs legacy hardware, proprietary protocols, and real-time control loops that cannot tolerate disruption. - Lifecycle and Change Models:
OT equipment may operate for decades; IT refresh cycles are far shorter and more agile.
These differences mean that security tools and processes that work in IT rarely translate directly into OT without significant adaptation.
2. The Myth of a Single SIEM for IT and OT
A centerpiece of many unified SOCs is the idea of a single SIEM or XDR ingesting logs from both enterprise and industrial control systems.
Why This Fails in Practice
- Telemetry Limitations:
Most OT devices don’t produce logs in the same way IT systems do. PLCs, RTUs, and DCS components may generate limited telemetry — or none at all. - Protocol Blind Spots:
Standard SIEMs lack deep decoding for industrial protocols like Modbus, DNP3, IEC 60870–5–104, BACnet, OPC UA, etc. Without protocol-aware parsers, alerts are meaningless noise. - Volume/Noise Mismatch:
OT environments generate extremely low signal yet extremely critical events. Standard IT SIEM thresholds cannot distinguish between normal cyclic PLC behavior and malicious manipulation without OT-specific analytics.
Resulting Gaps
- False negatives: Critical OT attacks go undetected.
- False positives: Normal OT behavior triggers alerts that overwhelm analysts unfamiliar with industrial systems.
3. Skills Gaps: “One Team to Understand Both Worlds” Is Unrealistic
Unified SOCs often assume that analysts can be trained to monitor both IT and OT effectively. Yet:
IT Analysts
- Are trained in Windows, Linux, Active Directory, cloud-based threats, phishing, malware, and lateral movement.
- Have little to no real exposure to industrial protocols, control loops, deterministic network behavior, or safety impacts.
OT Security Engineers
- Understand PLC logic, control operations, safety instrumented systems (SIS), and process physics.
- May not be fluent in IT attacker TTPs like adversary frameworks (MITRE ATT&CK for Enterprise), malware families, or network pivoting.
Expecting one team to become experts in both domains introduces skills dilution — not synergy.
4. Incident Response Differences: One Playbook ≠ Fit-All
Unification implies a single incident response (IR) playbook. But IR in OT and IT is not the same process.
IT Incident Response
- Common IR actions: isolate endpoint, kill process, reimage host, restore from backups.
- Downtime is tolerable; systems can be taken offline for investigation.
OT Incident Response
- Taking a PLC offline could stop production or cause unsafe states.
- Investigators can’t just pull a drive or reflash firmware without understanding the sequence of operations and safety consequences.
- Forensic imaging is often impossible on embedded controllers.
A unified playbook risks causing more harm than good if OT events are handled using IT-centric procedures.
5. Regulatory and Compliance Divergence
Industrial sectors like energy, water, transportation, and manufacturing are subject to specialized compliance requirements:
- NERC CIP
- ISA/IEC 62443
- CFATS
- OSHA/NEP safety regulations
These regulations often require domain-specific controls, segmentation, and risk assessments that don’t map neatly into enterprise security frameworks.
A unified SOC strategy that ignores these regulatory nuances may expose operators to compliance violations or audit failures.
6. The Technology Illusion: “One Pane of Glass” Is Not Enough
Unified SOC advocates push dashboards showing all alerts in one place. But visibility does not equal situational understanding in OT.
Real OT Requirements
- Network flow visibility that understands deterministic industrial traffic cycles.
- Process context: What does this state change mean in the actual control logic?
- Safety alarms and process thresholds, beyond IT security events.
Without this deep context, analysts see numbers, not meaning.
7. Cultural Tensions: IT Rules ≠ OT Rules
Unified SOCs often reflect IT governance priorities:
- Patch quickly
- Enforce strict access controls
- Prioritize rapid incident containment
These can conflict with OT needs:
- Patch only during scheduled maintenance windows
- Preserve uptime even under investigation
- Maintain safe state ahead of all else
Without collaboration and domain-specific governance, unified SOCs can produce costly friction or poor decisions.
8. The False Economy of Consolidation
Unified SOCs promise cost savings by reducing headcount or tool duplication. But:
- The cost of a missed OT attack far exceeds staff or license savings.
- Training IT analysts on OT context is expensive and slow.
- Deploying improper tooling generates more work and risk.
Often organizations realize they need dual capability anyway, an OT-centric team plus an enterprise team, erasing the supposed savings.
9. What Should Organizations Do Instead?
1. Complementary SOCs with Clear Integration
- Maintain specialized IT and OT security teams.
- Enable controlled information sharing where meaningful (e.g., threat intelligence, attacker TTPs).
- Ensure senior leadership aligns risk criteria across domains.
2. OT-Aware Tooling
- Protocol-aware IDS/ICS monitoring
- Asset inventory built for OT
- Process modeling and anomaly detection tailored to control environments
3. Domain-Appropriate Playbooks
- Separate IR playbooks with escalation cues between IT and OT responders
- Joint tabletop exercises to refine coordination without forcing a single script
4. Skill Investment
- Develop dedicated OT security staff
- Cross-training programs, but not to turn every analyst into a full IT+OT expert
5. Governance That Recognizes Differences
- Risk management frameworks that respect the unique value and safety imperatives of OT
- Service-level definitions for detection, response, and restoration that differ between domains
Conclusion: Unified in Theory, Divided in Practice
The idea of a unified SOC for IT and OT stems from good intentions: break silos, reduce complexity, and gain holistic visibility. But in the real world of industrial operations, this goal is often a false promise. Without acknowledging and architecting for the fundamental differences between IT and OT, unified SOCs can expose organizations to gaps in detection, response, compliance, and safety.
Real security leadership doesn’t chase a simplistic consolidation; it designs complementary capabilities that respect domain distinctions, drive meaningful communication, and ensure that both environments are protected according to their intrinsic risks.
Comments
Post a Comment