Rhebo packet captures need an incident custody rule

Define what the capture can and cannot prove

The operating answer begins with the monitored conduit and physical mission. Rhebo's official page says its Industrial Protector can document network anomalies in packet-capture format. A packet capture can preserve observed traffic at a collection point; it cannot by itself establish every host, every communications path, the physical state of a plant, malicious intent, a process manipulation, or an incident cause. Record the site, zone, conduit, authorized collection point, clock source, capture window, filter, asset identifiers, network topology version, collector version, and expected traffic population before calling an observation an anomaly.

A mirrored stream may be incomplete, duplicated, altered by network architecture, or blind to alternate paths. A traffic burst can reflect startup, shutdown, maintenance, commissioning, failover, a vendor session, scheduled transfer, a fault, or an unauthorized change. The reviewing team should preserve its alternative explanations and engineering context. A product alert remains provider-generated analysis until an accountable asset owner and qualified incident team have reconciled it with independently available system and process evidence.

Protect the capture as a sensitive evidence object

Packet captures may contain operational identifiers, commands, credentials, proprietary process data, or information that could increase misuse risk if shared broadly. Set a site-approved collection purpose, minimum necessary scope, retention period, access roles, export conditions, encryption, evidence checksum, immutable copy rule, review log, and disposal authority. Keep the original capture, derived annotations, redacted share copy, and final incident record distinct. A SIEM event or dashboard summary should link back to the capture identity without requiring unrestricted access to raw traffic.

For an evaluation, use an authorized non-production or representative recorded scenario. Ask the provider to show a known network event, a routine operating-state transition, a duplicate mirror packet, an incomplete capture, a clock offset, and a collector gap. Inspect whether a reviewer can see source timing and filter rules, retrieve the original evidence, document a false-positive disposition, and hand an appropriately scoped record to plant engineering or incident response. Do not perform new collection, active queries, isolation, or blocking on a live system on the strength of this article.

Keep response authority beyond the NIDS

A validated observation may warrant investigation, but urgency and action depend on the asset's process role, current plant state, safety function, alternate controls, operational owner, vendor support, and recovery options. The owner should distinguish observed traffic, suspected anomaly, triaged security event, confirmed incident, engineering fault, and corrective action. Preserve who changed the classification, when, from which evidence, and what was left unresolved. An event number is not a control-system change ticket or proof that an intervention will be safe.

OT Defense Review reviewed the registered Rhebo page on September 15, 2026. Its statements establish provider positioning for passive monitoring, OT anomaly documentation, packet-capture records, and selected deployment options, not independent performance. No network, asset population, collector, capture, alert, SIEM integration, site incident, exploitation, process effect, safety outcome, response, certification, or compliance was tested. This is durable source-backed evidence-custody analysis, not a post-cutoff product-release claim or an operational procedure.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.