System Components

1.1 System Architecture

The detailed zoning architecture expands the reference model into five distinct horizontal bands, each representing a security domain with defined trust levels, asset types, and communication constraints. This multi-zone design is the foundational structure that enables the "deny by default" security posture while preserving operational continuity for industrial processes. Each zone boundary is enforced by dedicated firewall policies, VLAN segmentation, and routing constraints that prevent unauthorized lateral movement.

The architecture places the Industrial DMZ as the critical buffer between the IT domain and the OT domain. Within the DMZ, all services are purpose-built for cross-domain brokering: the bastion/PAM host handles all remote maintenance sessions, the file transfer gateway enforces malware scanning for every file crossing the boundary, the historian relay replicates only approved data slices, and the syslog collector aggregates logs for SIEM forwarding without creating a direct path into OT. The O&M Access Zone is logically separated from the DMZ and connects only to DMZ targets, never directly to OT subnets.

Figure 1.1: Detailed Zoning Architecture — five horizontal bands showing IT Zone, Industrial DMZ (with IT-FW and OT-FW), O&M Access Zone, OT Core Zone, Control Zone, and Field Zone with all component placements and data flow directions.

Zone Definitions and Responsibilities

Each zone in the architecture carries specific responsibilities and enforces strict ingress/egress policies. The table below summarizes the key attributes of each zone, including the assets they contain, the communication flows they permit, and the primary security controls applied at each boundary.

Key Data and Control Flows

Understanding the directional constraints of each flow is essential for correct firewall policy design. The following flow descriptions define the approved communication paths and their associated security requirements. Any flow not explicitly listed in the approved flow matrix must be blocked by default.

• Field → Control: Real-time process I/O; deterministic, kept entirely within OT; no DMZ involvement.
• Control → OT Core: Supervisory data, historian writes, alarm generation; internal OT only.
• OT Core → DMZ: Replicated historian slices, events, logs; OT-FW enforces outbound-only policy.
• DMZ → IT: Sanitized datasets and dashboards; SOC logs; IT-FW enforces no direct write path to OT.
• Remote O&M: Vendor/engineer → MFA VPN → O&M Zone → Bastion → controlled target in OT Core/Control; all sessions recorded.
• Patch/AV Updates: IT staging → DMZ mirror → OT patch staging server; hash verification required at each hop.

1.2 System Components

The system is composed of boundary devices, OT-internal services, and supporting infrastructure. Each component has a defined primary responsibility, specific input and output interfaces, measurable KPIs, and known mismatch risks that must be addressed during design and procurement. The component inventory diagram below illustrates the three-tier structure and the data flows connecting them.

Figure 1.2: System Component Inventory — three-tier structure showing Boundary & DMZ components, OT Internal components, and Supporting Infrastructure with input/output flows and KPI indicators.

1.3 Working Principles

Startup Sequence

The system initialization follows a defined sequence to ensure that security controls are established before any cross-domain communication is permitted. Deviating from this sequence risks creating temporary open paths that may not be properly closed afterward.

1. Establish physical connectivity and power for boundary devices (firewalls, DMZ hosts).
2. Initialize HA pairs, verify heartbeat links and failover states.
3. Bring up DMZ services: bastion, file gateway, log collector, time relay.
4. Load baseline whitelist rules: "deny all" then allow only required conduits.
5. Validate OT internal routing remains unchanged except via defined gateways.
6. Perform functional tests and negative tests before declaring the system operational.

Normal Operation

During normal operation, all OT process traffic remains internal to the OT domain. Supervisory data is aggregated in OT Core and pushed to the DMZ via defined exporters. Remote maintenance flows terminate at the bastion; all sessions are recorded; file transfers occur through the scanning gateway only. The system is designed so that a failure of any DMZ service degrades functionality gracefully without opening unauthorized paths.

Exception and Recovery

The system must handle three primary categories of abnormal conditions, each with a defined response chain. These chains are documented as runbooks and validated through periodic drills.