SCADA and DCS Security | SCADA Testing | Process Control Security

Suppose that we wished to test the implementation of protocol X in the device under test by sending the one byte payloads 1, 11, 111. Suppose further that the protocol specification states the correct behavior is to send a one byte 0 back.

For this stateless test our grammar file may look like this:

The template file would look like this:

The tuple file would look like this:

The result of the merge would be:

The executor would read these test cases in from a file and one by one send out the bytes following the TX:0 and expect back those following the RX:0. For example, for test case 2 the executor would send out 11 in one byte and expect back 0 in one byte.

This design had several drawbacks. Many of the fields we wished parameterized were bound too early, forcing us to make changes to the grammar proper to adapt the tests to a new DUT. Furthermore, creating large tuple files was cumbersome and usually required the employment of an external program.

For these reasons and others we re-worked our design. We identified what we believed to be the important variabilities present between implementations of a given protocol and we delayed their binding time as long as possible. The resulting design is shown in Figure 2.

The attribute grammar is passed as input to the Code Generator. The Code Generator parses the grammar and creates an executable program called the TestCase Generator. When supplied with an initialization file called the variable_ init file, the TestCase_Generator writes out the PTS's encoded by the grammar to the testCases file. The TestCase_Executor then reads the testCases file along with basic information about the DUT and executes the PTS's one by one, reporting and recording the results.