SCADA Protocol Testing in Critical Infrastructure
By Nate Kube
Critical infrastructure cybercrime has led to worldwide controversy and concern around the world. The Department of Homeland Security recently addressed cyber-attacks on natural gas pipeline companies; prior to that, the STUXNET computer virus wreaked destruction on Iran's nuclear program for nearly two years.
Embedded systems and integrated control systems (ICSes) have traditionally been protected within the silos of gas and oil refineries, nuclear facilities, wastewater management, and utility plants. However, the introduction of information technologies such as TCP/IP, Windows, Ethernet, and wireless technologies within industrial control devices has resulted in significantly less isolation from the outside world.
ICSes are computer systems that control and monitor industrial infrastructure or facility-based processes. Research and anecdotal evidence indicate that 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.
Little was known about these vulnerabilities until recently, and limited security tools or methodologies are 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 about network security for these industrial devices. Current methodologies for security testing focuses on business systems and their dependence on common operating systems such as Windows and UNIX. Vulnerability reporting primarily addresses IT products and seldom includes issues with industrial control products. New testing methodologies are required to determine the security robustness of integrated control systems.
New and exceptionally effective tools are needed to test the security robustness of ICSes. Many communication protocols are extremely intricate and their implementations are typically 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 expose themselves as segmentation faults or stack, heap or buffer overflows, all of which can cause the protocol implementation to fail, resulting in a potential exploit.
Tools to scan for vulnerabilities in conventional IT systems have been available for at least a decade. The market for these vulnerability scanners has been substantial 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 is released. This is particularly true for the SCADA systems used in critical infrastructures, such as the nuclear, oil and gas, and water and electrical generation/distribution industries.
These are not the usual Windows or UNIX-based platform embedded devices and the vulnerabilities are not available in IT-focused vulnerability lists. The reality is that until a disaster strikes, SCADA operators have little knowledge of possible vulnerabilities in their critical systems.
Highly integrated control systems typically consist of many distinctive devices and may implement 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.
Software engineer pioneer E.W. Dijkstra summarizes the situation well: "Program testing can show the presence of bugs but never their absence."
The most common approach for finding bugs is testing; 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, representing device capabilities and limitations, qualitatively and quantitatively. Such tests increase confidence in device performance, even though absolute confidence is not achievable.
Valuable testing data supports 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.
"Keeping the lights on" and protecting critical infrastructures remains the focus of any SCADA protocol test. In support of this goal, testing is not just critically important, it is essential. This imperative extends from the plant floor to every point touched by a facility's systems or by the Internet.
Counting on "security through obscurity" is no longer something we can rely on as more devices become Ethernet and wireless enabled in the critical infrastructure environment. Automated testing of SCADA protocols is key to helping protect critical infrastructures.
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. He is a subject matter expert in embedded device protection for high-availability process automation, medical, and health-care industries. Nate holds patents in formal test methods and critical systems protection. He has co-authored articles for the embedded-device security market, frequently presents on cyber security issues, and has testified on smart grid interoperability standards for the U.S. Federal Energy Regulatory Commission (FERC). He serves as an expert for the TC65 working group on the IEC 62443-2-4 international standards project. You can contact the author at firstname.lastname@example.org.