By Nate Kube
Not too long ago, the Department of Homeland Security revealed a rash of cyber attacks on natural gas pipeline companies. Prior to that, Stuxnet wreaked havoc on Iran’s nuclear program for nearly two years and sparked worldwide controversy and concern about the threat of cyber attacks and cyber crime within critical infrastructures around the world.
Embedded systems and integrated control systems have traditionally been protected within the silos of gas and oil refineries, nuclear facilities and wastewater management and utility plants. However, the introduction of information technologies such as Windows, Ethernet, TCP/IP and wireless technologies within industrial control devices has resulted in significantly less isolation from the outside world.
Industrial Control Systems (ICS) are computer systems that monitor and control industrial infrastructure or facility-based processes. Anecdotal evidence and research indicate Supervisory Control and Data Acquisition (SCADA) protocols, particularly those running over the top of transport protocols such as TCP/IP, have vulnerabilities that could be exploited by network hackers or terrorists, causing considerable disruption to critical infrastructure facilities.
Until only recently, little was known about these vulnerabilities and there was limited security tools or methodologies available for vendors or users to detect these flaws prior to equipment deployment. As highly integrated control systems have advanced, there has been shockingly little data, good or bad, on network security for these industrial devices.
Many current methodologies for security testing focus on business systems and their dependence on common operating systems such as Windows and UNIX. Similarly, vulnerability reporting primarily addresses IT products and rarely includes issues with industrial control products. New testing methodologies must determine the security robustness of integrated control systems.
There is a need for new and efficient tools to test the security robustness of industrial control devices. Many communication protocols are highly complex and their implementations are usually written to a specification that contains small but significant areas of ambiguity. Experience tells us that incorrect assumptions or carelessness of the implementer are common sources of protocol vulnerabilities. Protocol vulnerabilities can reveal themselves as segmentation faults, stack, heap or buffer overflows, etc., all of which can cause the protocol implementation to fail, resulting in a potential exploit.
Tools Can Test
Tools to scan for known vulnerabilities in traditional IT systems have been available for at least a decade. The market for these vulnerability scanners has been significant and many past products have been popular with IT administrators attempting to locate unpatched computers on their networks. Unfortunately these tools offer little in the way of security testing for new products with new vulnerabilities; they only check for known vulnerabilities available in vulnerability lists. As a result, most vendors have little knowledge of possible vulnerabilities in new systems until after the product releases.
This is particularly true for SCADA systems used in critical infrastructures, such as the nuclear, oil and gas, water and electrical generation/distribution industries. The embedded devices used in these systems are not the usual Windows or UNIX-based platforms and the vulnerabilities are not available in IT-focused vulnerability lists. The reality is until a disaster strikes, SCADA operators have little knowledge of possible vulnerabilities in their critical systems.
As highly integrated control systems typically consist of many different devices and because these devices may contain implementations of a variety of protocols, a truly valuable vulnerability-testing tool must be easily applicable to a wide variety of protocols. As well, a valued tool must be employable by users with varying skill sets. For example, the tool should be employable by the vendor, by a field engineer or by a plant floor worker.
However, no amount of testing guarantees correct device behavior in the field; only running all possible tests could do that, and there are generally far too many possible tests to exhaustively run them all. Worse, due to timing variations, a device may pass a test once and fail when the test is rerun later. The pioneering software engineer, E.W. Dijkstra, summarizes the situation well, “program testing can show the presence of bugs but never their absence.”
Detecting a Bug
Nonetheless, testing is the most common approach for finding bugs; a failed test definitively proves that a device has a bug. Well-designed tests are able to exercise a device in near real-world conditions, demonstrating device capabilities and limitations, qualitatively and quantitatively. Such tests increase confidence in device performance, even though absolute confidence is not achievable.
Testing provides valuable data to support comparisons between devices, including different versions of the same device and devices from different vendors. Additionally, testing provides legal and regulatory protection and as systematic testing of networked devices becomes common engineering practice, it will become increasingly risky to omit.
The singular aim of any SCADA protocol test is protecting critical infrastructure and “keeping the lights on.” In support of this goal, testing is not just critically important, it is imperative. This imperative extends from the plant floor to every point where a facility’s systems touch or are touched by the Internet.
In the critical infrastructure environment, we are no longer able to count on “security through obscurity” as more and more devices become Ethernet and wireless enabled. Automated testing of SCADA protocols is key to helping achieve that goal.
Nate Kube founded Wurldtech Security Technologies in 2006 and as the company’s Chief Technical Officer is responsible for strategic alliances, technology and thought leadership.