Security Must Be Top Priority in Bringing Critical Infrastructure Online

What you’ll learn:

• Why safety and security should take priority over getting the system online quickly.
• How does software architecture that offers an isolation environment prevent threats from accessing the sensitive data?
• Why the choice of hypervisor technology is important.

It feels that the rate of press coverage of cyberattacks on critical infrastructure is on the rise. In February, we learned that a Florida water treatment plant had been breached; in May, news broke of the attacks on the Colonial Pipeline and the Irish Public Healthcare service. These events prompt a fundamental question: Should these systems have been connected in the first place?

To be sure, external network connections bring benefits to the business. But they also make those systems vulnerable to attack, as the inclusion of an external connection enables hackers to more easily access these systems and cause mischief.

Do the benefits of connectivity outweigh the associated risks? In some of the recent hacks, the external connectivity was provided to simply offer remote monitoring and control of a function. Is that flexibility better than requiring a human to come to the building? This may seem like a somewhat Luddite statement from someone in the technology sector. But one of the phrases I’ve repeated over the last 10 years has been “just because it is connected does not make it a good idea!”

Once the decision is made to connect crucial infrastructure systems to outside networks, safety and security should take priority over quickly getting the system online. The system architecture for the connected, deployed platform must be carefully constructed to:

• Continually raise the immunity of the system to attack through supported updates to the system.
• Recognize when it has been compromised and be able to return the system to a known-good state.
• Partition the system such that any incursion can be contained in a way where the system’s functionality, safety and security, and key assets can’t be accessed or modified.

IT vs. OT

One insightful article noted that one of the challenges is the very different perspectives of Information Technology (IT) and Operational Technology (OT). To quote, “IT wants to keep data confidential; OT wants to keep everything running above all else, or keep everyone alive and safe.”

One of my favorite series of books (the movie was awful) was The Hitchhiker’s Guide to the Galaxy. In that, a babel fish was inserted in someone’s ear. This enabled any spoken language to be translated into the first language that the person understood. In these connected systems, there’s a similar need to bridge from the old to the new, translating the commands and frameworks used in the IT world into the safe, highly reliable, and highly available world of OT.

When discussing this in other forums, I’ve been challenged on several statements. One of the strongest pushbacks stated, “No software may be run safely on unsecure hardware.” I think we would all agree that we would like more secure hardware components.

The great news is that a number of efforts are underway to improve the system-level security of connected systems, one example being Arm’s Platform Security Architecture (PSA) initiative. It’s true that if such a system, running poorly written software, is compromised, the crown jewels of the system will not be accessible. That said, we should step back and consider:

• The timeline from silicon (not IP) availability.
• The design cycles of embedded systems.
• The timeline when PSA was rolled out.
• The length of time that embedded platforms are deployed for before they’re traded out.

How many of the 100 billion chips that Arm’s partners shipped in the last five years were PSA-compliant? The reality is that a significant number of platforms out there are based on legacy architectures (I reference Arm here, but similar challenges exist for x86-, MIPS-, and RISC-V-based components).

What’s needed is a software architecture that offers an isolation environment that prevents threats from accessing the sensitive data even when the endpoint has been compromised. Secure systems should be conceived as distributed ones—where security is achieved partly through the physical separation of their individual components and partly through the mediation of trusted functions performed within some of those components.

Creating Separation

Effectively, secure virtual enclaves, established using virtualization, need to be created in which operating systems, applications, and security functions can execute. Simply put, the control of how a machine’s resources are allocated and secured is separated from the operating system. This turns the endpoint from a point of vulnerability to a point of protection.

Just as an operating system enforces protected memory contexts between its processes, a separation kernel hypervisor enforces memory protection contexts between the different virtual machines (VMs). While processes within each VM may interact with each other, it’s impossible for them to interact with other VMs without explicit authorization.

The choice of hypervisor technology is important. Some of the embedded options are still founded on an underlying operating system, which means if they fail, then the whole system can crash. We’ve also seen variants that allow root log-ins. The minimally configured hypervisors that effectively assign resources to the various VMs immutably (i.e., can’t be changed after the system has booted) and then get out of the way, is really the path forward.

The rate of cyberattacks will likely become more frequent in the near term. Designing critical infrastructure systems with security a first and foremost priority will be key toward ensuring our key networks remain as impenetrable as humanly possible.