How to Send OT Logs Through a Data Diode to Splunk, Microsoft Sentinel or QRadar
Security teams want OT telemetry in the same SIEM as everything else. Operations teams will not accept an inbound path into the control network to deliver it. Both positions are correct, and a data diode is how the argument gets settled: telemetry leaves, nothing comes back, and the one-way property is enforced in hardware rather than by a rule somebody can change.
The concept is simple. The implementation is where projects stall, because most SIEM integrations assume bidirectional communication and a diode removes that assumption. This post covers the architecture that works. For the device itself, start with what a data diode is, and for the broader set of applications see our data diode use cases.
Why the obvious approach fails
Point a syslog forwarder at a diode and you will discover three problems in the first week.
- TCP needs acknowledgements. A diode cannot return them, because returning anything is the thing it exists to prevent. Any transport expecting a handshake fails outright.
- UDP syslog loses messages silently. It will traverse a diode, and under load you will drop events with nothing to tell you it happened. For security telemetry, silent loss is worse than no telemetry.
- SIEM agents expect to talk back. Most vendor agents check in, pull configuration and confirm receipt. None of that survives a one-way path.
|
What makes it work: proxies on both sides A working diode deployment terminates the protocol on the send side and reconstructs it on the receive side. A proxy inside the OT zone accepts normal TCP syslog from your sources, writes it to a queue, and streams it one-way across the diode. A second proxy outside receives the stream, reassembles it, and presents normal TCP syslog to the SIEM. Your log sources and your SIEM both believe they are talking to an ordinary collector. The diode sits in the middle and neither end needs to know. Every serious diode product ships this capability, and the quality of those proxies is the single most important thing to evaluate, far more than the raw throughput figure on the datasheet. |
The reference architecture
|
Component |
Role |
|
OT log sources |
Passive IDS sensors, switches, firewalls at the boundary, engineering workstations, historians. Send normal syslog to the internal collector. |
|
Internal collector and send proxy |
Inside the OT zone. Aggregates, normalizes, buffers to disk, and streams one-way. Disk buffering is what protects you during a SIEM outage. |
|
Data diode |
Hardware-enforced one-way transfer. No return path exists to be misconfigured. |
|
Receive proxy |
Outside the zone. Reassembles the stream and presents it to the SIEM in the expected format. |
|
SIEM |
Splunk, Microsoft Sentinel, QRadar or equivalent. Receives OT events alongside IT events. |
Five things to get right
- 1. Buffer on the inside. If the SIEM or the link is down, the internal collector must hold events on disk rather than discard them. Size the buffer for your worst realistic outage, not for an hour.
- 2. Sort out time before you start. With no return path you cannot run interactive time sync across the diode. OT sources need a reliable internal time source or your SIEM correlation will be worthless. This is the most common cause of a disappointing deployment.
- 3. Decide what crosses. Not everything. Security-relevant events, yes. Full packet capture, usually not, because volume and retention cost escalate fast. Our guidance on building an OT monitoring program covers what to collect.
- 4. Monitor the diode path itself. A one-way link that silently stops is a monitoring gap you will not notice. Generate a heartbeat event from inside and alert on its absence at the SIEM.
- 5. Accept that response stays inside. You now have visibility outside and no ability to act from there. Containment actions still require someone with access inside the zone, and your playbooks must say so explicitly.
What you give up, stated plainly
A diode removes the inbound risk and it removes inbound capability with it. No remote query of an OT asset from the SOC. No pushing a configuration change. No agent updates from outside. If your security operating model depends on reaching into the control network from a central console, a diode will break it, and the honest answer is to change the operating model rather than the diode. Where you need bidirectional control with inspection instead, the trade-offs are covered in data diode versus firewall.
Why Choose Arista Cyber
We design and deploy these paths on live plants, which means we size buffers against real outage history, solve the time synchronization problem before it bites, and write the response playbook that accounts for a one-way boundary. We supply OWA data diode appliances and passive OT intrusion detection, so the telemetry and the transport are designed together. See our case studies.
Next Steps
Decide what events need to cross before you specify hardware. The data selection drives the buffer sizing, the throughput requirement and the retention cost, and teams that specify the appliance first almost always buy the wrong size.
Common Questions
Can you send syslog through a data diode?
Yes, but not by pointing a forwarder at it. You need proxies that terminate the protocol inside the zone and reconstruct it outside, so both your log sources and your SIEM see a normal TCP collector.
Will a diode work with Splunk, Microsoft Sentinel or QRadar?
Yes. The SIEM does not need to know a diode is involved, because the receive-side proxy presents data in the expected format. The integration work is on the transport, not the SIEM.
What happens if the SIEM goes down?
The internal collector must buffer to disk and forward when the path recovers. Without disk buffering you lose events, which is why buffer sizing is a design decision rather than a default.
Can the SOC still respond to OT incidents?
They can see and investigate. They cannot act across the diode. Containment requires access inside the zone, and your playbooks need to state that explicitly rather than assume remote capability.
Should we send full packet capture across?
Usually not. Volume and retention costs rise steeply and most investigation needs metadata and security events rather than full capture. Select deliberately.
|
Want OT telemetry in your SIEM without an inbound path? Arista Cyber designs and deploys one-way telemetry architectures: event selection, proxy design, buffer sizing, time synchronization and the response playbook that works with a one-way boundary. |
Facing tougher cyber security challenges?
Talk to Arista Cyber about your OT security posture.
Request a consultation