Scada Ics Cyber Security Specialist

SCADA / ICS Cyber Security Specialist

When to Use

• Define OT/ICS security program scope, governance, and IT/OT coordination model
• Design Purdue/ISA-95 zones, conduits, segmentation, and DMZ patterns for control networks
• Build OT asset inventory — PLCs, RTUs, HMIs, historians, engineering workstations, gateways
• Plan secure remote access — jump hosts, PAM, vendor sessions, MFA, session recording
• Manage patch and vulnerability programs under change windows, compensating controls, and vendor SLAs
• Scope ICS-aware monitoring — passive taps, DPI for Modbus/DNP3/OPC/BACnet (high level), baselines
• Author safety-first OT incident response — coordination with operations, process safety, and IT IR
• Map IEC 62443 and NIST SP 800-82 concepts to gaps, SL-T targets, and remediation priorities
• Produce hardening roadmaps and evidence packs for audits, insurers, and leadership (not legal advice)
• Assess IT/OT convergence risks — shared AD, cloud historians, remote ops, supply chain

When NOT to Use

• Generic corporate network pentest without OT methodology → network-pentester
• Web application or API testing → web-pentester
• Authorized exploitation and red-team validation on IT paths → penetration-tester
• HIL bench, automotive ECU, or embedded fault-injection testing → hardware-in-the-loop-security-tester (complement for lab validation)
• Enterprise GRC program, audit prep, or vendor questionnaires without OT lens → compliance-specialist
• SOC alert triage and corporate detection playbooks only → soc-analyst
• IT-centric incident command without process-safety and operations coordination → incident-responder
• Corporate SIEM/EDR/IdP implementation without OT architecture → information-security-engineer
• Security strategy and board metrics without OT program delivery → cybersecurity
• Control-by-control evidence automation for IT SOC 2 → compliance-engineer
• Proactive threat hunting on corporate IT telemetry only → threat-hunter

Related skills

Core Workflows

1. Scope, safety, and governance

Define OT boundaries, safety constraints, roles, and handoffs with operations and IT.

See `references/scada_ics_scope_and_safety.md`.

2. Architecture and segmentation

Apply Purdue zones, conduits, remote access, and IT/OT convergence controls.

See `references/ot_architecture_and_segmentation.md`.

3. Standards and assessment

Map IEC 62443 and NIST SP 800-82 to gaps, maturity, and security levels (practitioner level).

See `references/standards_and_assessment.md`.

4. Asset and vulnerability management

Inventory OT assets; prioritize vulns with OT change constraints and compensating controls.

See `references/ot_asset_vulnerability_management.md`.

5. Detection and incident response

ICS monitoring patterns, safety-first IR sequencing, and OT threat classes.

See `references/ot_detection_and_incident_response.md`.

6. Hardening roadmaps and evidence

Phased remediation, metrics, test plans, and audit-ready artifacts.

See `references/hardening_roadmaps_and_evidence.md`.

Outputs

• OT security charter — scope, RACI, safety gates, escalation to operations and IT IR
• Zone/conduit diagram — Purdue levels, data flows, remote access paths, crown jewels
• OT asset register — device class, firmware, zone, owner, criticality, connectivity
• Vulnerability and patch register — CVE/vendor advisory, risk, compensating control, change window
• Secure remote access design — vendor access, session controls, logging, break-glass
• Detection use-case list — protocol anomalies, engineering changes, remote sessions (high level)
• OT IR playbook outline — safety hold points, isolation options, evidence preservation
• Standards gap matrix — IEC 62443 / NIST 800-82 mapping with prioritized remediation
• Hardening roadmap — phases, dependencies, metrics, validation criteria
• Executive OT security brief — posture, top risks, test results (not legal or safety certification)

Principles

• Safety and availability first — never recommend actions that could trip plant, endanger people, or violate site safety rules without operations approval
• No unsafe live-plant testing — prefer passive assessment, documentation review, lab replicas, and vendor-supported validation
• Assume brittle systems — patches, scans, and aggressive active tests can fault controllers; plan compensating controls
• Separate IT and OT evidence — corporate SOC findings do not equal OT coverage; document zone boundaries
• Coordinate with operations — process engineers and electricians own physical consequences; security owns risk framing
• Document accepted risk — deferred patches and legacy protocols need explicit sign-off and monitoring

Hardening roadmaps and evidence

Table of contents

1. Roadmap structure 2. Phasing and dependencies 3. Control families 4. Validation and retest 5. Evidence pack 6. Executive reporting 7. Peer skill alignment

Roadmap structure

Build a 12–36 month OT security roadmap aligned to business outages and capital cycles.

Phasing and dependencies

Phase 0 — Quick wins (0–90 days)

• Inventory critical assets and remote access paths
• Disable unused conduits; document exceptions
• MFA on jump servers; vendor session recording
• Emergency contacts and OT IR outline

Phase 1 — Foundation (3–12 months)

• Zone/conduit remediation per architecture doc
• Passive monitoring on control VLANs
• OT vulnerability triage process live
• Gold images for EWS/HMI

Phase 2 — Optimize (12–36 months)

• SL-T uplift per zone
• Replace EOL gear; qualified firmware program
• Integrated IT/OT SOC workflows
• Annual tabletops and restore tests for OT servers

Sequence identity and remote access before deep protocol analytics if budget is constrained.

Control families

Crosswalk to compliance-specialist when audits require SOC 2, ISO 27001, or sector frameworks.

Validation and retest

For each initiative define:

• Test method — config review, passive replay, tabletop, maintenance-window functional test
• Success criteria — measurable (e.g., 100% vendor sessions via PAM)
• Rollback — operations-approved backout
• Evidence artifact — screenshot, export, signed checklist

Never use production active exploitation as validation.

Evidence pack

Assemble for auditors, insurers, or leadership:

Redact safety-critical details that should not leave the site.

Executive reporting

One-page brief structure:

• Posture summary — maturity level, top 3 risks
• Progress — initiatives completed vs plan
• Incidents/near misses — OT-relevant only
• Investments needed — CAPEX for EOL, monitoring, staffing
• Decisions requested — risk acceptances, outage windows

Not a substitute for legal compliance or process safety certification.

Peer skill alignment

OT architecture and segmentation

Table of contents

1. Purdue model (practitioner view) 2. Zones and conduits 3. Crown jewels and data flows 4. Secure remote access 5. IT/OT convergence risks 6. Architecture review checklist

Purdue model (practitioner view)

Goal: enforce defense in depth so compromise at one level does not imply full plant control.

Zones and conduits

• Zone — collection of assets with common security requirements and trust boundary
• Conduit — controlled path between zones (firewall rules, data diode, unidirectional gateway, application proxy)

Patterns:

Document for each conduit: source/dest zones, protocols/ports, direction, business justification, owner.

Crown jewels and data flows

Prioritize protection for:

• Engineering workstations and project files (logic, recipes)
• PLC/RTU configuration interfaces
• SCADA master and redundancy pairs
• Historians and backup stores (long-term process data)
• Remote access gateways and VPN concentrators into OT
• Protocol translators (Modbus TCP ↔ serial, OPC UA gateways)

Map northbound (OT → IT/enterprise) and southbound (IT → OT) flows separately; convergence often hides in OPC, SQL replication, and RDP jump boxes.

Secure remote access

Vendor access: contract clauses for malware-free media, notification of personnel changes, and incident contact.

IT/OT convergence risks

Architecture review checklist

• [ ] Diagram shows all zones L0–L5 present on site (or explicit exclusions)
• [ ] Every cross-zone path is a named conduit with rules
• [ ] No undocumented dual-homed devices
• [ ] Remote access lands in DMZ/jump, not on PLC subnets
• [ ] Engineering workstations cannot reach internet without proxy controls
• [ ] Backup and patch paths documented and monitored
• [ ] SIS/BPCS separation validated with process safety (no security changes to SIS without safety review)

OT asset and vulnerability management

Table of contents

1. Asset inventory 2. Discovery methods 3. Criticality and prioritization 4. Vulnerability handling in OT 5. Patch management constraints 6. Compensating controls 7. Registers and metrics

Asset inventory

Minimum fields per OT asset:

Engineering workstations and project files (.acd, .zap, logic exports) are assets—track version control and backup.

Discovery methods

Criticality and prioritization

Combine:

• Process impact — unit trip, quality, environmental, safety
• Exposure — internet path, remote access, shared IT domain
• Exploitability — known exploit in the wild vs theoretical
• Compensating controls — segmentation, monitoring, physical access

Do not prioritize solely on CVSS; use OT risk scoring with operations input.

Vulnerability handling in OT

Workflow:

1. Intake — CISA ICS advisories, vendor PSIRT, CERT, internal scan (IT zone only) 2. Triage — affected models/firmware; false positive check against inventory 3. Technical assessment — vendor guidance, mitigations, patch availability 4. Operations review — change window, rollback, simultaneous outage risk 5. Decision — patch, mitigate, accept, retire asset 6. Verify — post-change validation in maintenance mode 7. Document — risk acceptance for deferrals

Patch management constraints

Patch relay / DMZ: distribute updates without giving L1 direct internet.

Compensating controls

When patch is deferred:

Record expiry date for compensating controls—force re-triage.

Registers and metrics

Export registers for hardening_roadmaps_and_evidence.md and audit packs (with compliance-specialist for framework mapping).

OT detection and incident response

Table of contents

1. Detection philosophy 2. ICS protocols (high level) 3. Monitoring patterns 4. OT threat classes 5. Safety-first incident response 6. Coordination with IT IR 7. Tabletop and exercise hooks

Detection philosophy

• Prefer passive collection on OT SPAN/taps; avoid inline devices that add latency or single points of failure
• Baseline behavior — normal Modbus/DNP3/OPC patterns per unit; alert on engineering changes and new masters
• Correlate OT alerts with IT identity, VPN, and EDR where conduits exist
• Tune with operations — reduce false positives that desensitize operators

Corporate SOC (soc-analyst) may lack OT context—define handoff criteria and shared runbooks.

ICS protocols (high level)

Detection content should reference function codes, new client IPs, write operations to sensitive registers, and firmware download sequences—without prescribing unsafe active tests.

Monitoring patterns

Integrate with SIEM where possible; maintain OT-specific dashboards for operations liaisons.

OT threat classes

High-level awareness (not attribution):

Route deep malware analysis and legal coordination to incident-responder and forensics partners.

Safety-first incident response

Before cyber actions, establish:

• Operations commander — authority to stop process, safe shutdown state
• Process safety contact — SIS not disabled for “cleanup”
• Communication plan — control room, field ops, executives

Phased approach:

1. Detect & confirm — validate not false positive; preserve SPAN captures 2. Triage impact — which zones, safety vs production systems 3. Contain (approved) — block conduit, disable remote access, avoid abrupt PLC power-off unless ops directs 4. Eradicate — reimage EWS/HMI from gold; replace logic only from known-good backup 5. Recover — staged restore; functional tests per operations checklist 6. Learn — AAR with safety and IT IR; update roadmaps

Prohibited without ops approval: mass password changes that lock operators out, antivirus full scans on realtime servers during peak production, active scanning of PLCs.

Coordination with IT IR

Single incident timeline; tag evidence as OT vs IT.

Tabletop and exercise hooks

Scenarios: ransomware in DMZ, rogue engineering laptop, lost VPN creds into jump host, false positive flood on Modbus alerts.

Inject safety decisions (unit trip vs degraded run). Capture gaps for hardening_roadmaps_and_evidence.md.

For threat hunting on IT-only telemetry, use threat-hunter; for pentest validation, use penetration-tester in lab or agreed test beds—not production OT.

SCADA/ICS scope and safety

Table of contents

1. Purpose 2. Terminology 3. In scope 4. Out of scope 5. Safety and operational constraints 6. Roles and RACI 7. Handoffs

Purpose

Establish OT/ICS cyber security program boundaries so assessments, designs, and roadmaps respect process safety, availability, and site-specific operating procedures.

This skill covers program design, architecture, assessment, and playbook authoring—not live plant manipulation or unsupervised testing.

Terminology

In scope

Out of scope

Safety and operational constraints

Never instruct the agent or operator to:

• Change setpoints, logic, or I/O on live equipment without written operations authorization
• Run vulnerability scanners, port scans, or fuzzing against production PLCs/RTUs
• Disable interlocks, safety systems, or antivirus on OT without documented change control
• Bridge OT and IT networks without an approved conduit design

Prefer instead:

• Document review, passive monitoring, vendor maintenance windows, lab replicas, and tabletop exercises
• Engage operations, maintenance, and vendor OEM before any change that touches control logic
• Use maintenance mode and backup/restore procedures per site runbooks

Roles and RACI

(A = accountable, R = responsible, C = consulted, I = informed — adapt to site RACI.)

Handoffs

• To `incident-responder` — when an event crosses into corporate IT, identity, or widespread ransomware; OT lead retains safety sequencing
• To `digital-forensics-analyst` — when disk images, malware analysis, or legal hold on OT hosts is required (with operations approval)
• To `compliance-specialist` — when audit scope spans IT and OT frameworks and evidence binders
• To `hardware-in-the-loop-security-tester` — when validation requires bench HIL, not production

Standards and assessment

Table of contents

1. IEC 62443 (high level) 2. NIST SP 800-82 (high level) 3. [Assessment approach](#assessment approach) 4. Gap matrix template 5. Maturity and security levels 6. Evidence and limitations

IEC 62443 (high level)

IEC 62443 (ISA/IEC) is the primary industrial automation and control systems security framework family.

Security Levels (SL-T): target rigor for a zone or system (SL 1–4). Document current vs target SL with compensating controls where target is not achievable short term.

Do not claim certification or SL achievement without qualified assessors and site-specific evidence.

NIST SP 800-82 (high level)

NIST SP 800-82 Rev. 3 provides guide to ICS security for U.S. federal and general industry reference.

Use 800-82 as structuring guide for gap assessments and roadmaps; pair with site standards and sector regulators (NERC CIP, FDA, etc.) when applicable — not legal interpretation.

Assessment approach

1. Kickoff — scope sites/units, safety rules, blackout periods, interview list (OT ops, IT, vendors) 2. Documentation — network diagrams, asset lists, change control, remote access, prior incidents 3. Walkthrough — physical and logical; identify shadow IT and ad-hoc conduits 4. Passive observation — where approved: SPAN/tap, asset discovery tools in listen-only mode 5. Control testing — configuration review, sampling; no active exploit or production scanning 6. Gap analysis — map findings to IEC 62443-3-3 / 800-82 control families 7. Roadmap — phased remediation with operations-owned change windows

Gap matrix template

Severity guidance: combine cyber exposure with process/safety impact (not CVSS alone).

Maturity and security levels

Evidence and limitations

Collect: diagrams, firewall exports, jump server configs, patch records, training logs, tabletop AARs.

Limitations to state explicitly:

• Passive-only assessment may miss misconfigurations on unused ports
• Vendor black-box PLCs limit firmware assurance
• Safety systems may be out of scope for cyber assessors
• This skill does not provide legal compliance opinions — route to compliance-specialist and counsel