From the top-down, device owners and operators want to manage their devices for remote maintenance and continuous health monitoring. From the bottom-up, device manufacturers want to harden their devices with security by design for identification, authentication and tamper resistance with supply chain provenance. At the epicenter, device life cycle management is the objective, and device intelligence is the enabler for transformative data science (DS), artificial intelligence (AI) and machine learning (ML). Intelligent decisions require device intelligence to build trustworthy training models. Operational efficiencies are required to reduce costs associated with devices from manufacture to in-field provisioning, operations and lifetime updates.

What are the challenges in OT?

The major challenges product security stakeholders face today are:

1. The information technology (IT) versus operational technology (OT) divide that requires fostering cross-functional skill sets.
2. The cost of PKI buildout from traditional enterprise IT systems to OT devices.
3. The recurring cost of certificates to protect millions of devices over their estimated service lifetime (from five to 30+ years).
4. Deriving value from certificates that may require application reengineering to effectively use certificates for device authentication, data signing and encryption.
5. Protecting the private keys locally on the device (with zero passwords).
6. Automation required to manage the service lifecycle of keys and short/long-lived certificates on heterogeneous devices.
7. Compliance with export and import controls on cryptography.

The difference between IT and OT

There are fundamental differences between IT and OT that warrant a paradigm shift.

Why things in IT and OT worlds are different

We need to change the way we manage things because the things we need to manage have changed.

Contrasting IT status quo with OT digital transformation

The imminent risks of preserving status quo in the context of IT versus OT assets are daunting to security and safety stakeholders, from product security architects to the corporate board of directors.

Why OT is not IT

1. What is the product in OT?
   • Not software, not security
   • It is special-purpose equipment (industrial robots, controllers, sensors, actuators, cameras, medical, scientific, etc.) that the OEMs/ODMs sell.
2. How do OT stakeholders perceive themselves as?
   • As a revenue center, not as a cost center
3. What is the lifetime of OT equipment compared to IT equipment?
   • Three–five years for IT, 15–30 years for OT
4. What is the patch management cycle in OT compared to IT?
   • Monthly in IT, 12–18 months in OT
5. How is the application of software updates different in OT compared to IT?
   • Fully controlled by the OEMs and field operators
   • Must not cause service outage in production environments
   • Backwards compatibility of APIs required for device to service connectivity (devices are updated in batches based on a schedule)
   • Interoperability between multi-vendor devices must be preserved during updates
6. How is support different in OT compared to IT?
   • IT: Performing NOC/SOC functions, patch management, administering corporate applications, servicing enterprise systems (servers, user workstations, network elements)
   • OT: API usage by polyglot applications in customer’s finished products, interoperability between third-party field devices, queries related to compliance and porting to other device family (within or across BUs)
7. How is setup and operations different in OT compared to IT?
   • The setup (installation, configuration) of services on-premises versus in a service provider cloud/hosted platform requires collaboration with customer’s IT
   • The operational workflow and requirements differ by industry sector
   • The setup of endpoints entails heterogeneous device types with a plurality of OEMs in the production ecosystem
8. How are field updates different in OT compared to IT?
   • IT: Updates are staged on representative enterprise endpoints before production rollout
   • OT: Updates must be staged by device owners/operators for supported device types in a non-production environment before rollout, and entail production downtime
9. How is securing devices in OT different from users in IT?
   • Users can use multi-factor authentication with interactive response (e.g., phone factor, password, PIN, etc.)
   • Devices are headless. Factory default passwords are a curse. Device unique passwords must be generated and stored locally encrypted using a black key generated by a physically unclonable function (PUF) on a root of trust (secure element)
10. How is interoperability between OT and IT assets different?
    • IT systems connect using secure transport over IP (TCP/UDP) protocols
    • In OT, brownfield and greenfield devices face interoperability challenges as legacy line of business applications are often not designed to handle encrypted broadcast and multicast traffic
11. How is development of OT and IT applications different?
    • IT applications use Java full stack, C++, REST APIs, scripting languages, and extensive application-level logs (e.g., syslog)
    • OT applications on devices use C, assembly, hardware acceleration for real time requirements, and there are limited to no logs on the device (due to storage, network and compute constraints)

Common objections to modernization in the OT world

1. No compelling reason (compliance mandates) to use cryptographic keys and certificates on resource-constrained, low-latency, air-gapped environment.
2. OEMs SSH using a password to remotely connect (over VPN) to the device for field maintenance. OEMs and device owners/operators reside in split public/private PKI domains.
3. Device hardening is perceived as OEM’s responsibility. OEMs use code signing and apply over-the-air (OTA) updates with good enough security (over Wi-Fi – Enterprise WPA2 with RADIUS authentication).
4. Lifecycle management of keys and certificates on field devices is a cumbersome transition and may require a truck roll with a field engineer.
5. Firewall management, traditionally delegated to IT NOC/SOC operators, requires fostering skillsets of OT operators.
6. Budgetary cost of PKI buildout (cheaper to use TLS-PSK/SRP ciphers for authentication).
7. Network based MDR/EDR solutions are good enough short-term interim retrofits for device discovery and vulnerability assessment.
8. The global market is fragmented by export/import restrictions on cryptographic functions associated with keys and certificates.

Customer pain points in OT

1. Identifiers for device identification
   1. Must be immutable and authoritative before onboarding
   2. IT-OT dichotomy
      • IT: DHCP (MAC Address), DNS (FQDN)
      • OT: Initial ID (Manufacturer issued), Local ID (Owner/Operator issued)
2. Metadata for device health monitoring
   1. Network-based detection limited by encrypted communications
   2. Endpoint-based detection requires collaboration with OEMs
3. Trust chain for device updates
   1. Field device updates are controlled by OEMs
   2. Maintenance performed by OEMs over VPN (remote access) or OTA (insecure)
   3. No supply chain tamper resistance or tracking

The must-haves for OT customer buy-in

1. Solution provides more value (the bar is higher in OT space).
2. Clear roadmap of capabilities to drive digital transformation across heterogenous devices (brownfield, greenfield) in OT space.
3. Deployment is non-disruptive to ensure field devices operate without any service outage.
4. Seamless integration with ecosystem elements in production environments (i.e., works out of the box).
5. Reduces costs (operational and manufacturing).
6. Reliable support services (24/7 for global market).

Conclusion

Industries are looking for a horizontal solution across heterogeneous IT/OT devices, and not yet another security product in their arsenal for NOC/SOC operators to manage and perform post-breach forensic analysis. Protecting devices in Internet of Things (IoT) and Industrial IoT (IIoT) ecosystems requires standards-based interoperability across heterogeneous brownfield and greenfield devices to design and implement a sustainable zero trust architecture. The secured use of protected keys, certificates and trusted end-to-end workflows provide the ability to design and implement zero trust models, and to authenticate, connect and operate devices securely.