MITRE ATT&CK for ICS: Practical Applications, Part 4: Utilize/Change Operating Mode

Part 4 of our blog series continues our journey into how security practitioners working at enterprises with industrial control systems can use the new MITRE ATT&CK for ICS matrix to bolster their cyber defenses.  We remain just as enthusiastic as the day the new ATT&CK matrix was announced. Hopefully you’re as excited as we are and are reviewing your procedures and controls for ways to enhance your current ICS protections.

For this edition, we move to one of the MITRE ATT&CK techniques called Utilize/Change Operating Mode. This technique falls under two tactics — Evasion and Inhibit Response Function — as shown in the graphic below.

MITRE attack matrix - Utilize_Change Operating Mode

Utilize/Change Operating Mode

Let’s look at what the MITRE ATT&CK technique T858: Utilize/Change Operating Mode is all about.

MITRE describes this technique as follows:

“Adversaries may place controllers into an alternate mode of operation to enable configuration setting changes for evasive code execution or to inhibit device functionality. Programmable controllers typically have several modes of operation. These modes can be broken down into three main categories: program run, program edit, and program write. Each of these modes puts the device in a state in which certain functions are available. For instance, the program edit mode allows alterations to be made to the user program while the device is still online.

By driving a device into an alternate mode of operation, an adversary has the ability to change configuration settings in such a way to cause a Impact to equipment and/or industrial process associated with the targeted device. An adversary may also use this alternate mode to execute arbitrary code which could be used to evade defenses.”

To change the program used by the PLC, the PLC must be in the proper mode. These key switch modes vary by vendor, but they typically include the following:

  • Run – standard mode of operation allowing read only access.
  • Remote – allows remote access to program variables but logic changes to programs are not allowed.
  • Stop – stops the control program running on PLCs, typically for modifications to the equipment.
  • Program – allows program loading, program changes, and program uploads or downloads.

This ATT&CK technique, then, is about putting the PLC into a mode that allows modification, or leveraging a current mode that already allows modification. Once in that mode, the adversary can modify the PLC program or upload a new program. You could liken this to the practice of disabling antivirus on a host device in order to allow malware to be installed unimpeded; or perhaps exploiting a vulnerability on a host to gain higher privileged access.

Is this one of those theoretical, ‘it-may-happen’ attack scenarios? Certainly not! MITRE helpfully provides a description of a real-world attack called Triton (aka TRISIS or Hatman) malware that can render the key switch mode moot by allowing program modifications regardless of the keyswitch position.  Triton can also manipulate the data that the industrial control system reports back, thus shielding from view whatever changes the new program might have made to the device’s operating condition.

Practical Defenses Strategies

What, then, are good defenses against this technique? Follow along as we walk through real-life controls in the context of the technique Utilize/Change Operating Mode.

Defense #1: Lock Down, and Monitor, all ICS Devices

Attackers take the path of least resistance, and that path is typically via the Internet. FireEye reported that attackers were able to install Triton malware after gaining remote access to an engineering workstation in just this manner. We addressed some ways to protect workstations from Internet access in our first blog in this series, but let’s look deeper at some additional methods that may help you lock down your devices.

We should all be familiar with the process of hardening devices, but sometimes this important step goes by the wayside in the race to get things into production. Hopefully, your security operations teams have the ability to oversee the rollout of devices that will be used to program and communicate with your PLC devices, and hopefully those devices are adequately hardened. Don’t take a one-size-fits-all approach across all devices on the network. Instead, consider the functionality of every device when removing unnecessary applications and services.

If possible, employ application whitelisting to prevent the installation of unapproved applications. Use anti-malware to block most infections, and keep patches up to date to prevent malware that relies on vulnerabilities to install themselves.

Finally, consider scenarios in which agent-based security controls themselves might be bypassed and lead to a device breach, or your network infrastructure becomes compromised, thus negating network segmentation. Either scenario could further leave your ICS environment susceptible. To guard against this, monitor the behavior of every device in your environment including engineering workstations, printers, cameras, badge readers, etc.  Look for behavior anomalies that indicate an attacker has gained a foothold. Manually comparing current behavior to a baseline of “known good” behavior is extremely difficult, so try to find an automated way to do this. Below is an example of an alert that Armis shows when device behavior is seen to be anomalous, such as an unexpected connection..

MITRE Attack Threat Detection

Defense #2: Get into the Right Mode(s)

Let’s visit another of the important lessons learned with Triton. We know that the mode the PLC was running in at the time of the Triton infection was for Programming.  Let’s look then at some ways we can limit the ability for adversaries to leverage this mode.

First, and this may seem obvious, is to not run PLCs in programming mode. Establish change control processes that ensure that this mode is operational only during planned periods of time. Since mistakes happen, make sure that you are auditing the position outside of these planned time frames for erroneous settings. Enlist network tools that understand when a mode change occurs, and create policies that will alert to this condition. Consider using two different severity level alerts — for example, one alert for normal working hours, and another alert for specific windows (e.g. change freezes) where mode changes should definitely not be occurring, and which triggers  at a higher severity.

An example of a mode change alert is shown below.

MITRE Attack Mode Change
Second, use role-based access (RBAC) controls and strong authentication methods to help prevent unauthorized users from changing the mode on the PLC.  Take steps to prevent lateral movement, e.g. by practicing good password hygiene and leveraging a least privilege strategy.

Finally, physically protect your ICS devices to prevent unauthorized changes to the mode. This can include biometrics, cages, and other locked or segregated spaces. Consider using camera surveillance for remote devices. Remove keys from keyswitches, and physically lock those keys away to provide an additional layer of protection.

Defense #3: Reinforce the Neighborhood

Up to this point, we’ve mainly focused on defensive techniques you can institute within your ICS environment. Let’s take a moment to think about how you can better secure devices outside your ICS environment, because these are frequently the doors that attackers use to enter your ICS environment.

Research suggests that Triton and Industroyer (aka CRASHOVERRIDE) first started in the enterprise environment and then moved into the ICS environment. Along the way, they left telltale signs (i.e. applications, service usage) that could have been used to alert security teams to their presence.

We recommend the following defensive techniques:

  • Segregate your network using firewall or VLAN techniques
  • Monitor network traffic for attack patterns with network-based tools
  • Employ anti-malware on devices that support it
  • Monitor devices for anomalous behaviors
  • Monitor device communication paths including potential bridges into other less-secure networks

As an example from the above list, let’s take a look at how Armis can help you find flaws in your network segmentation. Armis automatically generates a risk score for every device within your environment. The risk score is based on multiple factors, one of which is the presence of unexpected communication paths. In the risk factor chart below, you see that the device is connected to both the “corporate” network and the “ics” network. Note also that policies can be created to alert to these conditions, as well as the option for an audit report.

MITRE Attack Bridge
Armis also allows you to visualize your ICS network levels, using the Purdue model, as shown below. For optimum security, devices in one level should be allowed to communicate with devices in an adjacent level, but not across multiple levels. As you can see in this graph, several devices in Level 1 are communicating directly with devices in Level 4, which is a very poor security practice.

MITRE Attack Purdue Visualization

Conclusion

The old adage is true: your chain is only as strong as the weakest link. Strive to continually improve your defenses, and be vigilant with your monitoring and potential incident follow-up. Remember too that the chain extends beyond the ICS environment. Since ICS environments are increasingly connected to enterprise networks, you can’t secure one without securing the other.

If you want to learn more about how Armis maps to the MITRE ATT&CK for ICS matrix, check out our white paper.

If you haven’t had a chance to read them, you can find our previous blogs here:

Next week is our final blog in this series. We will discuss MITRE ATT&CK technique T816 Device Restart/Shutdown. Until then, be safe!

Have our blog posts sent to your inbox.