OT Security Monitoring and Threat Detection: A Practical Guide for ICS Networks

OT security monitoring is the continuous collection and analysis of industrial network, asset, and security telemetry to identify activity that could threaten safety, reliability, product quality, or production.

Effective monitoring does more than generate alerts. It establishes what normal operations look like, detects meaningful deviations, gives analysts enough process context to triage them, and connects suspicious behavior to plausible attack paths.

That requires an OT-specific approach. Industrial control systems use specialized protocols, contain long-lived assets, and prioritize availability and deterministic operation. Monitoring must therefore be passive by default, sensitive to process context, and coordinated with plant engineering.

What OT security monitoring should accomplish

A mature monitoring program should answer five questions:

• What assets and communications exist? Identify controllers, engineering workstations, HMIs, historians, remote-access systems, servers, and network infrastructure.
• What is normal? Understand expected communication pairs, protocols, commands, schedules, and configuration activity.
• What changed? Detect new assets, unauthorized connections, unusual commands, policy changes, and deviations from established patterns.
• Does the activity create operational risk? Evaluate the affected process, asset criticality, safety implications, and available attack paths.
• Can the team respond safely? Give analysts and operators evidence they can verify without immediately isolating or scanning a production asset.

Monitoring is one component of a practical OT cybersecurity lifecycle. It does not replace segmentation, access control, vulnerability management, incident response, or security validation.

Why monitoring ICS networks requires an OT-specific approach

Applying an IT security operations model directly to ICS can produce excessive noise or unsafe response actions. Important differences include:

• Legacy devices may not support endpoint agents or detailed logging.
• Active discovery can affect fragile controllers and embedded devices.
• Industrial protocols may lack authentication or encryption by design.
• Normal maintenance can resemble adversary behavior.
• A technically compromised asset may not be safe to reboot or isolate.
• Process state determines whether a command is expected or dangerous.

An OT alert therefore needs engineering context. A controller-program download during an approved outage is different from the same event during continuous production. Remote access from an approved vendor may be normal within a maintenance window but suspicious at another time.

Start with passive network monitoring

Passive network monitoring observes copied traffic without initiating sessions with production assets. It is generally the safest foundation for ICS visibility because it does not probe controllers or add traffic to control networks.

Practical deployment steps

• Document zones, conduits, data flows, and critical process areas using a security-first OT network architecture.
• Prioritize collection at high-value boundaries, including the IT/OT boundary, industrial DMZ, control-center connections, remote-access paths, and communications between supervisory and control layers.
• Use network TAPs or correctly configured switch mirror ports to provide packet or flow data to monitoring sensors.
• Confirm that mirrored traffic includes both directions and relevant VLANs.
• Measure packet loss and visibility gaps before treating absence of activity as evidence.
• Coordinate installation, troubleshooting, and changes with operations.

Passive monitoring has limits. Switched traffic may not cross an observed boundary, encrypted sessions hide payload details, and serial or isolated networks may require additional collection methods. Document what each sensor can and cannot see.

Build industrial protocol and asset visibility

Generic flow records show that two systems communicated. Industrial protocol analysis can show what they did.

Depending on the environment, monitoring may need to interpret protocols such as Modbus TCP, DNP3, EtherNet/IP, OPC, S7 communications, IEC 60870-5-104, IEC 61850, BACnet, and vendor-specific protocols. The exact set should follow the plant's real architecture rather than a generic checklist.

Useful protocol context includes:

• Client-server or master-outstation relationships
• Read operations versus write operations
• Controller programming and mode changes
• Firmware or logic transfers
• Tag, coil, register, or object access
• Unexpected protocol use across a zone boundary
• Error rates, rejected commands, and malformed requests
• New communication pairs or devices

Asset records should combine observed identity with function and consequence. Capture hostname, addresses, vendor, model, firmware when available, protocols, zone, owner, process role, criticality, and expected communication peers. Treat passive identification as evidence with a confidence level, not infallible truth.

Collect the right OT security log sources

Network telemetry is essential, but it cannot explain every action. Combine it with logs from systems that provide identity, administrative, and control context.

Synchronize clocks wherever operationally safe. Preserve original timestamps and account for devices that cannot use modern time services. Without reliable time, analysts cannot reconstruct a sequence across network, identity, and process data.

Establish behavioral baselines for industrial operations

A behavioral baseline describes expected activity for a defined asset, process, zone, or communication relationship. It should reflect operating modes rather than one universal version of normal.

Baseline at least:

• Known assets and approved communication pairs
• Expected protocols, ports, and command types
• Normal controller programming sources
• Remote-access users, destinations, and windows
• Traffic volume and timing patterns
• Regular batch, shift, startup, shutdown, and maintenance activity
• Approved firmware, configuration, and logic versions where available

Collect data across a representative period that includes normal operating states. Review candidate baselines with control engineers. Automatically learned patterns can reproduce existing misconfigurations or persistent malicious activity, so observed does not always mean approved.

Version baselines and record why they changed. A permanent exception without an owner, justification, and review date becomes an unmanaged blind spot.

Engineer high-value OT threat detections

Start with behaviors that are both observable and consequential. High-value candidates include:

• A new external or enterprise source communicating with a control asset
• A new protocol crossing an established zone boundary
• Controller logic download from an unapproved workstation
• PLC stop, reset, mode change, or firmware event outside an authorized window
• Repeated write commands to unusual registers or tags
• Remote access without an associated work order
• New administrative accounts or privilege changes on OT systems
• Security policy changes followed by new reachability
• An engineering workstation contacting unexpected internet or enterprise destinations
• Loss of visibility from a critical sensor or log source

Every detection should document its objective, required telemetry, affected assets, logic, severity factors, expected false positives, triage steps, owner, and validation status.

Avoid assigning severity from a single indicator. Enrich alerts with asset criticality, process state, identity, maintenance status, zone, direction of travel, and whether the activity contributes to a route toward critical operations.

Map detections to MITRE ATT&CK for ICS

MITRE ATT&CK for ICS provides a common language for adversary behavior. Use it to organize coverage—not as a substitute for site-specific threat modeling.

A practical mapping workflow is:

• Identify relevant threat scenarios and likely IT-to-OT entry routes.
• Select applicable ATT&CK for ICS techniques.
• Define the observable behavior for each technique in your environment.
• Identify the network, host, identity, and process data required.
• Create or update the detection.
• Record whether it is designed, deployed, producing telemetry, and validated.
• Track gaps where a technique is relevant but not observable.

The distinction between mapped and validated matters. A rule tagged to a technique does not prove that sensors can see the behavior or that analysts will recognize it. See the detailed guide to MITRE ATT&CK for ICS mapping and validation.

Create an OT-aware alert triage workflow

OT triage should preserve safety while moving quickly enough to contain real threats.

Recommended triage sequence

• Verify the evidence. Confirm timestamps, sensor health, packet context, and source reliability.
• Identify the assets. Determine function, zone, owner, criticality, and process role.
• Check authorization. Review work orders, change records, vendor sessions, and maintenance windows.
• Establish scope. Find related identities, connections, commands, configuration changes, and upstream activity.
• Assess operational consequence. Ask what could happen if the activity continued or the asset were isolated.
• Escalate jointly. Bring cybersecurity, control engineering, and operations into consequential decisions.
• Contain safely. Prefer predefined actions that account for process dependencies and fail-safe behavior.
• Capture lessons. Update detections, baselines, playbooks, and architecture records.

A useful alert package includes the triggering event, communication sequence, identity, affected process, maintenance context, comparable historical activity, and recommended verification steps.

Measure detection coverage and operational value

Raw alert volume is not a measure of security. Track metrics that reveal visibility, detection quality, and response performance:

• Percentage of critical assets covered by reliable telemetry
• Percentage of critical conduits monitored in both directions
• Telemetry uptime, packet loss, and log-ingestion delay
• Relevant ATT&CK techniques with deployed and validated detections
• Mean time to acknowledge, investigate, and contain by severity
• Percentage of alerts enriched with asset and process context
• False-positive rate and repeat-alert rate
• Percentage of detections with current owners and triage procedures
• Time between an approved architecture change and baseline update
• Detection coverage for validated attack paths into critical zones

Segment metrics by site, zone, and asset criticality. Enterprise averages can hide a poorly monitored plant. For a broader measurement model, review these OT detection effectiveness metrics.

Validate whether OT detections work

A detection is not proven because its query runs successfully. Validation should determine whether the relevant behavior produces telemetry, triggers the expected logic, reaches the right analyst, and leads to a safe decision.

Direct testing against production controllers may be unacceptable. Safer options include approved lab environments, offline log replay, packet-capture replay, tabletop exercises, and cyber digital twins. Digital-twin assessment can model architecture, controls, vulnerabilities, and adversary routes without directly interacting with live OT assets.

Validation should connect individual techniques to complete scenarios. An alert may detect one controller command while missing the compromised remote-access account, firewall path, and engineering workstation used to reach it. OT attack-path validation helps determine whether layered controls and detections interrupt the full route.

A practical OT monitoring implementation roadmap

First 30 days: Define critical processes, map priority zones and conduits, inventory available telemetry, assign owners, and document monitoring safety constraints.

Days 31–60: Deploy or tune passive collection at priority boundaries, integrate identity and remote-access logs, establish initial baselines, and create triage contacts and escalation rules.

Days 61–90: Implement a small set of high-consequence detections, map them to relevant ATT&CK techniques, test triage playbooks, measure telemetry health, and document visibility gaps.

Ongoing: Validate detections, tune baselines after approved changes, evaluate complete attack paths, and report risk reduction rather than alert counts.

Move from monitoring to validated defense

Monitoring tells you what your sensors observe. Validation determines whether those observations and controls are sufficient against realistic paths into critical operations.

Frenos builds cyber digital twins from data supplied by existing OT and security tools, then uses adversary-driven simulation to evaluate exploitable IT-to-OT routes without testing directly on production assets. This helps teams prioritize detections and mitigations by exploitability and operational impact—even when visibility is incomplete.

Request a demo of the Frenos OT cybersecurity platform to see how continuous simulated penetration testing can complement your monitoring and threat-detection program.