Trust boundaries and segmentation

Mark where ownership, identity, permissions and physical control change across the system. Use those boundaries to plan segmentation and access rules.

Overview#

A trust boundary exists whenever administration, identity, exposure, physical access, assurance, tenancy, safety impact, or data sensitivity changes. VLANs and firewalls can enforce part of a boundary, but the boundary is an architectural fact, not a network feature.

Common boundaries#

• field wiring or radio to controller;
• device/edge network to site platform;
• video, access, alarm, intercom, BMS, and OT domains;
• control plane to observation/analytics plane;
• tenant/site to shared service;
• on premises to supplier or cloud service;
• production to commissioning/support tooling;
• human operator to automation/workload;
• supplier managed appliance to customer managed identity and logging.

Zone by consequence and authority#

Group assets by their trust, ownership and failure requirements. Useful separations include:

field devices
local controllers
recording and event services
integration/broker boundary
management and update services
operator clients
enterprise identity/SIEM
external/cloud/vendor support

A camera analytics service that only needs events shouldn't share the same path/account as firmware administration. A BMS dashboard that consumes door occupancy shouldn't automatically inherit door control authority.

Conduit record#

For every permitted flow, record source/destination roles and zones, initiator, protocol/version, service identity, authentication, authorisation, data classification, rate, availability, logging, owner, and expiry/review date. Default deny everything not represented.

When a legacy protocol lacks authentication or encryption:

• keep it within the smallest physical/network zone;
• restrict endpoints and direction at a protocol aware or tightly scoped gateway;
• prevent direct enterprise/cloud reachability;
• monitor expected operations and rates;
• protect commissioning ports and wiring;
• plan migration instead of describing isolation as equivalent security.

Identity plus segmentation#

NIST SP 800-207 states that network location or ownership must not create implicit trust. Apply user, device, and workload identity and operation level authorisation even inside a zone. Segmentation remains valuable for reducing reachability, containing failures, and supporting simpler policy; it doesn't replace identity.

Cross domain gateway#

A gateway should:

• terminate and authenticate both sides independently;
• expose only required operations and fields;
• normalise identities and enforce site/tenant scope;
• validate size, schema, semantic range, freshness, and authorisation;
• bound queues and rates;
• make loss, staleness, and partial failure visible;
• separate observation and actuation paths;
• produce tamper resistant audit with correlation IDs;
• fail to an explicitly designed state.

Avoid transparent bidirectional bridges between security and OT/BMS networks. Prefer a narrow exported data product or broker namespace, with any reverse command path separately justified and approved.

Availability and recovery#

Segmentation controls can fail closed, fail open, or fail ambiguously. Define local autonomy, redundant dependencies, maintenance bypass governance, certificate/identity outage behaviour, and out of band recovery. NIST SP 800-82 Rev. 3 emphasizes that OT safeguards must respect availability, reliability, and safety.

Validation questions#

• Can a compromised viewing client reach device management?
• Can an analytics tenant publish a control message?
• Can a vendor support identity operate outside its window/site?
• Does DNS, time, certificate, or identity outage break local control?
• Can the gateway distinguish stale replay from a new alarm?
• Are denied and unexpected cross zone attempts observable?

Section overview · Wiki home