Automation is Key
Implementing automation for PKI integration in OT environments is key. It streamlines the process, reduces errors, and ensures consistency. Organizations can efficiently manage tasks such as certificate enrollment, key management, and renewal processes by leveraging automation solutions for the certificate lifecycle.
The implementation of automated certificate lifecycle management is categorized into three phases:
1. Planning, Design, and Integration
Assess the target environment and define and describe the business use cases. With business requirements, there is often a connection with regulatory requirements, and the expectation of business owners sets boundaries for implementations. Another important aspect is the expected assets, which need digital certificates. While a few hundred may offer some potential for manual management, the growth of connected devices in IIoT environments will quickly outstand this number. Manual management is not an option, as the business case for initial higher automation implementation effort gets calculated.
Devices and services affected by the implementation of PKI pretend automation possibilities by existing support for modern PKI-based lifecycle protocols. In the realm of operational technology (OT), there are various protocols with distinct levels of comprehensiveness. Some protocols may be very comprehensive but require higher effort for implementation. As a result, these protocols are not widely supported by many solutions. But in recent years, more lightweight protocols standardized often support more modern solutions, but on the other hand not legacy ones.
Transparency over the solution landscape gives organizations a good understanding of the expected effort for supporting automation for the certificate lifecycle in the existing environment.
2. Testing and Validation
When we address a high degree of automation for certificate lifecycle management, we test to ensure such processes carefully. When digital certificates call for mutual authentication in machine-to-machine scenarios, with no human interaction, lifecycle processes must be robust enough to handle different process issues. For example, the temporary unavailability of the enrollment endpoint of a lifecycle Certificate Authority or a validation service.
As much as the lifecycle processes are targeted for automation, the test processes must do the same. Whenever a condition changes in the lifecycle process, operators must be able to test the processes with low effort. Introducing mistakes into complex scenarios is not necessarily an exception, but the resulting consequences to the supported business process could be significant.
3. Maintenance and Monitoring
Operating PKI components can be very resource-demanding, and their outage would have a serious impact on the underlying business use cases. Certificate renewal would normally not be a problem when it is not immediately possible due to longer renewal periods considered in most use cases. In contrast, certificate validation services offer an extremely considerable risk of blocking certificate-based use cases, when not working properly.
Monitoring PKI services and optimizing their operations is important to ensure the value PKI brings to modern IIoT business use cases. Monitoring processes should be part of the automation strategy to test certificate-based use cases continuously end-to-end.
Certificate Lifecycle Management
Solid understanding and implementation of the comprehensive Certificate Lifecycle Management (CLM) is crucial for efficiently managing the growing number of devices and certificates. Manual efforts are no longer feasible due to the scale and complexity involved. Automation streamlines the CLM process, reducing manual errors, ensuring consistency, and improving overall efficiency. Here is a detailed step-by-step implementation process for achieving automation in CLM.
1. Inventory and Provisioning
Conduct a comprehensive inventory of existing certificates and associated devices. Make sure to design and implement solid identities for devices to ensure effective authentication solutions with the support of digital certificates. We recommend following the IEEE 802.1AR standard for secure identity design and implementation, which offers a particularly good framework and is already used by many solution providers.
The certificate inventory should be integrated with Asset Inventory solutions to allow other services to integrate with provisioned identity credentials. Where device management is managed with automated solutions for device deployment till its disposal, integration with certificate repositories makes sure the device state is reflected with the provisioned certificates.
2. Revocation and Key Management
No device is used forever in the same environment and under the same conditions. Certificates need to follow the lifecycle of devices and services and must be renewed if device conditions or information is changed or revoked if certificate information is outdated, or the device is taken out of business.
Revocation is a crucial process as revoking all certificates simultaneously poses a denial-of-service risk to the underlying business operations. Thus, many organizations leave revocation management out or manage it manually with labor resources. On a large scale, this is not a valid approach anymore. Credentials must be effectively revoked if either the identity is not valid anymore or if they become insecure. This should be implemented automatedly but surrounded with protection capabilities, like thresholds for revocations. Reaching a threshold could still require manual intervention to prevent denial of service attacks in a large-scale PKI.
The same applies to the renewal of key material for digital certificates. To ensure crypto hygiene, asymmetric keys should be exchanged from time to time, since the lifetime of digital certificates is usually limited. This should follow an automated approach and collect device capabilities and business process requirements automatically to orchestrate the right time and process for updating key materials for devices.
3. Compliance and Monitoring
To ensure the required level of security for the PKI setup and its processes, a series of compliance requirements documents are defined during design and implementation. The certificate policy defines the requirements to which implemented certificate lifecycle processes must adhere. This document is usually written once in one PKI, which does not have a too complex structure with diversified requirements. For more complex environments, multiple certificate policies might be defined, where each CP (Certificate Policy) covers specific requirements for the defined scope.
A Certificate Practice Statement (CPS) is the description of the certificate lifecycle processes, implemented following the requirements of a CP. That means that the CP is what needs to be fulfilled and the CPS defines how it is implemented.
Both documents usually rely on paperwork. As the paper is very compliant, automated testing of compliance for the implemented processes supports ensuring that the business processes fulfill security requirements, whereas PKI supports their fulfillment.
Integration with other supporting security monitoring, such as SIEM can help to implement immediate identification and reporting of compliance. Such solutions are usually in place and offer effective reporting capabilities paired with good security operation processes, which are available in many organizations.
Obsolescence Management
When organizations invest in OT solutions, this is often a long-term commitment, and foreseen use of the solutions is planned for a few decades. Given the implementation duration of complex OT environments and the fast evolution of IT, which plays an ever-increasing role in OT, many OT solutions are already almost outdated when their productive use starts.
Along with the overall IT evolution, cryptographic algorithms evolve and change. While RSA was exceptionally long the status quo in IT and OT for asymmetric cryptography, elliptic curve cryptography, and Edwards curves became more prominent in recent years. Even quantum cryptography is already actively discussed for future OT because many experts expect classic asymmetric algorithms to break once quantum computers can run attacks against them.
OT solutions can often not keep pace with this evolution. Especially with process control, which is often based on embedded systems, the ability to adopt new developments in the cryptography market is limited. The product cycles for such solutions are exceptionally long because their robust and resistant nature needs time for development and thorough testing.
Organizations need to plan during the implementation how they want to manage the obsolescence of such environments from an integration perspective with IIoT networks. We recommend using modular network segregation for OT conduits and connecting the conduits with IIoT gateways, which are capable of handling secure communication between conduits by ensuring the authenticity of the connection, encryption of traffic, and integrity validation of transmitted information. Such solutions are continuously developed and follow the security demands of modern IIoT environments.
These gateways usually rely on digital certificates for machine-to-machine communication. The certificates are used for mutual authentication and integrity protection of information, depending on the implementation. Thus, automated certificate lifecycle integration of such gateways is important because their number will significantly grow in an organization over the next years if IIoT is envisioned in the organization on a large scale.
OPC UA Support
Since its release in 2008, the OPC UA standard has been developing into the de facto standard for interoperability communication in OT environments. As an evolution from the Classic OPC, the OPC UA standard was developed with security by design in mind.
Many devices in OT already support some parts of the OPC UA standard and allow operators to integrate solutions from different vendors and even in a secure way, which was a serious challenge before. Digital certificates are leveraged by the standard to establish secure connections between communication partners on a network level. In addition to the network layer, there is also support for information security in the data model. Digital certificates can be used to encrypt but also ensure integrity of information in the protocol's data plane.
Part 12 of the OPC UA standard deals with the Global Discovery Service (GDS), which incorporates secure management of keys and certificates with standardized processes. With that extension, it is possible to integrate OPC UA-enabled devices and applications into organizations’ PKI and manage certificates’ lifecycle in an automated way.
Organizations should make sure that OPC UA and GDS support for the pull or push model for certificate management is available with the products they procure. This allows for vendor-independent integration of such solutions into the overall OT environment therefore simplifying and streamlining the way digital certificates are managed on connected solutions.
PKI Compartmentalization
Whether the PKI hierarchy for OT should be separated from the rest of the organization is a question of how the overall trust model is built. There are pros and cons to every approach.
Same Trust Hierarchy
If the same hierarchy is shared across the organization, the PKI service can be centralized more easily, and a core PKI organization takes care of the underlying services. This brings advantages regarding using resources and establishing the required skillset to build and run a PKI and all its exposed services securely.
The downside would be limited segregation of IT and OT, which can be important for some organizations. If the IT side causes a loss of the Root CA of the organization, OT is equally affected by resulting remediation and recovery activities. Also, this could mean some risk for OT, and the organization would need to ensure sufficient resources and skills are available in OT to run the PKI within OT with the required security and stability.
Separate OT Hierarcy
If organizations split the trust hierarchy completely between IT and OT, this can have positive effects on less dependency on OT from IT. The separated hierarchy can work fully autonomously within OT, and no dependence on the IT PKI services exists.
It requires sufficient skills and resources in OT to build and operate all the required services. Usually, this is a serious constraint in organizations. Another aspect that argues against splitting is the growing convergence of IT and OT through overarching IIoT use cases in enterprises. Where secure connectivity is required in broader scenarios, IT services are also involved. Having two separate trust models would also mean making the overlapping services aware of both trust hierarchies, reducing trust separation's benefit again.
BxC Takeaway
There are several ways of implementing PKI within OT; making sure legacy solutions are integrated and can be securely connected to IIoT use cases with the support of digital certificates. Automation is an important aspect of any PKI implementation or migration in the future to ensure large-scale OT devices and solutions can be handled with reasonable effort and sufficient security.
We at BxC combine expertise in OT security and PKI for the design, implementation, migration, and management of existing PKIs (Public Key Infrastructure) with a dedication to automation to enable the OT environments of tomorrow for secure IIoT use cases. No matter where in your PKI journey you are, we are there to support and help you get the most out of your investment, and make sure we find the best way for you to integrate secure certificate lifecycle management for your OT services.
Looking ahead, we envision the future of PKI integration in legacy environments. We actively explore emerging technologies, such as automated certificate discovery and management solutions, to enhance the security and scalability of PKI within legacy systems. By collaborating with industry partners and staying at the forefront of cybersecurity advancements, we at BxC ensure our clients have access to innovative solutions.
If you are interested in secure PKI implementation and management, reach out, and let us have a chat about your challenges and our contributions to the best solutions for you.
In a (click here for reading it) we highlighted the challenges companies face in brownfield OT environments when integrating public key infrastructure (PKI) functionality into legacy devices and services.