We at Armis are huge fans of the new MITRE ATT&CK for ICS matrix that was released in early January. This list of MITRE ATT&CK techniques helps security practitioners assess the strength of their cyber defenses and improve their ability to protect industrial control systems. 

In light of this new release, we plan to publish a series of blogs that will dive into a few of these MITRE ATT&CK techniques and offer some practical advice on how defenders could bolster their defenses.

Armis can detect all of the MITRE’s ATT&CK techniques, as shown below. For this series of posts, we’ll look at MITRE ATT&CK techniques from left to right, starting with the Internet Accessible Device technique (highlighted).

Internet Accessible Device

MITRE explains T883: “Internet Accessible Device” as follows:

“Adversaries may gain access into industrial environments directly through systems exposed to the internet for remote access rather than through External Remote Services. Minimal protections provided by these devices such as password authentication may be targeted and compromised.

In the case of the Bowman dam incident, adversaries leveraged access to the dam control network through a cellular modem. Access to the device was protected by password authentication, although the application was vulnerable to brute forcing.”

It’s common knowledge that, if possible, high-value assets like ICS systems should be protected and monitored from direct internet access through firewalls and other segregation techniques such as tunnels or VLANs. The problem is, these defensive measures by themselves are error-prone. Configuration errors or unknown loopholes can be baked (or creep) into what an administrator thinks is a perfectly segregated infrastructure.

Further, vulnerabilities such as  CDPwn, discovered and disclosed by Armis on February 5, 2020, show that attackers can break network segmentation techniques. Network segmentation should be part of the layered strategy, but by itself it is not sufficient for ICS devices, just like it is not sufficient for normal computers which are routinely loaded down with multiple security agents.

Devices using default or weak password protections lower the boundary of entry even further. One needs only to spend minutes using a search engine like Shodan (which calls itself “The Search Engine for the Internet of Things”) to understand the enormousness of the problem when the factors of direct remote access and poor passwords are compounded.

Practical Defense Strategies

What are some ways, then, that we can detect this MITRE ATT&CK technique?

Defense #1: Know Your Network

You can’t defend what you don’t know about. Be sure that your asset management database is accurate and regularly updated. There have been attacks like those seen at NASA in which an unsanctioned (and undiscovered) device led to a compromise. Asset discovery is the foundation of good security, acknowledged by all of the popular security frameworks (NIST, Critical Security Controls, etc.), so it’s important to do it as accurately as possible.

In the world of  IT management, device discovery tools that utilize network scanning techniques such as NMAP are common. These techniques, however, are risky to use in ICS environments because of the risk of crashing OT devices. Passive device discovery tools are preferred for ICS environments. These tools work by non-intrusively monitoring network traffic, observing the relevant flow of traffic coming from each device, and matching that data to known characteristics in a massive device knowledgebase.

Keep in mind that passive device discovery tools vary in quality. Simplistic discovery tools rely on MAC address or OUI information, but this can’t identify hosts that have had these details spoofed. More robust discovery tools examine multiple characteristics of the device such as it’s communication behavior, location, and software running on the device. Not only can these details lead to a more accurate identification of the device type, but they can also provide the context necessary to make decisions around which security policies you want applied to that device. Be sure that your asset database or device discovery tool provides a deep and useful amount of information for each device.

Defense #2: Monitor and Control Connections

For T883 “Internet Accessible Device and other MITRE ATT&CK techniques that leverage Internet connectivity, it is helpful to consider three different scenarios:

• Unexpected Internet Access — finding those devices that are communicating with the Internet, but should never be Internet accessible.
• Intentional Internet Access — monitoring connections for devices that require internet access.
• Temporary Internet Access — ensuring that access given to a device temporarily for troubleshooting or administrative tasks is not extended longer than required.

Scenario: Unexpected Internet Access

How do you identify unwanted and unexpected Internet access? You can’t simply look at ingress and egress logs because the logs provide no context. They don’t tell you what kind of device each IP address represents. Without this knowledge, it is impossible to know whether an IP address should be communicating with the Internet.  It may be possible to infer whether an Internet connection should be permitted by assuming that all devices on a network segment are the same type of device, but this is a crude and cumbersome approach that is prone to error, especially if network segments contain multiple types of devices, some of which require Internet access and some of which don’t.

A better approach is to combine a device inventory tool (see Defense #1, above) with a security policy engine, a network monitoring system, and a network traffic control point. Such a system would work as follows:

1. Discovery:  A device is discovered in your network. It is using IP address 10.xx.xx.xx. The device was made by manufacturer XXX, it is model number YYY, and it is categorized as a type ZZZ device (for example, a PLC).
2. Policy: Devices that are type ZZZ devices should never communicate with Internet addresses. 
3. Monitoring: All traffic from the IP address 10.xx.xx.xx is continuously monitored.
4. Control: If traffic from IP address 10.xx.xx.xx is detected going to Internet addresses, alert or block the traffic.

To illustrate how this could be done, let’s see how an Armis customer might configure a policy such as the one outlined above. To start with, the Armis platform automatically builds an inventory of every device on the network, including details such as the device type, category, manufacturer, model number, operating system, and many other attributes. Let’s say you decide that all devices of category manufacturing should not be communicating with the Internet. (This is a very simplistic policy, but useful for illustration.)

The Armis administrator would click on ‘Create New Policy’ and pick the pre-built policy template titled  ‘Restricted Device Connected to the Internet’. The new policy now looks like this:

Note the list of IP addresses. In this policy, anything outside of the default non-routable address space is assumed to be an internet connection. If there are routable addresses within your environment, you would define those here or under Internal IPs on the Armis Settings page.

If you wanted the policy to be more granular, you could list additional conditions such as: type:PLC, manufacturer:Rockwell, and protocol:modbus.To see if any devices meeting the conditions specified in the policy have communicated with the Internet over the past, say, 90 days, you can specify that this policy triggers based on past connections. All devices that match this policy will be listed in the Armis dashboard.

The results of the policy can be used to generate an alert or to apply proactive security controls. For example, this information can be used to set internal controls and/or perimeter-based network controls. Armis can interact directly with your switches to enforce the policy, or integrate with your existing network control systems. For example, Armis recently announced a new integration with Check Point. Through this joint development, Armis provides the Check Point IoT Security Manager with highly granular information such as device attributes, risk scores and policy recommendations; Check Point firewalls then provide the appropriate network controls to block unwanted / unexpected Internet access.

Scenario: Intentional Internet Access

Some ICS environments may contain devices that require Internet access. Here are some practical ways that you can ensure that each device is communicating appropriately with the Internet.

1. The defense team should ensure that devices that are directly exposed to the Internet have as few vulnerabilities as possible. Each device should be separately assessed. Is the software up-to-date? Is the device configured properly? Have default passwords been changed? If a vulnerability cannot be addressed (no patch available), are there other ways to mitigate the risk?
2. The defense team should also monitor each device to ensure that Internet communications are “normal” for that device. Is each device accessing the correct set of Internet IP addresses and domains? Are the right services being accessed? Does the amount of traffic, the frequency of communications, and the time of day all look normal for that device? Does the Internet traffic seem to match known attack behaviors? Traditional signature-based IPS can be employed as a layered approach, however, agentless and passive tools employing behavioral analytics can supercede those detections when Internet communications are out of character in ways that would not trigger IPS signatures.

To illustrate how each of these can be done, here are example screenshots from the Armis platform. First, an example of an automated risk assessment that Armis has conducted against an HMI device]:

As with the device inventory capability discussed previously, the risk assessment technique should not include network scans or active device probes because these techniques can negatively impact ICS devices.

In order to detect anomalous Internet communications, Armis uses a combination of machine learning (ML) and artificial intelligence (AI) to compare the real-time behavior of each device on your network with:

• The historical behavior of the device
• The behavior of similar devices in your environment
• The behavior of similar devices in other environments
• Common attack techniques
• Information from threat intelligence feeds

When Armis detects abnormal behavior, it can alert your security team, recommend mitigations,  and, if you wish, initiate an automated response. A typical Armis alert looks something like this:

Scenario: Temporary Internet Access

Lastly, temporary access needs to be accounted for. During times when devices require temporary internet access, you should deploy the same security controls as described above. Otherwise, security teams will be blind during these temporary periods. Be sure that your controls are enabled ahead of these occurrences.

Defense #3: Rinse and Repeat

“Set-and-forget” should not be included in any security control doctrine. Sometimes ACLs are audited and protections can be erroneously removed. Other times, security controls can be temporarily removed during a period of troubleshooting, and the controls are not put back in place. The list goes on and on for what can cause a change in the environment. Remember that errors happen, and it’s up to defenders to regularly monitor and tune controls for these changes.

Conclusion

To be sure, Internet access attacks are not the stuff of blockbuster spy thrillers. BUT… it is important to monitor direct internet access as part of your total defensive strategy. Various tools are available to help you do this.

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

Here are links to other blogs in our 5-part series about MITRE ATT&CK techniques: 

• Part 2 covers MITRE ATT&CK technique T875: Change Program State.
• Part 3 covers MITRE ATT&CK technique T839: Module Firmware.