Trust is never absolute. It is a measure of trustworthiness, a dynamic metric. Kevin Plank, founder of Under Armor sportswear company, said, “Trust is built in drops and lost in buckets.” Every network intrusion, data breach or ransomware attack will change that metric. “Trust but verify” was also the paradigm during the Cold War.

What is zero trust?

The notion of zero trust has been around for decades. Trust is established at the door when you log in to your computer or to a web portal. Trust can be one way when you access a secure site from a web browser over HTTPS with server certificate validation, or two way with mutual authentication where the client must present its certificate to the server. A user’s passwords can be compromised, and therefore two-factor authentication of the user became a necessity using the “what you know” plus “what you have” doctrine.

So where does the notion of zero trust begin? This brings us to the difference between implicit and explicit trust, and transfer of trust (or transitive trust). Trust is a chain. Trust transfers from a root of trust at the local peer, establishing a vertical chain of trust, and bridges across a horizontal chain of trust to the remote peer. Trust begins with trusted identities and must persist throughout the lifecycle of connected things.

Trusted device identities

The emerging world of devices (things on the internet) poses new challenges. A headless device is a non-real-life entity where “what you know” does not apply. The second factor for a device is a local root of trust with an immutable identity that is verifiable with proof of possession of a secret protected within the local secure element on the device. The womb-to-tomb phases in the lifecycle of devices are onboarding, provisioning, operations and offboarding.

Onboarding devices

Adding a device into a network fabric implies trusting the device before it is plugged into the wiring closet. That is implicit trust. Explicit trust requires establishing a chain of trust from a local root of trust, generating a local cryptographic key with high entropy, protecting the key in a secure keystore, and issuing the birth and operational certificates from a public or private certificate authority. The birth certificate must be linked to a manufacturer-issued initial identity, and the operational certificates must be linked to a local identity issued by the device owner. This establishes multi-factor authentication for a headless device.

Provisioning devices

Next comes the enablement of device functions from initial configuration, to installing the line of business applications, and security controls for device management system (DMS), network operations center (NOC), security operations center (SOC) operators to activate and manage the device.

Device operations

Nothing happens on the internet unless things communicate. That is where connected things can get wild. Fortunately, cryptographic ciphers come to the rescue. Unfortunately, cryptography requires secure storage of private keys and secure exchange of temporal session keys. With unlawful intercept of network traffic and use of post quantum computing, new challenges have emerged. Fortunately, secure elements (e.g., trusted platform modules), quantum-safe ciphers and enhanced transport layer security protocols (e.g., TLSv1.3) have emerged to counter such threats. The transfer of trust between connected peers requires establishing two-way trust with mutual authentication. Data protection requires data exchange between trusted peers based on the notion of explicit trust.

With sophisticated tools and methods in their arsenal, cyber criminals are always two steps ahead of the defenders. Therefore, rekeying session keys, rotating private keys and renewing certificates is a prudent risk countermeasure. You cannot control threats, but you can manage your risks. Once a device is shipped out of the factory, it will require updates throughout its service lifetime, from the firmware to the operating system, applications and configuration. Protecting field devices requires establishing a tamper-resistant chain of trust in the update package from the suppliers (providers) to the distributors (publishers). The transitive chain of trust includes secure development operations (DevSecOps) at the supplier, secure code signing for supply chain provenance of the software bill of materials (SBOM) in the update package, tamper resistant chain of custody through update package providers and publishers, and finally protection controls on the device that verify the trustworthiness of the received update package before applying the update. This establishes bidirectional track and trace.

Device offboarding

All good things must retire someday. The risks posed by abuse of cryptographic artifacts necessitates a wipe of keys and certificates on the device as a decommissioning ceremony. That is what zero trust is all about. It is the fusion of explicit trust with transitive trust that persists throughout the lifetime of device operations. Trust is established at the door, but zero trust is measured beyond the door.

Conclusion

While this may appear to be a cumbersome solution to implement, it is a shared responsibility between device vendors, device operators and device owners. It will take a village to digitally transform cyberspace and enable convergence of information technology (IT) with operational technology (OT) in the years ahead. New technologies are opening doors to unprecedented operational efficiencies and cost reductions for all industry sectors.