Cyber Resilience

Axilon's differentiated cyber approach

Cyber resilience is part of Axilon’s DNA. Although the benefits and core use cases of Axilon extend beyond mitigating cyber risk, enhanced cyber resilience is one of the key advantages of the Axilon platform.

Background

Before cyber attacks became common, building resilient application infrastructure meant simply ensuring that systems are physically uncorrelated from each other, meaning that they are geographically isolated and run on different hardware. However, with the advent of cyber threats, resilience now requires software- and firmware-level isolation and hardening.

Enumerating Cyber Risks

There are a few distinct gaps from a cyber perspective with existing approaches to industrial infrastructure resilience. We can break these challenges down into two categories: a) risks to the integrity of configuration data and configuration management tools, and b) attack surface at the orchestration and availability layer.

Data integrity and configuration management risks

On the data integrity and configuration management side, the primary risks are as follows:

Data Store: If the attacker can get access to backed-up data to either delete or encrypt it, then the backup system itself becomes useless.

Configuration Management Engine: Even if the data itself is immutable, if an attacker can corrupt the channels by which that data enters and exits the store, then that attacker can freely modify it at those endpoints. It’s not much use to have immutable storage if the data coming in or out is compromised. (In other words, garbage in, garbage out.)

Application Orchestration and Availability Risks

When it comes to the application orchestration and availability layer, there are major concerns as well:

Secondary systems: Within a traditional High Availability setup, each secondary machine can become a vehicle for threats, due to the common architectural practice of constant intercommunication (i.e. state duplication) between primary and secondary systems. This intercommunication is commonly referred to as a “heartbeat,” and the cyber risk is that threats buried within the primary can propagate to the secondary trivially.

Orchestrator: The host or orchestrator of the secondary system(s) is itself a potential vehicle for corruption. In other words, an attacker that is able to compromise the secondary system orchestrator can directly push viral payloads into those machines, even after the original threats have been identified, quarantined, and treated. This is a more intricate attack, but can be significantly more damaging and difficult to prevent.

The Axilon Cyber Approach

All of the aforementioned risks must be considered by any competent resilience system for the software layer of an IT or OT process, as failures to defend any one of them can lead to compromise of the entire system.

At Axilon, we take advantage of recent advances in the world of hardware-enabled security to ensure cyber isolation and resilience.

In particular, Axilon leverages the unique security properties provided by Trusted Execution Environments (TEEs)—specifically, AMD Secure Encrypted Virtualization (SEV)—as well as our proprietary software architecture to significantly reduce the aforementioned attack surfaces.

Brief Primer on Trusted Execution Environments (TEEs)

TEEs, also known as Secure Enclaves, are specialized compute regions on chips designed to guarantee the integrity of code running within those regions, even against an untrusted host or physical access to the chip. In other words, if a TEE is programmed with a specific set of software, that software is provably all that is able to run on that TEE (unless the entire region of the chip is restarted).

Additionally, TEEs allow for the linkage of cryptographic material to the specific code running on the chip. This means that a user can link keys or identity to the chip verifiably running an application’s specific code and nothing else.

Addressing Cyber Risks

The Axilon platform uses these integrity and attestation properties, as well as additional mechanisms for attack surface limitation, to defend against each of the discrete risks described above.

Mitigating Data integrity and Configuration Management Risks

In terms of data and configuration management, Axilon relies on the hardware-enabled security of TEEs to maintain integrity.

Data store: The data store in the Axilon platform is only accessible to read or write via the TEE. No direct access is possible, whether from the attacker or user. This accessibility constraint is guaranteed by the attestation properties of the TEE: the only access to the data store is gated by keys locked behind the cryptographic linkage described above. Thus, the only way to reach the data store is by running the exact fixed code of the integrity enclave, meaning that no malicious code can access it, to read or write.

Configuration Management Engine: The Configuration Management Engine in the Axilon platform runs as a highly slimmed-down codebase—specifically for snapshot processing, analysis, saving, and retrieval—within a TEE. Physical access or compromise is prevented by the aforementioned TEE properties of host isolation. Logical access is also prevented: even if an attacker gained access to the physical hardware running the Configuration Management Engine, any attempt to corrupt the process would immediately stop the corrupt process from touching the datastore. This property is enforced by the integrity constraints of the TEE and demonstrated to the client via communication signatures with keys gated behind that integrity.

Mitigating Application Orchestration and Availability Risks

For the orchestration and availability layer, Axilon combines a novel partitioning architecture with the integrity properties of TEEs to ensure tamper-proof reliability.

Secondary systems: The attack surface of lateral movement from primary to secondary via the traditional “heartbeat” mechanism is significantly reduced due to Axilon’s novel partitioning of Virtual Machine (VM) state into customer specific state (e.g. individual device locations and network topology) and customer generic state (e.g. which applications should be installed on those VMs and what libraries should be installed on those applications). Traditional High Availability systems copy both of these from primary to secondary, which opens up large attack surfaces for cyber threats. In contrast, Axilon only pulls in customer-specific state from actual customer systems, while the customer-generic state is provided by pre-existing purpose-built VM images living on the orchestrator (for more on this, see Custom VM Images). This partitioning limits the attack surface for individual VMs to two threat scenarios: attack the host/orchestrator and attempt to escalate from customer configuration to full control. The first threat scenario is discussed next, and the latter would require a full zero-day in the application itself, which is impossible for Axilon to prevent and is the responsibility of the application vendor.

Orchestrator: Like the Configuration Management Engine, the Axilon Orchestrator has its core functions (VM image verification, credential generation) running within a TEE. As above, physical compromise is prevented by TEE properties, as is logical access, meaning that even if an attacker gained access to the physical hardware running the Axilon Orchestrator, any attempt to corrupt the process would immediately stop the corrupt process from modifying old VMs or creating new valid ones.