Adversaries may send unauthorized command messages to instruct control system assets to perform actions outside of their intended functionality, or without the logical preconditions to trigger their expected function. Command messages are used in ICS networks to give direct instructions to control systems devices. If an adversary can send an unauthorized command message to a control system, then it can instruct the control systems device to perform an action outside the normal bounds of the device's actions. An adversary could potentially instruct a control systems device to perform an action that will cause an Impact. [1]
In the Dallas Siren incident, adversaries were able to send command messages to activate tornado alarm systems across the city without an impending tornado or other disaster. [2] [3]
| ID | Name | Description |
|---|---|---|
| C0028 | 2015 Ukraine Electric Power Attack |
During the 2015 Ukraine Electric Power Attack, Sandworm Team issued unauthorized commands to substation breaks after gaining control of operator workstations and accessing a distribution management system (DMS) application. [4] |
| C0034 | 2022 Ukraine Electric Power Attack |
During the 2022 Ukraine Electric Power Attack, Sandworm Team used the MicroSCADA SCIL-API to specify a set of SCADA instructions, including the sending of unauthorized commands to substation devices.[5] |
| S1045 | INCONTROLLER |
INCONTROLLER can send custom Modbus commands to write register values on Schneider PLCs.[6] INCONTROLLER can send write tag values on OPC UA servers.[6] |
| S0604 | Industroyer |
Using its protocol payloads, Industroyer sends unauthorized commands to RTUs to change the state of equipment. [7] |
| S1072 | Industroyer2 |
Industroyer2 is capable of sending command messages from the compromised device to target remote stations to open data channels, retrieve the location and values of Information Object Addresses (IOAs), and modify the IO state values through Select Before Operate I/O, Select/Execute, and Invert Default State operations.[8][9] |
| C0020 | Maroochy Water Breach |
In the Maroochy Water Breach, the adversary used a dedicated analog two-way radio system to send false data and instructions to pumping stations and the central computer.[10] |
| C0030 | Triton Safety Instrumented System Attack |
In the Triton Safety Instrumented System Attack, TEMP.Veles leveraged Triton to send unauthorized command messages to the Triconex safety controllers.[11] |
| ID | Mitigation | Description |
|---|---|---|
| M0802 | Communication Authenticity |
Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| M0937 | Filter Network Traffic |
Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages. |
| M0807 | Network Allowlists |
Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. [12] |
| M0930 | Network Segmentation |
Segment operational assets and their management devices based on their functional role within the process. Enabling more strict isolation to more critical control and operational information within the control environment. [13] [14] [12] [15] |
| M0813 | Software Process and Device Authentication |
Devices should authenticate all messages between master and outstation assets. |
| M0818 | Validate Program Inputs |
Devices and programs that receive command messages from remote systems (e.g., control servers) should verify those commands before taking any actions on them. |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0015 | Application Log | Application Log Content |
Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs. |
| DS0029 | Network Traffic | Network Traffic Content |
Monitor for unexpected ICS protocol command functions to controllers from existing master devices (including from new processes) or from new devices. The latter is like detection for Rogue Master but requires ICS function level insight to determine if an unauthorized device is issuing commands (e.g., a historian). Monitoring for unexpected or problematic values below the function level will provide better insights into potentially malicious activity but at the cost of additional false positives depending on the underlying operational process. |
| Network Traffic Flow |
Monitor for new or unexpected connections to controllers, which could indicate an Unauthorized Command Message being sent via Rogue Master. |
||
| DS0040 | Operational Databases | Process History/Live Data |
Monitor industrial process history data for events that correspond with command message functions, such as setpoint modification or changes to system status for key devices. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections. |
| Process/Event Alarm |
Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs. |