Mar 17, 2011

Implementing SCADA Protocols: Simulating IEC104

by Frank Gifford

By Frank Gifford

For a while, after the Stuxnet worm was discovered in the summer of 2010, supervisory control and data acquisition (SCADA) protocols were a hot news topic. Now the news channels are more concerned about telling us about the latest celebrity drug abuse scandal and seem to have forgotten all about SCADA. Here at BreakingPoint, however, we set to work implementing SCADA protocols in our products so our users could accurately simulate these types of systems, which monitor and control large industrial, infrastructure, or facility-based operations. Additionally, we also added the ability to simulate Stuxnet itself to our security attack coverage.

In this post, I’ll focus on the IEC 60870-5-104 (IEC104) SCADA protocol. Readers may recall my earlier blog post, discussing SCCP and the problems arising from its complex, ad hoc structure. By contrast, IEC104 is simple and clearly defined.

An Overview of IEC104

Like other SCADA protocols, IEC104 transmits data measurements from monitoring devices, such as temperature or pressure sensors, across an industrial control system. In large installations, there may be many of these devices, and they may generate a lot of data over time. The protocol can encode a wide variety of information in a number of different formats. Additionally, it can aggregate measurements in order to reduce the amount of bytes transmitted. The protocol sits on top of TCP, so sequencing and reliability are handled automatically.

There are essentially three types of packets: labeled “I” (Information), “S” (Supervisory), and “U” (Control). Each of these has a common header, which tells us that this is an IEC104 packet and gives the length of the whole packet.

The length is defined as an eight-bit field, so the total packet size will be smaller than 256 bytes, which means fragmentation and reassembly won’t be an issue. As an aside, the protocol defines the maximum length as 253 bytes. But from a security perspective, we need to deal with the possibility that a device might send us bogus data. If we want to write unit tests for this, we should include a packet with a length of 255, just to be sure that the program on the other side behaves correctly.

Within the packets, the system can encode up to 127 measurements. The actual data measured is prefixed with a one-byte type to describe what it is — i.e., floating-point data with a time tag. While the number of bytes to represent the data might vary in length, it’s easy to scan the data in the order provided, so there is no need to back up in the data stream.

At the end of all this scanning, we will be sitting at the end of the packet. It’s easy for the server to validate that it has all the variable data claimed and that it matches up with the previously defined packet length.

Validating IEC104

This protocol would generally be used where the measurement devices themselves are not connected to the outside world, which limits potential hacking. To attack these devices, a hacker would have to get inside your facility or else get a worm onto a computer that interacts with the control system running IEC104. (I’ll caution you again, as I did in the SCCP blog post, that a cunning attacker could attain this access in your corporate waiting area as he “applies” for a job.)

Functional testing of this protocol is relatively straightforward: The device measures a known value and it correctly shows up in your resulting database. But before you buy such a system, it’s worth validating it against more extreme cases. That’s where we come in.

What really matters in SCADA implementations is that you have a few hundred sensors around your factory and they all need to talk to a server, with some sort of requirements for timeliness in reporting data. Using a BreakingPoint CTM, it’s easy to simulate your existing internal network; with the addition of IEC104 to our protocol coverage, you can now simulate any number of IEC104-enabled devices and send them to an actual server. Within a few minutes, you will be able to tell whether your network and the vendor’s server can indeed handle these devices. If not, you can tweak your network parameters in order to find out whether and how you can reach an acceptable performance level.

You can also easily create a scenario where one device erroneously sends a high volume of bogus data. At what point does the server break? It’s a given that in every system there is a data rate at which the server cannot keep up. Once it gets behind, it will be overwhelmed and may even fail completely. Knowing how your system will perform in this extreme case may be a real eye-opener. In any case, wouldn’t it be better to figure out the system’s breaking point during a simulation — before you deploy an IEC104-based system in production?

Lessons Learned and Recommended Actions

For the programmer:

  • Simple protocols are easy to validate; stick with them whenever you can.
  • Build on top of existing features such as TCP’s retransmit and sequencing. Time and again, programmers take the harder route of creating protocols on top of UDP and then trying to put in these features. (For example, run a Google search for “NFS over UDP.”)
  • Verify that your system handles random packets and not just nicely formed data. For IEC104, the first byte is all that is needed to distinguish it. Since the protocol is so simple, it’s easy to verify that a server will do something sane, even when given bogus input.

For the business owner:

  • It’s hard to build a full mockup of a SCADA implementation, complete with hundreds or thousands of measurement devices. It’s easy, however, to build a simulation with our device that will allow you to easily vary parameters — and still let you know how the real-life implementation will work.
  • Figure out the most likely worst-case scenarios and simulate them. Fast turnaround on simulations also means covering more scenarios.
  • Develop your action plans ahead of time for these scenarios. You already know this — and in fact it sounds simplistic to say. But do the people on your team know and practice these plans?

SCADA systems may have dropped out of the headlines, but they’re still important — and still need to be evaluated for performance, security, and stability. We’ll keep improving your ability to simulate real-world protocols and other conditions that affect your network infrastructure — whether they make front-page news or not.

Tags:
blog comments powered by Disqus