WAF++ WAF++
Back to WAF++ Homepage

WAF-OPS-020 – Infrastructure as Code Enforced

Pillar: Operational Excellence | Severity: High | Category: Infrastructure as Code | Automatable: High

Description

All cloud infrastructure MUST be defined as code (Terraform, Pulumi, AWS CDK). Manual resource creation through the cloud console MUST be prohibited for production and staging. IaC definitions MUST be versioned, reviewed, and deployed through CI/CD.

Rationale

Manually created infrastructure cannot be reliably reproduced, cannot be reviewed, and cannot be audited. Snowflake servers are a primary risk for reliability and operational debt. IaC eliminates configuration drift, enables audit trails, and allows disaster recovery in minutes instead of weeks.

Threat Context

Risk Description

Configuration Drift

Manual console changes create invisible deviations between the IaC definition and reality.

Snowflake Servers

Manually configured systems cannot be reproduced after a failure.

Missing Peer Review

Without IaC and pull requests, there are no second eyes on infrastructure changes.

DR Failure

Disaster recovery tests fail because the actual infrastructure deviates from the documented IaC.

Requirements

  • All production and staging infrastructure MUST be defined as IaC

  • Manual changes MUST be restricted by IAM policy or Service Control Policy (SCP)

  • Remote state backend with locking MUST be configured (no local state)

  • All IaC changes MUST go through pull request review

  • State bucket MUST have versioning enabled for rollback capability

Implementation Guidance

  1. Configure remote state: S3+DynamoDB (AWS), Azure Storage Account, GCS Bucket – with locking

  2. Secure state bucket: Enable versioning; encryption at rest; access logging

  3. Restrict console access: SCP or IAM permission boundary for production accounts

  4. Build module library: Reusable modules for networking, compute, security

  5. Enable drift detection: terraform plan daily via EventBridge schedule; alert on drift

  6. Brownfield import: Take over existing resources into state with terraform import

Maturity Levels

Level Name Criteria

1

Manual

No IaC; infrastructure created manually via console or CLI.

2

Inconsistent IaC

Parts of the infrastructure as IaC; manual resources coexist; no remote state.

3

IaC Fully Enforced

100% production infrastructure as IaC; remote state; manual changes restricted.

4

Drift Detection & Policy Enforcement

Drift detected and alerted daily; policy-as-code in CI; module library present.

5

GitOps

Git state = single source of truth; automatic drift remediation; IaC coverage 100%.

Terraform Checks

waf-ops-020.tf.aws.s3-terraform-state-backend

Checks: Terraform remote state is configured in S3 backend (not local state).

Compliant Non-Compliant 
terraform {
  backend "s3" {
    bucket         = "my-org-tf-state"
    key            = "service/prod/terraform.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}
 
terraform {
  # No backend – local state
  # WAF-OPS-020 Violation:
  # no remote state, no locking
}

waf-ops-020.tf.aws.s3-state-bucket-versioning

Checks: S3 state bucket has versioning enabled.

# Compliant
resource "aws_s3_bucket_versioning" "state" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"  # Not Suspended
  }
}

Remediation: Configure remote state backend with S3+DynamoDB locking. Enable state bucket versioning.

Evidence

Type Required Description

IaC

✅ Required

Terraform repository with remote state configuration (backend.tf with S3/Azure/GCS).

Config

✅ Required

State backend configuration with versioning and locking enabled.

Process

Optional

Drift detection report (last 30 days, drift events with resolution times).

Governance

Optional

SCP or IAM policy preventing direct console changes in production accounts.

Related Controls

Regulatorisches Mapping

Framework Controls

ISO/IEC 20000-1:2018

8.2.3 – Change management; 8.3.4 – Release management; 10.2.2 – Financial management

ITIL 4

SVS – Service value system; DP – Design principle; OV – Operation value chain

AWS Well-Architected Framework

Operational Excellence Pillar – Prepare; Operational Excellence Pillar – Deploy

DORA

DORA 2024 – Technical practices; DORA 2024 – Organizational culture

SOC 2 Type II

CC4.1 – Monitoring activities; CC7.1 – Infrastructure and software monitoring

Google SRE Book

Chapter 2 – SRE: The role of an SRE; Chapter 3 – Service Level Objectives

PCI DSS v4.0

Req 6.4 – Secure development lifecycle; Req 6.5 – Secure coding practices

FinOps Foundation

Core Module – Financial accountability; Management Layer – Cost governance

BSI C5:2020

OPS-01 – Operational monitoring; OPS-02 – Operational control; OPS-03 – Operational capacity

NIST SP 800-53

CM-1 – Configuration management policy; CM-2 – Configuration management

NIST CSF 2.0

GV.PO – Policy; RC.RP – Recovery planning; DE.CM – Continuous monitoring

TISAX

Information security – Change management

ANSSI SecNumCloud

Domain – Change management

BIO

BIO – Veranderingenbeheer

ENS High

op.exp.6 – Gestión de cambios

UK NCSC CAF

A4 – Policy and assurance; A5 – Continual improvement

CMMC 2.0

CM.L2-3.4.1 – Establish baseline configurations

IRAP

ISM – Change management

CCCS PBMM

CM-2 – Baseline configuration; CA-7 – Continuous monitoring

MAS TRM

Ch.3 – Technology risk governance; Ch.9 – Change management

ISMAP

Operational excellence and continuous improvement

FISC

Operational measures – Change management

Best Practice