How ZoneSentry Works

The Core Idea

Every managed firewall on an OT network generates syslog. These logs contain a complete record of which devices are communicating, where they're reaching, what protocols they're using, and whether traffic was allowed or denied. This data is almost always ignored.

ZoneSentry ingests this syslog over an encrypted TLS connection, parses it, builds behavioural baselines for every device observed, and uses AI-powered analysis to flag anomalies — all without deploying hardware, installing agents, or touching the OT network.

Architecture

ZoneSentry is a multi-tenant platform. All firewall connections are encrypted over TLS. For firewalls that support it, mutual TLS (mTLS) using client certificates issued by ZoneSentry's private certificate authority provides cryptographic device authentication. Data from different tenants is isolated at every layer.

What We See

Any device that communicates across a firewall zone boundary is visible to ZoneSentry. For each connection, we capture:

• Source and destination IP addresses
• Source and destination ports
• Protocol (TCP, UDP, ICMP)
• Firewall action (allow, deny, drop)
• MAC address (when available from the firewall)
• Source and destination zones / VLANs
• Bytes transferred
• Timestamp (UTC)

From this data, ZoneSentry builds a device inventory, maps zone-crossing relationships, and constructs per-device behavioural baselines.

What We Don't See

ZoneSentry provides boundary-observed device inventory. A device that only communicates within its own VLAN — traffic that stays on local switches and never hits a firewall rule — is invisible to us.

For most OT environments with 8–30 devices on a flat VLAN, the boundary view catches the threats that actually matter: a device reaching the internet, talking to something in a different zone, or appearing where it shouldn't be. Intra-zone threats require deep packet inspection hardware at every site — that's what the enterprise platforms sell, and why they cost what they cost.

What If My Network Isn't Segmented?

Many OT environments — especially at junior producers and smaller operators — run flat networks without formal zone separation. If that's your situation, ZoneSentry still provides value, but the visibility model is different.

With a flat network, ZoneSentry monitors what crosses your perimeter firewall: which OT devices are reaching the internet, which external hosts are connecting inward, and what protocols are in use at the boundary. You get perimeter anomaly detection rather than inter-zone monitoring.

This is also the first step toward segmentation. ZoneSentry's device inventory and traffic mapping shows you exactly what's talking to what — which is the data you need to design a segmentation plan. Many operators start with perimeter monitoring and use ZoneSentry's baseline data to plan their first zone boundaries.

If you're working with an integrator to build segmentation, ZoneSentry's traffic map becomes the blueprint. And as you add zones, ZoneSentry's visibility grows automatically — no reconfiguration needed, just more firewall zone boundaries generating more syslog.

Device Profiling

When a new device appears, ZoneSentry identifies it via MAC OUI lookup (manufacturer), then searches its profile database for known make/model combinations. Profiles define what a device is expected to do:

• Expected protocols — what ports and protocols this device should use
• Expected destinations — internal only, internet-allowed, or specific hosts
• Expected peers — which other devices it should communicate with
• Red flags — behaviours that should always trigger an alert (e.g., SSH from a camera)

Profiles are confidence-scored. A curated profile (manually verified) scores higher than an AI-researched one, which scores higher than one generated purely from observed traffic. Alert aggressiveness scales with confidence.

Baseline & Anomaly Detection

Over the first 24–72 hours, ZoneSentry builds a behavioural baseline for each device: typical destinations, typical ports, typical communication peers, typical traffic volumes. As more data accumulates, the baseline becomes more confident.

The daily analysis engine compares recent activity against both the device profile (what this type of device should do) and the behavioural baseline (what this specific device normally does). Deviations generate alerts.

Alert Types

Alert Type	What It Means
Unknown device	A device appeared that hasn't been seen before
Unexpected protocol	A device used a protocol not in its profile
Unexpected destination	A device reached a host it has no business talking to
Unexpected peer	Two devices communicated that don't normally interact
Policy violation	Traffic crossed a zone boundary that policy doesn't allow
Baseline deviation	Traffic volume, timing, or pattern changed significantly

Every alert includes a plain-language narrative explaining what happened, why it was flagged, and what the operator should consider doing. Written by AI for humans who don't read packet captures.

Security Model

Syslog is transported over TLS 1.2+ on TCP port 6514 (RFC 5425). Each tenant firewall connects to a dedicated TLS endpoint. All connections are encrypted in transit. Where the firewall supports mutual TLS (mTLS), a unique client certificate issued by ZoneSentry's private CA provides cryptographic device authentication and the receiving endpoint verifies the certificate chain against an allowlist.

All data is stored in Canada.

Supported Firewalls

ZoneSentry works with any firewall that can send syslog over TLS. The parser architecture is modular — adding a new firewall brand is a drop-in module, not a platform change. If your firewall speaks syslog, we can support it.

Deployment

On the customer side, deployment requires one firewall configuration change: add ZoneSentry's endpoint as a syslog destination over TLS, import the CA chain, and install the client certificate. No hardware. No rack space. No power. No site visit required for remote locations.