How to Architect for Cyber Recovery

Cyber recovery architecture is about preserving enough certainty and control to keep your organization capable of responding and recovering when the broader environment can no longer be trusted.

Command Under Uncertainty

Every military commander knows that no battle unfolds exactly as planned, in part because the enemy gets a vote.

Given that uncertainty, the military protects its ability to command with extraordinary care because losing it could jeopardize everything that follows.

That means command authority, command centers, communications networks, and the systems that support them are engineered to withstand the most sophisticated attacks imaginable.

Similarly, cyber recovery strategy requires identifying which enterprise capabilities must remain trustworthy and available during active compromise, then architecturally compartmentalizing and hardening them accordingly.

Anchors of Certainty

We examined the foundational systems and dependencies required for disaster recovery earlier in The Systems That Make Recovery Possible.

But cyber recovery presents a harder architectural problem because recovery unfolds under conditions shaped in part by an active adversary whose actions cannot be fully anticipated.

So architecting for cyber recovery requires treating a small set of systems and capabilities differently from the broader enterprise because they establish the trust and control on which recovery depends.

Crucial Systems

Three categories of systems are particularly important to establishing that foundation:

1. Identity Systems establish trusted authority by determining who and what can authenticate, assume privilege, and exercise administrative control.
2. Management Systems provide administrative control over the infrastructure and systems being rebuilt and reactivated.
3. Backup Systems retain trusted recovery points for systems and state.

If these systems are compromised, you must first re-establish those functions before you can reliably contain the attack, rebuild systems, and restore the business.

Supporting Capabilities

The trustworthiness of these crucial systems also depends on supporting capabilities that establish authenticity, integrity, context, and known-good state. And each can be deliberately subverted to make a compromised environment appear trustworthy.

• Cryptographic services establish authenticity through certificate authorities, key management, code signing, and hardware-protected keys.
• Configuration baselines, trusted software images with proven chains of custody, and infrastructure definitions provide known starting points for reconstruction. 
• Audit logs and immutable operational records preserve evidence needed to validate what has changed and when it changed.
• Asset inventories and configuration management databases (CMDBs) provide an authoritative record of the systems, dependencies, and configurations expected to exist.
• Name resolution services provide the authoritative naming that allows systems and their dependencies to locate one another and operate correctly once restored.
• Time synchronization services establish a trustworthy temporal reference for sequencing events, preserving log integrity, and validating time-dependent activity across systems.

Even system design and operational documentation can become targets because they preserve the knowledge required to recover and rebuild.

Together, these supporting capabilities provide the evidence, reference points, and operational context needed to determine what can still be trusted and how recovery can proceed.

Prioritizing How Much Protection Is Enough

These sources of trust and control warrant greater protection than other systems that could be compromised without directly undermining the organization’s ability to recover.

A tiering model provides a practical way to determine how much protection different systems and capabilities require.

Tier 1 – Trust

Systems and capabilities that establish trust, authority, authenticity, or trusted recovery state.

Examples include enterprise identity providers, directory and federation services, privileged-access systems, backup control planes and recovery repositories, PKI and key-management services, trusted configuration and software repositories, immutable audit records, and authoritative inventories.

Tier 2 – Critical Infrastructure

Infrastructure and security capabilities that preserve control, containment, and maneuverability during an active cyberattack.

Examples include network and security control infrastructure, virtualization and cloud management planes, endpoint and security-management platforms, critical storage, recovery networking, clean-room infrastructure, and alternate communications systems.

Tier 3 – Core Infrastructure

Shared infrastructure and platforms required for normal operations that can be replaced, re-provisioned, or re-established during recovery.

Examples include general-purpose compute, standard virtualization, shared storage, database platforms, container platforms, middleware, and common application platforms.

Tier 4 – Business Systems

Workloads for which protection is governed primarily by business criticality rather than by their role in establishing trust or preserving recovery options.

Examples include revenue-generating systems, internal systems, reporting and analytics platforms, productivity services, and other operational workloads.

Restoration prioritization for these workloads should be based on business criticality and dependency.

Applying the Tiers

The first two tiers require more deliberate architectural treatment.

Tier 1 systems should be architected to preserve trust throughout a destructive cyberattack, while Tier 2 infrastructure should be architected to preserve the options needed to contain the attack and maneuver through recovery.

Tier 3 infrastructure can typically be rebuilt, while Tier 4 workloads should be architected for restoration according to business priorities.

This classification should follow architectural function rather than product category. For example, a nonobvious management or security platform that has privileged control across the enterprise may still warrant Tier 1 treatment if its compromise would undermine the trust required for recovery.

Architecting for Survivability

Once those systems, capabilities, and infrastructure have been identified and prioritized, the next step is to determine how they should be architected so that they will remain usable and trustworthy during compromise and recovery.

Trust Boundary

A trust boundary is an architectural separation within which the trustworthiness of selected environments and systems can be independently verified and maintained.

That boundary can be established through identity, administrative, network, infrastructure, repository, or physical separation, reinforced by controls such as hardware-backed credentials and offline copies.

Tier 1 systems should preserve trust through verifiable boundaries that can survive compromise of the broader enterprise. Their authority, recovery state, configurations, and other trusted artifacts must be independently verifiable even when the systems around them cannot be trusted.

Tier 2 infrastructure should preserve options by keeping alternate control, network, and hosting paths available during a cyberattack. Network, virtualization, and cloud infrastructure should be structured so compromise of one path does not eliminate the ability to isolate systems, redirect traffic, or rebuild elsewhere.

A trust boundary is architecturally sufficient only when compromise outside it cannot invalidate trust within it.

Control Boundary

A control boundary defines who can exercise administrative authority over a system, from where, and through which paths.

Architecturally, this means separate privileged identities, separate administrative domains, dedicated administrative endpoints, restricted management networks, and constrained interfaces.

Tier 1 systems should preserve trust by keeping administrative authority separate from ordinary enterprise control paths. That requires dedicated privileged identities, endpoints, and management channels.

Tier 2 infrastructure should preserve options through protected administrative paths that remain usable during a cyberattack. Those paths should allow infrastructure to be isolated, redirected, or re-established when primary administrative paths are compromised.

A control boundary is architecturally sufficient only when broader administrative compromise cannot confer control over the systems required for recovery.

Isolation Boundary

An isolation boundary limits the architectural paths through which compromise can propagate into systems and infrastructure needed for recovery.

Isolation can be implemented across identity, network, management, infrastructure, and physical domains.

Tier 1 systems should preserve trust by isolating them from the identities, networks, management planes, platforms, and physical access paths through which compromise could spread from the broader enterprise. That may require dedicated administrative domains, segmented networks, isolated hosting, or physically separated components.

Tier 2 infrastructure should preserve options by preventing compromise of one infrastructure domain from eliminating viable paths to containment and recovery. That may require separate management planes, alternate network paths, or infrastructure administered independently from the compromised domain so it can still be used to isolate, redirect, or rebuild.

Isolation must also address dependencies.

A system cannot be truly isolated if it still depends on identity, network, platform, storage, DNS, time, or administrative services outside the boundary. Any dependency that creates a path across the boundary should be separated, duplicated, or otherwise addressed.

An isolation boundary is architecturally sufficient only when cross-boundary dependencies cannot carry compromise into the systems and infrastructure required for recovery.

Integrity Mechanism

An integrity mechanism provides an independent basis for determining whether systems, configurations, data, and recovery artifacts remain trustworthy.

Integrity can be established through cryptographic verification, immutable records, trusted baselines, signed software, protected configuration sources, and authoritative inventories.

Tier 1 systems should preserve trust by being independently verifiable. Their identities, configurations, recovery state, and other critical attributes should be supported by evidence that establishes they remain authoritative, trustworthy, and known-good.

Tier 2 infrastructure should preserve options by remaining independently verifiable before it is used for containment and recovery. Management planes, network controls, virtualization platforms, and alternate hosting environments should be validated as known-good before they are relied upon to isolate, redirect, or rebuild.

Integrity must also extend across time and provenance.

Audit logs need trustworthy timestamps, software and infrastructure artifacts need known chains of custody, and backup recovery points need evidence that they predate or exclude the attacker’s modifications.

The same evidence may also be required for forensic investigation, regulatory review, insurance claims, and law-enforcement activity, so recovery actions must not inadvertently destroy the records needed to establish what happened.

An integrity mechanism is architecturally sufficient only when trustworthy state can be distinguished from state that is merely available.

Availability Requirement

An availability requirement defines the minimum capability that must remain usable while portions of the enterprise are being contained, isolated, or rebuilt.

Availability can be preserved through redundancy, geographic separation, alternate infrastructure, independent communications, reserved capacity, and other means that sustain essential function under the degraded conditions of a cyberattack.

Tier 1 systems should preserve trust by remaining available at the level required to sustain authoritative control, validation, and trusted recovery state. Identity, management, backup, cryptographic, DNS, and time services should retain enough capability to continue those functions even when their normal operating environment is unavailable or compromised.

Tier 2 infrastructure should preserve options through redundant control paths, alternate network routes, independent management access, and infrastructure capacity that can be brought online outside the compromised domain. Those alternatives should remain sufficient to isolate systems, redirect traffic, establish replacement environments, and continue rebuilding during the cyberattack.

An availability requirement is architecturally sufficient only when enough capability remains usable to continue recovery.

Recovery Path

A recovery path defines how a foundational system or capability can be re-established if it is compromised, corrupted, or lost.

A credible recovery path can draw on protected recovery points, known-good configurations, alternate infrastructure, independent credentials, protected documentation, and other trusted sources outside the failed environment.

Tier 1 systems should preserve trust through recovery paths that re-establish authority, known-good state, and trusted recovery capability without relying on the compromised instance. That may require independent identity recovery, protected credentials, recoverable backup catalogs, preserved key material, and authoritative configuration sources.

Identity recovery is particularly unforgiving because restoring compromised identity state can also restore the attacker’s persistence. Recovery therefore has to establish which identity state can be trusted rather than simply return the directory to an earlier point in time.

Tier 2 infrastructure should preserve options through alternate recovery paths that restore control and maneuverability when the primary infrastructure is lost. That may require alternate network paths, management planes, independently provisioned infrastructure, or another hosting environment.

Recovery paths must also account for dependency order.

Foundational systems and supporting capabilities may themselves be prerequisites for restoring other systems, so their recovery sequence should be understood in advance and reflected in the architecture.

A recovery path is architecturally sufficient only when the system or capability can be re-established independently of the compromised environment.

Recovery Infrastructure

How you will recover from a destructive cyberattack is just theoretical unless you know that you have a trustworthy place to recover.

Disaster recovery generally assumes the recovery environment will be available when needed. But a destructive cyberattack removes that assumption because the infrastructure intended for recovery may itself be compromised, inaccessible, or otherwise untrustworthy.

Systems may therefore need to be restored, rebuilt, or re-established somewhere else. And that destination must provide an isolated, trustworthy environment where recovered components can be validated before returning to service.

Some recovery infrastructure can be provisioned when needed. But some systems require infrastructure that already exists.

Either way, the destination should be determined, secured, and validated before the cyberattack.

Additionally, SaaS and other provider-managed platforms present a different architectural problem because the underlying infrastructure is not under your control. So that part of recovery may instead depend on re-establishing trusted tenant configuration, identities, application credentials, integrations, and data within the provider’s environment.

Provisioned Recovery Infrastructure

For systems that can be recreated on demand, recovery infrastructure does not need to exist permanently. It can be provisioned when needed in an isolated environment designed for restoration, validation, and rebuild.

Cloud infrastructure makes this approach practical at enterprise scale. Compute, storage, networking, identity, and management services can be assembled into a clean-room environment without maintaining duplicate production capacity.

That environment may serve as a staging area or may have to become the new production environment. In either case, restored components should enter as untrusted and be validated before joining the recovered environment.

But this approach still requires the recovery foundation to exist in advance.

Infrastructure definitions, trusted software images, configuration baselines, credentials, deployment tooling, and the cloud accounts, networking, quotas, and security controls needed to use them should be established in advance and protected from compromise.

Preserved Recovery Infrastructure

Some systems cannot be recreated on demand or run on alternate infrastructure and therefore require recovery infrastructure that already exists.

Mainframes, specialized appliances, industrial platforms, and tightly coupled legacy systems may be bound to specific hardware, software, licensing, networking, security controls, or operational processes that cannot simply be reproduced elsewhere.

The British Library encountered this problem directly.

Some older systems could not be restored onto modern infrastructure because they depended on technology that would no longer operate under the hardware and security controls of the rebuilt environment.

For these systems, recovery may depend on physically or logically separated infrastructure, contracted recovery facilities, geographically distinct platforms, or other dedicated environments maintained for that purpose.

Unfortunately, the architectural requirement is straightforward: if a system that must be recovered cannot be rebuilt on alternate infrastructure, the infrastructure needed to recover it must itself be preserved, protected, or replicated.

Restoring Business State

Restoring individual systems does not necessarily restore a coherent business state.

Different systems may be recovered to different points in time, leaving transactions, balances, orders, inventory, and other shared state out of synchronization. Recovery therefore needs to account for how authoritative business records will be reconciled across systems before normal processing resumes.

The problem becomes more difficult as recovery spans SaaS platforms, databases, event streams, external partners, and systems with different recovery points.

But putting the business back together ultimately requires restoring a coherent state across the processes those systems collectively support.

Exercising Recovery

All of these recovery paths should also be architected with the assumption that they will ultimately be exercised under adversarial conditions, including compromised identities, unavailable infrastructure, untrusted recovery sources, and normal administrative paths that can no longer be relied upon.

Built to Take Back What’s Yours

Earlier in my career, I spent a great deal of time helping companies develop disaster recovery strategies and engineer their infrastructure and systems to survive failures of facilities, power, communications, and, of course, the apex predator of network infrastructure: the backhoe.

But it was always a difficult investment to justify, even in the largest, well-funded enterprises, simply because they had to spend money today to prepare for a failure that might never happen, instead of addressing whatever was happening right now.

A lot has changed since then.

Destructive cyberattacks, particularly ransomware, are now boardroom-level risks and priorities. And the threat is fundamentally different because the event may be shaped by an adversary who has already spent time inside your environment preparing it to fail on their terms.

Cybersecurity policies, controls, and layered defenses remain essential, but they can fail. And when they do, when your systems and data are no longer yours, cyber recovery quickly becomes an architectural problem that, if it has not already been addressed, everyone will wish had been.