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
Previous Series: Part-4: Tools, Technologies, and Control Implementation Catalog
Jump to Part-7: State-Owned ICS Cybersecurity Blueprint
A strong ICS architecture reduces attack paths.
Cyber operations determine whether the organization can detect, respond, and recover when something goes wrong.
For state-owned critical infrastructure, the SOC mission is not simply alert handling.
The mission is national service continuity.
The SOC, OT engineers, safety teams, field operations, vendors, executives, legal, communications, and national response bodies must be able to work together before a crisis.
The operating rule is:
Detect early. Contain safely. Preserve evidence. Recover critical services. Improve controls.
OT cyber operations model
Executive summary for leaders
A mature OT cyber operations program should prove that:
- critical OT assets are monitored
- remote access is reviewed
- unauthorized control behavior can be detected
- alerts are triaged with process context
- containment actions are approved by the right operational owner
- backups are tested
- incident playbooks are exercised
- lessons learned become funded remediation
- leadership receives risk metrics, not raw alert volume
If the SOC cannot explain what physical process an alert affects, it is not ready for ICS operations.
1. OT SOC operating model
An OT SOC is not just an enterprise SOC watching another dashboard.
It needs OT-specific context, escalation, and safety approvals.
Tier 1: initial triage
Responsibilities:
- validate alert quality
- identify source, destination, user, protocol, and time
- check asset criticality
- check maintenance window
- check vendor approval
- identify whether behavior is read-only, write-capable, or administrative
- escalate high-risk OT behavior immediately
Tier 1 should not independently block critical OT traffic unless a pre-approved action exists.
Tier 2: investigation
Responsibilities:
- analyze logs and packet captures
- correlate remote access, identity, firewall, and OT sensor data
- validate whether activity matches approved work
- coordinate with OT engineers
- recommend severity and containment
- preserve evidence
Tier 3: detection engineering and threat hunting
Responsibilities:
- build MITRE ATT&CK for ICS mapped detections
- tune false positives
- build threat hunts
- validate detections through exercises
- analyze suspicious tooling
- improve telemetry coverage
- support incident response and post-incident review
OT engineering
Responsibilities:
- explain physical process impact
- confirm whether engineering activity is legitimate
- approve containment that may affect operations
- validate controller logic and settings
- restore systems from known-good backups
- define safe state and manual operation options
Incident commander
Responsibilities:
- coordinate incident bridge
- maintain timeline
- approve escalation
- coordinate legal, privacy, communications, safety, operations, and executives
- ensure evidence preservation
- drive post-incident remediation
2. Telemetry required
A SOC cannot detect what it cannot see.
Critical log sources
Collect from:
- OT firewalls
- industrial switches and routers
- OT IDS sensors
- remote access portal
- VPN
- jump hosts
- PAM platform
- Active Directory or OT identity
- HMIs
- SCADA servers
- historians
- engineering workstations
- Linux servers
- backup systems
- endpoint security tools where safe
- physical access systems
- change management
- ticketing system
- vulnerability platform
- cloud analytics platform where used
High-value OT events
Prioritize:
- new device in OT segment
- industrial protocol write
- PLC or relay mode change
- controller logic upload or download
- relay setting change
- engineering workstation connection to controller
- firmware change
- HMI project change
- remote vendor login
- failed privileged login
- jump host session start and end
- firewall rule change
- new route or ACL change
- backup failure for critical asset
- badge access to restricted operational area
Retention
Critical infrastructure needs enough retention to investigate slow adversary activity.
Use:
- hot logs for active investigation
- warm logs for incident review
- cold archive for legal, regulatory, and historical analysis
- rolling packet capture in the most critical segments where feasible
Retention must follow national law, privacy obligations, and operational policy.
3. Detection engineering
Generic malware alerts are not enough.
OT detections must focus on control behavior, remote access, engineering actions, segmentation failures, and process context.
Detection 1: unauthorized PLC or relay write
Logic:
If source is not an approved engineering workstation
AND destination is a controller, RTU, IED, or relay
AND protocol action is write-capable
THEN create high-severity OT alert.
Triage:
- confirm source asset
- check user and session
- check change window
- check engineering approval
- review packet capture
- ask OT owner if action was expected
- preserve evidence
Containment options:
- block source at cell firewall
- disable suspicious endpoint switch port
- terminate unauthorized vendor session
- disable compromised account
- do not stop controller without OT approval
Detection 2: vendor access outside approved window
Logic:
If vendor account logs in
AND no active approved ticket exists
OR session occurs outside approved time window
THEN alert SOC and OT owner.
Triage:
- validate user and source
- review approval system
- review session recording
- confirm target asset
- disable account if unauthorized
Detection 3: engineering workstation abnormal behavior
Logic:
If engineering workstation connects to unusual controllers
OR launches unauthorized remote admin tools
OR creates unusual archive files
OR executes new binaries
THEN escalate to Tier 2.
Triage:
- check maintenance activity
- review endpoint telemetry
- review user activity
- verify project file access
- confirm with engineering lead
Detection 4: logic or setting change outside window
Logic:
If controller logic, relay setting, or firmware indicator changes
AND no approved change exists
THEN create critical OT alert.
Triage:
- confirm affected process
- engage OT engineer
- compare against known-good backup
- preserve project files and logs
- prepare containment and recovery plan
Detection 5: IT-to-OT protocol crossing
Logic:
If source zone is enterprise IT
AND protocol is industrial or engineering-related
AND destination is OT
THEN create high-severity segmentation alert.
Examples of protocols or services to watch:
- Modbus
- DNP3
- S7
- EtherNet/IP
- IEC 61850
- OPC Classic
- engineering workstation protocols
- RDP
- VNC
- SSH
- SMB
4. Threat hunting
Useful OT hunts:
- new assets in control zones
- new external remote access sources
- rare industrial protocol function codes
- RDP from non-jump-host systems
- vendor access outside business process
- engineering tool execution on non-engineering hosts
- abnormal historian queries
- new scheduled tasks on HMIs
- new local administrator accounts
- PLC communication from unexpected subnet
- file archives created on engineering workstations
- DNS queries from OT assets that should not use internet DNS
- relay setting changes outside planned work
Every hunt should produce one of three outcomes:
- confirmed incident
- control gap
- detection tuning opportunity
5. Vulnerability management in operations
Vulnerability management must be consequence-based.
Do not rank only by CVSS.
Prioritize by:
- asset criticality
- process impact
- exploitability
- exposure
- known exploitation
- segmentation
- patch availability
- vendor support
- compensating controls
- recovery readiness
Remediation options:
- patch during maintenance window
- upgrade firmware after lab validation
- disable vulnerable service
- restrict source IP
- add cell firewall rule
- move asset to segmented zone
- monitor for exploitation
- remove enterprise reachability
- replace unsupported system
- create time-bound exception with compensating controls
Evidence:
- vulnerability report
- affected asset list
- risk rating
- remediation ticket
- mitigation proof
- vendor advisory
- exception approval
- retest result
6. Patch and change management
OT patching requires planning.
Process:
- Track vendor and national advisories.
- Match advisories to asset inventory.
- Assess process impact.
- Test patch or firmware in lab or spare system.
- Confirm vendor support.
- Schedule maintenance window.
- Confirm backup and rollback.
- Apply change.
- Monitor cyber and process telemetry.
- Record evidence and lessons learned.
Change control applies to:
- firewall rules
- remote access
- controller logic
- relay settings
- HMI projects
- SCADA configuration
- historian connectors
- switch and router configuration
- firmware updates
- user and role changes
- cloud data pipelines
- safety system changes
Every OT change needs:
- owner
- approval
- maintenance window
- rollback plan
- monitoring plan
- stop condition
- post-change validation
7. SOAR and automation
Automation helps when it reduces analyst workload without creating operational risk.
Generally safe to automate
- enrich alert with asset criticality
- attach owner and location
- check change ticket
- check vendor access approval
- collect relevant logs
- query threat intelligence
- notify OT owner
- open incident ticket
- create evidence folder
- draft timeline
- recommend containment options
Must require human approval
- blocking OT network flows
- disabling vendor access during active maintenance
- isolating HMI or SCADA server
- disabling switch ports
- changing firewall policy
- resetting OT passwords at scale
- restarting services
- reloading controller logic
- disconnecting IT/OT boundary links
Failure mode
A SOAR playbook that automatically blocks a controller communication path can stop a process.
The required controls are:
- approval gates
- rollback
- audit logging
- simulation testing
- OT owner sign-off
- emergency bypass procedure
8. Incident response for OT
OT incident response must be safety-led.
Severity model
SEV-1 Critical:
- unauthorized control action
- confirmed logic or relay setting manipulation
- ransomware affecting operations
- safety impact
- loss of control visibility
- major service disruption
- active attacker in critical OT zone
SEV-2 High:
- compromised engineering workstation
- unauthorized PLC or relay write attempt
- vendor account compromise
- malware on HMI
- confirmed lateral movement toward OT
SEV-3 Medium:
- unauthorized device in OT
- suspicious scan
- failed privileged logins
- policy violation
- unmanaged remote access path
- monitoring gap with significant risk
SEV-4 Low:
- false positive
- benign misconfiguration
- informational alert
- low-impact hygiene issue
Triage questions
Ask:
- Which asset is affected?
- What physical process does it support?
- Is the process stable?
- Is this read traffic, write traffic, or administrative activity?
- Is this inside an approved change window?
- Is a vendor approved to connect?
- Can containment harm safety or availability?
- What evidence must be preserved?
- Who can approve action?
- What rollback exists?
Containment principles
Good containment:
- disable suspicious endpoint port
- block attacker source at cell firewall
- terminate unauthorized vendor session
- disable compromised account
- move operators to standby HMI
- disconnect enterprise path while keeping local OT running
- preserve packet captures and logs
Avoid without approval:
- stopping controllers
- rebooting HMIs during live operations
- reloading logic without validation
- broad password resets during operational stress
- shutting down switches supporting active process control
The principle is:
Isolate the attacker, not the process.
9. Backup, recovery, and continuity
Backups are a cyber safety control.
Critical backups:
- HMI images
- engineering workstation images
- SCADA server configuration
- historian configuration
- PLC and RTU logic
- relay settings
- network device configuration
- firewall policy
- remote access configuration
- license keys
- vendor installation media
- recovery procedures
- offline contact lists
Minimum standard:
- offline or immutable copy
- physically or logically disconnected copy
- restore test for critical systems
- spare hardware for high-criticality assets
- firmware and software version records
- recovery runbook accessible during IT outage
- recovery exercise at least annually for critical services
Leadership should ask:
Can we restore the most critical process-control function from known-good backups during a cyber incident?
10. Purple team and exercises
Exercises turn plans into capability.
Run:
- tabletop exercises
- detection validation
- restore drills
- vendor access abuse scenarios
- ransomware-on-HMI scenario
- unauthorized PLC logic change scenario
- relay setting change scenario
- loss of IT/OT boundary scenario
- national crisis communication exercise
- manual operation coordination exercise
Use MITRE ATT&CK for ICS to build scenarios.
Example scenario:
vendor VPN compromise
-> OT network discovery
-> RDP to engineering workstation
-> project file collection
-> unauthorized logic download
-> alarm suppression attempt
For each stage define:
- expected telemetry
- detection rule
- response owner
- containment option
- evidence required
- control gap
- remediation owner
11. Metrics that matter
Do not report only alert volume.
Report operational cyber risk.
Good metrics:
- percentage of critical OT assets inventoried
- number of direct IT-to-OT flows remaining
- vendor accounts active outside approved windows
- percentage of critical assets with tested backups
- unauthorized write attempts
- critical vulnerabilities past SLA without compensating controls
- percentage of firewall rules reviewed this quarter
- mean time to triage high-severity OT alerts
- restore tests completed
- open exceptions by age and criticality
- OT detections tested in the last quarter
- percentage of remote sessions recorded
- unmanaged devices found in OT
- sites with passive monitoring coverage
- engineering changes with complete evidence
A strong board statement:
We have inventoried 94% of critical OT assets, removed direct enterprise-to-controller access, placed vendor access behind MFA and recording, tested restores for the top three process-control functions, and validated detections for unauthorized controller writes. Remaining risk is concentrated in two legacy sites and one vendor remote access path.
That is better than:
We deployed an OT monitoring platform.
12. Operating rhythm
Daily:
- review high-severity OT alerts
- review remote access anomalies
- confirm critical monitoring health
Weekly:
- review new assets and flows
- review failed privileged logins
- review vendor activity
- tune noisy detections
Monthly:
- review vendor accounts
- review privileged accounts
- validate backup job status
- review open critical vulnerabilities
- review unmanaged devices
Quarterly:
- review firewall rules
- run detection validation
- review exceptions
- update threat model
- report metrics to leadership
Semiannual:
- run restore test
- run incident response tabletop
- review architecture against current operations
Annual:
- conduct OT security assessment
- run sector or national exercise
- refresh strategy, budget, and risk register
Takeaway
Cyber operations decide whether architecture becomes real security.
A mature OT SOC does not chase every alert equally.
It understands process context, detects meaningful behavior, acts safely, preserves evidence, supports recovery, and improves controls after every event.
For state-owned ICS, that is not just a security function.
It is part of national continuity.
Let's move to Final Part-6: AI, Governance, Procurement, and the 180-Day National Roadmap
Top comments (0)