This site has been deprecated in favor of https://attack.mitre.org and will remain in place until 11/1/22.
Modify Alarm Settings
|Modify Alarm Settings|
|Tactic||Inhibit Response Function|
|Data Sources||Network Traffic: Network Traffic Content, Application Log: Application Log Content, Operational Databases: Process History/Live Data|
|Asset||Human-Machine Interface, Control Server, Safety Instrumented System/Protection Relay, Field Controller/RTU/PLC/IED, Device Configuration/Parameters|
Adversaries may modify alarm settings to prevent alerts that may inform operators of their presence or to prevent responses to dangerous and unintended scenarios. Reporting messages are a standard part of data acquisition in control systems. Reporting messages are used as a way to transmit system state information and acknowledgements that specific actions have occurred. These messages provide vital information for the management of a physical process, and keep operators, engineers, and administrators aware of the state of system devices and physical processes.
If an adversary is able to change the reporting settings, certain events could be prevented from being reported. This type of modification can also prevent operators or devices from performing actions to keep the system in a safe state. If critical reporting messages cannot trigger these actions then a Impact could occur.
In ICS environments, the adversary may have to use Alarm Suppression or contend with multiple alarms and/or alarm propagation to achieve a specific goal to evade detection or prevent intended responses from occurring.1 Methods of suppression often rely on modification of alarm settings, such as modifying in memory code to fixed values or tampering with assembly level instruction code.
In the Maroochy Attack, the adversary disabled alarms at four pumping stations. This caused alarms to not be reported to the central computer.2
- Authorization Enforcement - Only authorized personnel should be able to change settings for alarms.
- 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.
- 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.3
- Access Management - All devices or systems changes, including all administrative functions, should require authentication. Consider using access management technologies to enforce authorization on all management interface access attempts, especially when the device does not inherently provide strong authentication and authorization functions.
- 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.34
- User Account Management - Limit privileges of user accounts and groups so that only designated administrators or engineers can interact with alarm management and alarm configuration thresholds.
- Jos Wetzels, Marina Krotofil. (2019). A Diet of Poisoned Fruit: Designing Implants & OT Payloads for ICS Embedded Devices. Retrieved November 1, 2019.
- Marshall Abrams. (2008, July 23). Malicious Control System Cyber Security Attack Case Study– Maroochy Water Services, Australia. Retrieved March 27, 2018.