SCADA Networking Facilitated Using DNP3

February 2011, Vol. 238 No. 2

Kevin L. Finnan, Goshen, CT

Although malware has, for good reason, recently grabbed the attention when it comes to SCADA security, the other threats have not exactly gone away. Since the Stuxnet worm specifically targeted SCADA systems, that is all the better reason to ensure that vulnerability assessments and implementation measures encompass an even broader range of threats to one’s system.

Among the more traditional threats to SCADA systems are eavesdropping and spoofing. Since SCADA networks are often wireless with the communications infrastructure located outside areas that the operator can physically secure, third parties can readily monitor transmissions. If data security is critical, encryption is the key implementation measure. However, adding encryption to systems has, in some cases, caused disruptions and problems with bandwidth.

In many SCADA systems, eavesdropping on data transmission is not as high a threat as spoofing. In spoofing, an outside party attempts to penetrate the SCADA network and send commands. For instance, the outside party could attempt to start or stop compressors on a gas pipeline.

How realistic is this threat? It has happened, though in a different industry. In a now-famous incident in Australia in 2000, a disgruntled former contractor hacked into a SCADA system and operated sewage pumps at lift stations. It didn’t happen only once, either, but 46 times.

In systems in which spoofing is at a much higher threat level than data security, authentication is an appropriate implementation measure. One advantage to authentication is that it presents a much smaller bandwidth load to existing SCADA networks than encryption.

Semaphore recently participated in a project with the scope comprising DNP3 Secure Authentication in an installation of 50 RTUs. DNP3 Secure Authentication is an extension to the existing DNP3 standard incorporating IEC62351 Version 2.0 authentication on top of the DNP3 communication protocol.

DNP was originally created by Westronic, Inc. (now GE Harris) in 1990.1 In 1993, the “DNP 3.0 Basic 4” protocol specification document set was released into the public domain. Ownership of the protocol was given over to the newly formed DNP User Group in October 1993. Since then, the protocol has gained worldwide acceptance, including the formation of Users Group Chapters in China, Latin America, and Australia.

In January 1995, the DNP User Group Technical Committee was formed to review enhancements and to recommend them for approval to the general User Group. One of its most important tasks was to publish the “DNP Subset Definitions” document which establishes standards for scaled-up or scaled-down implementations of DNP3. DNP3 is an open, intelligent, robust, and efficient modern SCADA protocol. It can:

  • Request and respond with multiple data types in single messages,
  • Segment messages into multiple frames to ensure excellent error detection and recovery,
  • Include only changed data in response messages,
  • Assign priorities to data items and request data items periodically based on their priority,
  • Respond without request (unsolicited),
  • Support time synchronization and a standard time format,
  • Allow multiple masters and peer-to-peer operations, and
  • Allow user definable objects including file transfer.(1)

A key advantage of DNP3 is that it is an open, standard protocol with oversight by a vendor-independent user group. With the oversight of a technical committee, DNP3 is able to evolve through the addition of new technology while ensuring backward compatibility so that existing systems don’t find themselves obsolete.

Unlike de facto standard protocols such as Modbus, DNP3 is not subject to vendor-specific variants, which are incompatible with existing installations. While suppliers are not required to completely implement all DNP3 functionality, the implementations have to fall within very well-defined subsets.

Only a nominal fee is charged for documentation, but otherwise, it is available worldwide with no restrictions. This means that a user, such as a utility, can purchase master station and outstation computing equipment from any manufacturer and be assured that they will reliably communicate with each other. Utilities are not bound to one manufacturer after the initial sale.(2)

Authentication Background
DNP3 Secure Authentication (3) is an extension to the existing DNP3 standard incorporating IEC62351 Version 2.0 authentication on top of the DNP3 communication protocol. According to the DNP3 User Group, the purpose of this specification is to define a protocol mechanism that:

• A DNP3 outstation can use to unambiguously determine it is communicating with a user who is authorized to access the services of the outstation.
• A DNP3 master can use to unambiguously determine that it is communicating with the correct outstation.

The specification addresses authentication only, not encryption or other security measures. It does not rule out the possibility of such measures being added to DNP3 later or through the use of external measures such as “bump in the wire” link encryptors.


(caption)DNP3 Secure Authentication is available in an increasing number of RTU products such as the Kingfisher G30.

The Challenge Process
(Ed. note: see article header image.) When a command, e.g. to open a valve or start a compressor, is received from the server, the RTU challenges the server to be sure it is a legitimate node on the network (blue arrow in the diagram).
The server responds with an authentication message (yellow arrow in diagram).

If the server authenticates correctly, only then will the RTU perform the action (green arrows).

The authentication key is updated at regular intervals in order to prevent old keys from being stolen and re-used.

If an RTU does not receive a new key within a specified time limit, it will mark the key as stale and ignore commands until a new key is provided.

Interpretation
While the DNP3 User Group stated their intentions very clearly in the DNP3 Secure Authentication specification, there were still areas open for interpretation among the SCADA host developers, RTU driver developers and RTU firmware developers. Security key management was a major issue. Questions included: 1) who is responsible for the keys? 2) how are keys updated? 3) how often are keys updated?

Communication among the parties was essential to resolving all the issues with the resulting system meeting all needs in terms of security, operations and maintenance.

Compatibility with the DNP3 Time Synch exemplified these issues. Secure DNP3 is compatible with Standard DNP3 to enable progressive security enhancements to existing networks. In an existing, DNP3 network, all RTUs would normally accept the time synchronization, which is broadcast from a server. Since this network uses DNP3 Secure Authentication and Time Synch messages must be challenged, the team determined that, instead of broadcasting to all nodes, updates should occur individually to prevent a flood of authentication requests.


The project team determined that DNP3 Time Synch updates should occur individually rather than being broadcast in order to prevent a flood of authentication requests.

Benefits Beyond Security
For SCADA systems in the pipeline and utility industries, the DNP3 protocol offers numerous benefits in addition to secure authentication.

DNP3 uses the term outstation to denote remote computers or devices as found in the field. The term master is generally used for the computers in the control centers. DNP3 supports a variety of network architectures, including point-to-point, multi-drop, hierarchical and data concentrator.(2)

DNP3 also allows multiple masters and peer-to-peer operations.

Using DNP3, a master gathers data from outstations primarily by sending requests, which function is known as polling. This keeps the data base in the master up-to-date with respect to the data bases in the outstations.

One master station may communicate with multiple outstation devices. Conversations are typically between the master and one outstation at a time. The master requests data from the first outstation, then moves on to the next outstation for its data, and continually interrogates each outstation in a round-robin order. The communication media is a multi-dropped telephone line, fiber-optic cable or radio. Each outstation can hear messages from the master and is only permitted to respond to messages addressed to itself. Outstations may or may not be able to hear each other.(2)

DNP3 also allows an outstation to send unsolicited messages to a master. This best allows immediate notification of an important occurrence such as an alarm.


DNP3 supports point-to-point and point-to-multi-point (multi-drop) connections between a SCADA host “top end” server, in the capacity of a master, and RTUs in the capacity of outstations.


Compatibility with IP and wireless networks has allowed DNP3 to be used over contemporary, Ethernet and GSM/GPRS cellular networks.

Among the broad variety of SCADA system architectures accommodated by DNP3 is a hierarchical network. Since Kingfisher supports master and outstation functionality in the same RTU, it fully supports hierarchical networks. These are often used to suit SCADA system layouts with clusters of installations in a number of remote regions. Since the overall SCADA system master links with a much smaller number of devices than it would in a flat network, communications costs on networks such as cellular and satellite can be significantly reduced.

Addressing and messaging are all part of standard, DNP3. The intermediate RTU may be referred to as a master, outstation or data concentrator DNP3 device. This may not always be present in other devices. Configuration is greatly simplified and the complex programming required for hierarchical networking when using other protocols is avoided.


In a hierarchical network, an RTU can function as both a DNP3 master and DNP3 outstation and route messages in a “pass-thru” manner.

Data Concentrator
The terms, “data concentrator,” and “protocol converter” are used for a device that gathers data using one protocol and transmits it using a different protocol. SCADA systems using DNP3 often also include intelligent end devices, otherwise known as intelligent electronic devices, which use different protocols. These devices can be wireless sensors or hard-wired devices that interface with serial ports or Ethernet.

Data concentrators are often also used in systems, which are evolving to DNP3 from an older, perhaps proprietary, protocol. Since an entire, system-wide protocol conversion is not usually feasible, data concentrators allow the conversion to be done in a step-wise manner.


An RTU can also function as a “data concentrator,” which communicates as a DNP3 outstation to a DNP3 master and, in turn, as a master to other RTUs in a network that uses a different protocol.


Conversely, the RTU can be a data concentrator that is a DNP3 master and an outstation using another protocol. This typifies installations in which the SCADA host or “top end” system continues to use an existing protocol while the rest of the system upgrades to DNP3.

Network Master
As a network master, an RTU can provide functionality that is not available in, or is a very expensive addition to, the SCADA host software. For example, DNP3 Secure Authentication may not be available. Using the RTU as a network master, the SCADA system can implement secure authentication, end-to-end, even though it is not a feature of the host software.

In a hierarchical network, other RTUs can be both masters and outstations. In that capacity, they are often referred to as “sub-masters.”


An RTU has the capacity to “top off” a large, SCADA network and can provide functionality that is not available in the SCADA host/top end. For example, the RTU can be a DNP3 Secure Authentication master and provide for a secure, DNP3 network, end-to-end, even when the SCADA host lacks that feature.

Multi-master Architecture
A multi-master architecture is among the methods for implementing redundancy at the host level and also allows third-party users to link to one or more RTUs in the SCADA system. In a hierarchical network, multiple masters can be employed at any level. An outstation RTU can communicate with a SCADA host computer system and another RTU, both of which are masters.

The RTU uses a single communication port and distinguishes the masters by the source address. This implementation provides a secondary advantage in that if a master station changes the interface it is employing for communications with the outstation, it can seamlessly resume communications from the point it left off.

A practical application has emerged in the natural gas industry in custody transfer and fiscal metering installations. An example is a meter station which links a power plant to a natural gas pipeline. While the pipeline operator uses a SCADA system across the entire pipeline, the power-plant operator is interested only in the gas flow and related information from the meter station. Using a computer system that is a master to the outstation RTU at the meter station, the power plant operators can access the information they require. At the master station level, data base configuration makes it simple to restrict access only to the information they need.


Multi-master support allows third parties to access information in an RTU or on a portion of the network.

Peer-to-peer Communications
SCADA systems commonly include distributed control or distributed data bases, which require information transfer from one RTU to another. This information may or may not be included in the host data base. Since DNP3 messages include a source address and a destination address, one RTU can send a message directly to another RTU. Peer-to-peer messaging is often used between nearby substations, a meter station and a nearby compressor station, or a primary and back-up generator.


Using DNP3 peer-to-peer communication, one RTU transmits messages directly to another.

Two Messaging Types
DNP3 supports two types of messaging – exception reporting and respond without request – which are often confused with each other. Exception reporting or report-by-exception (RBE) is messaging in which the outstation is polled by a master but only reports values that have changed since the prior poll. RBE can substantially decrease the amount of information that is transmitted, reduce communications costs, and decrease turn-around time.

Respond without request, unsolicited messaging or push communications is messaging in which the outstation initiates a message without being polled by a master. This is best for alarms, emergencies, operations failures or any critical messages which should not wait for the master to get around to the outstation on its polling cycle.

Recovery
Using DNP3, an RTU can automatically upload missing data upon restoration of communications after a failure. The DNP3 driver in the SCADA host software must support this capability. Systems are currently operating using a wide variety of communications media, including Ethernet, ISDN, private telephone lines, PSTN and radio.

To test or demonstrate this capability, the communication link between the RTU and a PC can be disconnected for a period of time and then reconnected. DNP3 communications will be restored and the data stored in the RTU during the communications outage will be sent to the software on the PC.


Using DNP3, an RTU can automatically upload missing data upon restoration of communications after a failure.

Conclusion
DNP3 Secure Authentication is an extension to the existing DNP3 standard incorporating IEC62351 Version 2.0 authentication on top of the DNP3 communication protocol. According to the DNP3 User Group, the purpose of this specification is to define a protocol mechanism that:

• A DNP3 outstation can use to unambiguously determine it is communicating with a user who is authorized to access the services of the outstation.
• A DNP3 master can use to unambiguously determine that it is communicating with the correct outstation.

The DNP3 protocol has gained worldwide acceptance. It is a vendor-independent protocol and is owned by the DNP3 User Group. DNP3 is an open, intelligent, robust, and efficient modern SCADA protocol. It can, request and respond with multiple data types in single messages, segment messages into multiple frames to ensure excellent error detection and recovery, include only changed data in response messages, assign priorities to data items and request data items periodically based on their priority, respond without request (unsolicited), support time synchronization and a standard time format, allow multiple masters and peer-to-peer operations, and allow user definable objects including file transfer.

Author
Kevin L. Finnan
is vice president of Marketing for CSE-Semaphore, a global supplier of automation and RTU products for SCADA system applications. He has 30 years of experience in the automation and measurement industries with companies including Semaphore and Bristol Babcock.

References
1. DNP3 Overview, Triangle MicroWorks, Inc., Raleigh, NC.

2. A DNP3 Protocol Primer, DNP Users Group, P.O. Box 43075, DVPO, Calgary, Alberta T2J 7A7 Canada.

3. DNP3 SPECIFICATION, Supplement to Volume 2, SECURE AUTHENTICATION, Version 2.00, 31 July, 2008, DNP Users Group, P.O. Box 43075, DVPO, Calgary, Alberta T2J 7A7 Canada.

Find articles with similar topics
, ,