TroutTrout

OT microsegmentation that feeds your SIEM.

How to deploy OT microsegmentation as an overlay, and send the alerts, flows, and audit events straight to your SIEM. No agents, no rewiring, no downtime.

Last updated:

The short answer

To do OT microsegmentation in practice, you add an overlay next to your network. It splits the network into small zones and controls exactly which device can talk to which, on what protocol, and when. Every session is logged and sent to your SIEM. No agents on the equipment, no rewiring, no downtime. Trout Software's Access Gate works this way.

The architecture

An overlay, four jobs

Discover

Builds the asset and flow baseline passively: it listens on the overlay and a span or tap and does no active polling or probing of the equipment, so fragile controllers are never touched. That baseline is what your zones are drawn from.

Zone

Splits the network into logical zones (IEC 62443 zones and conduits). Each zone has clear rules: which device, read or write, which protocol, which hours. No VLAN redesign.

Enforce

Checks every connection, ties it to a person, and allows only the flows you declared. Everything else is blocked and logged.

Feed the SIEM

Sends alerts, flows, and audit events to your SIEM over syslog, so your SOC finally sees what happens inside OT.

One design choice matters: the overlay runs next to the network, not in the middle of it. Cyclic controller-to-I/O traffic stays on the underlay; only routable supervisory, engineering, and vendor sessions ride the overlay. So if the appliance goes down, the running process does not: local controllers and HMIs keep going, and the cyclic loops never traversed enforcement in the first place. For the governed north-south sessions, fail-open versus fail-closed is a per-asset, logged decision, and the appliance runs as a high-availability pair so a single fault is not a single point of failure.

Enforcement is at the function-code level, from parsing the protocol on the wire, not from trusting the port. Concretely: a chem-feed vendor can read the chlorine analyzer (Modbus FC3, read holding registers) but cannot write the dosing setpoint (FC6 or FC16, write registers) on port 502. Same session, same protocol, one allowed and one denied, because the overlay reads the request rather than just routing it. See what is an industrial proxy, PLC security, IEC 62443 zones and conduits, and agentless Zero Trust for OT.

SIEM integration

How it connects to your SIEM

Access Gate sends events over TCP syslog. Splunk, Elastic, IBM QRadar, and Microsoft Sentinel accept them out of the box, with no custom connector. You pick which detection rules forward, and each event carries four fields you can filter and alert on.

Field
Event
What it holds
What happened, in plain text (a login, an access, a blocked flow)
Use in the SIEM
Audit trail, incident timeline
Field
MITRE technique
What it holds
The MITRE ATT&CK technique the rule maps to
Use in the SIEM
Threat detection, correlation
Field
Source
What it holds
Who or what triggered it (the principal and its IP)
Use in the SIEM
Attribution, alerting
Field
Rule
What it holds
The detection rule that fired
Use in the SIEM
Filtering, saved alerts

Setup is a syslog destination on the Access Gate side and a TCP input on the SIEM side. Because the events are identity-bound, they double as audit evidence for CMMC, NERC CIP, NIS2, and the New York DOH and DEC water rules. The step-by-step guides are linked at the bottom of this page.

How it compares

Overlay microsegmentation vs the alternatives

Approach
Firewall / VLAN segmentation
What it does
Splits the network into zones and filters north-south by IP and port at the boundary.
Where it falls short in OT
A VLAN tag is an organizational label, not identity. It cannot tell a Modbus read from a write, and re-VLANing a live plant means downtime.
Approach
Agent-based microseg (Illumio, Guardicore)
What it does
Enforces host-to-host policy with a software agent on each workload.
Where it falls short in OT
Most OT controllers, HMIs, and validated EWS cannot host an agent and cannot be taken offline to install one. Coverage stops at the assets that can run the agent.
Approach
Passive OT visibility (Claroty, Nozomi)
What it does
Listens on a span or tap and builds an asset inventory and anomaly baseline.
Where it falls short in OT
Excellent for seeing, but it does not enforce. It tells you a bad write happened; it does not stop it. Detection without an enforcement point.
Approach
Overlay microsegmentation (Access Gate)
What it does
Adds an agentless overlay next to the network, brokers governed north-south sessions with identity, and enforces per-flow rules at the function-code level.
Where it falls short in OT
Governs routable north-south access, not the cyclic control loop, which stays on the underlay by design. That boundary is deliberate, not a gap.

Visibility tools and an enforcement overlay are complementary, not either-or: many sites run a Claroty or Nozomi sensor for inventory and feed both it and the SIEM from the overlay.

Questions

Architecture and SIEM, answered

You add an overlay next to your existing network. It splits the network into small logical zones (aligned to IEC 62443 zones and conduits) and controls exactly which device can reach which, on what protocol, and during which hours. Every allowed flow is spelled out, and every blocked flow is logged. Because the overlay does not renumber the network or touch the equipment, you avoid the VLAN redesign and downtime a traditional segmentation project needs.

Access Gate sends its events to your SIEM over TCP syslog (RFC 5424). Splunk, Elastic, IBM QRadar, and Microsoft Sentinel accept them out of the box, with no custom connector. You choose which detection rules forward, and each event carries four fields: the event description, the MITRE ATT&CK technique, the source, and the rule that fired. That gives the SOC the OT context it usually lacks.

No. An overlay enforces segmentation at the network layer, so it needs no software on PLCs, HMIs, or SCADA servers. That matters in OT, where most controllers cannot run an agent and cannot be taken offline for one. Access Gate is agentless and deploys without rewiring or a maintenance window.

Alerts, flows, and audit events. In practice that is access and login alerts, session and flow records with full attribution, rule detections tagged with their MITRE ATT&CK technique, and blocked-flow events. Because the events are identity-bound, they are usable directly as audit evidence for CMMC, NERC CIP, NIS2, and the New York DOH and DEC water rules, not just for alerting.

Because the overlay needs no rewiring and no agents, a standard-sized site is usually protected in about four days: map the network and assets, define the zones and rules, enforce them, then point the event stream at the SIEM. You get visibility from day one and harden the zones step by step, without stopping production.

Events go out as RFC 5424 syslog over TCP. For IBM QRadar you can emit them as CEF (Common Event Format) or LEEF (Log Event Extended Format), the two key-value formats QRadar's DSMs parse without a custom connector, so fields like the MITRE ATT&CK technique and the principal land in the right QRadar properties. Splunk, Elastic, and Microsoft Sentinel ingest the RFC 5424 stream directly.

Access Gate logs access, session, flow, and blocked-flow events, not raw packet capture, so the volume tracks how many governed north-south sessions you have, not total OT traffic. That keeps events-per-second and SIEM licensing far below a span-port firehose. Size it from your session count during the pilot rather than from a rule of thumb, and forward only the detection rules you care about to trim it further.

Each rule detection is tagged with the ATT&CK for ICS technique it maps to, so the SOC gets OT context it usually lacks. Typical coverage includes unauthorized command messages (T0855), modify parameter (T0836), and the remote-access and lateral-movement techniques that precede them. The tag rides in the event, so you can correlate OT detections against the same ATT&CK matrix you already use for IT.

Yes. The syslog destination is not exclusive: you can fan out the same event stream to your SIEM for detection and to a historian, data lake, or long-term archive for retention and audit. The two paths are independent, so a SIEM outage does not cost you the audit record.

Retention is a SIEM-side and archive-side policy, not something the overlay caps. Because the events are identity-bound audit records, most teams keep them to satisfy the longest applicable rule, commonly one year or more for NERC CIP, CMMC, and NIS2 evidence. The dual-destination pattern lets you keep hot data in the SIEM and cold data in cheaper storage.

The overlay runs next to the network, so cyclic controller-to-I/O traffic never depended on it and keeps running regardless. For the governed north-south sessions, fail-open versus fail-closed is a per-asset, logged decision, not a global default: a historian collection path might fail-open to preserve continuity while a vendor path fails-closed. Access Gate runs as a high-availability pair so a single fault is not a single point of failure, and the break-glass path is authenticated and logged. During any enforcement gap the honest answer is that brokered-session events are not recorded for that asset, which is exactly why the HA pair and the logged break-glass path exist.

The second layer of value

Access Gate secures your assets first, then exposes the simple services your teams and vendors actually want, so they run through the sanctioned path, not around it.

OT runs through you, not around you.