Commissioning OT Cybersecurity Monitoring for Visibility

The dashboard shows missing assets, incomplete communication paths, or recurring alerts that operators cannot act on. Treat those symptoms as commissioning defects first: establish ownership, place collection points where the traffic actually flows, complete the asset model, and tune detections against approved operations. Nozomi, Claroty CTD, Dragos, Armis, and comparable OT monitoring platforms depend on the same foundation—representative network visibility and accurate operational context.

Commissioning Ownership and Acceptance Criteria

Before anything else, confirm who owns each part of the deployment. A platform can discover traffic automatically, but it cannot resolve undocumented serial devices, assign meaningful asset names, approve communication flows, or decide whether an alert represents normal process behavior.

1. List the monitored sites, networks, serial segments, and required asset classes.
2. Name an owner for capture infrastructure, asset enrichment, alert review, and OT validation.
3. Define completion in measurable terms: monitored segments, reconciled assets, approved flows, and tested alerts.
4. Reserve controls-engineering time for symbolic naming, topology correction, device-level query review, and alarm disposition.

Do not move on until each responsibility has an owner and the team can state what evidence will close commissioning.

Traffic Capture Placement

Configure visibility from observed traffic paths, not from the logical network drawing alone. A SPAN on a core OT switch commonly reveals north-south traffic crossing that switch while missing east-west traffic exchanged between field devices on another switch or local segment. Adding dashboard licenses cannot recover packets that never reach a sensor.

1. Map each required communication path from source interface to destination interface.
2. Mark every switch, routed boundary, local cell, remote field network, and serial gateway traversed by that path.
3. Place a SPAN source or network tap at a point that carries the required traffic. Use additional collection points where local exchanges bypass the core.
4. Check for asymmetric routing. A collector that sees only one direction may identify endpoints while failing to reconstruct sessions reliably.
5. Compare the collector input with switch-interface counters and a controlled packet capture. Look for missing VLANs, unexpected filters, one-way conversations, and capture oversubscription.

A SPAN session is a copied observation feed, not a substitute for the forwarding path. Its destination must receive the intended source ports or VLANs without becoming a bottleneck. Do not move on until a known request and its response are visible for every representative monitored segment.

IP and Serial Asset Reconciliation

IP-based assets can populate quickly when the platform sees their conversations. Serial assets require a different workflow because they may sit behind gateways, lack an IP identity, or remain invisible to an Ethernet collector. Large serial deployments can demand hundreds of hours of manual inventory work; one utility deployment required manual treatment for thousands of serial assets.

1. Export the discovered IP inventory and group records by segment, address, protocol role, and observed peer.
2. Compare those records with PLC hardware configurations, HMI communication setups, gateway mappings, panel drawings, and field surveys.
3. Resolve documentation conflicts at the configured endpoint. Drawings can lag the hardware and PLC configuration.
4. Create manual records for serial devices that passive Ethernet monitoring cannot identify individually.
5. Record each serial device’s parent PLC, gateway, or communication module so the inventory represents the control path rather than an isolated name.
6. Assign symbolic names that operators recognize, then remove or merge duplicates only after checking addresses and communication relationships.

Do not move on until every required asset is discovered or manually represented, linked to its communication parent, and reconciled against installed configuration.

Asset Context, Queries, and Communication Zones

Populate the operational context that turns packet observations into usable security findings. Turnkey discovery does not eliminate the need to configure device-level queries, symbolic names, communication zones, and accepted traffic relationships.

1. Assign each asset a functional name, equipment role, location, owner, and process association using the fields available in the selected platform.
2. Enable device-level queries only after the controls owner reviews how the query reaches the device. Where passive identification is sufficient, avoid adding active traffic solely to improve labels.
3. Create zones that match operational boundaries such as site, process area, control layer, or field network. Base them on actual routing and switching behavior.
4. Review observed flows between zones. Mark legitimate control, engineering, maintenance, and supervisory communications according to the platform workflow.
5. Investigate undocumented flows before accepting them. Identify the source, destination, service, equipment owner, and process purpose.

Zone quality depends on capture quality. A missing east-west feed can make a zone appear quieter than it is and produce a false baseline. Do not move on until a controls engineer can select a representative asset and identify its correct name, zone, peers, and process role from the dashboard.

Alert Baseline and Triage Workflow

Commission alerts with OT participation. Security staff can manage queue discipline and escalation, while controls engineers determine whether a new communication pattern, device query, or asset change matches the process. Leaving all dashboard work with either group creates a gap: IT may lack process context, while controls staff may lack time for continuous queue management.

1. Start the baseline only after representative capture points and asset records are in place.
2. Review recurring alerts by asset, zone, traffic direction, and operational state.
3. Classify each finding as expected behavior, a configuration problem, an investigation item, or an approved exception.
4. Correct the underlying zone, asset, or visibility error before suppressing an alert.
5. Assign an escalation route for findings that can affect control equipment or process availability.
6. Repeat the review during representative operating modes. A baseline limited to one production state will miss legitimate changes seen during maintenance, startup, or other scheduled operations.

Tuning can require sustained work; a reasonably large Nozomi site took nearly a month of focused effort. Plan that work as a commissioning phase rather than incidental dashboard maintenance. Do not move on until recurring alerts have owners and dispositions, and a new unexplained flow remains visible for investigation.

End-to-End Verification

Prove the complete chain from packet visibility to human response. Asset count alone is not an acceptance test because a platform can list endpoints while missing local conversations, serial children, or actionable context.

1. Select one representative IP asset from each monitored segment and one manually modeled serial path where serial networks exist.
2. Generate or observe an approved communication exchange and confirm that both endpoints, direction, protocol role, and zone relationship appear correctly.
3. Trace an east-west exchange that remains local to a field segment. Confirm that the designated capture point sees it rather than assuming the core SPAN does.
4. Compare a representative device record with the installed PLC, gateway, or network configuration and correct any topology mismatch.
5. Use an approved test condition or platform test facility to exercise the alert workflow without disrupting control. Confirm detection, queue assignment, OT escalation, disposition, and retention of the investigation record.
6. Review platform health after the test and verify that collectors continue receiving traffic from every required feed.

Accept the deployment only when the test communication is visible at the intended collector, the assets and zones are correct, the serial path is represented, and the test finding reaches the assigned responder.

Frequently Asked Questions