CIP Security is a new method of securely transmitting data at the protocol level rather than relying solely on additional hardware or applications to provide protection. It is in rapid development with the ODVA as an additional way to bolster your Defense in Depth. From a high-level there are 3 key ways it helps bring deeper security: by providing authentication of endpoint identity, preventing tampering of data in transit, and even encrypting all communications so if intercepted, it is useless to the interpret.
Let’s look at each of these in a little more detail.
What is meant by “Authentication”?
In Part 1 of this blog the example I used mentioned pinging an IP address where a device is expected, and that device is a ControlLogix processor. Let’s discuss ping for a moment.
When you ‘ping’ a device, you are instructing your PC to send an echo request packet to another device and wait for the response. When the target device replies, it sends that echo packet back, thereby acknowledging its presence on the network. It is for this reason that ping is often used as the first line of troubleshooting on any given network.
Notice though, there is no way of knowing what the target actually is. Since ping uses an IP address to identify anything on the network, and an IP address can be manually assigned, what is to stop another device from masquerading as that ControlLogix processor? If you are sending critical control data, it would make sense to ensure that the two devices passing instructions are who they say they are.
In short, your end devices need to have some form of identification to communicate – just as you need your username and password to log on to a computer, your Driver’s License to allow law enforcement to know who you are, or your fingerprint to access your smartphone. It is high time our automation equipment does something similar.
Using products that support CIP Security, identity is confirmed by each CIP Security enabled device generating a digital certificate. The participating devices exchange certificates in an encrypted TLS and DTLS session to send a one-time session key that establishes a trust relationship between them. Unless the communications originate and complete with that relationship in place, communication sessions cannot be established.
An unauthorized device (one without the appropriate digital certificate) that attempts to directly connect to a device is immediately rejected and a connection is never established. So, like someone at the airport without any identification, their access to boarding a plane would be denied.
“You can’t board a plane without identification, why should your control system communicate without identification?”
In the situation where a control instruction or message relaying a specific tag value has been tampered with, the variance in consequences can vary dramatically – whether it be an off-specification product or something far more dangerous, such as a “close” command on a valve changing to “open”.
Digital communications are fundamentally built of zeros and ones. Because of this ease of communication, it is also intrinsically easier to exploit. There are numerous occasions where simply changing a one to a zero or vice versa may cause inexplicable problems. It is the similar to an unshielded copper cable near electromagnetic interference may change high and low voltages on the wire yielding the same problem; though that situation is in error while this would potentially be done maliciously.
CIP Security uses hashes and keyed-Hash Message Authentication Codes (HMACs) to provide data integrity and message authenticity to prove that the data is consistent with intent and has not be tampered with or modified.
A hash is a mathematical function, like a checksum or cyclic redundancy check. The HMAC is attached to each message and is not possible to change without changing the hash from which it was derived, thereby preserving the integrity of the data.
What does that look like? Think of a pristine sheet of paper. If you were to crumple it up into a ball and then attempt to lay it out flat again, no amount of effort will make it look pristine again. You can’t get it back to its original form. It is the same here, with the keyed HMAC. If a change was somehow made to the original message, it would in turn change the hash computation so the final HMAC would be invalid. It will never be the same, just like the piece of pristine paper.
Additionally, two different messages with the same hash is not feasible, so the message cannot be copied.
Ultimately, this protects the data in transit from being modified, but the data could still theoretically be read. What could be done do avoid this?
Imagine a typical minimally protected automation network. In most cases, there is nothing stopping an individual from being able to plug in a laptop to an open switchport. In most scenarios we have seen the ports are not logically shut down, belong to the same VLAN, and have a very obvious addressing scheme. In the instance where that is not the case, an individual could simply use a known used IP address of an automation device (say a drive or HMI) and replace that device with the laptop, thus masquerading as an automation device and getting onto the network.
Couple easy accessibility with free utilities such as Wireshark, and you have an instance that allows any packets in transit to be read as they are. This means, anything in plain text including programming, password, recipes, etc. passing through an automation network could easily be captured and stored.
To counteract this possibility, CIP Security can allow encryption that is negotiated as part of TLS/DTLS authentication handshaking. This encodes every message so any data that is intercepted will be unreadable to a third party.
These are the same concepts used for typical banking and healthcare websites that are tasked with protecting sensitive and private information. A number of years ago there was a push to make websites dealing in sensitive information use https instead of http which has spread to nearly all websites. You might have seen the lock icon in the URL bar of your favorite web browser. This indicates the site is secured using an SSL certificate, which encrypts the data passed in that communications session so if it were ever intercepted, it would be pure gibberish without the key. Conceptually, this is why using a wireless encryption key to protect your WiFi network is a good idea and also why you should never use an open unsecured wireless network without a VPN. Again, encryption!
It is being used everywhere in our personal lives, is it time for encryption on the plant floor? We think so and CIP Security can make it happen.
With CIP Security offering additional layers of protection at the protocol level – meaning intrinsic to the language the devices are speaking – you can be sure that the transmission of data is being done by devices that should be, in a fashion that is consistent with what it should without being altered, and also prevents snooping or unauthorized disclosure of data.
Combined with the use of perimeter firewalls, layer 2 firewalls, auditing and versioning tools such as AssetCentre and Tripwire Industrial Visibility, and the built in FactoryTalk Security features of endpoints, CIP Security sets a new standard for improving your multilayered security posture.
CIP Security will start with support for Logix 5580 processors, FactoryTalk Linx, 1756-EN4TR EtherNet/IP Modules, PowerFlex 755T drives, and Kinetix 5700 drives and the portfolio will continue to expand. The suite will be controlled by FactoryTalk Policy Manager, which also has features to provide whitelisting for legacy non-CIP Security enabled devices for easier integration to existing systems.
Below are a few links and a short video explanation. We’ll also be updating with more articles as CIP Security continues to mature and more supported devices become available. Stay tuned!