Most Industrial Cyber Assessments Are IT Audits in OT Clothing.
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.
- CVE-list audits, scraped from engineering workstations and stitched into a CVSS heatmap
- IT vulnerability scanners pointed at PLCs and DCS controllers — and occasionally faulting them
- Generic ATT&CK technique mentions, with no mapping to the Modbus, Profinet, EtherNet/IP or OPC UA actually on the bus
- Recommendations the plant cannot execute — line-stop windows that do not exist, controller reboots not permitted in production
- No consequence model tied to OEE, batch integrity, interlock function or EHS — the report stops at severity, never reaches outcome
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 Is a Consequence Equation. Not a Patch Backlog.
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.
Our Method — ATT&CK for ICS, Mapped to the Protocols and Devices in Your Plant.
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.
Worked Example — Engineering Workstation to Silent Interlock Bypass.
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.
twinos Assess · Industrial — ATT&CK at the Tag · Member Level.
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.
Two Scanners. Same Realisable Surface. Zero Impact on Production.
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.
The Risk Register Is Computed. Same Rubric, Every Site, Every Time.
There is one path from controller to register — and the customer can re-run it next year and get the same verdict.
- Scanner output — controller, protocol surface, OS posture, HW exposure
- × Realisation-condition database — per-technique realisability per asset
- × Consequence × Capability × Exposure rubric — per-asset, per-technique risk
- → Prioritised risk register, device-level roadmap, IEC 62443 / NIS2 evidence pack, executive and EHS readout
- Same depth on every controller — the engineer does not get tired on Unit-4
- Reproducible — the auditor and the EHS officer can re-run the scan next year and replicate the verdict
- Recommendations move scanner-observable preconditions — close the precondition, the technique falls off the register on the next scan
- Comparable across plants — multi-site OT risk roll-ups stop being apples-to-oranges
We compute the risk register the way a process engineer computes a heat balance.
Risk-Based Scoring. Not CVE-Based.
The industry default
- Count CVEs per asset from a vulnerability database
- Sum or average CVSS — produce a per-PLC 'severity'
- Rank assets by patch backlog the plant cannot apply
- Heatmap by colour, file the report, present at the SteerCo
- Production cannot reboot a controller mid-batch
- Same finding next quarter, same colour, same shelf
The twinos rubric
- Score consequence per technique per controller — what breaks in the plant
- Tier the plausible adversary for this plant, this product, this geography
- Score exposure with segmentation, key-switch policy and EWS hygiene credited
- Risk = Consequence × Capability × Exposure — defensible line by line
- Recommendations sized against the production calendar, not a patch calendar
- The same controller can be 'CVSS 9.8' and negligible risk — and vice versa
What You Get — Artefacts, Not Adjectives.
| 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.
How an Engagement Runs — Without Touching Production.
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.
- 1. Scoping — plant areas, scope of cells / units / SIS, ground-rules signed off in writing (1 week)
- 2. Passive collection — span-port capture on control networks, configuration export from controllers and EWS, P&ID and network architecture review, vendor remote-access review, interviews; no active probes on the OT network (1–2 weeks)
- 3. Protocol & device analysis — Modbus / Profinet / EtherNet-IP / OPC UA traffic decomposition, controller inventory, key-switch and EWS hygiene audit, SIS-vs-BPCS separation review (1–2 weeks)
- 4. Risk modelling — apply the rubric, score consequence / capability / exposure with process engineers in the room, draft the risk register (1–2 weeks)
- 5. Validation workshop — walk the findings with plant, EHS and corporate teams; calibrate consequence and exposure with the people who run the plant (2 days)
- 6. Report & readout — register, roadmap, evidence pack, executive and EHS readout (1 week)
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.
Why twinos.
- Generated, not authored — every finding is computed from scanner output and a realisation-condition database; the engineer does not get tired and the auditor can re-run the scan next year
- Plant-OT native methodology — built from control rooms, cabinets and engineering workstations; not an IT framework retrofitted with OT vocabulary
- Protocol- and device-specific to tag / member — every finding cites the controller, program, routine, tag and member (or the equivalent Modbus register / OPC UA node), not a generic technique number
- Risk-based, not CVE-based — consequence × capability × exposure; the only rubric a board and an EHS officer can defend the same way
- Audit- and EHS-ready by construction — every artefact maps line-for-line to IEC 62443, NIST SP 800-82, NAMUR and NIS2; the regulator does not need a translation layer
- Operations-conscious — 80 percent of the answer comes from vendor project archives and EWS exports; we bring the bus in only when the archives do not tell us
We are the plant-OT cyber assessment your control engineer would write if they had three months and a methodology.
Where This Sits in Your Programme.
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:
- Continuous plant-OT monitoring — convert the risk register into live Modbus / Profinet / EtherNet-IP / OPC UA detections tuned to your controllers
- Architecture review — segment IT/OT, harden EWS and vendor remote access, instrument the control-network boundary
- Incident response retainer — the team that wrote the rubric is the team that picks up the phone when the line goes silent
No upsell pressure. The assessment is sold standalone, priced standalone, and delivered standalone.