Secure your SCADA architecture by separating networks
Many critical national infrastructure systems include supervisory control and data acquisition (SCADA) functionality. These systems can be viewed as the set of software, computers and networks that provide remote co-ordination of controls systems for tangible infrastructures such as power generation systems, chemical plants, manufacturing equipment and transportation systems
Adapted from Cyber Attacks: Protecting National Infrastructure (Butterworth-Heinemann) By Edward G Amoroso
Many critical national infrastructure systems include supervisory control and data acquisition (SCADA) functionality. These systems can be viewed as the set of software, computers and networks that provide remote co-ordination of controls systems for tangible infrastructures such as power generation systems, chemical plants, manufacturing equipment and transportation systems. The general structure of SCADA systems includes the following components:
- Human-machine interface (HMI) -- the interface between the human operator and the commands relevant to the SCADA system
- Master terminal unit (MTU) -- the client system that gathers data locally and transmits it to the remote terminal unit
- Remote terminal unit (RTU) -- the server that gathers data remotely and sends control signals to field control systems
- Field control systems -- systems that have a direct interface to field data elements such as sensors, pumps, and switches
Firewalls between MTUs and RTUs are essential to SCADA systems
The primary security separation issue in a SCADA system architecture is that remote access from an MTU to a given RTU must be properly mediated according to a strong access control policy. The use of firewalls between MTUs and RTUs is imperative in any SCADA system architecture. This separation must also enforce policy from any type of untrusted network, such as the internet, into the RTUs. If this type of protection is not present, then the obvious risk emerges that an adversary can remotely access and change or influence the operation of a field control system.
As one might expect, all the drawbacks associated with large-scale firewall deployment are also present in SCADA systems. Coverage and accuracy issues must be considered, as well as the likelihood that individual components have direct or wireless connections to the internet through unknown or unapproved channels. This implies that protection of RTUs from unauthorised access will require a combination of segregated local area firewalls, aggregated enterprise-wide firewalls, and carrier-hosted network-based firewalls.
SCADA environments developed in isolation from systems protected by security mechanisms
The biggest issue for SCADA separation security is that most of the associated electromechanical systems were designed and evolved in an environment largely separate from conventional computing and networking. Few computing texts explain the subtle details in SCADA system architecture; in fact, computer scientists can easily complete an advanced programme of study without the slightest exposure to SCADA issues. Thus, in far too many SCADA environments, the computerised connections between tangible systems and their control networks have occurred in an ad hoc manner, often as a result of establishing local convenience such as remote access. For this reason, the likelihood is generally low that state-of-the-art protection mechanisms are in place to protect a given SCADA system from cyber attack.
An additional problem for SCADA firewall usage is that commercial firewalls do not generally support SCADA protocols. When this occurs, the firewall operator must examine which types of ports are required for usage of the protocol, and these would have to be opened. Security experts have long known that one of the great vulnerabilities in a network is the inadvertent opening of ports that can be attacked. Obviously, national infrastructure protection initiatives must be considered that would encourage and enable new types of firewall functionality such as special proxies that could be embedded in SCADA architecture to improve immediate functionality.
Physical separation of networks -- unplug the internet!
One separation technique that is seemingly obvious, but amazingly underrepresented in the computer security literature, is the physical isolation of one network from another. On the surface, one would expect that nothing could be simpler for separating one network from any untrusted environment than just unplugging all external connections. The process is known as air gapping, and it has the great advantage of not requiring any special equipment, software, or systems. It can be done to separate enterprise networks from the internet or components of an enterprise network from each other.
The problem with physical separation as a security technique is that, as complexity increases in some system or network to be isolated, so does the likelihood that some unknown or unauthorised external connection will arise. For example, a small company with a modest local area network can generally enjoy high confidence that external connections to the internet are well-known and properly protected. As the company grows, however, and establishes branch offices with diverse equipment, people and needs, the likelihood that some generally unrecognised external connectivity will arise is high. Physical separation of networks becomes more difficult.
How can you create a truly air-gapped network?
The answer lies in the following basic principles:
- Maintain clear policy over acceptable connections -- if a network is to be physically isolated, then clear policy must be established around what is and what is not considered an acceptable network connection. Organisations need to establish policy checks as part of the network connection provision process.
- Use boundary scanning to identify leaks -- isolated networks, by definition, must have some sort of identifiable boundary. Although this can certainly be complicated by firewalls embedded in the isolated network, a program of boundary scanning will help to identify leaks.
- Spell out the consequences of violating the network separation -- if violations occur, clear consequences should be established. Government networks in the US military and intelligence communities, such as SIPRNet and Intelink, are protected by laws governing how individuals must use these classified networks. The consequences of violation are not pleasant.
- Provide reasonable alternatives -- leaks generally occur in an isolated network because someone needs to establish some sort of communication with an external environment. If a network connection is not a reasonable means to achieve this goal, then the organisation must provide or support a reasonable work-around alternative.
Dual homing the biggest threat to isolated networks
Perhaps the biggest threat to physical network isolation involves dual-homing a system to both an enterprise network and some external network such as the internet. Such dual-homing can easily arise where an end user uses the same system to access both the isolated network and the internet. As laptops have begun to include native 3G wireless access, this likelihood of dual-homing increases.
Implementing a national separation programme
Implementing a national separation programme would involve verification and validation of design goals in government agencies and companies with responsibility for national infrastructure. These goals, related to policy enforcement between requesting users and the protected national assets, would include the following:
- Internet separation -- critical national assets simply should not be accessible from the internet. One would imagine the control systems for a nuclear power plant, for example, would be good candidates for separation from the internet. Formal national programs validating such separation would be a good idea. If this requires changes in business practice, assistance and guidance would be required to transition from open, internet connectivity to something more private.
- Network-based firewalls -- national infrastructure systems should be encouraged to use network-based firewalls, preferably ones managed by a centralised group. The likelihood is higher in such settings that signatures will be kept up to date and that security systems will be operated properly. Procurement programmes in government, in particular, must begin to routinely include the use of network-based security in any contract with an internet service provider.
- DDOS protection -- all networks associated with national assets should have a form of DDOS protection arranged before an attack occurs. This protection should be provided on a high-capacity backbone that will raise the bar for attackers contemplating a capacity-based cyber attack. If some organisation, such as a government agency, does not have a suitable DDOS protection scheme, this should be likened to having no disaster recovery program.
- Internal separation -- critical national infrastructure settings must have some sort of incentive to implement an internal separation policy to prevent sabotage. The Sarbanes-Oxley requirements in the US attempted to enforce such separation for financial systems. While the debate continues about whether this was a successful initiative, some sort of programme for national infrastructure seems worth considering. Validation would be required that internal firewalls exist to create protection domains around critical assets.
- Tailoring requirements to the network -- incentives must be put in place for vendors to consider building tailored systems such as firewalls for specialised SCADA environments. This would greatly reduce the need for security administrators in such settings to configure their networks in an open position.
Regardless of the method, if any sort of connectivity is enabled simultaneously to both systems, the end user inadvertently creates a bridge. It is worth mentioning that the bridge does not necessarily have to be established simultaneously. If a system connects to one network and is infected with some sort of malware, this can be spread to another network in a later connection. For this reason, laptops and other mobile computing devices need to include some sort of native protection to minimise this problem. Unfortunately, the current state of the art for preventing malware downloads is poor.
A familiar technique for avoiding bridges between networks involves imposing strict policy on end-user devices that can be used to access an isolated system. This might involve preventing laptops, PCs and mobile devices from connecting to the internet. Instead, they exist solely for isolated network usage. This certainly reduces risk, but is an expensive and cumbersome alternative. The advice here is that for critical systems, especially those involving safety and life-critical applications, if such segregation is feasible, it is probably worth the additional expense. In any event, additional research in multimode systems that ensure avoidance of dual-homing between networks is imperative and recommended for national infrastructure protection.
©2011 Elsevier, Inc. All rights reserved. Printed with permission from Butterworth-Heinemann, a division of Elsevier. Copyright 2011. "Cyber Attacks: Protecting National Infrastructure" by Edward G. Amoroso. For more information on this title and other similar books, please visit elsevierdirect.com
