Securing SCADA Islands

Islands of SCADA in a sea of 'public' insecurity
photo - 'squares' by flickr:fdecomite

Good Tidings - This post discusses securing the environment of SCADA where in-stations and outstations are located within a sea of insecurity created by the use of the Internet as well as the other 'public' communications channels. These Islands of Security require additions to the SCADA protocol stacks as well as the higher user level metrics and accountability.

Dear Readers,

Over the past 10 years, a variety of standards bodies and committees and organisations have been looking into what can be done about securing SCADA systems, given the fundamental fact that they are built that their communications channels are unreliable and essentially insecure.  A knee-jerk response still being seen in newspapers is to require SCADA systems to use 'privately' controlled communications.  I maintain that this is an impossibility in the post-modern SCADA era, such as we have with us now.  Fortunately there is a convergence of thought which shows some promise, and which assumes as a pre-requisite that the public communications domain is inherently unreliable and insecure.  Fantastic.  Lets start from there.

In this blog post - I only have a couple of hours - Christmas is coming you know. -- lets look at the great work recently published by the Distributed Network Protocol [DNP] organisation.  I refer to the DNP Secure Authentication v5 2011-11-08 document recently published.  There are other great works done prior to this, being all the work and discussions on the AGA12 committee and also the engineering standard which underpins the DNP approach.  IEC62351-5.  As I said it is Christmas, so I just wanted to let you know where you could look further for example.

Lets try to summarise the DNP document and some of the general principles involved.  For those of you, a bit hazy on the DNP protocol, the stack is defined in some simple layers, which I will describe briefly:-

• Top layer [User Layer] and number of user programs can use the stack itself.
• [DNP Application layer] This layer, absent in most other protocols, provides the right kind of environment to include the secure authentication barriers.
• [DNP Transport Function]
• [DNP Data Link Layer]
• Bottom Layer [Linkages through common unsecured communications channels, Serial and Internet Protocol]

Most of the requirements for DNP Secure Authentication will impact on either the USER or the DNP Applicatiion Layers.

The class of threats which a communication protocol must address are related to so called Man in the Middle - that is if you imagine an undersea cable deep down in the sea of public communications - the Man in the Middle will be a diver down there somewhere, hidden from view, tapping into the cable, listening in, and then trying to subvert the communications without detection from the people or equipment using the communication channel in the cable. In addition, the protocol must assume that perhaps a rogue application has subverted the authentic SCADA application, and provides for checks to 'shut the gate' on any rogue applications that may have got through any IT based firewalls either by fair means or foul.

Specific threats addressed:-

• - Spoofing - pretending to be a SCADA outstation
• - Modification - intercepting a command and changing it
• - Replay - catching a typical command response sequence and playing it back to assure that all is well.
• - Eavesdropping  - [key exchange only, not data]

Eavesdropping

In a public communications environment, it is difficult to stop people eavesdropping on a communication channel.  In the past, it was difficult, but only because the protocols were not well known, not open, and definitely stuck in a piece of copper wire, not out there on a radio channel or the internet.  The DNP approach is to just prevent eavesdropping or catching the key exchange, which means any encrypted information is not decipherable in real-time.  So the focus is on the key exchange mechanism.

Authentication Only Principle

At this stage, the main requirement is to keep authenticating the right of the application at either end of the protocol stack, to use the stack.

Application Only Principle

The focus on the application layer at both ends of the protocol chain, allows for significant intelligence and heuristics to be applied to not only the action of the protocol itself, but also the action of the interfacing SCADA application, which in turn operates multiple channels and outstations over the DNP links.

Bi-Directional Principle

SCADA consists of Master Stations {MTU}{Controlling Role } and Outstations[RTU] {Monitoring / Controlling Role}.  From the protocol point of view, communications transmission is either from master-to- outstation which is the controlling direction or outstation-to-master which is the monitoring direction.

Challenge Response Principle

Supporting a pragmatic approach which allows secure and unsecure devices to be mixed on the same channels, placing the responsibility for security on the device that requires the authentication.

Pre-Shared Keys Principle

For practical reasons pre-shared keys will be the default.  If the risk is heightened then other options for remote change-out of the pre-shared key can be handled using either symmetric or asymmetric [public key] cryptography.

Backwards Tolerance Principle

This principle describes the conditions that allow secured devices to co-exist with insecure devices.  This is important, because not all devices will constitute a risk or target for a cyberattack, and may not need to be secured as a priority.  This is really a brilliant principle and very pragmatic for real-life SCADA systems.

1. Putting a secure DNP supporting device on a network is ok and it can co-exist with un-secured devices.
2. Un-secured devices must continue to operate normally in the presence of a secured DNP device.
3. Non-Critical information can still be exchanged between secured and unsecured DNP devices

Upgradeable Principle

The whole secure authentication application has to be upgradeable, so algorithms and their data can be changed or improved continually as required, upgrading one end of the link at a time will be ok.

Perfect Forward Secrecy Principle

If an attacker does manage to compromise a DNP session by getting access to a key, then that compromise has a limited lifespan and the attacker would not be able to authenticate data in future sessions.

Multiple Users and Auditing Principle

It is outside the scope of the protocol to do auditing itself, but the NIST requirements for audit trails and the identification of users, in turn require the Protocol Application layer to manage authentication of each user separately from each other and from the master station itself.

....

So dear readers, please take a look when you have time in the new year, and keep in mind that the SCADA community really has determined that public communications networks based on serial links and the suite of IP protocols are here to stay, and as such security for SCADA has to be built into the protocol interface which attempts to use that pool of widespread communications options.  The DNP Secure Authentication is an excellent step in that direction.  Now if you are NOT using the DNP protocol, and in particular if you are using a standard polled Modbus style protocol, then you might consider the upgrade to DNP as a first step to raising the secure awareness of SCADA systems in your environment.

I wish you all the best for Christmas and Happy Holidays and a great New Year on 2012.

Chris Smith - 

Sydney, NSW, Australia