ICSJWG: Basic, but Effective Security

Friday, October 26, 2012 @ 03:10 PM gHale


EDITOR’S NOTE: Joel Langill, chief technology officer at SCADAhacker, gave a presentation at the ICSJWG fall conference in Denver. This report is an excerpt from that presentation. There is also a copy of the presentation on the SCADAhacker site and a copy of the spreadsheet of calculatons.

By Joel Langill
Most industrial control system vendors, integrators and end-users familiar with the leading cyber security standards are aware of the importance of properly segmenting their networks in order to isolate the various hosts from one another.

From an industrial control system (ICS) point of view, this isolation should center on the relative security level of each hosts with respect to others, such that hosts that share similar security profiles are within the same segment or “zone” per the ISA99 standards.

RELATED STORIES
ICSJWG: Attack Tree Blooms
ICSJWG: Whitelisting Project
ICSJWG: Cyber Exercises a Key
ICSJWG: Knowledge Sharing
ICSJWG: Researchers on Same Team

The most obvious step is the separation of the control system networks from the traditional office networks. At the highest level, these two zones can end up separated from all traffic between these two zones passing through a “conduit.” Users usually install a firewall on the conduit, which uses a set of rules that determine exactly what traffic it allows through this conduit. What commonly ends up missing, however, is some form of additional protection or “defense-in-depth” strategy to help restrict data flow in the event of a malfunction in the firewall installed on the conduit. This malfunction may be due to the exploitation of a vulnerability or software bug, or something more common such as misconfiguration of the rules.

The basis for nearly all the networks used for industrial control systems is on the Internet Protocol or IPv4, which contains a pair of numbers used to define its location on a network: The host address and the subnet mask. Together, these numbers help uniquely identify a host in terms of its host number and also its network number.

What often ends up overlooked is the fact a firewall contains a network interface configured with an IP Address and subnet mask for each of the networks that it connects. Furthermore, any traffic that sends out these interfaces, possesses the network characteristics defined by its interface.

What are you talking about here?

Let’s use an example. If the firewall has an interface configured with an address of 192.168.1.1 and a subnet mask of 255.255.255.0, then all of the data placed on this interface must fit into this addressing scheme. This means any data placed on this interface can communication with up to 254 addresses contain on Network 192.168.1.0 over a range of 192.168.1.1 through 192.168.1.254. The first and last numbers in the range are reserved and are used for special purposes, and cannot typically be assigned to hosts.

So, going back to the to the original premise: If all data that enters the firewall and placed on the network interface can communicate with all possible hosts on the network, what additional layers of protection do we have if something happens to “slip through” the firewall? Very little.

What we can do is restrict the hosts that are “visible” to the firewall by using a variable length Subnet mask on its interface based on the devices that need to be visible through the firewall. Here is a simple example. If there is only one server that needs to communication with the network on the other side of the firewall, then why don’t we restrict the firewall’s network interface such it can only see this single device. So, if we configured the firewall with an Address of 192.168.1.1 and a Subnet Mask of 255.255.255.252, the only other host that can communicate with this interface is at 192.168.1.2.

This model can further expand to actually prevent certain devices on a network from communication with some devices, while allowing full communication with others. In one example, you can configure a PLC with an address/mask combination that allows it to only communication with the SCADA server, while blocking communication from the HMI or any traffic that enters the network through the router. The server is able to communicate with all devices on the network, and is also visible to any traffic that enters the network through the router.

This can be a very useful security control, as it adds an additional layer of protection to the network, and can in fact, simplify the configuration of the router and/or firewall. Implementing these types of addressing schema at a very low level makes it extremely difficult for malware to successfully navigate and potentially infect other nodes on the network, at the same time, make the ability to create covert communication channels with remote hosts and command-and-control servers very difficult.

Joel Langill is the chief technology officer at SCADAhacker.



Leave a Reply

You must be logged in to post a comment.