Architecture without implementation is just a diagram.
Previous Series: Part 1: Executive Briefing
Previous Series: Part 2: National Risk, Threat Landscape, and the First 30 Days
Previous Series: Part-3: Target Architecture for IT, OT, Cloud, and Power Grid Environments
Jump to Part-7: State-Owned ICS Cybersecurity Blueprint
This is written for CISOs, security architects, procurement teams, SOC managers, OT engineers, and government program owners who need to build a real security capability.
The message is direct:
Do not buy tools first.
Define the control.
Define the enforcement point.
Define the owner.
Define the evidence.
Then select the tool.
Executive summary for leaders
A national ICS cybersecurity program needs technology, but technology alone will not protect the plant.
Each tool must answer:
- What risk does it reduce?
- Where is it enforced?
- Who operates it?
- What evidence proves it works?
- What happens if it fails?
- Can it operate safely in OT?
- Does it support recovery during a crisis?
If the answer is unclear, the tool is not ready for critical infrastructure.
1. Control architecture model
Every control should be documented using this format.
Control ID:
Control objective:
Risk reduced:
Enforcement point:
Technology examples:
Owner:
Evidence:
Failure mode:
Residual risk:
Example:
Control ID: OT-RA-01
Control objective: prevent uncontrolled vendor access to OT
Risk reduced: third-party compromise leading to controller or HMI access
Enforcement point: remote access portal, MFA, PAM, jump host, firewall
Technology examples: CyberArk, BeyondTrust, Delinea, Fortinet, Palo Alto, Duo, Okta
Owner: OT security and vendor manager
Evidence: access ticket, session recording, VPN log, monthly account review
Failure mode: vendor receives broad subnet access or account remains active after contract ends
Residual risk: vendor endpoint compromise may still occur, so session monitoring remains required
This level of clarity separates real security from policy language.
2. Asset inventory and visibility
Control objective
Know every critical OT asset, its owner, location, function, software or firmware version, communication path, and process impact.
Tools and technology examples
- Nozomi Networks
- Dragos Platform
- Claroty
- Microsoft Defender for IoT
- Forescout eyeInspect
- Tenable OT
- Security Onion with Zeek for teams that can operate open-source tooling
- industrial network switch exports
- engineering workstation project files
- CMDB or asset database
Required evidence
- critical asset inventory
- unknown device list
- firmware and software inventory
- zone assignment
- owner assignment
- criticality rating
- remote access dependency
- backup status
- unsupported asset list
- inventory reconciliation record
Failure mode
A passive discovery tool identifies networked assets but misses offline controllers, serial devices, spare PLCs, relay settings, or undocumented engineering laptops.
Required operating practice
Combine passive discovery with engineering walkdowns and configuration review.
Do not treat tool discovery as complete truth.
3. Network segmentation
Control objective
Prevent compromise in one network zone from spreading into critical control zones.
Enforcement points
- IT/OT firewalls
- OT DMZ
- industrial firewalls
- router ACLs
- switch ACLs
- VLANs
- data diode or unidirectional gateway where appropriate
- proxy or broker services
- jump hosts
Tools and technology examples
- Fortinet FortiGate and FortiSwitch
- Palo Alto Networks NGFW
- Check Point
- Cisco Secure Firewall and industrial networking
- Tofino Xenon
- Belden / Hirschmann
- Siemens Scalance
- Ruggedcom
- Waterfall Security or Owl Cyber Defense for unidirectional use cases
Required evidence
- zone and conduit diagram
- firewall rule export
- rule owner
- business justification
- review date
- approved exception list
- blocked direct enterprise-to-controller path evidence
- segmentation test result
Failure mode
The organization has a firewall between IT and OT but keeps broad rules such as:
source: enterprise network
destination: OT network
service: any
purpose: support
That is not segmentation.
That is an attack path with a firewall in front of it.
4. Remote access and vendor access
Control objective
Ensure all remote OT access is authenticated, approved, recorded, limited, and time-bound.
Enforcement points
- remote access portal
- MFA
- PAM
- jump host
- firewall
- ticketing workflow
- session recording
- vendor account lifecycle
Tools and technology examples
- CyberArk
- BeyondTrust
- Delinea
- Teleport for controlled access where appropriate
- Fortinet ZTNA or VPN
- Palo Alto GlobalProtect
- Cisco Secure Access
- Duo
- Okta
- Microsoft Entra ID
- ServiceNow or Jira for approval workflow
Required evidence
- approved access ticket
- MFA log
- session recording
- target asset list
- access start and end time
- vendor account review
- emergency access review
- monthly access attestation
Failure mode
Vendor VPN provides broad OT subnet access.
Required fix
Vendor access should land on a controlled jump host and then only reach named target assets during an approved window.
5. Identity and privileged access
Control objective
Prevent credential compromise from becoming OT control.
Enforcement points
- separate OT identity boundary
- MFA
- PAM
- group policy
- local account vaulting
- privileged role review
- break-glass process
- service account governance
Tools and technology examples
- Active Directory with separate OT forest
- Microsoft Entra ID with careful federation design
- CyberArk
- BeyondTrust
- Delinea
- Thycotic/Delinea Secret Server
- Duo
- Okta
- Ping
- Microsoft LAPS or Windows LAPS for local admin management
Required evidence
- privileged account list
- access review sign-off
- service account register
- break-glass test record
- MFA enforcement report
- PAM session log
- local admin password management evidence
Failure mode
Corporate Active Directory compromise provides direct access to OT workstations.
Required fix
Create separation, enforce MFA and PAM, remove unnecessary trust, and restrict privileged access to approved administration paths.
6. Endpoint and engineering workstation security
Control objective
Protect HMIs, SCADA servers, historians, and engineering workstations from malware, unauthorized software, credential theft, and unauthorized engineering activity.
Enforcement points
- hardened OS baseline
- application allowlisting
- EDR in OT-safe mode
- host firewall
- USB control
- local admin restriction
- log forwarding
- golden image
- backup
Tools and technology examples
- Microsoft Defender for Endpoint configured for OT compatibility
- CrowdStrike or SentinelOne where validated for OT use
- Windows Defender Application Control
- AppLocker
- Ivanti or Tanium for managed environments
- vendor-approved hardening tools
- Group Policy for Windows OT environments
Required evidence
- hardening baseline
- application allowlisting policy
- EDR coverage report
- exclusion list approved by vendor and security
- local admin review
- USB exception list
- golden image record
- restore test evidence
Failure mode
An endpoint tool blocks a vendor HMI process or overloads a fragile system.
Required fix
Validate endpoint controls in a lab, maintenance window, or spare system before broad deployment.
7. Controller, PLC, RTU, and relay security
Control objective
Restrict who can modify control logic, relay settings, firmware, and controller configuration.
Enforcement points
- controller access control
- engineering workstation restriction
- cell firewall
- physical cabinet access
- change workflow
- logic backup
- checksum or integrity verification
- vendor secure protocol settings where available
Tools and technology examples
- vendor engineering software
- PLC and relay backup tools
- OT monitoring platforms
- industrial firewalls
- configuration management tools
- physical access control
- secure engineering workstations
Required evidence
- controller inventory
- approved engineering workstation list
- logic backup
- firmware version
- checksum or vendor integrity evidence
- change approval
- restoration test
- access control configuration
Failure mode
Anyone on the plant VLAN can reach a PLC programming interface.
Required fix
Restrict programming access to approved engineering workstations and monitor write-capable commands.
8. OT monitoring and detection
Control objective
Detect unauthorized access, abnormal protocol behavior, new devices, controller writes, logic changes, and segmentation failures.
Enforcement points
- passive OT sensors
- SIEM
- detection rules
- packet capture
- jump host logs
- identity logs
- firewall logs
- change management integration
Tools and technology examples
- Dragos Platform
- Nozomi Networks
- Claroty
- Microsoft Defender for IoT
- Forescout eyeInspect
- Tenable OT
- Security Onion
- Zeek
- Suricata
- Splunk
- Microsoft Sentinel
- Google SecOps
- Elastic Security
- IBM QRadar
Required evidence
- log source inventory
- sensor placement diagram
- detection catalog
- alert tuning record
- test cases
- triage playbooks
- packet capture retention policy
- MITRE ATT&CK for ICS mapping
Failure mode
The tool alerts on everything, the SOC trusts nothing, and real control activity is missed.
Required fix
Build detections around process-relevant behavior and tune with OT engineers.
9. Vulnerability management
Control objective
Identify, prioritize, remediate, or compensate vulnerabilities without destabilizing operations.
Tools and technology examples
- Tenable OT
- Claroty
- Nozomi
- Dragos
- CISA ICS advisories
- vendor advisories
- Qualys, Rapid7, or Tenable for IT zones
- SBOM and software inventory tools where available
Prioritization model
Do not rank only by CVSS.
Prioritize by:
- exploitability
- exposure
- asset criticality
- process consequence
- internet or enterprise reachability
- known exploitation
- compensating controls
- patch availability
- vendor support
- recovery readiness
Required evidence
- vulnerability report
- affected asset list
- risk decision
- remediation ticket
- patch or mitigation evidence
- vendor advisory
- exception approval
- compensating control record
- retest result
Failure mode
The team runs aggressive IT scans against live controllers.
Required fix
Use passive assessment first, controlled active scanning only with written OT approval, lab validation, stop conditions, and rollback.
10. Backup and recovery
Control objective
Restore critical control functions from known-good backups during a cyber incident.
Tools and technology examples
- Veeam
- Commvault
- Rubrik
- Cohesity
- Acronis
- vendor-specific PLC backup tools
- offline media
- immutable storage
- secure backup vault
- spare PLC, relay, HMI, and workstation hardware
Required evidence
- backup inventory
- backup schedule
- offline or immutable copy proof
- restore test result
- firmware and software dependency record
- license key inventory
- recovery runbook
- spare hardware list
Failure mode
Backups exist but have never been restored.
Required fix
Test recovery of the most critical process-control functions, not only backup job completion.
11. File transfer, malware inspection, and patch staging
Control objective
Prevent malware and unapproved files from crossing into OT.
Enforcement points
- managed file transfer gateway
- malware sandbox
- content inspection
- hash verification
- signed package validation
- OT DMZ staging server
- removable media procedure
Tools and technology examples
- secure file transfer gateway
- sandbox analysis platform
- antivirus scanning station
- content disarm and reconstruction where appropriate
- YARA scanning for mature teams
- vendor package verification tools
Required evidence
- file transfer logs
- package approval
- hash verification
- malware scan result
- change ticket
- OT owner approval
- removable media register
Failure mode
A vendor brings a USB drive directly to an engineering workstation.
Required fix
All removable media and vendor packages must pass through controlled inspection before OT use.
12. Cloud and IIoT security
Control objective
Enable analytics and reporting without creating a control path from cloud or enterprise systems into OT.
Enforcement points
- data gateway
- brokered API
- private connectivity
- one-way transfer where appropriate
- cloud IAM
- encryption
- logging
- data classification
- egress control
Tools and technology examples
- AWS IoT SiteWise or equivalent industrial data services
- Azure IoT Operations / Azure Arc where appropriate
- Google Cloud industrial analytics services
- private connectivity
- cloud SIEM or data lake
- KMS/HSM services
- CSPM or CNAPP for cloud governance
Required evidence
- data classification
- approved data flow
- cloud IAM policy
- encryption evidence
- API logs
- egress monitoring
- architecture approval
- local operation fallback evidence
Failure mode
Cloud analytics becomes a hidden dependency for live operations.
Required fix
Local operation must continue safely without cloud availability.
13. Physical-cyber integration
Control objective
Detect and respond to combined cyber and physical activity.
Data sources
- badge access
- CCTV event metadata
- visitor logs
- cabinet access
- field crew dispatch
- maintenance windows
- cyber alerts
- remote access sessions
- engineering changes
Useful correlation:
after-hours badge access to substation
+ vendor remote login
+ relay setting change
= high-priority investigation
Evidence
- physical access logs
- cyber alert
- maintenance ticket
- investigation notes
- operator confirmation
- incident decision record
14. Tool selection principles
Before selecting a tool, ask:
- Does it support passive deployment?
- Does it understand industrial protocols?
- Can it operate without disrupting process control?
- Can OT engineers interpret the alerts?
- Does it integrate with SIEM and ticketing?
- Does it provide usable evidence?
- Does it support regulated environments?
- Can it scale across national sites?
- Can local teams operate it?
- What happens if the vendor or cloud service is unavailable?
- What data leaves the country?
- What is the total operating cost?
A tool that the organization cannot operate is not a control.
It is shelfware.
Takeaway
A 5 star quality ICS security program is not defined by the number of products deployed.
It is defined by whether controls are enforced, evidenced, owned, tested, and safe for operations.
Tools matter.
Control design matters more.
Top comments (0)