7.10 Recovery Strategies

Key Takeaways

CISSP 7.10 focuses on implementing recovery strategies.

The current CISSP outline explicitly covers backup storage strategies, recovery site strategies, multiple processing sites, system resilience, high availability, Quality of Service and fault tolerance.

Recovery strategy should begin with business requirements.

A Business Impact Analysis helps identify critical processes and the recovery requirements needed to support them.

RTO describes how quickly service should be recovered.

RPO describes the point in time to which data should be recovered.

MTD represents how long disruption can continue before significant business harm occurs.

RTO = time to restore. RPO = data to restore. MTD = maximum tolerable disruption.

Recovery capability must be capable of satisfying the business recovery objectives.

Faster recovery generally requires more ready capacity and therefore greater investment.

Recovery architecture should therefore be proportionate to business impact.

Backup strategies can use onsite, offsite and cloud storage.

Onsite backups can provide convenient and rapid access but may share physical risk with production.

Offsite copies provide greater separation from site-level disasters.

Cloud backup can provide scalable remote storage, but connectivity, identity, provider resilience, encryption and restoration throughput still matter.

Full backups copy all selected data.

Incremental backups copy changes since the previous backup.

Differential backups copy changes since the last full backup.

Full = everything. Incremental = since previous backup. Differential = since last full.

Incremental strategies can reduce backup time and storage requirements but often create a longer restore chain.

Backup design should therefore consider restoration requirements rather than optimising only backup speed.

Snapshots can provide valuable point-in-time recovery.

However, a snapshot is not automatically an independent backup if it remains within the same storage or administrative failure domain.

Replication and backup are also different.

Replication maintains another relatively current copy and can support availability.

Historical backups allow recovery to an earlier state.

Replication = current copy. Backup = recoverable history.

Replication can faithfully reproduce ransomware encryption, corruption or malicious deletion.

Historical recovery points are therefore still required even in highly replicated environments.

Ransomware recovery may require backups that attackers cannot easily modify or delete.

Immutable or offline recovery copies, separate administrative credentials and strong access controls can strengthen recovery resilience.

Backups themselves contain sensitive information.

Their confidentiality, integrity and availability must therefore be protected.

Encryption can protect backup confidentiality, but recovery planning must also protect and preserve the keys required to decrypt that information.

Encrypted backup + unavailable key = unavailable recovery.

The most important measure of a backup is whether the organisation can successfully restore from it.

Backup success ≠ restore success.

Recovery site strategies commonly include cold, warm and hot sites.

Cold sites provide basic facility capability and require substantial technology installation before operation.

Warm sites provide some technology and telecommunications capability.

Hot sites are much more prepared for rapid technology recovery.

Generally:

colder = cheaper but slower. hotter = more expensive but faster.

A hot site does not automatically guarantee zero downtime.

Routing, application activation, data synchronisation and validation may still be required.

A hot site also does not automatically guarantee zero data loss.

Data recovery depends on the backup and replication architecture.

Recovery capacity can also be obtained through contractual arrangements with providers or through reciprocal arrangements between organisations.

Such arrangements should define and validate capacity, compatibility, activation time and responsibilities.

Different physical sites should reduce exposure to common-mode failures.

Two facilities may still share electricity, telecommunications, flood zones or administrative systems.

Different location ≠ different failure domain.

Multiple processing sites can use active-passive or active-active architectures.

Active-passive designs keep one environment operating while another waits to take over.

Active-active designs distribute live production workload across multiple locations.

Recovery capacity must be considered.

If two active sites normally each process half of the workload, each site may need enough remaining capacity to support the required service when the other fails.

Cloud availability zones and regions can support multi-site recovery architectures.

They do not eliminate common dependencies such as identity, DNS, configuration, privileged access or application defects.

Data replication can be synchronous or asynchronous.

Synchronous replication keeps participating copies very closely aligned but introduces coordination and latency considerations.

Asynchronous replication allows the secondary copy to lag the primary.

This can support greater geographic separation but may permit loss of recent transactions during sudden failover.

Distributed recovery designs should also guard against split-brain conditions where multiple systems incorrectly believe they are authoritative at the same time.

System resilience is broader than recovery.

Resilient systems aim to withstand disruption, continue important functions where possible, adapt to degraded conditions and recover effectively.

High availability uses redundancy and failover to minimise service interruption.

Fault tolerance aims to allow correct operation to continue despite component failure within the system's designed tolerance.

HA = minimise interruption. Fault tolerance = continue despite fault.

High Availability and Disaster Recovery are not the same.

A highly available cluster inside one building may survive server failure but still disappear when the entire building fails.

Load balancing and clustering can support availability by distributing workloads and enabling failover.

Their effectiveness depends on avoiding shared single points of failure.

RAID and similar disk-resilience technologies can protect against some storage-device failures.

RAID ≠ backup.

Disk redundancy does not preserve historical state against ransomware, deletion or application corruption.

Quality of Service can prioritise important network traffic when resources are constrained.

QoS may help critical applications continue operating during degraded network conditions.

QoS does not create an alternate network connection.

QoS = prioritise available capacity. Redundancy = provide alternative capacity.

Graceful degradation is another resilience approach.

During disruption, less important functionality can be reduced so essential services remain available.

Recovery architectures should identify single points of failure across power, compute, network, storage, sites, suppliers and people.

Recovery planning must also understand application dependencies.

An application can be operational while remaining unusable because DNS, identity, networking, databases or encryption-key services are still unavailable.

Application recovered ≠ business service recovered.

Recovery order must therefore reflect dependencies.

The service with the highest business priority may rely on lower-level infrastructure that must technically recover first.

Cyber recovery requires additional attention to data integrity.

The newest backup may not be the safest backup if an attacker had already established persistence.

Most recent recovery point ≠ known-good recovery point.

Recovery environments should retain appropriate security controls.

Logging, identity controls, segmentation, encryption and monitoring should not be casually discarded simply because restoration is urgent.

Suppliers and cloud providers can become critical recovery dependencies.

Their real recovery capabilities should align with the organisation's own recovery requirements.

A business RTO of two hours cannot be reliably achieved through a critical supplier whose recovery capability takes 24 hours unless another strategy exists.

Recovery capability must be maintained as the production environment changes.

An alternate site that has not been updated after years of application and architecture changes may no longer provide meaningful recovery.

Recovery strategies should therefore be regularly tested.

Testing should validate backups, failover, data integrity, capacity, dependencies, security and actual recovery time.

Designed recovery ≠ demonstrated recovery.

CISSP 7.10 and 7.11 are closely connected but should not be confused.

7.10 focuses on the strategies and capabilities that make recovery possible.

7.11 focuses on performing the Disaster Recovery processes when those capabilities are needed.

7.10 = How will recovery be possible? 7.11 = How do we execute the recovery?

The central CISSP principle is:

determine business recovery requirements first, then implement sufficiently independent backup, alternate-processing, redundancy and resilience capabilities to meet those requirements - and test them before the organisation has to depend on them.