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. Each customer's firewall authenticates via mutual TLS (mTLS) using a unique client certificate issued by ZoneSentry's private certificate authority. Only firewalls with valid certificates can connect. Data from different tenants is isolated at every layer.
Outside the control loop. ZoneSentry receives a copy of firewall logs. It never sends commands to firewalls, never modifies rules, never injects traffic. It's a passive observer of boundary traffic — the monitoring equivalent of reading the security camera feed, not operating the door locks.
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.
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 authenticates with a unique client certificate issued by ZoneSentry's private CA. The receiving endpoint verifies the certificate chain, checks the Common Name against an allowlist, and checks the certificate against a revocation list before accepting any data.
All data is stored in Canada. The intermediate CA private key is encrypted at rest using LUKS full-volume encryption. The root CA exists only on an offline, physically secured USB device.
Supported Firewalls
ZoneSentry works with any firewall that can send syslog over TLS. Current parser support:
- Ubiquiti UniFi — UDM Pro, USG (production parser)
- Sophos — XGS / SFOS (in development)
- FortiGate — FortiOS 6.2+ (in development)
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.
Time to first alert: Most customers see their device inventory populated within hours and receive their first behavioural baseline within 24 hours. The AI analysis engine runs daily.