An Introduction to
CIP Security
The Next Big Step in EtherNet/IP
What is CIP Security
Threats to corporate facilities and networks are increasing as are actual attacks, but they’re rarely discussed. Almost no-one writes a press release after a successful attack on one of their corporate networks.
Over time, outside entities (foreign and domestic) with malicious intent have directed their energies to manufacturing systems. There are a couple of reasons for this. One, there is no longer much challenge, esteem or financial reward in attacks directed against personal computer systems. Two, these entities have learned that while corporate IT systems are well safeguarded, manufacturing networks are much less well protected. Sometimes, controllers are even publicly accessible from the Internet.
These people and groups have found that if they can penetrate a programmable controller’s I/O subnets, they can often easily access the data table or control code of the controller. Controllers are well-defended from external threats where they are linked to manufacturing, enterprise and cloud systems but almost unprotected from attacks originating on their I/O networks. This attack route is often more vulnerable with much less resistance.
ODVA designed the CIP Security® architecture to protect programmable controllers and devices on I/O networks from attacks originating on those networks. At first blush, attacks on the I/O network seem unlikely. I/O networks aren’t generally connected to the Internet, so what’s the concern? In practice, however, these kinds of attacks are not all that unlikely.
Many people have access to a manufacturing network. System integrators, product vendors, contractors and corporate employees come and go from a facility and connect to networks with laptops that may be compromised. Employees may fail to disable open ports on switches and unknowingly make connections that link to the Internet. Some employees knowingly engage in sabotage. There are a myriad of ways for attackers to get access to your I/O network. CIP Security is designed to increase the immunity to such attacks.
CIP Security is a software architecture designed to protect CIP Technology networks (EtherNet/IP™, DeviceNet®, CompoNet®, ControlNet®) in this sort of hostile environment. EtherNet/IP is the first implementation as Ethernet networks are the source of the clear majority of attacks.
CIP Security provides Message Integrity, Message Confidentiality, Message Authentication and Endpoint Authentication. Message Integrity ensures that the contents of the message received are identical to the contents of the message transmitted. Message Confidentiality ensures that no outside entities have access to data that is transmitted across a network. Message Authentication means that a message sender is authenticated as the device expected to send the message. And Endpoint Authentication means that an endpoint must prove that it is the device it says it claims to be prior to instantiating a connection.
How Does it Work?
Standard, Off-The-Shelf IT System Security
EtherNet/IP supports both acyclic and cyclic communications. Acyclic communications are used for moving information between Scanners (controller side devices) and Adapter devices (I/O type devices). Cyclic communications are used for moving I/O data between Scanners and Adapters. Acyclic messages send information or configuration parameters like a ramp-up time on an intermittent schedule while Cyclic communications are repeated continuously.
Because of the underlying differences between the EtherNet/IP transport layers, CIP Security uses two different security mechanisms. Both are off-the-shelf and standard IT software tools.
Acyclic communications (TCP transport) uses TLS (Transport Layer Security). TLS is a well-known Internet security standard designed to ensure message integrity, to authenticate endpoints and to keep the contents of messages private. You’re using TLS whenever you see that little lock and the “https:” at the beginning of a URL in your browser.
Cyclic communications (UDP transport) uses another standard IT communication mechanism, DTLS (Datagram Transport Layer Security). DTLS, a variant of TLS, is designed to overcome the problems associated with unacknowledged UDP communications.
Two Different Trust Models to Validate Device Connections
A trust model is an important consideration in manufacturing system security. The trust model is the collection of rules that govern how a device decides to trust another device.
CIP Security implementation supports two trust models: Pre-Shared Key (PSK) and X.509 Certificates.
- Pre-Shared Key is an uncomplicated system that works well in small systems. Private Key Sharing operates very simply. A private key is known and shared by all the devices in a network. Any device that knows the private key is authenticated and able to encrypt and decrypt messages.
- X.509 Certificates are a standard way for two devices to communicate securely over the Internet. Each device has a certificate identifying the entity issuing the certificate and some certificate authority that vouches for that issuer. A device can encrypt and decrypt messages using the public and private keys associated with the certificate.
CIP Security vendors are required to support both trust models. End users can decide which makes more sense for their facility and commission their device appropriately.
Three New Objects
All the Common Industrial Protocol™ (CIP) technologies – EtherNet/IP™, CompoNet™, ControlNet™ and DeviceNet™ – are object-based technologies. That means that users interact with CIP devices by interacting with the objects implemented in those devices.
There are three new objects implemented to support CIP Security: the CIP Security Object, the Certificate Management Object and the EtherNet/IP Security Object.
- The CIP Security Object is a high-level control object. It is the simplest of the CIP Security objects. It provides a flag that external entities can check to determine if a device is in the CIP Security configuration state. It maintains a trusted authorities list, and it identifies the CIP Security profiles that the device supports.
- The Certificate Management Object (CMO) is the CIP Security object that manages the X.509 certificates maintained by the device and creates Certificate Signing Requests (CSR). Signing requests are applications to a Certificate Authority for creation of an X.509 certificate. In some commissioning applications, a configuration tool will request the Certificate Management Object to create a signing request. The Certificate Management Object stores the request in the File object where it can be read by the configuration tool and used to obtain a certificate from a Certificate Authority local to the application.
- The EtherNet/IP Security Object is the CIP Security object that manages the parameters that govern how CIP Security operates on an EtherNet/IP device. It manages the parameters that control TLS and DTLS operation, the cipher security suites, the lists of trusted authorities and the mechanisms for obtaining X.509 certificates. It identifies the current active device certificate that the device is using for secure communications.
How Do Devices Get Commissioned?
Not all devices in an EtherNet/IP network need to support CIP Security, and not all devices need to be commissioned as a secure device. It is perfectly acceptable for a system to have a mixture of unsecured and secured devices.
There are several ways that users can commission secure devices. At the highest level, users must choose either Pre-shared keys or X.509 Certificates as their trust model.
Pre-Shared Key Trust Model – Commissioning a device for Pre-shared key requires that an originating device (Scanner) and a target device (Adapter) share the encryption key. It is simple and straightforward. Commissioning a device for pre-shared key requires a configuration tool to make a secure connection to a device and set the Pre-shared Key Attribute of the EtherNet/IP Security object to the key value.
X.509 Certificate Trust Model – Commissioning of devices in systems using X.509 certificates is more complicated but more secure. An X.509 certificate consists of identifying information, a public key available to everyone and a private key that is securely protected. Devices exchange certificates to validate their authenticity as they initiate a connection. Once connected, they use their keys to encrypt and decrypt I/O data and ensure that the sending device is the device that formed the initial connection.
Certificates can be pre-loaded by a vendor if their end-users accept the vendor as a Certificate Authority or it has a reputable certificate from a Certificate Authority. Vendors offering devices with Certificate Authority from a Honeywell, Rockwell or similar vendor would likely be automatically accepted by end-users.
If not, CIP Security provides two mechanisms for end users to load X.509 certificates in the field: the Push Model and the Pull Model. In the Push Model, a configuration tool makes a secure connection to a device and pushes a certificate into it. In the Pull Model, a device uses devices like DNSs (Device Name Servers), Enrollment Servers and Certificate Authority devices to obtain a certificate.
Is Rockwell Supporting It?
Rockwell Automation is already shipping controllers supporting CIP Security. It is expected that they will begin shipping EtherNet/IP Adapter devices equipped with CIP Security and a configuration tool that will automate the process of managing CIP Security devices in the near future.
It is likely that many manufacturers will be designing CIP Security into their next set of devices.
What Should I Do Next?
CIP Security is emerging in 2020 as a real game-changing technology within the Rockwell Automation ecosystem. Device vendors must identify how they will deploy this new technology, how they will configure EtherNet/IP Adapter devices, what ciphers they will use, what certificates they will accept and a lot more. Making these critical decisions is outside the expertise of many control engineers.
Vendors have an even more difficult challenge. Vendors building CIP Security devices must decide what kind of certificate they should provide, how they will protect their private keys and how they will address the challenges of encrypting and decrypting messages in devices never designed for that. They will certainly need to revise their EtherNet/IP software stack and possibly re-spin hardware.
