The WITS-DNP3 protocol relies on the security provided by the standard DNP3 protocol. DNP3 has never looked at the physical layer of the communications network and so when implementing DNP3 systems the user must be aware of the need to secure the communications network. The SCADA system is only vulnerable if the attacker has access to the system:
- Using ADSL where some part of the communications system spans the public domain internet. In this case the system needs to be protected by implementing additional features such as VPN tunnels between the Field Device and the user’s central premises.
- Using GPRS, either with a private APN or managed APN, the system will only be vulnerable to an attack from an insider
- Using radio networks then these are open to attack. The user should check if the radio offers a data encryption feature. Using encryption will give the user protection against eavesdropping, a threat not protected by DNP3 secure authentication
- Using GSM / PSTN then these are open to attack because the telephone numbers cannot be guaranteed to be kept secret
So, where the system is open to attack, we rely on the security offered by DNP3 secure authentication.
Moving from DNP3 SAv2 to SAv5?
IEEE 1815-2012™, the standard defining the DNP3 Specification, includes a significant update to the Secure Authentication section of the specification. An updated security procedure (SAv5) has been developed that replaces the previous version (SAv2) and the document states that it is recommended that the new version be used in new deployments.
The DNP User Group is aware that there are field deployments using SAv2. These systems can continue to be used. There are no mandatory requirements to remove, replace or update existing deployments to SAv5. SAv5 is recommended for new deployments.
So why does IEEE 1815-2012 make these changes?
There are three drivers for the changes between SAv2 and SAv5:
- Addressing evolving security threats:
In developing SAv5, the operation of DNP3 SA has been reviewed by independent external security experts. A number of features in SAv2 were identified as being potentially vulnerable. Additionally, the Smart Grid Interoperability Panel (SGIP) Cyber Security Working Group (CSWG) has a set of security criteria that must be met in order to permit IEEE 1815 to be adopted as a recommended standard for use in the Smart Grid. Some modifications that appear in SAv5 were included in order to meet SGIP security requirements.
- Correcting faults that have been found in SAv2:
Some operational incompatibilities have been found in the procedures defined in SAv2. These errors primarily relate to sequences used in unsolicited reporting and device restart and are corrected in SAv5.
- Adding remote key-management functions:
This additional functionality is optional: A major part of these functions support multiple users with user roles. This enhanced functionality allows remote changes to users roles and manages the creation of new users and deletion of existing users. None of this is applicable to a WITS device because WITS only defines one user, with a role defined as “allowed to do everything”. If SAv5 is used without support for these functions there is little difference in the amount of software and processing power required to support SAv5 compared to what was required in SAv2.
1. The evolving security threats
a. Brute force attacks
SAv2 defaults to using a SHA-1 algorithm for computing HMAC (hash) values. The SAv2 specification allows the resulting 20 octet hash value to be truncated to as few as 4 octets. Truncating the resulting hash to less than 10 octets is considered a risk and offers poor protection against “brute force” attacks. US standards insist on the hash value being at least 10 octets.
b. Collision attacks
Recent analysis and publications show that the SHA-1 algorithm is not as secure as originally thought. SHA-1 has been shown to be vulnerable to collision attacks. US standards now recommend the use of an algorithm from the “SHA-2 family”, which so far have been shown not to be vulnerable to these attacks. So the default algorithm SHA-1 that is specified in SAv2 is changed to be SHA-256 in the SAv5 specification.
SAv2 has content that states that it protects against the threat of non-repudiation i.e. that it can protect against a user saying “I didn’t do that”. Security analysis shows that this threat is not actually protected by SAv2, merely that SAv2 can provide an audit trail allowing visibility of the user actions. The SAv5 specification corrects this statement.
d. Denial of service (DOS) attacks
SAv2 does not categorise the different failures when handling the different DNP3 messages. As a result the fail count can increase very quickly which then results in a re-key requirement. An attacker sending invalid requests to the device can cause continuous re-keying which may stop virtually all normal DNP3 traffic. SAv5 identifies different classes of failure, shows which classes should cause a re-key, and if re-keying is occurring very frequently then specifies a way to minimise re-keying. This provides some alleviation of DOS attacks.
SAv2 also specified that if a device is waiting for a specific security response and receives a different message then it should stop waiting for the expected response and process the received message. This opens the device to the threat of DOS attacks. SAv5 correctly specifies that the device should ignore the received message and continue to wait for the security response.
e. Improved security statistics
The method specified in SAv5 for identifying the different classes of failure uses an enhanced set of security counters. SAv5 maps these counters to data objects that can be retrieved by the Master Station over the normal DNP3 communications channel. Users thus have visibility of these counters which may assist in recognising the occurrence of cyber-attacks.
2. Faults identified in SAv2
a. Unprotected operations
SAv2 specifies the DNP3 operations that are considered to be “critical” and hence must be challenged when they are used. Security analysis showed that there are some functions that should have been identified as critical in order to secure the operation of a remote device. SAv5 adds to the list of critical functions, including operations such as open file, close file and delete file. The WITS-DNP3 specification has already identified “open file” and “delete file” as critical, “close file” as optional.
b. Unsolicited communications
The WITS-DNP3 devices that implemented SAv2 identified a number of possible different actions to scenarios which were not covered in the specification. With help from the DNP Technical Committee these actions were agreed. SAv5 documents these actions.
c. Device restarts
The WITS-DNP3 devices that implemented SAv2 identified a number of possible different actions at device restart which were not covered in the specification. With help from the DNP Technical Committee these actions were agreed. SAv5 documents these actions.
It is believed that WITS-DNP3 devices with SAv2 already implement all of the above.
3. Adding remote key-management functions
SAv5 adds functionality to the specification in two forms. The first is to allow remote changes to the user’s “update key”. The second adds functionality to manage users and their roles.
a. Remote changes of the update key
If a device’s update key is compromised then rather than being forced to visit the device to configure a new key SAv5 describes how a new key can be sent from the Master Station. Implementing this function requires that the Mater Station be able to communicate with an entity known as the “DNP Authority”. This entity is a software package that manages the generation of keys etc.
b. Managing users and roles
SAv2 included in the specification the ability to identify a number of different users at the master station – each user having their own security keys. SAv5 adds enhancements to the specification to allow users to have different roles. It then specifies how users can be added and removed from the system, as well as having changes made in their roles.
The WITS-DNP3 specification has a single user with a single role (allowed to do everything) so these SAv5 functions are not applicable to WITS devices.
So should a WITS user consider the move to SAv5?
The immediate benefits of a move to SAv5 are:
a. Improved resilience to attacks
Does the user have evidence of attack? What sort of attacks are being seen? Has a “brute force” attack allowed an attackers critical function to be actioned in the system? Has the system been subjected to a DOS attack? If the answer to any of these is yes then a move to SAv5 should be considered.
b. Faults in SAv2
These should already be implemented in WITS-DNP3 devices so there is no benefit here in moving to SAv5.
c. Additional functionality
WITS-DNP3 does not have multiple users and roles, so this part of the additional functionality is not relevant. Has a user experienced his update keys being compromised? Has the user experienced costs in having to visit sites to re-configure update keys? If so then maybe a move to SAv5 should be considered.