GUARD DEVICES
OT Network Guard
Extend the operational life of in-service, certified equipment with an added layer of protection
Partner now
Overview
The challenge for OT
Operational technology in critical infrastructure is increasingly exposed to network-borne threats that it was never designed to withstand. The constraint is structural. Many devices cannot be patched without triggering recertification, locking known vulnerabilities in for the operational life of the equipment. The only available mitigations are network-layer controls external to the device.
Kry10's OT Network Guard is a physical inline appliance installed between an untrusted network and a protected OT device.
Product Description
-
A physical inline appliance installed between an untrusted network and a protected OT device.
-
Requires no modification to the protected device and no changes to its configuration or firmware.
-
Every packet passes through three inspection phases: rules-based ingress validation, formally verified protocol conformance, and operational policy compliance.
-
Packets that are not permitted, not conformant, or not compliant are detected and, if active filtering is commissioned, dropped before they reach the protected device.
How it works
Network Guard
Boundary inspection operates in both directions. Inbound traffic from the untrusted network must pass through all required inspection phases (see below) before it can reach the OT device.
Internet
Outbound traffic from the OT device is equally controlled. Commands and data leaving the protected system pass through equivalent inspection before they can reach the untrusted network.
PLC
Kry10's OT Network Guard is a physical inline appliance installed at the IT/OT boundary, where an untrusted network meets an OT device requiring protection. It requires no modification to the protected device at any stage: no firmware changes, no configuration alterations, and no network redesign.
Inspection Phases
Every data packet passes through three inspection phases:
-
Phase A
Rules-based validation. Firewall rules, checksum verification, IP/port match.
-
Phase B
Formally verified protocol parser. Every packet's payload is validated against a formally verified parser, generated from the official protocol specification by EverParse (Microsoft Research's verified parser framework). Parser correctness is proven, not tested. There are no untested edge cases.
-
Phase C
Stateful policy compliance. Message frequency, field value bounds, transaction pair matching against operator-defined operational policy.
Built on seL4® – a formally verified operating system kernel
OT Network Guard’s operating platform is KOS, built on seL4® – a formally verified operating system kernel, whose isolation and security properties have been mathematically proven.
Other application-specific OT firewalls run on general-purpose operating systems and inherit the associated attack surface. A vulnerability in the underlying OS can undermine and disable any protection entirely. Formally verified isolation, provided by the KOS platform, prevents faults from crossing component boundaries.
Network Guard Configurations
Network Guard comes in a base configuration. Options governing traffic and data movements can be layered on top, depending on client requirements.
Configuration 1
Base Configuration
Every message between the two sides passes through the one Guard, in both directions, and is inspected before it is delivered. There is no physical barrier, bad traffic is prevented based on what the Guard chooses to allow or block.
Configuration 2
Additional Observability
A second, physically separate link can be added to provide observability to your OT team. Not even a fully compromised OT device can send anything back through the data diode.
Configuration 3
Additional Encryption
A VPN can be added to the same set-up, allowing encrypted remote access.
Future Configuration 4
Control AI Loop
A future configuration will add an AI module to the chosen Guard/Diode configuration. The AI continuously reads telemetry from the trusted control network, building a live model of expected behavior and feeds that back to the trusted control network through the Guard. Anomalies or control decisions can be automated.
Future Configuration 5
Assured Reserve Mode Architecture (ARMA)
A future configuration adds an ARMA, an independent safeguard on the protected asset itself, that can act independently of the network, Guard or AI to stop the asset being driven into a damaged state.
Other solutions
