There has been so little cryptography in OT / Purdue Levels 0 – 2 that managing the keys for cryptography has not been much of an issue. And the lift to get encryption and authentication into OT is so heavy that even those of us who know the importance of key management tend to push it aside with a little hand waving. It might be time to get serious about key management in OT and show some simple solutions so the complex solutions don’t overwhelm the community.
First, the state of play today:
- The popular ICS protocols and systems are beginning to deploy encryption for confidentiality and implicit source and content authentication by wrapping their communication with TLS (the same security protocol used in https).
- There is a school of thought that only authentication is needed and encryption actually causes more harm than good because it defeats network monitoring, or at least makes it a lot harder. This school is currently losing in terms of specifications and available solutions.
- Almost all of the protocols and systems available to date allow self-signed certificates. Most of the protocols and systems have a default of creating a self-signed certificate and accepting self-signed certificates.
Cryptography, key management, and certificates are complex topics, and yet the concepts are quite simple. If you and I want to communicate securely, we need to create and exchange keys. In the simplest, and increasingly default in ICS, method of self-signed certificates, the device or application creates keys, creates a certificate, and signs the certificate with the keys it created.
When a self-signed certificate arrives at the destination the level of proof is similar to: Hi, I’m Dale Peterson. Trust me I’m really Dale Peterson because I say so. I could have just as easily said: Hi, I’m Steve McQueen. Trust me I’m really Steve McQueen because I say so. It’s easy to see the security fail in this approach, which again is often the default in ICS because few want to introduce any key management complexity into ICS.
Some of the available systems have manual trust solutions that can be effective for small and static systems. In these systems the self-signed certificate is placed in a “needs approval before use” status. Approval is an offline process where some level of identity verification occurs, and then an administrator marks it as an approved self-signed certificate in the receiving device or application. This verification can be a phone call, email exchange or other means that are of course subject to social engineering or hacking.
A public key infrastructure (PKI) is necessary for anything but the small and static systems, and this is where the conversation and requirements often get overwhelming. PKI introduces trusted third parties who can help validate a certificate really belongs to the device, application or person that claims it. The PKI trust model can be quite complex and hierarchical, but it doesn’t have to be. Let’s start with a simple example that is very applicable to ICS and early use of secure ICS protocols.
One Trusted Third Party / Certificate Signer
If you are a single plant that wants to have encrypted and authenticated communication between your OT cyber assets, this simple PKI is likely the answer.
- The group responsible for securing the plant creates, and protects, a Certificate Authority (CA). These are typically available from the ICS vendor or Microsoft or others. It is not difficult to create. (Note: It can be more of a challenge to protect and maintain if it is rarely used after deployment.)
- Each device and application loads the CA’s certificate prior to deployment.
- Each device, application or individual creates a certificate, or the CA creates it for them, and then the CA “signs” the certificate after verifying the device, application or individual is what it claims to be. This certificate signed by the CA is loaded into the device or application.
That’s it.
This does add steps to deployment. It does add steps to maintenance. If a technician needs to replace a PLC, they need to either have the certificates signed and loaded prior to placing it on the depot shelf. Or they need to be able to accept the delay it will take for the CA administrator to go through the signature process.
When the device or application is deployed, it will be able to say, for instance: I’m PLC123. Here is the security information you need for us to communicate securely, and here is proof that Plant CA has verified my identity and security information. The entity PLC123 is communicating with, let’s say EWS456, provides its signed certificate with its identity and security information verified by the Plant CA. Now they both know the other side is considered authentic, and they now have the keys needed and ability to communicate securely.
Everything in the above two paragraphs requires no user action, in the same way that no user action is required to use https rather than http to browse the web (except typing the s or clicking on links with https). All of the work is in the initial provisioning of the CA and getting a signed certificate in the devices and applications.
Your PKI enthusiasts will say: hold on. It’s not that simple. What about certificate revocation? What about expired certificates?
They are not wrong. If a device with a signed certificate is stolen or compromised, then the other devices and applications in the network should no longer trust that device’s certificates. In PKI this is addressed with a Certificate Revocation List (CRL) that devices should periodically query. And there are other valid issues that will arise if you dig into PKI.
This should not delay, even if unavailable or unsupported, the move from self-signed certificates to this simple, single site PKI. Efficient risk reduction and risk management, not perfection or PKI purity, is the objective. Accepting unverified self-signed certificates eliminates most of the value of using encryption and authentication. Not having a CRL does open the system up to some types of attacks and can make maintenance harder, but it does prevent a huge number of attacks if that adversary has a beachhead in OT.
PKI can, and likely will, become more complicated in OT in the future. An asset owner with many sites may have a two-tier PKI, with a CA for the asset owner that signs CA certs for each plant that then sign the device, application and user certificates at the plant. Multi-site applications and users may require certificates signed by multiple CA’s or a different branch in the trust model. As supporting vendors are allowed access the PKI complexity will grow as there are multiple ways to do this and determining which is best will require some expertise.
At this point though the best approach is to keep it simple so we can get over the self-signed, unverified certificate de facto situation in most secure ICS protocol deployments. It will serve the community poorly if attackers break through the poorly implemented secure ICS protocols, or the more likely case that assessments and penetration tests show this effort to deploy secure ICS protocols has only provided illusory security. Now that secure ICS protocols exist, and hopefully will be deployed, we can no longer afford to hand wave key management away.