When installers build automation systems getting it working is their main focus. They see building automation security as an obstacle to overcome rather than the goal. If authentication is getting in the way, they disable it. When firewalls are blocking communication, they disable that too. Even more problematic is the fact that several popular automation protocols do not even support authentication or auditing of any kind.

What Is Security?

Security is more than just access control or encryption. In Understanding Cryptography (a great book for anyone interested in the subject) these services of security are defined, which I am paraphrasing:

• Secrecy – nobody can listen in
• Integrity – ensures that attackers have not tampered with messages
• Authentication – ensures the sender is who they say they are
• Undeniable – the author of a message cannot deny that they sent it

All of these are valuable for an automation system, to varying degrees.

Building Automation Security Services

Secrecy is not always important, depending on what you are doing. You probably won’t mind if a motivated attacker knew your room temperatures, but in an industrial setting you might care about keeping your process secret. You may consider electrical metering information private as well as that leaks information about your business.

Integrity is important for an automation protocol when commands have critical effects that could harm your business if mishandled. If an attacker is able to modify your commands that could give them a subtle way of harming your business. Some encryption methods do not protect against this; a malicious person could modify even an encrypted message with unknown content so long as they know something about that content.

Authentication is an important security requirement for an automation protocol that I think everyone can understand. You should need some kind of username and password or other means of authentication to affect the field. Sadly, few protocols support this and those that do have very meager support.Your front end may have a login, but the protocol that ultimately commands the system may not.

In the case of a common “operator” password valid across an entire network, commands are deniable. To prevent this, we can use digital signatures where the user must enter their personal password to sign a message, validating that it was in fact them and not someone who knew some common code. This is valuable in auditing; if a problem occurs as a result of a command, we want to know who did it.

Protocol Security Support (in practice)

Advances are slow to come as security generally not a priority except in applications where the automation is considered a critical system. Manufacturers often do not support more advanced security when its available.

OPC (legacy, non-UA)

OPC is a DCOM-based protocol and as such inherits support for authentication. In fact this support is on by default and is a frequent problem when integrating these systems. Typically the client authenticates with Windows credentials that must be valid on the server. Access rights are broken up as: local access, remote access, launch and activation. As far as I know, you can’t selectively provide access to only some tags; if the user is authenticated by the system they can do anything to it.

• Secrecy – No.
• Integrity – No.
• Authentication – Yes.
• Undeniable – Depends?

OPC UA has much improved building automation security, though it is still quite new. It’s looking like it will be the most security-conscious protocol on the market.

Modbus

Modbus is an extremely basic protocol and does not support authentication of any kind. If you are on the network, you can read or write anything you like. Some memory addresses are read only, but they are read only for everyone.

• Secrecy – No.
• Integrity – No.
• Authentication – No.
• Undeniable – No.

BACnet

BACnet is a relatively advanced protocol.makes its lack of even authentication puzzling. All modern front-ends have segmented user access permission levels, and yet this modern protocol allows the network to be a free-for-all. If you’re on the network you can override points at priority levels above the front end. Read or write access is handled by the end device and is not on a per-user basis.

• Secrecy – No.
• Integrity – No.
• Authentication – No.
• Undeniable – No.

LONworks

LON does support authentication for the sender of messages though I have yet to see it in practice. The sender of LON requests has a 48 bit authentication key. When a device sees an authenticated request from the sender it sends back a 64 bit random number as a challenge to the sender. The sender uses their key to modify this random number and sends it back, providing some manner of authentication.

This at least protects against arbitrary clients commanding field devices as would be the case with Modbus or BACnet.

• Secrecy – No.
• Integrity – No.
• Authentication – Yes.
• Undeniable – No, the key is shared.

Conclusion

Building automation security is still in its infancy. Protocols are not built with security in mind, though the new OPC UA protocol looks promising. When you need to secure an automation system, look to defense in depth rather than relying on protocol security. Protect access to your network, lock up your controllers, and segregate your network.