OT Security Monitoring Platform Deployment Guide

Introduction

Deploying an OT security monitoring platform is one of the highest-value security investments available to industrial organizations. Without monitoring, security events occur invisibly. An attacker who gains access to an OT network, conducts reconnaissance for weeks, and then modifies PLC logic leaves no observable evidence in organizations without monitoring. With a properly deployed passive monitoring platform, every one of those activities generates observable data, and potentially, actionable alerts.

The gap between "deployed" and "properly deployed" is substantial. An OT monitoring platform that is capturing traffic from the wrong locations, has protocol decoders configured for the wrong industrial protocols, has no tuned alert rules, and is not integrated into any investigation workflow provides minimal actual security value despite representing significant capital investment. This is not a hypothetical concern. When Beacon Security engages with organizations that already have an OT monitoring platform in place, we find poorly deployed sensors and unconfigured alert rules more often than not. The platform exists; the capability doesn't.

This guide provides a detailed deployment methodology, from platform selection through sensor placement, configuration, baseline establishment, alert tuning, SIEM integration, and multi-site scaling.

Platform Selection Criteria

Core Capability Requirements

Before evaluating specific platforms, define the capability requirements for your environment:

Protocol coverage: Which industrial protocols are present in your environment? A platform without native decoders for your specific protocols provides limited value. Common protocols to verify:

• Modbus TCP / Modbus RTU over TCP (nearly universal in OT environments)
• EtherNet/IP / CIP (Rockwell environments; common in discrete manufacturing)
• PROFINET (Siemens environments; common in European manufacturing)
• DNP3 (utilities, electric, water, oil and gas)
• IEC 104 / IEC 101 (electric utilities, substation automation)
• IEC 61850 / GOOSE / MMS (substation automation, protective relay communication)
• OPC DA / OPC UA (data server communications, historian integration)
• BACnet/IP (building management, HVAC integrated with OT)

Vendors claim broad protocol support, verify the depth of support, not just the list. A "Modbus" decoder that only identifies the protocol without function-code-level inspection provides limited detection capability.

Asset discovery and inventory: The platform should passively build and maintain an asset inventory from observed network traffic, identifying device type, vendor, model, and firmware version where protocol fingerprinting supports it.

Behavioral analytics: Static signature-based detection alone is insufficient for OT. The platform must support behavioral baselines, learning the normal communication patterns of the environment and alerting when those patterns change. Without behavioral detection, you can only catch known attacks, not novel ones.

Threat intelligence and signatures: Does the platform include OT-specific threat intelligence and signatures for known malware families (TRITON, INDUSTROYER, PIPEDREAM-related indicators) and known attack techniques?

ATT&CK for ICS alignment: Are detections mapped to the MITRE ATT&CK for ICS framework? This enables coverage gap analysis and supports structured reporting (see TG-018).

SIEM integration: Does the platform support log forwarding to your SIEM platform (Splunk, Microsoft Sentinel, IBM QRadar, Chronicle) via CEF, Syslog, or native connector?

Scalability: How many devices and how many sites can the platform support? How is data from multiple sites centralized?

Platform Comparison Overview

Do not select a platform based on marketing literature alone. Request a proof-of-concept deployment in your environment, ideally a representative site, and evaluate the platform against your actual protocol mix, device population, and alert quality.

Architecture: Centralized vs. Distributed Management

For single-site deployments, a single platform instance typically suffices. For multi-site organizations, consider:

Centralized architecture: All sensors forward data to a central platform instance. Analysts work from a single console. Configuration is centrally managed. This simplifies operations but creates WAN bandwidth requirements for forwarding decoded event data from remote sites.

Distributed architecture: Each site has its own platform instance. A central aggregation layer collects normalized events from all sites for cross-site correlation. This reduces WAN bandwidth but increases the complexity of managing multiple platform instances.

Most enterprise OT platforms support hierarchical architectures where site-level instances handle local data processing and forward events to a centralized management console. This is the recommended approach for organizations with more than three or four sites.

Sensor Placement Strategy

The most consequential deployment decision after platform selection is sensor placement: where on the network to collect the traffic that the platform will analyze. Getting this wrong means paying for a platform that can't see what matters.

TAPs vs. SPAN Ports: An Insider's Perspective

This is one of those decisions where the right answer is clear in principle, but the practical pressures in real deployments push teams toward the wrong choice. Here's the honest picture.

Network TAPs (Test Access Points) are hardware devices inserted in-line on a network link that passively copy all traffic from that link to an output port connected to the monitoring sensor. TAPs have no IP address, generate no traffic, and cannot be remotely exploited. They provide 100% packet capture with no dropped frames under any load condition. For OT environments where missing packets means missing attacks, TAPs are the right tool for critical monitoring points.

Types of TAPs:

• Passive fiber TAP: Uses optical splitting to copy light from the fiber to the monitoring output. Completely passive, no power, no electronics, nothing that can fail or be attacked.
• Active copper TAP: For copper (RJ45) links, an active TAP regenerates the signal to provide the copy output. Requires power and introduces a small probability of link issues.
• Aggregation TAP: Combines traffic from multiple links into a single monitoring output, useful for monitoring multiple links with a single sensor interface.

SPAN ports (Switched Port Analyzers) are switch configurations that copy traffic to a designated monitoring port. They use existing switch infrastructure without additional hardware, which is why organizations reach for them first. The problem is that SPAN ports may drop packets under high switch load, they add CPU load to the switch, and misconfigurations such as incorrect VLAN selection or asymmetric SPAN can result in incomplete traffic capture.

The practical recommendation: Use TAPs at the most critical monitoring points, IT/OT DMZ uplinks, zone boundary uplinks. Use SPAN ports for supplementary collection within zones where TAP installation is impractical. At Beacon Security, when we help clients deploy monitoring infrastructure, we push hard for TAPs at the boundaries and accept SPAN ports within zones where deploying physical hardware is difficult. A hybrid approach gives you reliability where it matters most.

Coverage Requirements: What Must Be Monitored

Prioritize sensor placement based on security value:

Priority 1, IT/OT Boundary: Network links between the IT network and the OT DMZ, and between the DMZ and the OT network. Traffic at this boundary has the highest security significance, all IT-to-OT communications and any cross-boundary movements are visible here.

Priority 2, Zone Boundary Uplinks: Network links at the boundaries between OT security zones. Traffic between the supervisory zone (SCADA, historians, HMIs) and the control zone (PLCs, DCS) should be monitored. Traffic entering or leaving the safety zone should be monitored.

Priority 3, Engineering Workstation Network Segment: Engineering workstations are high-value targets and initiate programming sessions to PLCs. Monitoring traffic from the engineering workstation segment provides visibility into any unauthorized programming activity, which maps directly to T0843 (Program Download) detection.

Priority 4, Control Zone Backbones: Core switch uplinks in the primary control zone provide visibility into the majority of control network traffic.

Priority 5, Remote Site Connections: WAN links connecting remote sites, unmanned substations, remote RTU sites, offshore platforms, to the central SCADA network.

Sensor Sizing

OT monitoring sensors must have sufficient processing capacity for the traffic volumes at their collection point. Underpowered sensors drop packets and provide incomplete traffic capture, which degrades detection coverage silently, you won't know what you're missing.

Calculate expected traffic volumes at each monitoring point. Polling-based protocols like Modbus and DNP3 generate regular, predictable traffic. Process historian data collection from many PLCs can generate substantial traffic. During engineering sessions, vendor maintenance, or configuration changes, traffic spikes significantly.

Deploy with 50% headroom above typical peak volumes. Sensor vendors publish throughput specifications; verify that the specified sensor hardware exceeds the peak traffic volume at the deployment point.

Protocol Decoder Configuration

Protocol decoders translate raw network packets into structured industrial protocol data that the platform can analyze and alert on.

Protocol Auto-Detection vs. Manual Configuration

Most platforms support protocol auto-detection: the platform observes traffic on known protocol ports and attempts to identify the protocol. Auto-detection is a starting point, not a final configuration. OT environments often include protocols running on non-standard ports, multiple protocols sharing the same port, and vendor-proprietary protocols with no standard port designation.

After auto-detection, review the protocol configuration and manually configure any protocols that were not automatically detected or were identified on non-standard ports.

Configuring OT-Specific Decoder Parameters

For each detected protocol, configure decoder parameters that enable the deepest inspection and most context-rich detection:

Modbus TCP: Configure the list of expected unit identifiers (device slave addresses) for each monitored segment. Alert generation for Modbus traffic to unknown unit identifiers helps detect reconnaissance and unauthorized device access.

EtherNet/IP CIP: Configure the list of expected Identity Objects for the monitored segment. Deviation from the known device list triggers new device detection. Configure permitted service code ranges for each device role (SCADA server, engineering workstation, operator HMI) to enable T0855 detection.

DNP3: Configure expected station addresses for master and outstation devices. Alert on unsolicited responses from unexpected stations and on operations from unexpected master addresses.

OPC UA: Configure expected server endpoint URLs and certificate subjects. Alert on connections to unexpected OPC UA endpoints and on certificate validation failures.

IEC 104 / IEC 101: Configure ASDU address ranges and permitted ASDU types for your substation network. Alert on commands from unexpected sources.

Vendor Protocol Considerations

Many OT vendors use proprietary protocols or proprietary extensions to standard protocols. Siemens S7 (ISO-TSAP over TCP/102), Rockwell PCCC (DF1 over EtherNet/IP), Honeywell FTE, and others require vendor-specific decoder support. Verify platform support for vendor-specific protocols present in your environment before deployment. Gaps in vendor protocol coverage mean blind spots in monitoring coverage, and blind spots are what attackers rely on.

Baseline Learning Period Management

Behavioral detection requires an established baseline: the platform must learn what "normal" looks like before it can alert on anomalies. Poorly managed baseline periods produce either poor detection coverage (too short) or excessive false positives (normal operational variations not captured in the baseline).

Baseline Period Planning

Minimum duration: 4 weeks. A shorter baseline will not capture the full range of normal operational variations including shift changes, batch cycle variations, and periodic vendor maintenance activities.

Recommended duration: 8-12 weeks for environments with complex operational patterns, seasonal processes, or infrequent maintenance cycles. Missing a maintenance activity that occurs every 6 weeks means that the first time it happens post-baseline, every action it generates will fire an alert.

Operational coverage requirements: The baseline must capture every distinct operational state that occurs in the environment, normal production at varying rates, planned maintenance activities, process startups and shutdowns, shift handover communication patterns, and automated batch sequences.

Coordinate with operations: Notify the operations team when the baseline learning period begins. Instruct them to perform all normal operational activities, including scheduled maintenance, during the baseline period. Abnormal activities should be noted in a baseline event log so they are not incorporated as "normal" patterns. This coordination is easy to skip and frequently regretted.

Baseline Quality Review

At the end of the baseline period, review before enabling behavioral alerting:

1. Communication pair coverage: Review the complete list of communication pairs observed. Are all expected pairs present? Are there pairs that should not be present, unrecognized IP addresses communicating with PLCs?

2. Protocol distribution: Does the observed protocol distribution match engineering expectations? Absent expected traffic may indicate a sensor placement issue or a too-short baseline period.

3. Traffic volume baseline: Review typical hourly and daily traffic volumes. The baseline should reflect the range from minimum (early morning off-shift) to maximum (peak production). If only one operational state was captured, the volume baseline is incomplete.

4. Outlier communications: Identify any communication pairs in the baseline that are unexpected and investigate before accepting them. Unknown devices communicating with PLCs should be investigated, not normalized.

Incremental Baseline Updates

After initial deployment, baseline updates will be needed as the environment legitimately changes: new devices, new data flows, engineering sessions for major logic changes. Most platforms support manual baseline updates that add specific new communication patterns without restarting the full learning period. Use this feature for legitimate planned changes; do not use it to suppress investigation of unexpected changes.

Alert Tuning Methodology

Newly deployed OT monitoring platforms generate high volumes of alerts until tuning is complete. Untuned alert volumes overwhelm analysts, lead to alert fatigue, and cause true positives to be missed among false positive noise. This is the most common failure mode for organizations that deploy a platform and then stop investing in it.

The Tuning Workflow

Phase 1, Alert triage and categorization (weeks 1-4 post-baseline): Review every alert generated in the first four weeks. For each alert, classify it as a true positive, a tunable false positive (legitimate behavior addressable by adjusting the alert rule), or an acceptance-required false positive (legitimate but unusual pattern that cannot be easily distinguished from malicious behavior by rule tuning alone).

Phase 2, Rule adjustment: For tunable false positives, adjust the alert rule to reduce the false positive rate while maintaining true positive sensitivity. Increase specificity, adjust thresholds, or add exception lists for known legitimate communication pairs.

Phase 3, Alert priority calibration: Reassign alert priorities based on observed behavior. Escalate to high priority the alerts that have consistently been true positives; reduce to medium those that are occasionally true positives; reduce to low the alerts that have been consistently false positives after tuning but should remain active for periodic review.

Phase 4, Ongoing tuning: Alert tuning is continuous. New equipment, operational changes, and software updates regularly introduce new legitimate communication patterns that generate false positives. Establish a monthly tuning review in the SOC operations calendar. Organizations that treat tuning as a one-time activity end up with analysts who have learned to ignore the platform.

False Positive Reduction Techniques

Communication pair whitelisting: Most platforms support explicit whitelisting of communication pairs (source, destination, protocol) that are known legitimate. Use whitelisting surgically, whitelist specific pairs, not broad subnets.

Time-based exceptions: If a specific alert type consistently fires during authorized maintenance windows, create a time-based exception that suppresses the alert during those windows while maintaining alerting at all other times.

Context enrichment: Enrich alerts with asset context (device type, zone, criticality) to enable priority-based filtering. An alert on a non-critical peripheral device may be lower priority than the same alert on a PLC directly controlling a critical process.

Protocol-specific threshold adjustment: Some alerts are triggered by volume thresholds. Adjust thresholds to match the actual traffic volumes observed for normal operation rather than vendor default values, which are typically tuned for generic environments.

SIEM Integration Architecture

Event Forwarding Configuration

Forward OT monitoring platform events to the SIEM in normalized format. Most platforms support CEF via Syslog, JSON via Syslog or HTTP, or native SIEM connectors (Splunk TA, Microsoft Sentinel data connector, QRadar DSM).

Verify that forwarded events include sufficient context: device name, zone, protocol, source and destination, and the ATT&CK technique reference where applicable. Test forwarding volume at peak alert generation rates. Configure a separate SIEM index or data stream for OT events, which enables OT-specific retention policies, access controls, and search optimization.

Cross-Domain Correlation Rules

The real value of SIEM integration is cross-domain correlation, connecting OT events with IT events to identify attack patterns that span both environments:

Failed IT login followed by OT access: Multiple failed authentication attempts on IT systems within a short window, followed by a new connection to an OT system from the same source IP. This pattern may indicate credential stuffing moving from IT to OT.

IT malware alert followed by OT workstation activity: An IT endpoint detection alert on an engineering workstation, followed within 24 hours by an unusual connection from that workstation to a PLC. Indicates potential engineering workstation compromise attempting lateral movement to controllers.

IT lateral movement followed by OT DMZ probe: Lateral movement indicators detected in IT (Mimikatz, PsExec activity), followed by connection attempts to OT DMZ addresses. Indicates adversary reconnaissance across the IT/OT boundary.

These cross-domain rules are among the most powerful detections available, they catch attacks at the transition point between IT and OT, before the attacker has fully established themselves in the OT environment.

Multi-Site Deployment Considerations

For organizations with OT monitoring at multiple facilities, deployment consistency and centralized visibility require additional planning.

Standardized Deployment Template

Develop a standard deployment template that defines sensor hardware specification per site traffic volume tier, TAP placement requirements, protocol decoder configuration standards for your vendor ecosystem, standard alert rule set and priority definitions, and SIEM forwarding configuration.

Apply the template consistently across all sites. Inconsistent deployments make cross-site comparison difficult and create monitoring coverage gaps at sites that deviated from the standard. When every site is different, operating the program at scale becomes very difficult.

Bandwidth Planning for Centralized Architectures

Most platforms forward decoded event data rather than raw packet captures to the central console, which significantly reduces bandwidth requirements. Estimate event rates per site, multiply by the normalized event size for your platform, and add 50% headroom for peak event rates during maintenance windows or incidents.

For sites on low-bandwidth connections, cellular, satellite, ensure event forwarding is prioritized but does not crowd out OT control traffic. Use QoS marking on event forwarding traffic or configure bandwidth limits on the forwarding channel.

Consistent Asset Context Across Sites

Multi-site asset inventories require consistent naming and zone taxonomy across sites: asset naming conventions that encode site, area, and device type; zone naming that is consistent across sites; and criticality ratings that apply consistent criteria. Consistent taxonomy enables cross-site search and analysis in the SIEM and the centralized monitoring console.

Conclusion

Deploying an OT monitoring platform is a multi-month process that produces durable, compounding security value when done correctly. The investment in proper sensor placement, thorough protocol configuration, careful baseline management, and systematic alert tuning determines whether the platform provides genuine detection capability or generates noise that analysts learn to ignore.

The monitoring program also delivers secondary benefits: the passive asset discovery builds the asset inventory needed for vulnerability management; the communication baselines inform firewall rule design; and the historical traffic data provides the forensic foundation for incident investigation. These benefits compound over time as the program matures.

Build the program with the disciplines described here from the start. Retrofitting discipline into a poorly deployed program is harder than deploying it correctly the first time.

Beacon Security provides OT monitoring platform deployment services, including sensor placement design, platform configuration, baseline management, alert tuning programs, and SIEM integration for industrial environments. Contact us to plan and execute your OT monitoring deployment.