Security Onion for ICS and OT network monitoring

A Security Onion sensor on an OT segment sees Modbus, DNP3, BACnet, OPC UA and S7 traffic only when those packets reach its capture interface, and it can be built to observe without sending commands to controllers. The sensor's NICs receive a copy of traffic from a mirror port, a network tap or a similar feed, and Zeek and Suricata parse the sessions from that copy. Zeek protocol analyzers for these protocols are the target for this work, but which analyzers ship in your Security Onion release, which are enabled by default, and which need custom parsers or packages must be confirmed against the documentation for the version you intend to install. Make that check the first item in your design review, because it determines how much protocol detail you get without extra engineering.

Sensor placement affects what you see more than the number of sensors does. Put sensors where zones meet: the boundary between the enterprise network and the OT zone, the boundary between control and supervisory zones, and any conduit that carries engineering access, historian replication or vendor remote sessions. A sensor on a single PLC switch sees a narrow set of polling conversations, while a sensor on a conduit sees the commands and responses that cross between zones. Start from your zone and conduit model, list the links that carry Modbus, DNP3 or S7 traffic, and give each sensor a named owner, a documented capture point and a reason tied to a specific conduit. Extra sensors inside one zone usually add duplicate views of the same conversations.

Most industrial switches copy traffic through SPAN or mirror sessions, and those features have limits you must check before designing around them. Confirm the number of simultaneous mirror sessions the switch supports, whether one mirror source can span several VLANs, whether the copy includes both directions, and how the switch behaves when the mirror port is busy. An oversubscribed mirror port drops frames without telling the sensor, which leaves gaps in protocol sessions that look like quiet periods. Ask the switch vendor for the mirror limits for your exact model and firmware, and record them in the design. Where SPAN cannot deliver a complete copy, a network tap on the conduit is the usual alternative, with added cabling, cost and a change window for installation.

Mirrored traffic must not add load to PLCs or HMIs, so test that before production capture starts. Passive capture does not send commands, but a mirror configured on a device port, a poorly chosen source or a switch with limited spare capacity can still change timing on a controller. Build the test in a staging segment or during an agreed maintenance window. Measure controller CPU, poll cycle times, HMI refresh behavior and alarm latency with mirroring off and then on, under normal and peak load. Have the operations owner set the acceptance criteria before the test starts, and keep a documented step that removes the mirror session. Confirm separately that the sensor runs no active scanning or probing against OT assets, since active checks carry their own risk and need their own approval.

The Distributed deployment type is the recommended production design for Security Onion. It separates the platform into a manager node, one or more sensor nodes and one or more search nodes. For an OT environment, that split matters because the sensors are the only components that need to sit close to the segments you monitor. Each sensor captures traffic from the segment it can see, so you can place sensors in the cells, zones or lines you need to watch while the manager and search nodes stay in a location your team can administer and protect. A Standalone install puts capture, indexing and console access on one machine, which concentrates the same risks in one place. Document which segment each sensor observes before you choose the number and location of sensors.

The architecture notes state that when the manager goes down, search nodes stop indexing because they cannot reach Redis. Sensors keep capturing traffic on their segments, but analysts should not expect new events to become searchable until the manager returns. Treat this as a planned outage scenario, not a background condition. Confirm with the Security Onion documentation how sensors hold data during a manager outage, how long they can hold it on local disk, and what happens to queued data when the manager comes back. Then test that behavior in a lab before you rely on it for an OT network where monitoring gaps must be explained to operations and compliance staff.

The architecture notes also say that receiver nodes add pipeline redundancy and load balancing. Receivers are a design decision, not a default you can assume is present. Decide whether the log path needs more than one receiver by listing every component that carries events from sensors to search nodes and asking which single failure would stop ingestion. The number of receivers should follow that analysis and the event volume each path must carry. Ask your Security Onion contact or review the architecture documentation to confirm how receivers are placed, configured and scaled in the version you plan to run, and record the answer in your design document.

The published hardware minimums are 4 cores, 12 GB RAM and 2 NICs for a sensor, and 4 cores and 16 GB RAM for a manager or search node. Security Onion supports only x86-64 processors. These figures are starting points for a lab or small deployment, not a sizing decision for a production OT network. Storage and retention must come from your own traffic: the bandwidth of each monitored segment, how many sensors feed each search node, how long you need full packet capture and indexed events, and how much the index grows over that period. Measure a representative segment during normal production operation, then size disks, memory and search capacity from those measurements and confirm the figures with your hardware vendor before you purchase.

Security Onion supports full installs on networks without internet access, so a plant network can stay isolated while the sensors and manager are built. The ISO carries the operating system packages along with the NIDS, YARA and Sigma rule sets, so a first install needs no outside connection. Later updates arrive as newer ISO media, which the soup tool applies in airgap mode. The decision to make early is who owns each boundary crossing, who approves the media, and how that approval fits your change management process. Confirm the airgap procedure in the vendor documentation for the exact version you plan to run before you schedule the first build.

Every package that crosses the boundary should be treated as a controlled item. On the connected side, download the ISO and any supporting files, record their checksums and verify the vendor signatures, then write them to approved media. Carry the media through your plant's scanning and approval steps, and verify the checksums again on the isolated side before soup or the installer touches anything. This is the control CIP-013-2 describes for supply chain risk management, which asks entities to verify the integrity and authenticity of vendor software and patches. Even if your plant is not a registered entity under that standard, the same evidence trail is useful. Keep the hashes, signature results and approvals in the change record for each transfer.

Rule updates follow the same media path. NIDS rules load into Suricata, Sigma rules load into ElastAlert and YARA rules load into Strelka, so each rule set reaches the isolated segment only when a new media set is imported. The rule freshness you achieve is therefore set by your transfer cadence, not by the sensor's connectivity. Keep local tuning separate from vendor content. Suppressions, threshold changes and modified NIDS rules made in the Detections interface should be documented with their reason, so you can review them after each update. Confirm how your version treats locally modified rules during an update, because a changed vendor rule can alter or override your tuning.

Plan rollback before the first soup run. Confirm the rollback steps, backup requirements and supported upgrade paths in the documentation for your version. In a distributed deployment, the architecture docs note that search nodes stop indexing if they cannot reach the manager's Redis, so update the manager first in a planned window and test the sensors and search nodes afterward. Security Onion 2.4 reached end of life on October 1, 2026. A 2.4 installation on Oracle Linux 9 can upgrade to 3 after Stenographer is replaced with Suricata for full packet capture, while other distributions need a fresh install. Settle your update cadence, media approval workflow and rollback test in writing before the plant depends on the system.