Skip to content

PATTERN Cited by 1 source

IaC rebuild from separate version control

Pattern

When rebuilding infrastructure during cyber-event recovery, rebuild from IaC templates stored in a separate, version-controlled repository — not from a backup of the running configuration. The repository must be isolated from the workload it deploys so a compromise of production credentials doesn't reach the source.

Verbatim from the canonicalising source:

"Rebuild infrastructure in the IRE from infrastructure as code (IaC) templates stored in a separate, version-controlled repository." (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

This is the rebuild leg of the Rebuild-Restore-Rotate framework — "Infrastructure is code" — operationalised as a concrete architectural requirement.

Why a separate repository

The pattern's load-bearing property is trust isolation between the workload and its configuration source of truth:

Source of configuration What's trusted? Cyber-event posture
Running production config Possibly modified by attacker Cannot be trusted as recovery source
Backup of running production config May reflect attacker's modifications Cannot be trusted as recovery source
IaC repository in separate VCS Independent audit trail (commits, code review, branch protection) Trusted as recovery source (if the repository itself wasn't compromised)

The pattern moves "configuration source of truth" from production runtime to the IaC repository — with an independent compromise surface that's typically better protected than production credentials (e.g. enforced 2FA on git push, branch protection, code review requirements, signed commits).

What goes in the repository (rebuild-from-code category)

Per the framework:

  • IAM policies and roles
  • Security Groups, VPC configuration, subnets, route tables
  • EC2 launch templates, Auto Scaling configurations
  • Lambda function code and configuration
  • CI/CD pipeline definitions
  • API Gateway / ALB / NLB configurations
  • Step Functions / EventBridge rules
  • Tagging policies, SCP definitions

What doesn't go in the IaC repository:

  • Customer data (restored from backup)
  • Database content (restored from backup)
  • Secrets (rotated/re-issued, not stored)
  • Runtime state (regenerated)

The load-bearing caveat: trusted IaC source

The pattern's most consequential assumption (verbatim from the canonicalising source):

"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 forces a recursive question: where is the IaC source's source of truth? Practical answers:

  • Independent backup of the IaC repository to a separate provider / location.
  • Signed-artifact immutable mirror in object storage with S3 Object Lock or equivalent.
  • Last-known-good snapshot taken on a regular cadence to a separate trust domain.
  • Hardware-backed signing keys (HSM-backed code-signing keys like HSM-backed roots) for verification of recovered IaC.

The pattern doesn't prescribe which approach — just that knowing where your trusted source lives and how it's protected is part of the recovery design, not an emergency-time decision.

Composition with the IRE

The pattern composes with the IRE — IaC templates deploy into the IRE during Stage 4 rebuild. This means the IaC templates must be:

  • Account-parameterised — they take a target account ID as input and create resources in the IRE rather than the original Production Account.
  • Region-parameterised — same, for cross-Region recovery.
  • Tag-parameterised — recovery resources should be tagged for cutover tracking.

Idempotent IaC (Terraform, CloudFormation, CDK) makes this natural — "deploy this template to account X in region Y" is a standard operation.

Cross-account references in IaC

A subtle requirement: IaC templates that reference other accounts' resources (cross-account roles, KMS key grants, resource policies) must reference accounts in a way that survives cutover. Two common approaches:

  • Variable / parameter references — account IDs are template parameters that get substituted at deploy time; cutover updates the parameter values.
  • AWS Config / IAM Access Analyzer inventory as the cutover reference list — Stage 5 of the recovery workflow uses this to identify cross-account references that need updating.

When to use this pattern

Use this pattern when:

  • Production infrastructure is large enough that manual reconstruction isn't feasible.
  • The team is mature enough to maintain IaC as the source of truth (not just for recovery — generally).
  • Cyber-event recovery is a real concern, not just routine DR.

Weaker fit when:

  • IaC adoption is partial (only some infra is in code; the rest is ClickOps). Mitigation: invest in IaC coverage as a recovery requirement.
  • The team can't sustain code-review / branch-protection discipline on the IaC repository (which weakens the trust isolation that makes this pattern load-bearing).

Composition with other patterns

Failure modes

  1. IaC drift from production reality. ClickOps changes to production weren't ported back to IaC; rebuild produces infrastructure that doesn't match what was running. Mitigation: AWS Config / drift-detection on a routine cadence; treat drift as a recovery-readiness defect.
  2. IaC repository compromised. Attacker modifies IaC before triggering the cyber event; rebuild deploys malicious config. Mitigation: independent backup of repository; signed commits with verification at deploy time; access controls separated from workload identity.
  3. IaC depends on production runtime data. Templates pull secrets / configuration from running production resources during apply; rebuild fails because production is isolated. Mitigation: IaC must be self-contained (parameters from documented sources, not from runtime queries against the failed production).
  4. Cross-account references hard-coded. Templates have the old Production Account ID baked in; rebuilt infrastructure points at isolated/old production. Mitigation: account ID as parameter; cutover step updates parameter values.
  5. IaC versions don't match data backup versions. Restored database has schema X; IaC deploys schema Y. Mitigation: tag IaC versions and data backups together; recovery runbook specifies matched-pair selection.

Generalisation beyond AWS

The pattern is substrate-agnostic — applicable to any infrastructure with declarative deployment:

  • GCP — Terraform / Cloud Deployment Manager / Cloud Foundation Toolkit.
  • Azure — ARM templates / Bicep / Terraform.
  • Kubernetes — Helm charts / Kustomize / GitOps with Flux or ArgoCD.
  • On-prem — Ansible / Pulumi / Terraform for heterogeneous infra.

The structural property is infrastructure declared in a separately- governed repository, not derived from running state.

Seen in

Last updated · 542 distilled / 1,571 read