Skip to content

CONCEPT Cited by 1 source

Rebuild-Restore-Rotate framework

Definition

Rebuild-Restore-Rotate is the cyber-event recovery decomposition framework that sorts every recovery target into one of three categories with a one-line per-category heuristic:

Infrastructure is code. Data is backup. Credentials are new. (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

Each category answers the question "where does this thing come from when we rebuild?" with a different source of truth and a different trust assumption.

The three categories (canonical AWS reference)

Category Examples Why
Rebuild from code IAM policies and roles, Security Groups, Amazon EC2, Amazon VPC, AWS Lambda, CI/CD pipeline definitions Configurations come from reviewed, version-controlled templates rather than from a backup that may have been affected
Restore from backup Amazon RDS, Amazon Aurora, Amazon EFS, Amazon EBS, Amazon FSx Business data cannot be recreated from code and must come from validated, immutable backups
Rotate or re-issue IAM access keys, database passwords, API keys, certificates, OAuth tokens, SSH keys Any secret that may have been exposed during the event window is replaced, not carried forward from backup

Why the three-way split is structurally correct

Each category corresponds to a different trust assumption about the source:

  • Rebuild from code. IaC templates in a separate version- controlled repository have independent audit trails (commit history, code review, branch protections). They're more trustworthy than running configuration that may have been modified by an attacker after deployment. The framework moves "configuration as source of truth" from production runtime to the IaC repository.
  • Restore from backup. Business data is irreplaceable — there is no source-of-truth substitute for customer orders, transaction history, document content. The pipeline that gates this is the multi-layer validation pipeline, which is the cyber-resilience equivalent of the IaC-as-source-of-truth posture: prove this data is clean before trusting it.
  • Rotate or re-issue. Credentials that may have been exposed during the event window cannot be carried forward — even from a backup, because the backup might encode the exposed value. The rotate leg replaces every secret comprehensively.

Two-category services: the layered cases

The framework explicitly handles services that sit across two categories:

"Some services sit across two categories. For example, Amazon S3 buckets and Amazon DynamoDB tables have both configuration (rebuilt from code) and data inside them (restored from backup), so recovery treats the two layers separately."

Service Configuration leg Data leg
S3 buckets Bucket policy, encryption config, lifecycle rules — rebuild from IaC Object content — restore from backup
DynamoDB tables Table schema, indexes, encryption, IAM policy — rebuild from IaC Item content — restore from backup

The general principle: separate the management plane from the data plane of every service, treat the management plane as code, restore only the data plane.

AWS-issued credentials: the framework still applies

"Some credentials are re-issued by AWS rather than rotated by you. For example, consider service-linked roles and STS session tokens. The framework still applies, it's just AWS that issues them fresh."

The rotate-or-re-issue category is about the property, not about who does the rotation. AWS issues fresh credentials for service- linked roles and STS session tokens because the framework requires new credentials; the customer doesn't have to do this part, but the framework still applies.

Derived data stores: the recovery dependency caveat

"Other data stores aren't backed up at all because they are derived from sources that are backed up. Search indexes, analytics tables, caches, and materialized views are common examples. These regenerate from restored data, so they are a recovery dependency rather than a separate recovery category but they must be included in the recovery runbook and sequenced after the data they depend on has been restored."

Common examples and their dependencies:

  • Elasticsearch / OpenSearch indexes — derived from primary database via reindexing; sequence: restore RDS → reindex into ES.
  • Analytics tables / materialised views — derived from raw event store via batch jobs; sequence: restore raw events → rerun pipelines.
  • Caches (Redis, Memcached) — derived from primary; sequence: restore primary → warm cache.

These are recovery dependencies, not recovery categories — but they must be in the runbook and sequenced correctly. Forgetting them means the rebuilt environment looks healthy but doesn't function under load.

The load-bearing caveat: trusted IaC source

The framework's most consequential assumption:

"The framework assumes that your source of configuration, including IaC templates, pipelines, and source repositories, wasn't itself the target of the attack. If it was, recovery starts further upstream with a trusted copy of source before rebuild can begin. Knowing where your known-good source of configuration lives, and how it is protected, is worth thinking through in advance."

This is the highest-leverage caveat in the framework — every cyber- resilience design has a source-of-truth-for-code that is itself a recovery dependency. If the IaC repository is compromised, the rebuild leg becomes a "rebuild from where?" question with no clean answer, and recovery has to start further upstream (e.g. from a trusted off-site mirror, an immutable signed artifact store, or a last-known-good snapshot of the repository).

This composes with patterns/iac-rebuild-from-separate-version-control — the rebuild leg requires that IaC live in a separate repository from the workload it deploys, with its own access controls.

Operational prerequisite: a working rotation process

The rotate leg is only viable if there's a rotation process that already exists and is exercised:

"AWS Secrets Manager rotation, IAM Identity Center session revocation, AWS Certificate Manager renewal, and workload-specific rotation hooks are components most customers already have in some form. The cyber recovery capability is the ability to invoke that rotation comprehensively and verify that nothing was missed."

The components for AWS:

The cyber-recovery capability is not the rotation infrastructure itself — it's the ability to invoke rotation comprehensively and verify nothing was missed. Routine rotation cycles validate the mechanism; recovery-time rotation is the forced application of the same mechanism to every secret.

Generalisation beyond AWS

The framework is substrate-agnostic — applicable wherever there's a distinction between configuration, data, and credentials:

  • GCP / Azure — same three categories with platform-specific primitives (Cloud Deployment Manager / ARM templates / Terraform for code; Cloud SQL / Azure Database for data; Secret Manager / Key Vault for rotation).
  • On-prem — Ansible / Terraform / Pulumi for code; database backups for data; HashiCorp Vault / cyberark for rotation.
  • Kubernetes — manifests + Helm + GitOps for code; PV snapshots for data; cert-manager + external-secrets for rotation.

The structural property — "three independent sources of truth, three independent trust assumptions, three independent recovery legs" — is universal.

Seen in

Last updated · 542 distilled / 1,571 read