Device Restart/Shutdown
| Device Restart/Shutdown | |
|---|---|
| Technique | |
| ID | T816 |
| Tactic | Inhibit Response Function |
| Data Sources | Sequential event recorder, Alarm history, Network protocol analysis, Packet capture |
| Asset | Field Controller/RTU/PLC/IED |
Description
Adversaries may forcibly restart or shutdown a device in the ICS environment to disrupt and potentially cause adverse effects on the physical processes it helps to control. Methods of device restart and shutdown exist as built-in, standard functionalities. This can include interactive device web interfaces, CLIs, and network protocol commands, among others. Device restart or shutdown may also occur as a consequence of changing a device into an alternative mode of operation for testing or firmware loading.
Unexpected restart or shutdown of control system devices may contribute to impact, by preventing expected response functions from activating and being received in critical states. This can also be a sign of malicious device modification, as many updates require a shutdown in order to take affect.1
For example, DNP3's function code 0x0D can reset and reconfigure DNP3 outstations by forcing them to perform a complete power cycle.1
In the 2015 attack on the Ukranian power grid, the adversaries gained access to the control networks of three different energy companies. The adversaries scheduled disconnects for the uniterruptable power supply (UPS) systems so that when power was disconnected from the substations, the devices would shut down and service could not be recovered.2
Procedure Examples
- The Industroyer SIPROTEC DoS module exploits the CVE-2015-5374 vulnerability in order to render a Siemens SIPROTEC device unresponsive. Once this vulnerability is successfully exploited, the target device stops responding to any commands until it is rebooted manually.3 Once the tool is executed it sends specifically crafted packets to port 50,000 of the target IP addresses using UDP. The UDP packet contains the following 18 byte payload:
0x11 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 9E.3
Mitigation
- Restrict user privileges with Role-Based Access Control (RBAC). Configure and assign “roles” based on the principle of least privilege. Levels of access can dictate several factors, including the ability to view, use, and alter specific ICS data or device functions.4
- In general, it is unlikely devices in an ICS environment should experience frequent shutdowns. Therefore, monitor physical devices for unexpected state changes and the network for suspicious, related activity.4
- Whenever possible, intrusion detection systems, sensors, logs, and patch management should be done in real-time. These tools can provide tangible records of evidence and system integrity. Additionally, active log management utilities may actually flag an attack or event in progress and provide location and tracing information to help respond to the incident.4
- Applying best password policies and being multi-factor authentication enabled can add an additional barrier to device shutdown, in the situation only verified users have the shutdown capability.4
- Restrict access to control room(s), portable devices, and removable media, which should be locked down and physically secured. Keep track of cables, to ensure that the ICS and IT environments remain separate and no interceptive, adversarial devices are installed. Cable exposure should be as minimal as possible, to reduce likely hood of tampering.4
- Depending on security needs and risks, it might also be prudent to disable or physically protect power buttons to prevent unauthorized use.4
References
- a b Bonnie Zhu, Anthony Joseph, Shankar Sastry. (2011). A Taxonomy of Cyber Attacks on SCADA Systems. Retrieved January 12, 2018.
- ^ Electricity Information Sharing and Analysis Center; SANS Industrial Control Systems. (2016, March 18). Analysis of the Cyber Attack on the Ukranian Power Grid: Defense Use Case. Retrieved March 27, 2018.
