Fortress Backup and Recovery can support all types of backup data, ranging from file/folder level backups to drive and image level snapshots of client systems. Additionally, Fortress has built out several SCADA- and DCS-specific tools for structured historian and configuration data backup and recovery. For Failover, Fortress has built out custom, slimmed-down VMs for the process control (i.e. DCS), SCADA, and other critical software (e.g. EMS) offerings of most major industrial Original Equipment Manufacturers (OEMs).  If there’s a vendor that you work with and would like to know if we currently support it, please reach out.

Fortress can handle data at all levels of granularity, ranging from individual file and folder level backups to full system drives or VM images. Additionally, Fortress has built out SCADA-specific database backup and restoration tools. All of these backup types can be managed through the same intuitive single-pane-of-glass frontend interface.

Fortress is an agent-based system and is easy to set up and maintain, since the system handles all Trusted Execution Environment (TEE) orchestration and requires no additional infrastructure management. The setup process for Fortress Backup and Recovery takes about two hours for the first machine, and mere minutes for every additional machine. The setup process for Fortress Failover takes approximately two hours to set up the necessary network infrastructure and minutes for each software application.

Hardware-enabled security, as defined by NIST, is “security with its basis in the hardware platform”, as distinct from software or firmware-enabled security, which have their bases in the code running on that hardware.   This distinction is relevant for two reasons.  

First, unlike hardware, software and firmware are modifiable, either by a malicious actor or by the manager of the platform on which the software is running.  Because of this, no software-enabled security platform can fully protect against insider threats or supply chain concerns – there’s no way to guarantee that the software providing the security is actually what’s running on the system.  Hardware-enabled security is the only way to guarantee that the code the client wants to be running on a third party machine actually is.

Additionally, software and firmware enabled security platforms take a blacklisting approach to securing their systems.  Specifically, any undesired access needs to be explicitly forbidden, and any access or usage that isn’t forbidden is assumed to be permitted.  This means that any mistakes made in configuration or unforeseen attack vectors lead directly to threats on the system’s security.  In contrast, hardware-enabled security takes a whitelisting approach, where any desired activity or access needs to be explicitly allowed on the system.  This way, mistakes made in configuration and new attack vectors can at worst lead to difficulties accessing the system, rather than threats to the integrity or confidentiality of the data contained within it.

There are three core types of Hardware-enabled security devices: TPMs, HSMs, and TEEs.  Fortress uses TEEs, the newest and most generic Hardware-enabled security device family, for it’s backup, recovery, and failover capabilities.

Trusted Execution Environments (TEEs), also known as Secure Enclaves, are physically-isolated computing environments for securely executing code on an untrusted host machine. To be more specific, a TEE is a specialized region of certain classes of CPUs that contains its own subdivided processors, memory, and microkernel. This region of these CPUs is designed to verify on startup that it is running a specific piece of code, and present signed proof of that verification.

TEEs were developed by public- and private-sector researchers over the past decade and have recently been made available for commercial use. The leading TEE platforms are AMD Secure Encrypted Virtualization (SEV), Intel Software Guard Extensions (SGX), and Arm TrustZone. TEEs are notoriously complex to directly work with, since they require remote evidence attestation (the ability to check the verification proofs of the TEE) and key management operations (the generation and provisioning of keys based on those verification proofs), but the Fortress platform leverages the security properties of TEEs for all backup, recovery, and failover operations while fully abstracting away the complexities of management and orchestration.

Fortress offers failover capabilities for mission-critical software applications to run in offsite Trusted Execution Environments (TEEs) while a primary system recovery is underway (since a full recovery could take hours or days). First, Fortress differs from traditional failover systems by running the applications in these secure computing environments with code integrity and end-to-end data confidentiality. Second and perhaps more important, Fortress only runs slimmed-down Virtual Machines (VMs) with these pre-configured applications, to avoid “lifting and shifting” entire compromised Operating Systems (OSs) to the failover environment. By comparison, traditional “digital twin” failover systems may provide value in the case of a physical disaster but, in the case of a cyber attack (such as ransomware or wiperware), will be vulnerable to the same threat that can compromise the primary system(s).

Alternative data backup and recovery solutions are either a) on-premise, manage-your-own-hardware offerings that do not provide adequate logical isolation in the case of cyber attacks, or b) cloud-based offerings that introduce additional attack surface and third-party risk.

Fortress is an offsite platform that provides hardware-enabled security with no additional third-party risk because all backup and recovery operations are localized within Trusted Execution Environments (TEEs), which are fully controlled by the client. Additionally, unlike other data backup and recovery platforms, Fortress provides TEE-based failover capabilities for mission critical software in order to facilitate operational continuity in the immediate aftermath of a cyber attack or physical disaster.

The purpose of combining Failover with Backup and Recovery is to ensure maximal flexibility and robustness of system recovery, without compromising on recovery times. Client industrial environments may be bandwidth constrained, which would slow down a data recovery, as would recovering large amounts of data. Failover ensures maximal flexibility and continuity so that industrial operations don’t have to be put on hold for the hours or days (or longer) that it could take to recover primary systems.

The Fortress platform’s Trusted Execution Environments (TEEs) manage the encryption and decryption keys for long-term storage of snapshots. These keys are locked to only be accessible to TEEs running the correct backup, recovery, and failover software, ensuring that only the client has access to their data. Additionally, Fortress has built out a multiparty “break glass in case of emergency” key system that allows clients to retrieve and read backups even if they lose access to their TEE credentials. This system stores fragments of read-only keys with the client and with client-chosen trusted parties, that can be reassembled to decrypt snapshots when the client requests it.

Fortress has built an automated recovery testing solution to regularly test the recoverability and integrity of backups. This solution pulls down all new backups on a client-scheduled basis and confirms both that the backups successfully restore and that they contain the expected file contents. Any issues with the recovery testing or more generally with backup, failover, and recovery processes are logged and reported to the client.

No. While the Fortress platform is designed to live off-premise, the client’s sensitive OT devices, servers, and workstations never need to directly connect to off-premise systems. Instead, Fortress has built out proxy servers (”jump hosts”) as agents that can live on a client’s preexisting head-end servers. Those proxy systems live on the client’s network and communicate via TLS-encrypted tunnels to the static IP addresses corresponding to Fortress infrastructure. The client’s actual OT devices communicate only with those proxies, never with the wider world.