SCADA Systems Security | SCADA Protocol Testing

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 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 products such as Nessus, FoundScan and Internet Security Scanner (ISS) have been popular with IT administrators trying 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 such as CERT or BugTraq. As a result, most vendors have little knowledge of possible vulnerabilities in new systems until after the product is released to the public.

This is particularly true for the 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 the IT-focused CERT or BugTraq vulnerability lists. As a result, SCADA operators have little knowledge of possible vulnerabilities in their critical systems until a disaster (such as the August 2003 blackout in the Eastern U.S.) strikes.

In the academic world there have been several test tools that have had success in locating new vulnerabilities in network devices based on grammar and fuzzy techniques. Considerable work has been done by the PROTOS project group [4] and by Tal, Knight and Dean [5]. Each considers the syntax-based generation of protocol data units (PDU's). A PDU translates into a single test packet to be sent to the device under test (DUT). Their methods have proven effective in finding vulnerabilities [4][5]. However, they only allow for the construction of simple single-packet test cases. Such test cases are not sufficient for testing protocol functionality requiring interaction between the test case generator and the DUT. To perform such testing the test case generator must be able to generate test cases consisting of semantically meaningful sequences of PDU's.

A sequence of PDU's in which each PDU is preceded by its communication direction relative to the test case generator is termed a protocol test sequence (PTS). PTS's can direct test case executors to not only transmit certain PDU’s but also to compare received packets against indicated PDU's. Such ability greatly enhances the effectiveness of fuzzer-based methods.

Furthermore, as highly integrated control systems typically consist of many different devices and because these devices may contain implementations of many different protocols, a truly valuable protocol 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. To the best of our knowledge, no such tool exists.