Navigating IT OT convergence - Irdeto Insights

A question frequently confronted at Irdeto concerns the seemingly inevitable convergence of IT (Informational Technologies) and OT (Operational Technologies) systems. Clearly, such convergence makes a lot of sense as we are all well into the process of moving toward always-connected products and data-driven insights and value streams.

But is it possible to create synergies and reuse the same security solutions across both domains? Will there ever come a time when an organization can manage the security of their fielded products in the same way (and possibly with the same team and procedures) used today to manage their own IT systems?

Traditional IT security solutions are unfit…

The short answer is no; security solutions traditionally used in the IT sector are too anchored into a certain computing model and are tailored to risk profiles which are fundamentally different than those applicable to the OT domains and to embedded products.

Take security solutions based on cryptography signatures for instance (e.g. PKI certificates). Even though the underlying cryptography is often the same (e.g. RSA or ECC), embedded products are hardly designed to consume corporate X.509 PKI certificates; for instance, they are too resource constrained, and the validation logic can’t fit into memory as easily as it does in a Window PC.

Additionally, the security of embedded products is often anchored into the hardware root-of-trust offered by the underlying microprocessor or SoC (System-on-Chip), which varies from vendor to vendor and even across architectures from the same vendor. As a result, for instance, a control such as Code Signing looks radically different than what IT professionals intend with that term (e.g. Windows Authenticode) and concepts such as code encryption are almost unheard of to them (with the notable exception of iOS apps).

…but there is still hope with the most modern IT practices

However, the most innovative aspects of IT are clearly making inroads into embedded product development. Cultural shifts such as DevOps have already radically transformed business and consumer software development practices, bringing massive competitive advantage to adopters. DevOps is also quickly finding application in the field of embedded software.

The concept of a fully automated pipeline that incrementally takes new firmware features and automatically builds, validates, and possibly deploys across a series of (often virtual) targets is reality at many innovative product companies, as they can gather feedback and iterate much quicker. And although one cannot automate safety and security certifications, a battery of automated tests can cover a lot of ground to make at least the pre-certification activities much faster.

Within the DevOps movement, one can also notice the emergence of DevSecOps practices as a means to integrate and heavily automate security assurance into the firmware development process, for instance to streamline static source code analysis and security reviews.

The threat of software supply chain attacks

DevSecOps techniques enable an organization to efficiently implement measures against the rising threat of software supply chain attacks, that is, attacks that target systems where software is developed and built or where it is stored for distribution. While the most prominent and famous example so far concerns IT infrastructure applications (SolarWinds hack), software supply chain attacks are certainly also applicable to firmware and embedded software meant for critical systems.

The automotive domain is particularly vulnerable because the risk increases with the complexity of the supply chain. A vehicle is composed of a vast number of parts and components often sourced from different vendors. The software supply chain is deep and distributed; attacks can target the seams of the process and the trust boundaries between the several organizations involved.

As articulated in the excellent paper “Deliver Uncompromised: Securing the Critical Software Supply Chains” by MITRE, a solid foundation is built upon three initiatives:

1. A software bill of material (SBOM) whereby metadata attests which components, provenance, version, and patch levels make up the software in each product, at any given time. SBOMs propagate through suppliers and inform risk-based decisions when continuously matched with information taken from vulnerability databases throughout the product’s lifetime.
   
   
2. High-Assurance Code Signing to enable all parties in the supply chain up to the final product itself to verify integrity of all software modules they receive, to promptly detect code injection and tampering. One could argue that Code Signing is already a fairly common practice for embedded development – so aren’t we covered already? As mentioned above, the advantages offered by automation in the firmware development cycle imply that traditional code signing (which was hopefully performed with offline key ceremonies) have to be enhanced to increase protection for cryptographic secrets, while enabling the definition and enforcement of code signing policies, e.g. based on quorums and approvals. Also, Code Signing needs to enable crypto agility in the face of potential cryptographic breakthroughs anticipated with future progresses in Quantum Computing (QC).
   
   
3. Hardening of the build environment: the two measures above (SBOM and Code Signing) are ineffective if the underlying build infrastructure is compromised. To prove this point, one should remember that the library affected by the most famous supply chain attack to date (the SolarWinds hack) was actually correctly signed. Simply put, attackers were able to inject the adversarial payload in the pipeline before the signing step and/or impersonate a privileged user. It is therefore important to perform a risk analysis on the entire development pipeline (including suppliers) and follow best practices that allow one to quickly detect and limit the blast radius of an internal compromise. And despite the benefits of a fully automated pipeline, the risk analyses we have performed always indicate that a few assets (or crown jewels) for critical systems and products are still best protected in an air-gapped, isolated network.

Conclusion

Organizations developing systems and products for the critical infrastructure (including for the automotive domain) can greatly benefit from the adoption of modern software development practices such as DevOps to increase quality and shorten the time-to-market. However, traditional IT security solutions are not the best fit for embedded products as they are designed for a significantly different computing and risk model. Yet, organizations might consider leapfrogging such solutions and directly embracing DevSecOps practices to anticipate the emerging threat of (embedded) software supply chain attacks.

If you have any questions, please get in touch with Irdeto’s Connected Transport team.

Stay tuned for our next blog and follow us here to stay up to date. You can also read more here about Irdeto Connected Transport.