Previous Series: Part 1: Executive briefing
Previous Series: Part 2: National Risk, Threat Landscape, and the First 30 Days
Jump to Part-7: State-Owned ICS Cybersecurity Blueprint
Part 3 turns that into architecture.
This is a target architecture for a state-owned ICS environment that also operates regular IT services.
It applies to power grids, water utilities, transport networks, refineries, ports, national manufacturing, and similar critical infrastructure.
For a power grid, map the zones to:
- corporate IT
- control center
- Energy Management System
- Distribution Management System
- substation automation
- protection relays
- generation plant control
- telecom and SCADA communications
- outage management and dispatch
- market and billing systems
- field crew systems
- national or sector SOC
The design objective is simple:
A compromise in one area must not become a national service disruption.
Executive summary for leaders
A strong ICS architecture has no uncontrolled shortcuts.
The design should ensure:
- enterprise IT cannot directly reach controllers
- vendors cannot land directly inside control networks
- cloud systems cannot control critical processes by accident
- identity compromise in IT does not automatically grant OT control
- safety systems are isolated and harder to modify
- every IT/OT flow has a business purpose, owner, approval, and logs
- monitoring observes OT without creating a new control path
- local operations can continue if enterprise IT or cloud services fail
If the architecture cannot support those outcomes, it is not ready for national critical infrastructure.
1. Design principles
Principle 1: safety and control first
Security controls must not create unsafe process behavior.
Every major architecture decision should be reviewed by cybersecurity, OT engineering, operations, and safety.
Principle 2: no direct enterprise-to-controller access
Corporate IT must not directly communicate with PLCs, RTUs, protection relays, safety controllers, or control networks.
Principle 3: controlled exchange through OT DMZ
Data exchange between IT and OT should pass through a controlled exchange layer.
That layer is the OT DMZ.
Principle 4: remote access is privileged access
Remote access into OT must be approved, MFA-protected, time-bound, recorded, and limited to named targets.
Principle 5: segment by consequence
A substation, turbine control cell, safety system, and office network should not share one flat trust zone.
Principle 6: monitor behavior, not just malware
ICS attacks often appear as abnormal control behavior, engineering activity, remote access, or protocol use.
Principle 7: local control must survive cloud or IT failure
For critical national services, cloud analytics and enterprise systems must not become dependencies for safe local operation.
2. Reference architecture
Use this conceptual model.
Internet
|
Public Edge / DDoS / WAF
|
+--------------+--------------+
| |
Public Services DMZ Remote Access Portal
citizen portals, APIs, MFA, PAM, approval,
email gateways device checks, recording
| |
+--------------+--------------+
|
Enterprise IT
identity, email, ERP, HR, finance, billing,
office endpoints, market systems, reporting
|
Enterprise SOC
SIEM, SOAR, threat intelligence, case management
|
IT/OT Boundary
firewalls, proxies, brokers, malware inspection,
approved conduits, optional one-way transfer
|
OT DMZ
historian replica, patch staging, file transfer,
update relay, log relay, jump access mediation
|
OT Operations Zone
SCADA, EMS/DMS, local historian, OT identity,
engineering workstations, operator services
|
+--------------------+--------------------+
| | |
Generation Cell Substation Cell Water/Process Cell
PLCs, turbine RTUs, IEDs, PLCs, RTUs,
controls, HMIs relays, gateways HMIs, analyzers
| | |
Physical process Physical process Physical process
turbines, breakers, breakers, feeders, pumps, valves,
transformers transformers dosing systems
Separate supporting zones:
- OT security monitoring zone
- backup and recovery zone
- out-of-band management zone
- physical security integration zone
- national CERT or sector SOC reporting path
- lab and test environment
Do not collapse these into one flat network.
3. Security zones and what belongs in each
Enterprise IT zone
Contains:
- corporate users
- ERP
- HR
- finance
- procurement
- billing
- user endpoints
- enterprise identity
- enterprise applications
- normal internet access
Allowed:
- read replicated operational data through approved reporting systems
- submit work orders and maintenance requests
- receive sanitized reports from OT historian replicas
- send approved logs to the SOC
Blocked:
- direct access to HMIs
- direct access to SCADA servers
- direct access to engineering workstations
- direct access to PLCs, RTUs, relays, and safety systems
- direct RDP, SMB, SSH, database, or industrial protocol access into OT
Public services DMZ
Contains public-facing services such as:
- citizen portals
- external websites
- public APIs
- DNS and email gateways
- WAF and DDoS protection
Rules:
- no direct trust into OT
- no shared credentials with OT
- no live control data access
- strong monitoring and rate limiting
- clear incident isolation plan
OT DMZ
The OT DMZ is the controlled exchange zone.
Use it for:
- historian replication
- patch staging
- antivirus or EDR update relay
- secure file transfer
- vendor package inspection
- jump access mediation
- log relay
- time synchronization relay where appropriate
- controlled data broker services
Do not use the OT DMZ as a flat bridge.
Do not place live control systems in the OT DMZ.
OT operations zone
Contains:
- SCADA servers
- EMS/DMS
- local historian
- operator services
- OT domain services where used
- engineering workstations
- OT management services
Rules:
- no direct access from enterprise users
- no uncontrolled internet access
- engineering activity logged
- remote access mediated by jump host
- internal segmentation to lower-level control cells
- backup and restore tested
Control cell zones
Each process cell, substation, plant unit, or control function should be segmented.
Examples:
- generation unit control cell
- substation automation cell
- protection relay cell
- water treatment dosing cell
- pump station cell
- turbine control cell
- distribution automation cell
- safety system zone
The purpose is blast-radius reduction.
A compromise in one control cell should not automatically expose the whole national infrastructure.
Safety and protection zones
Safety systems and protection systems require stronger isolation.
Controls:
- restrict inbound writes
- require approved engineering stations
- use physical separation or one-way transfer where feasible
- require stronger change approval
- monitor logic and setting changes
- keep offline backups
- validate restore procedures
- document safety impact before changes
For power environments, protection relays and substation automation deserve special attention because misconfiguration can affect grid stability.
4. Conduits and allowed flows
Every zone-to-zone connection is a conduit.
Every conduit needs:
- source
- destination
- protocol
- direction
- business purpose
- owner
- approval record
- logging requirement
- review frequency
- emergency shutdown process
Example: enterprise reporting
Good flow:
Corporate analyst
-> enterprise reporting application
-> OT DMZ historian replica
-> read-only replicated data
Bad flow:
Corporate analyst
-> live historian
-> SCADA server
-> controller network
Example: patching
Good flow:
vendor update source
-> enterprise download area
-> malware and integrity inspection
-> OT DMZ patch staging
-> OT patch server pulls approved package
-> lab or spare asset test
-> production maintenance window
Bad flow:
production HMI
-> direct internet update
Example: vendor support
Good flow:
vendor engineer
-> MFA remote access portal
-> approved time-bound ticket
-> recorded OT jump host
-> named engineering workstation
-> named target asset
Bad flow:
vendor VPN
-> broad OT subnet
-> direct Level 2 or Level 1 access
Example: SOC monitoring
Good flow:
OT sensors and logs
-> OT log relay
-> SIEM or security data lake
-> SOC investigation
Bad flow:
enterprise SOC tool
-> interactive management session into controllers
Monitoring should observe OT.
It should not accidentally become a control path.
5. Power grid reference mapping
For power-sector readers, the same architecture maps to common grid functions.
Generation
Secure:
- turbine control
- boiler or plant control
- excitation systems
- balance-of-plant systems
- safety and protection systems
- generation plant historian
- engineering workstations
Key controls:
- isolate generation control cells
- restrict engineering access
- protect local HMIs
- test restoration of control projects
- monitor controller writes and workstation access
Transmission control center
Secure:
- EMS
- SCADA front-end processors
- ICCP or inter-control-center communication
- telemetry systems
- operator consoles
- historian
- network management systems
Key controls:
- restrict external data exchange
- segment EMS support systems
- monitor operator and engineering access
- protect control center identity
- preserve manual and contingency procedures
Substations
Secure:
- RTUs
- IEDs
- protection relays
- station gateways
- engineering ports
- serial-to-IP converters
- telecom routers
- local HMIs
Key controls:
- segment substations from corporate networks
- restrict relay setting changes
- monitor firmware and setting changes
- remove unmanaged cellular modems
- protect physical access and cabinets
- collect logs where technically feasible
Distribution
Secure:
- DMS
- feeder automation
- reclosers
- capacitor banks
- outage management integration
- field crew access
- AMI/MDMS dependencies where applicable
Key controls:
- separate operational control from customer/billing systems
- govern field access
- segment AMI-related systems from core control
- monitor remote switching and automation commands
6. Identity and privileged access architecture
Identity architecture must prevent enterprise compromise from becoming OT control.
Recommended model:
- separate OT identity boundary where feasible
- controlled federation only where required
- MFA for remote and privileged access
- named engineer accounts
- named vendor accounts
- PAM for privileged sessions
- break-glass accounts vaulted and monitored
- service accounts documented and reviewed
- local legacy accounts vaulted with compensating controls
Minimum rules:
- no shared engineering account for routine work
- no shared vendor account
- no standing vendor access without justification
- automatic expiry for vendor sessions
- quarterly privileged access review
- monthly vendor access review
- alert on access outside approved window
Break-glass design
Break-glass access is necessary, but dangerous if unmanaged.
Required controls:
- unique account
- strong vaulting
- offline access procedure
- dual approval where feasible
- monitoring and alerting
- post-use review
- password rotation after use
- tabletop exercise to confirm it works
7. Remote access architecture
Remote access should follow this pattern.
user identity verification
-> MFA
-> device posture check where feasible
-> approval ticket
-> time-bound access
-> privileged access broker
-> recorded jump session
-> named OT asset
-> automatic termination
-> review and evidence retention
Required controls:
- MFA
- named users
- least privilege
- session recording
- file transfer control
- clipboard restriction for high-risk sessions
- no direct internet exposure of RDP, VNC, SSH, HMI, or PLC interfaces
- no unmanaged vendor tools
- source restrictions where feasible
- emergency access procedure
- monthly vendor access review
- alerting outside approved window
Failure mode to prevent:
vendor VPN connected
-> broad OT subnet access
-> compromised vendor laptop scans OT
-> attacker reaches engineering workstation
-> attacker reaches controller network
The fix is narrow, approved, recorded access to specific assets only.
8. Network security architecture
Enterprise to OT boundary
Controls:
- default deny
- explicit allow rules only
- no any-to-any
- no industrial protocols from enterprise
- no direct database access to live OT systems
- proxy or broker for approved services
- malware inspection for file transfer
- logging enabled
- quarterly rule review
- emergency block procedure
Internal OT segmentation
Controls:
- segment by Purdue level and process cell
- separate safety systems from basic control
- separate engineering workstations from operator HMIs where feasible
- separate remote sites and substations
- use industrial firewalls or switch ACLs
- restrict write-capable protocols
- monitor east-west traffic
- manage broadcast exposure
Wireless and cellular
Controls:
- inventory all wireless bridges, access points, and modems
- disable unapproved wireless
- use strong authentication and encryption where wireless is required
- segment wireless access
- monitor rogue access points
- remove undocumented 4G or 5G maintenance modems
- include wireless in physical inspections
Undocumented connectivity is one of the fastest ways to invalidate a good architecture.
9. Cloud, IIoT, and analytics
Cloud may be useful for reporting, analytics, predictive maintenance, and fleet visibility.
Cloud must not become an uncontrolled control path.
Minimum rules:
- replicate data outward through controlled gateways
- prefer one-way or brokered data flows for high-criticality systems
- do not expose controllers to cloud services
- do not allow cloud identity compromise to control OT
- encrypt data in transit and at rest
- use private connectivity where feasible
- use least-privilege service accounts
- monitor cloud API access
- classify data before export
- respect data sovereignty
- keep local control independent from cloud availability
Critical national systems must remain operable if cloud services are unavailable.
10. Security monitoring architecture
Deploy an OT monitoring zone.
Collect through:
- SPAN ports
- network TAPs
- packet brokers
- OT sensor appliances
- industrial switch mirrors
Log sources:
- OT firewalls
- remote access portal
- jump hosts
- VPN
- PAM
- OT identity
- Windows HMIs and servers
- engineering workstations
- Linux servers
- OT IDS sensors
- industrial switches
- backup systems
- physical access systems
- change management
- vulnerability platform
- cloud analytics platform
Correlations that matter:
- vendor login outside window plus engineering protocol traffic
- badge access after hours plus privileged login
- new host in OT VLAN plus PLC discovery
- HMI service restart plus new executable
- firewall rule change plus new IT-to-OT flow
- relay setting change outside approved window
11. Evidence required before architecture approval
Do not approve the architecture on a diagram alone.
Required evidence:
- current network diagrams
- zone and conduit register
- IT/OT flow register
- remote access register
- firewall rule export
- identity architecture
- vendor access procedure
- asset inventory
- backup and restore evidence
- monitoring coverage map
- incident response contact roster
- emergency isolation procedure
- exception register
- business owner approval
- OT engineering approval
- safety owner approval
The strongest architecture is the one that can be operated, audited, and restored.
12. Approval checklist
Approve the design only when these statements are true.
- Critical processes are identified.
- IT and OT are segmented.
- OT DMZ exists and is not a flat bridge.
- Enterprise users cannot directly reach controllers.
- Vendor access is MFA-protected, time-bound, recorded, and approved.
- Engineering workstations are controlled.
- Control cells are segmented.
- Safety and protection systems have stronger restrictions.
- Logs flow to monitoring without creating a control path.
- Backups are offline or immutable and tested.
- Cloud flows are controlled and non-critical to local operation.
- IT identity compromise cannot automatically become OT control.
- Emergency isolation mode is designed and tested.
- Firewall rules have owners and review dates.
- Exceptions expire and have compensating controls.
Takeaway
A state-owned ICS architecture should be boring by design.
No shortcuts.
No broad routes.
No unmanaged vendor paths.
No direct enterprise-to-controller access.
No undocumented modems.
No uncontrolled cloud dependency.
Every sensitive action should pass through an approved, monitored, and reversible path.
That is how architecture becomes national resilience.
Top comments (0)