The current state of the practice: pull a CVE list off the engineering workstation, point an IT VA scanner at the PLCs, sum CVSS into a heatmap, recommend patches that demand a line-stop window that does not exist. The deliverable looks rigorous and answers the wrong question — and sometimes crashes a controller on the way.
The plant manager recognises this report. The OT security lead has filed three of them. None of them changed what the control-room operator is afraid of on Sunday night.
Plant OT risk has three terms and CVE count is not one of them. A PLC can carry a CVSS 9.8 vulnerability and present negligible OT risk — and a fully patched controller can sit one parameter write away from a silent interlock bypass. The rubric matters.
| Term | What it measures | What it ignores |
|---|---|---|
| Consequence | Loss of view, loss of control, interlock bypass, off-spec batch, batch-record integrity loss, unplanned shutdown, quality excursion, EHS event, regulatory notification — measured in plant outcomes, not data records | CVE severity in isolation |
| Adversary capability | Plausible threat actor tier for this plant, this product, this geography — opportunist, insider, criminal, nation-state — and the techniques each can actually deploy against a control system | Theoretical exploits no realistic adversary will weaponise against a process controller |
| Exposure | Reachable attack surface accounting for IT/OT segmentation, conduit boundaries, EWS hygiene, key-switch policy, vendor remote access, contractor identity and physical access to control rooms | Open-port counts on a flat-OT-network assumption |
Risk = Consequence × Capability × Exposure. Every finding in our report scores on this rubric. Every recommendation moves one of these three terms — and is sized against a production calendar, not a patch calendar.
MITRE ATT&CK for ICS is the public scaffold. On its own it is a vocabulary, not an assessment. We add three layers of mapping that turn a vocabulary into a finding the control engineer can act on.
| Layer | What we map | Example |
|---|---|---|
| Protocol layer | Each ATT&CK technique against the protocols actually on the plant network — Modbus TCP / RTU, Profinet, EtherNet/IP (CIP), OPC UA, S7, HART / WirelessHART, Foundation Fieldbus, IEC 60870-5-104 for utility-tied plants | T0843 Program Download → S7 project download to a production PLC |
| Device layer | Each technique against the devices on the rack — PLCs (Siemens S7, Rockwell ControlLogix, Schneider M340/M580, Mitsubishi), DCS controllers (DeltaV, Experion, Centum, 800xA), SIS logic solvers (Triconex, ProSafe-RS, AC800-HI), HMIs, historians, engineering workstations, safety relays | T0836 Modify Parameter → interlock threshold change via engineering workstation |
| Consequence layer | Each technique against the plant outcome it produces — loss of view, loss of control, interlock bypass, off-spec batch, production stop, environmental release, EHS event | Silent widening of safe operating envelope on a critical interlock |
The library is curated for the control-system stacks and protocol mixes we see in process, discrete and hybrid plants — and it grows with every engagement.
One real chain, end to end, against the rubric. This is what twinos Assess · Industrial emits against a plant control network — not a hand-written finding, not a CVE row, not a CVSS number. One row out of a generated register.
| Step | Finding |
|---|---|
| Technique | T0843 Program Download / T0836 Modify Parameter / T0858 Change Operating Mode — engineering workstation to production PLC over vendor management protocol |
| Protocol exposure | S7 / CIP / Modbus management functions unauthenticated at the controller; no project-change baseline; no audit log on mode change or parameter write |
| Device exposure | Production PLC governing a critical interlock; PLC key-switch permanently in REMOTE; reachable from the engineering workstation; engineering workstation reachable from plant LAN with a shared local-admin credential |
| Adversary capability | Tier-2 actor with a stolen engineer credential or unattended-workstation access — observed reachable path during scoping; insider risk concurrent and not separable |
| Consequence | Interlock threshold silently widened by a single parameter write; safe operating envelope expanded without HMI annunciation; downstream quality excursion under normal operations, potential EHS event under upset conditions; batch record carries the new threshold as if it were normal |
| Risk score (our rubric) | Consequence: High · Capability: Medium · Exposure: High → Aggregate: High. CVE-only view of this chain: zero CVEs, no scanner output, would not appear on any quarterly VA report |
| Recommendation | PLC key-switch returned to RUN with audit alerting on mode change; segment the engineering-workstation network behind a jump host; enforce per-engineer named identities and MFA on the EWS; baseline the PLC project and continuously diff for unauthorised parameter changes |
Zero CVEs. EHS-grade OT risk. Generated, not authored. The next three slides are how.
Public ATT&CK for ICS publishes technique names. twinos Assess holds a database of realisation conditions per technique — mapped to vendor protocol primitives (S7, CIP / EtherNet-IP, Modbus, OPC UA), down to controller / program / routine / tag / member; extended to OS hardening gaps and hardware exposure. For any controller whose project archive or tag database we hold, we can compute which techniques are realisable today — before we walk on site.
| Technique | Protocol primitive | Mapped point | Realisation conditions | Realisable? |
|---|---|---|---|---|
| T0843 Program Download | S7 / CIP / EtherNet-IP project download | PLC program image | Management protocol unauthenticated · key-switch in REMOTE · no project baseline / diff | Yes — High consequence (silent logic mod) |
| T0836 Modify Parameter | EWS to controller (vendor mgmt) | PROG_INTLK.RUNG_007.SP_HI | EWS shared local-admin · no per-engineer identity · no audit on tag write | Yes — High consequence (interlock bypass) |
| T0858 Change Operating Mode | S7 STOP / RUN | production PLC mode register | Management protocol unauthenticated · no audit on mode change · physical key-switch policy not enforced | Yes — Medium consequence (loss of view) |
Every row in our risk register starts as a realisation-condition query. The report is a join, not a narrative.
Most assessments collect what an engineer can write down in a notebook. twinos Assess collects what the controller, its project archive and its hardware actually say — and feeds it into the realisation-condition library.
| Mode | What it reads | Bus impact | What we see |
|---|---|---|---|
| Active — protocol | Modbus reads, Profinet / EtherNet-IP browse, OPC UA reads, S7 read under signed read-only ground rules | Negligible — read-only, rate-limited, vendor-recommended cadence | Live controller state, online tag values, mode and key-switch state |
| Passive — protocol | Vendor project archives (S7 .ap*, Rockwell .ACD, Studio 5000 exports), tag databases, controller online uploads, network drawings | Zero packets on the OT network | Full program / routine / tag hierarchy, interlock logic, write paths, vendor-managed I/O bindings |
| Passive — OS | Configuration exports from EWS, HMIs, historians, jump hosts — services, accounts, patch state, hardening posture | Zero | OS-level realisation conditions per technique |
| Passive — HW | Controller datasheets, FAT documents, panel port surveys, key-switch and door-contact policies | Zero | Debug ports, console exposure, firmware extraction reachability, physical interlock surface |
On a typical plant, around 80 percent of the answer comes from vendor project archives and EWS exports alone. We bring the bus in only when the archives do not tell us.
| Deliverable | What it contains | Who reads it |
|---|---|---|
| Prioritised Plant-OT Risk Register | Per-controller, per-technique findings — protocol, device class, consequence, capability tier, exposure, aggregate risk, recommendation | OT security lead, plant manager, process engineer |
| Device-Level Remediation Roadmap | Sequenced 0–3 month, 3–9 month, 9–24 month actions — segmentation, EWS hardening, key-switch and identity policy, project baselining, compensating controls; replacement only where it pays back | CISO, head of engineering, production head |
| Compliance Evidence Pack | Findings mapped to IEC 62443-3-3 system requirements, NIST SP 800-82 controls, NAMUR NA 163 where applicable, NIS2 obligations — auditor-ready, citation-grade | Auditor, compliance officer, regulator-facing team |
| Executive & EHS Readout | Boardroom narrative paired with an EHS-facing annex — what the plant is exposed to, what we are doing about it, what we are accepting and why | C-suite, EHS officer, board risk committee |
Every artefact is defensible — line by line, against a documented rubric. The auditor, the EHS officer and the board read it the same way.
Operations-conscious by design. We do not actively scan PLCs or DCS controllers. We do not patch in flight. We do not require a line-stop window to deliver the assessment.
Indicative duration — 4 weeks for a single plant area, 6–10 weeks plant-wide or multi-site. No faulted PLCs. No unplanned shutdowns during the assessment itself.
The assessment is the entry point — and complete in itself. The risk register, roadmap and evidence pack stand on their own; many plants stop here and use the output to drive their internal OT security programme for a year.
When the next question is asked, the same methodology extends:
No upsell pressure. The assessment is sold standalone, priced standalone, and delivered standalone.