This site has been deprecated in favor of https://attack.mitre.org and will remain in place until 11/1/22.
Detect Operating Mode
|Detect Operating Mode|
|Data Sources||Network protocol analysis, Packet capture|
Adversaries may gather information about a PLC’s or controller’s current operating mode. Operating modes dictate what change or maintenance functions can be manipulated and are often controlled by a key switch on the PLC (e.g., run, prog [program], and remote). Knowledge of these states may be valuable to an adversary to determine if they are able to reprogram the PLC. Operating modes and the mechanisms by which they are selected often vary by vendor and product line. Some commonly implemented operating modes are described below:
- Program - This mode must be enabled before changes can be made to a device’s program. This allows program uploads and downloads between the device and an engineering workstation. Often the PLC’s logic Is halted, and all outputs may be forced off.1
- Run - Execution of the device’s program occurs in this mode. Input and output (values, points, tags, elements, etc.) are monitored and used according to the program’s logic. Program Upload and Program Download are disabled while in this mode.2314
- Remote - Allows for remote changes to a PLC’s operation mode.4
- Stop - The PLC and program is stopped, while in this mode, outputs are forced off.3
- Reset - Conditions on the PLC are reset to their original states. Warm resets may retain some memory while cold resets will reset all I/O and data registers.3
- Test / Monitor mode - Similar to run mode, I/O is processed, although this mode allows for monitoring, force set, resets, and more generally tuning or debugging of the system. Often monitor mode may be used as a trial for initialization.2
- Triton contains a file named TS_cnames.py which contains default definitions for key state (TS_keystate). Key state is referenced in TsHi.py.5
- Triton contains a file named TS_cnames.py which contains default definitions for program state (TS_progstate). Program state is referenced in TsHi.py.5
- Authorization Enforcement - All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism.
- Human User Authentication - All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support Account Use Policies, Password Policies, and User Account Management.
- 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).
- 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.6
- Access Management - Authenticate all access to field controllers before authorizing access to, or modification of, a device's state, logic, or programs. Centralized authentication techniques can help manage the large number of field controller accounts needed across the ICS.
- Software Process and Device Authentication - Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.
- Network Segmentation - Segment operational network and systems to restrict access to critical system functions to predetermined management systems.6
- 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.