Security monitoring for military base OT and critical infrastructure

A military base is not a single network. It is a layered environment: the administrative IT domain that handles email and logistics, the operational networks that carry C2 and mission data, and a third domain that is frequently overlooked by security teams – the operational technology (OT) layer that runs the physical infrastructure. Power generation and distribution, fuel storage and transfer systems, water treatment, HVAC, access control, perimeter sensors, and runway lighting are all managed by ICS and building automation systems that predate modern cybersecurity practices, run proprietary protocols, and in many cases cannot be patched or updated without disrupting live operations. These systems are also, from an adversary's perspective, extremely attractive targets: disrupting power or fuel at a base can ground aircraft, disable communications, and neutralize a facility far more efficiently than a conventional cyber attack against classified networks.

This article examines the architecture and operational practices for comprehensive OT security monitoring on military installations – covering passive ICS visibility, behavioral baseline modeling, alert prioritization, and the integration of facilities data into the IT SOC. For a companion treatment of how to detect intrusions once an adversary is already present in an OT environment, see the article on intrusion detection for military OT and ICS systems.

Why OT monitoring requires a different approach

The instinct of an IT security team encountering an unfamiliar network is to run a vulnerability scanner. On an OT network, that instinct can cause an outage. PLCs (Programmable Logic Controllers), RTUs (Remote Terminal Units), and building automation controllers are embedded systems designed for deterministic, real-time process control. They allocate fixed memory buffers, run on minimal stacks, and have no defensive logic for unexpected network traffic. An NMAP scan or a Nessus agent that would run harmlessly on an IT workstation can exhaust a PLC's communication stack and cause it to drop into a fault state – which means the process it controls stops.

This constraint drives the foundational rule of OT security monitoring: everything must be passive. The monitoring system observes traffic that is already flowing on the network – it does not generate any. This is implemented through network TAPs or managed switch SPAN (mirror) ports that copy traffic to a dedicated monitoring interface without injecting any packets onto the OT segment. The monitoring sensor has a read-only presence: it receives a copy of network traffic, parses it, and forwards normalized data out through a completely separate interface that is isolated from the OT network.

The second constraint is protocol specificity. OT environments use a range of industrial and building automation protocols – Modbus TCP/RTU, DNP3, BACnet/IP, IEC 61850, EtherNet/IP, PROFINET, LonTalk – that standard IT monitoring tools do not parse. Parsing these protocols is not optional for effective monitoring. The security-relevant content of OT traffic is at the protocol level: which Modbus function codes are being used, which DNP3 objects are being read or written, which BACnet properties are being modified. A monitoring system that sees only IP-level flows is blind to the actual operations being performed on the controlled equipment.

OT asset inventory as the monitoring foundation

Effective monitoring requires knowing what you are monitoring. Most military bases do not have an accurate, current OT asset inventory – facilities management has records of what was installed, but additions, replacements, and undocumented modifications accumulate over the years. The first step in building a monitoring program is deriving an inventory from passive observation.

A passive network discovery session – capturing traffic on all OT segments for a full operational cycle, ideally one to two weeks – reveals every device that communicates on the network: its IP and MAC address, the protocols it uses, its communication peers, and (for many OT devices) its vendor and model identifier embedded in protocol handshakes. BACnet device objects self-report vendor ID, object name, and model number. Modbus devices respond to a limited set of identification queries that a passive parser can capture from existing traffic. EtherNet/IP devices exchange device identity objects in normal I/O messaging.

The resulting inventory drives two downstream functions: criticality classification (which devices, if disrupted, would affect mission-critical systems versus non-critical facilities) and baseline scope (which communication relationships are normal and should be modeled). A substation protective relay and a lighting controller both appear as IP devices on the network – the asset inventory is what tells the monitoring system that one warrants immediate SOC escalation if it behaves anomalously, while the other can be queued for investigation.

Behavioral baseline modeling

OT networks are highly repetitive. A PLC controlling a fuel pump executes the same polling cycle every few hundred milliseconds. A SCADA master reads the same set of registers from the same set of RTUs on the same schedule, day after day. This repeatability is operationally essential – it is what makes the system predictable and reliable – and it is also what makes behavioral baseline modeling so effective as a detection mechanism.

Baseline modeling captures the expected behavioral state of the OT network: which device pairs communicate, using which protocols and function codes, at what frequencies, with what payload size distributions. After a learning period of two to four weeks (long enough to capture weekly maintenance cycles, shift-change patterns, and seasonal HVAC variations), the baseline represents a comprehensive model of normal operations. Anomalies are deviations from this model that exceed a statistical threshold – a new communication peer appearing, a function code that has never been observed on a circuit, a polling rate that doubles without a corresponding maintenance event in the change log.

The critical engineering challenge in baseline modeling is handling legitimate variability without generating excessive false positives. OT networks change more slowly than IT networks, but they do change: planned maintenance, seasonal system behavior, equipment replacement, and operational tempo changes all produce traffic patterns that deviate from the historical baseline. A well-designed monitoring platform handles this through maintenance window suppression (known change windows suppress anomaly scoring for affected devices), manual baseline overrides (the facilities engineer can mark a new device as expected), and time-windowed baselines that model daily, weekly, and seasonal patterns separately rather than collapsing them into a single average.

Protocol-level anomaly detection

Beyond the communication-pair and frequency dimensions of the baseline, protocol-level anomaly detection examines the content of OT protocol exchanges. The most operationally significant anomalies occur at the function code and object level: a Modbus write command to a coil that has only ever been read by the SCADA system; a DNP3 direct operate command (function code 3) where only data reads have previously occurred; a BACnet WriteProperty command targeting a setpoint that controls critical environmental systems. These command-class anomalies are the signature of an adversary who has obtained access to the OT network and is attempting to manipulate process equipment.

Protocol-level detection also covers protocol abuse patterns – malformed packets, unexpected function codes, devices querying peers they have never communicated with before. The network segmentation architecture of the installation determines which communication relationships are architecturally permissible; the monitoring system enforces these by flagging any cross-segment communication that violates the intended topology.

Connecting OT monitoring to the IT SOC

Facilities security and IT security have historically operated as separate organizational domains on military installations. The facilities management team owns the OT network; the S6 or equivalent IT function owns the IT network and the SOC. This separation creates a visibility gap: the SOC lacks the data to detect attacks that originate in or propagate through the OT layer, and the facilities team lacks the security expertise to interpret anomaly data as potential threats.

Bridging this gap requires two things: a technical architecture that enables one-way data flow from the OT monitoring platform to the IT SIEM, and an organizational model that gives the SOC enough context about OT assets to act on OT alerts without requiring embedded ICS expertise on the SOC floor.

The technical architecture uses a data diode or unidirectional security gateway positioned at the boundary between the OT monitoring network and the SOC network. The OT monitoring sensor forwards normalized alert data and event logs through this one-way path – the diode physically enforces that no traffic can flow from the IT side back to the OT side. The normalized data arrives at the SIEM in a standard format (CEF syslog, JSON, or a native connector), where it is correlated with IT security events. A lateral movement event that begins with an OT protocol anomaly, progresses through the IT-OT boundary, and appears in Windows event logs as a new service installation is only visible as a connected sequence if both data streams reach the same SIEM.

For the SOC to act effectively on OT alerts, the SIEM must be enriched with OT asset context: device criticality, physical location, associated business function, and the operational impact of disruption. An alert that reads "new communication peer on 192.168.40.15" is unactionable without context. The same alert enriched with "192.168.40.15 = substation control relay, Building 14 primary power feed, criticality: HIGH" produces an immediate, unambiguous escalation decision. This enrichment is derived from the asset inventory built during the monitoring deployment and maintained through the ongoing asset management process.

Alert prioritization and SOC workload management

A military base with a mature OT monitoring deployment will generate a substantial volume of anomaly candidates – not because the OT environment is under constant attack, but because baseline deviation is structurally common in a large, operationally active facility. Planned maintenance, equipment aging, seasonal variations, and periodic system upgrades all produce traffic patterns that deviate from historical norms. Without effective prioritization, a SOC analyst team will be buried in low-significance anomalies and will miss the high-significance events that require immediate response.

Effective prioritization uses a risk scoring model that combines three dimensions: device criticality (from the asset inventory), anomaly severity (a new outbound connection to an external IP scores higher than a 10% polling rate increase), and operational context (a change during a documented maintenance window scores lower than the same change on a normal operational day). Events that cross a combined risk threshold after contextual suppression generate active SOC alerts. Events below the threshold are logged and accessible for retrospective investigation but do not generate queue entries.

The integration of OT monitoring into broader SIEM and SOAR workflows allows high-priority OT alerts to trigger automated response playbooks – isolating a compromised device at the network boundary, notifying facilities engineering, and initiating the incident response process – without requiring manual SOC analyst intervention for every event. SOAR automation for OT incidents must be designed conservatively: automated containment actions (blocking a network path, isolating a device) can have immediate physical consequences in an OT environment. Automated notification and evidence collection are safe starting points; automated containment requires explicit organizational authorization and detailed scenario analysis before deployment.

Continuous monitoring hygiene and tuning

OT monitoring is not a deploy-and-forget capability. The OT environment changes over time – devices are replaced, systems are upgraded, operational procedures evolve – and the monitoring baseline must evolve with it. A baseline that was accurate eighteen months ago may now generate a significant false positive rate because the facility has changed and the baseline has not been updated. A monthly tuning cycle with the facilities engineering team is the minimum operational cadence: reviewing the previous month's alert volume, identifying systematic false positive sources, updating baseline exceptions for planned changes, and adding detection rules for new device types or protocols introduced since the last review.

Firmware updates on OT devices require particular attention. A firmware update may change a device's communication behavior – different polling intervals, new diagnostic messages, modified function code usage – and will appear as an anomaly wave if the monitoring baseline is not updated concurrently with the update deployment. Coordinating OT monitoring baseline updates with the change management process for OT equipment is an organizational dependency that must be built into the base's IT-facilities coordination model from the start.