Why do factories need a SOC with OT competencies?
Traditional SOCs (Security Operations Centers) focus on IT environments — monitoring network traffic, server logs, endpoints and applications. But in a factory, critical systems are not servers — they are PLC controllers, SCADA systems, HMI stations and historian servers running on industrial protocols that a traditional SOC does not understand.
The ransomware attack on Norsk Hydro (2019) was only detected when IT systems began shutting down en masse. Had the company had a SOC with OT monitoring, the lateral movement from IT to OT could have been detected and stopped before reaching control systems.
The NIS2 directive requires continuous threat monitoring — for manufacturing companies this means monitoring covering not just IT but also the OT network.
Differences between IT SOC and OT SOC
Protocols and technologies
- IT SOC: TCP/IP, HTTP/S, DNS, SMTP, Active Directory
- OT SOC: Modbus TCP/RTU, OPC UA/DA, EtherNet/IP, PROFINET, S7comm, DNP3, BACnet
Priorities
- IT SOC: Confidentiality → Integrity → Availability (CIA)
- OT SOC: Availability → Integrity → Confidentiality (AIC) — physical safety first!
Monitoring methods
- IT SOC: Active scanning, endpoint agents, inline blocking
- OT SOC: Passive monitoring (SPAN/TAP), no agents on PLCs, no inline blocking
Response windows
- IT SOC: Can isolate an endpoint immediately
- OT SOC: Isolating a PLC may stop a physical process — requires coordination with operations
Analyst competencies
- IT SOC: Network security, malware analysis, SIEM
- OT SOC: All the above + knowledge of industrial processes, OT protocols, the Purdue model
OT SOC architecture for a factory
Data collection layer
OT sensors (passive) installed at key points in the production network:
- At Purdue zone boundaries (especially the DMZ between IT and OT)
- In segments with PLC controllers and SCADA systems
- On control layer switches
- At historian servers (IT/OT intersection point)
Sensors use SPAN/mirror ports or TAPs (Test Access Points) — listening to traffic without interference.
Log collection from systems that generate them:
- Historian and MES servers
- Engineering workstations (Windows Event Logs)
- Industrial firewalls and managed switches
- Physical access control systems
Analysis layer
OT NDR platform (Network Detection and Response) analyzes traffic:
- Deep Packet Inspection of industrial protocols
- OT asset inventory based on network traffic
- Normal traffic baseline and anomaly detection
- Detection of known CVEs in OT communications
- PLC firmware and configuration change monitoring
SIEM with OT context correlates events:
- IT anomaly (e.g., unusual login) + OT anomaly (e.g., new Modbus session) = lateral movement detection
- PLC configuration change outside maintenance window = critical alert
- New host on OT network = potential rogue device
Response layer
Response procedures accounting for OT specifics:
- Escalation to OT engineer before isolation — verifying the action will not stop a critical process
- Predefined playbooks for OT scenarios: IT→OT lateral movement, unauthorized PLC change, rogue device
- Coordination with operations — shift manager informed of incidents
Key OT SOC detection scenarios
1. Lateral movement from IT to OT
Detecting communication from the IT segment to devices in the OT segment outside established paths. Indicators: new SMB/RDP connections to engineering workstations, port scanning in the OT network, use of remote access tools.
2. Unauthorized PLC configuration change
Monitoring programming commands (upload/download) to PLC controllers. Alert when changes occur outside defined maintenance windows or from unauthorized sources.
3. Industrial protocol anomalies
Detecting unusual Modbus commands (e.g., write to a register that is normally read-only), unusual polling frequency or communication with unknown addresses.
4. Rogue device on OT network
A new device appearing on the production network — it could be a service technician’s laptop (planned) or an attacker’s device (threat).
5. Ransomware propagation
Detecting patterns typical of ransomware: mass file encryption, C2 communication, SMB lateral movement — before it reaches OT systems.
SOC as a Service vs in-house OT SOC
Building an in-house OT SOC
- Cost: 5-10 OT security specialists x employment cost = significant annual investment
- Time: 12-18 months to full operability
- Challenges: difficulty recruiting specialists combining IT security + OT competencies
- Advantages: full control, deep process knowledge
SOC as a Service with OT competencies
- Cost: a fraction of in-house SOC cost
- Time: deployment in 4-8 weeks
- Advantages: access to OT experts, threat intelligence, 24/7 without building a team
- Model: nFlo SOC as a Service with OT threat detection
For most manufacturing companies, SOC as a Service is the optimal solution — delivering OT security competencies whose internal development is costly and time-consuming.
OT SOC deployment — step by step
Phase 1: Discovery (weeks 1-2)
- OT security audit — asset and network inventory
- Purdue zone mapping and monitoring point identification
- Critical process and system identification
Phase 2: Deployment (weeks 2-4)
- Passive sensor installation (SPAN/TAP)
- Log collection configuration
- OT NDR platform integration
- Normal traffic baseline (learning period)
Phase 3: Tuning (weeks 4-8)
- False positive reduction
- Creating environment-specific rules
- Defining response playbooks
- Personnel training on escalation procedures
Phase 4: 24/7 Operations
- Continuous monitoring and alert analysis
- Regular reporting to management
- Sector-specific threat intelligence
- Continuous detection rule improvement
Need OT security monitoring in your factory? Schedule a consultation — we will present a SOC as a Service model tailored to your production environment.
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
Related topics
See also:
