One-Way Log Forwarding to a SOC: Telemetry Without a Return Path

01Key takeaways

1. 01

   Monitoring should not require an inbound route into the protected network; the telemetry can move outward instead.

2. 02

   One-way log forwarding sends logs and events to a SOC while removing the reverse path through that channel.

3. 03

   Push-based forwarding (syslog, file export, packet metadata) fits one-way transfer better than pull-based collection.

4. 04

   You give up remote query and remote management through that path, which must be handled by a separate controlled process.

5. 05

   Buffering and integrity checks are essential so gaps and corrupted transfers are visible rather than silent.

02The inbound-monitoring-path problem

Many monitoring designs assume the collector can reach the monitored system. In IT that is often acceptable. In OT, where the goal is to reduce unnecessary reachability, an inbound collection path works against the architecture.

An inbound monitoring route is still a route. It can be misconfigured, its credentials can be stolen, and it can be reused for lateral movement. If the only reason it exists is to retrieve logs, it is worth asking whether the logs can simply be pushed out instead.

The question to ask: does the SOC need to reach in, or does it only need the data to come out?

03What one-way log forwarding is

One-way log forwarding is a publication-only pattern. The protected network sends logs and events across a boundary that enforces direction, so the SOC receives data without any ability to initiate traffic back through that channel.

The boundary can be a data diode or unidirectional gateway for the strongest separation, or a controlled connection that is offline by default and opens only to push data. In both cases the design intent is the same: telemetry leaves, nothing returns through the same path.

04Forwarding patterns that fit one-way transfer

Syslog push

Devices and collectors emit syslog outward to a forwarder that relays it across the one-way boundary to the SOC's collector.

File-based export

Logs are batched into files and replicated one way, which suits environments where continuous streaming is not required.

Packet metadata

Flow records or packet metadata are forwarded for network visibility without sending full captures or opening a query path.

Event normalization at the edge

A forwarder normalizes and filters events before sending, reducing volume and avoiding the need for the SOC to query back for context.

05What you give up, and how to handle it

One-way forwarding removes the reverse path on purpose, so anything that depended on that path needs a different home.

• Remote queries into devices for ad-hoc investigation must be handled by a separate, controlled access process rather than the monitoring channel.
• Remote configuration or management cannot ride the log path; it needs its own governed conduit.
• Two-way SIEM features such as active polling or response actions toward OT assets must be redesigned or scoped out.
• Acknowledgement-based delivery is replaced by buffering and integrity checks, since the receiver cannot confirm back across the boundary.

None of this weakens monitoring; it separates monitoring from control. The SOC still sees the environment, but seeing it no longer requires a way in.

06Buffering, gaps and proving delivery

Because the receiver cannot acknowledge across a one-way boundary, the forwarding design must make loss visible rather than silent.

• Buffer on the send side so a brief SOC outage does not drop events.
• Sequence and checksum batches so the SOC can detect missing or corrupted segments.
• Emit heartbeat or counter records so a gap in telemetry is itself an alert.
• Monitor forwarder health locally, inside the protected zone, without exposing a management path to the SOC.

For environments that prefer an offline-by-default boundary over a permanently connected one-way link, an AIRGAPNET controlled connectivity approach can schedule the export window and keep the channel disconnected the rest of the time.

07One-way log forwarding checklist

• Which logs and events must reach the SOC, and at what latency?
• What enforces direction on the forwarding boundary?
• How are buffering, sequencing and integrity handled so gaps are detectable?
• Where do investigation and response live now that the monitoring path is one-way?
• How is the forwarder itself monitored without creating an inbound route?
• Can the team prove which events were sent and when?

08Closing thought

Good monitoring does not require a door into the thing you are monitoring. By forwarding telemetry one way, a SOC can keep full visibility while the protected network keeps a boundary with no return path.

Design the data out first, then deliberately decide where investigation and control will live. The result is monitoring that adds visibility without adding reachability.

FAQFrequently asked questions

SRCSources of record