Modify Control Logic
|Modify Control Logic|
|Tactic||Inhibit Response Function, Impair Process Control|
|Data Sources||Sequential event recorder, Controller program, Network protocol analysis, Packet capture|
|Asset||Safety Instrumented System/Protection Relay, Field Controller/RTU/PLC/IED|
Adversaries may place malicious code in a system, which can cause the system to malfunction by modifying its control logic. Control system devices use programming languages (e.g. relay ladder logic) to control physical processes by affecting actuators, which cause machines to operate, based on environment sensor readings. These devices often include the ability to perform remote control logic updates.
Program code is normally edited in a vendor-specific Integrated Development Environment (IDE) that relies on proprietary tools and features. These IDEs allow an engineer to perform host target development and may have the ability to run the code on the machine it is programmed for. The IDE will transmit the control logic to the testing device, and will perform the required device-specific functions to apply the changes and make them active.
An adversary may attempt to use this host target IDE to modify device control logic. Even though proprietary tools are often used to edit and update control logic, the process can usually be reverse-engineered and reproduced with open-source tools.
An adversary can de-calibrate a sensor by removing functions in control logic that account for sensor error. This can be used to change a control process without actually spoofing command messages to a controller or device.
It is believed this process happened in the lesser known over-pressurizer attacks build into Stuxnet. Pressure sensors are not perfect at translating pressure into an analog output signal, but their errors can be corrected by calibration. The pressure controller can be told what the “real” pressure is for given analog signals and then automatically linearize the measurement to what would be the “real” pressure. If the linearization is overwritten by malicious code on the S7-417 controller, analog pressure readings will be “corrected” during the attack by the pressure controller, which then interprets all analog pressure readings as perfectly normal pressure no matter how high or low their analog values are. The pressure controller then acts accordingly by never opening the stage exhaust valves. In the meantime, actual pressure keeps rising.1
In the Maroochy Attack, Vitek Boden gained remote computer access to the control system and altered data so that whatever function should have occurred at affected pumping stations did not occur or occurred in a different way. The software program installed in the laptop was one developed by Hunter Watertech for its use in changing configurations in the PDS computers. This ultimately led to 800,000 liters of raw sewage being spilled out into the community.2
- Triton can reprogram the SIS logic to cause it to trip and shutdown a process that is, in actuality, in a safe state. In other words, trigger a false positive. Triton also can reprogram the SIS logic to allow unsafe conditions to persist.3 The Triton malware is able to add a malicious program to the execution table of the controller. This action leaves the legitimate programs in place. If the controller failed, Triton would attempt to return it to a running state. If the controller did not recover within a certain time window, the sample would overwrite the malicious program to cover its tracks.3
- 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
- Monitor sensors, logs, Intrusion Detection Systems (IDS), antivirus, patch management, policy management software, and other security mechanisms on a real-time basis as feasible. 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
- Restrict access to control room(s), portable devices, and removable media, which should be locked down and physically secured. Avoid unauthorized and suspicious media and keep it away from systems and the network. Keep track of cables, to ensure that the ICS and IT environments remain separate and no interceptive, adversarial devices are installed.4
- Encrypt and protect the integrity of wireless device communications, while taking care not to degrade end device performance. OSI Layer 2 encryption, rather than Layer 3, can reduce encryption-based latency. Hardware accelerator solutions for cryptographic functions may also be considered. Restrict access to control room(s), portable devices, and removable media, which should be locked down and physically secured.4
- Make use of antivirus and malware detection tools to further secure the environment. In particular, intrusion detection system solutions can assist with monitoring the ICS environment for unexpected or alarming behaviors.4
- Ralph Langner. (2013, November). To Kill a Centrifuge: A Technical Analysis of What Stuxnet's Creators Tried to Achieve. Retrieved March 27, 2018.
- Marshall Abrams. (2008, July 23). Malicious Control System Cyber Security Attack Case Study– Maroochy Water Services, Australia. Retrieved March 27, 2018.
- Blake Johnson, Dan Caban, Marina Krotofil, Dan Scali, Nathan Brubaker, Christopher Glyer. (2017, December 14). Attackers Deploy New ICS Attack Framework “TRITON” and Cause Operational Disruption to Critical Infrastructure. Retrieved January 12, 2018.
- Keith Stouffer. (2015, May). Guide to Industrial Control Systems (ICS) Security. Retrieved March 28, 2018.