Skip to main content

Concepts

OT risk explained

In OT, severity scores describe software. Risk describes what the process can be made to do. This page explains the four factors the atlas uses to rank findings — and how to apply them to real vendor and protocol situations.

Why should I care?

A CVSS 9.8 on a reporting server that cannot touch the process outranks nothing. A CVSS 5.3 on a controller that can open a valve outranks almost everything. NIST SP 800-82 Rev. 3 is explicit that OT decisions weigh safety, reliability and performance first.

Factor

Reachability

Who can actually touch the device today?

  • Directly internet-exposed (cellular router, port-forwarded HMI) — highest weight
  • Reachable from the enterprise network or a vendor VPN with no broker
  • Reachable only inside the control zone from an engineering workstation
  • Isolated behind a data diode or an air-gapped maintenance segment

Factor

Process consequence

What happens to the physical process if it is abused?

  • Safety function defeated or a hazardous state reachable — treat as critical regardless of CVSS
  • Unplanned shutdown, product loss, environmental release or public-service interruption
  • Degraded visibility only — operators lose trend data but control remains
  • No process effect: reporting, licensing or engineering convenience systems

Factor

Exploitability

How much work is a working attack?

  • Documented protocol feature, not a bug — Modbus writes, DNP3 control, PCOM/UMAS commands need no exploit at all
  • Public exploit code or a KEV listing for the exact firmware family
  • Authenticated or physically-present-only, requiring a keyswitch position or console access

Factor

Compensating controls

What already blocks or reveals the attack path?

  • Keyswitch in RUN, write-protected logic and change-detection on the controller
  • Conduit rules allowing only named engineering hosts during named windows
  • Protocol-aware monitoring alerting on program download, stop and firmware write
  • Tested offline backups of logic and project files with a rehearsed restore

Worked examples

What this looks like per vendor

Same method, five different plants.

Rockwell Automation

CIP / EtherNet-IP on 44818/TCP

A ControlLogix chassis reachable from the business VLAN scores high on reachability even with no CVE: CIP supports mode change and program download as designed. Consequence is set by the line it runs, and the honest mitigation is conduit restriction plus keyswitch discipline, not a patch window.

Siemens

S7comm / ISO-on-TCP on 102/TCP

S7-300/400 families accept block download and stop from anyone who can open port 102. Rate the finding on who can reach 102 and what the block controls — an S7-1500 with access protection and a monitored conduit is a very different risk from the same CVE on a flat cell network.

Schneider Electric

UMAS on 502/TCP and Triconex SIS

Modbus function code 90 (UMAS) carries engineering operations inside ordinary Modbus. A Modicon finding is a process-consequence question; the same weakness adjacent to a Triconex safety controller moves straight to the top of the queue because the consequence axis maxes out.

ABB

800xA and Relion GOOSE

Substation risk is dominated by layer-2 reachability: GOOSE has no authentication, so anything on the station bus can publish trip messages. Score the station-bus isolation and port security, not the CVSS of the relay firmware alone.

Unitronics

PCOM on 20256/TCP with default credentials

The 2023 water-sector defacements needed no exploit: internet-exposed Vision PLCs with default passwords. Reachability maximal, exploitability trivial, consequence public-service — the textbook case for scoring reachability before severity.

Reference

Where the weight usually sits

Highest consequence assetsSafety instrumented systems, protective relays, PLCs on hazardous processes
Highest reachability assetsCellular RTUs, remote-site HMIs, vendor-managed jump hosts, engineering laptops
Protocols with no native authModbus, DNP3 (without SAv5), GOOSE, PROFINET DCP, PCCC, PCOM, S7comm
Signals that change a scoreKEV listing, keyswitch position, conduit rule, tested backup, passive monitoring coverage
Expert notes+
  • Score the reachable instance, not the product. The same firmware in two zones is two different risks.
  • Consequence is an engineering answer, not a security answer — get it from the process owner and write it down.
  • If the abuse uses a documented protocol feature, patching cannot be the plan; the conduit and the keyswitch are the plan.
  • Re-score after every architecture change. Adding a jump host or a new cellular modem moves reachability more than any CVE.