Or: “A Few Simple Suggestions for Improving Core Control System Security”

The core precepts of IT security are confidentiality, integrity and authentication, precepts not present in the design of most control systems, but there are some simple changes whose implementation would serve to greatly improve the security of control systems. Changes which could be readily and easily added to the majority of in the field systems.

Currently, in the majority of control systems, if an attacker can penetrate into the control system network segment, the lack of the core security principle allows the attacker to “own the system”. These failures are most notably:

*The use of poor authentication schemas e.g. no passwords, default passwords, and cleartext password exchanges. Authentications is critical in any system as it ensures that a user is who they “appear” to be and authentication limits the privileges that a user had to modify data and interact with system processes. This inherent weakness in control systems allows attackers a variety of attack pathways including; firmware attacks, and simple vectors into “rooting” control system services on both field devices and pc based servers and workstations.

*No use of data integrity schemas. The lack of integrity controls allows attackers to manipulate the data communicated on the system through man in the middle, IP spoofing and various other attacks.

*No encryption. Though confidentiality of the control system communication may not be of the upmost importance, the encryption of password and key exchanges would serve to greatly improve the security postures of control systems.

The main impetus of this posting is to suggest some simple modifications to control system designs that will correct these faults. Changes that could be readily implemented on existing control systems and that would not excessively tax the resources of field devices nor introduce excessive latency into time critical communications. Many of these suggestions are based on the specifications for the IPsec data authentication (Authentication Header) standard.

Though there has been a lot of discussion of encrypting all communications on control systems, there are various trip-falls to implementing this. Namely the field devices lack the computational horsepower to perform full packet encryption and decryption. This then requires the use of a bump in the line encryption device, which could be very costly and difficult to deploy on all devices “in the field” of large installation.

Data confidentiality on control systems via strong encryption is also not an essential necessity. Full packet encryption makes debugging communications virtually impossible, and outside of authentication exchanges what if any of the data exchanged needs the protection of encryption? Note that “outside of authentication exchanges” is key.

The IPsec  Authentication Header standard describes a robust schema for providing data authenticity, integrity and confidentiality. By following the basis described by IPsec’s Authentication Header we can develop a similar security headers for control system protocols. This header would contain:

*Encrypted authentication key, token or password. This is equivalent to the Security Parameters Index (SPI) of the IPsec standard.

*Encrypted packet sequence number.

*Integrity Check Value. Like the IPsec ICV this is a hash of the packets data including the majority of the headers. This hash is recomputed by the receiver and if the calculated has does not match the sent hash then the packet has been tampered with.

Each of these fields is a 32 bit value adding 96 bits to the end of a packet.

The addition of this security header to packets in control system protocol ensures Authentication and Integrity. If the packet is faked, replayed, or modified by an unauthorized user (attacker) the lack of the proper authentication key will ensure that the packet is rejected. The hash of the packet will also compute incorrectly doubly assuring that the packet will not be processed and assuring the integrity of the data in the packet. Man in the middle attacks with the specific goal of packet tampering are now moot.

Returning to the topic of authentication. A recent SCADASEC list discussion indicates that the use of no or default passwords is rampant in control systems, a finding already widely known by everyone who has spent any time in these environments. This practice must change. Vendors must provide systems that require new passwords be chosen during the installation/configuration phase of system deployment. These passwords must be changed to passwords that meet some minimum password policy determined by the asset owner. 

As asset owners and system maintainers have voiced some concern over operators having sufficient time to type in passwords during critical situations, the use of some type of stored token/key on a fob or USB stick may also be permissible. This would allow for the system to quickly query the key, while still providing for strong authentication.

Strong authentication also allows for better accountability, auditing and forensics as each login and transaction can now be correlated to a specific user.

Passwords exchanged across the network, wherever in the packet they occur must be encrypted. If the above IPsec style authentication and integrity schema is employed then each packet can be signed by its originator’s/user’s password/key.

As this schema only employs 96 bits of encrypted/hashed data it is a feasible implementation for security on many existing control systems and field devices. This schema removes the ease by which attackers can now infiltrate control systems by using no passwords, default passwords and sniffing passwords off of the network and also provides data integrity by which the tampering and replaying of data can be detected and avoided. This schema also increases the ability to perform real auditing and forensics on control systems.