Most deployments are based on infrastructure as code from Cloud Security Maturity Model 2.0 framework

Home
Browse frameworks
Contact us
SAMMY premium

Cloud Security Maturity Model 2.0

Browse Cloud Security...

Governance
Organization Management
IAM
Security Monitoring
Network Security
Workload Security
App Security
Data Security
Risk Assessment and Provider Management
Resilience
Compliance and Audit
Incident Response

BCR-04.2: Most deployments are based on infrastructure as code

BCR-04.2: Infrastructure as code increases resiliency by providing consistency and, in some cases, portability (because the IaC can rebuild into new or multiple deployments). In mature organizations, most or all production stacks are deployed using IaC as the default. Note that IaC doesn't deploy data, just the configuration of the data plane, so it creates workload resiliency but not necessarily data resiliency. This control objective can be automatically assessed when using the built-in IaC capability of the cloud provider (e.g., CloudFormation) or if tooling integrates with the CI/CD pipeline that uses a third-party IaC like Terraform.

Control automation: Partially Automated
AWS control specification: * Pass if >70% of compute resources (instances/container tasks/Lambda functions) are tagged with an associated CF stack
Azure control specification: none
GCP control specification: none
Third-party (CSPM/CNAPP) control specification: none

Not Applicable - Not applicable

Level 1: Initial - Initial. Manually managing policies/procedures, mostly through console. Architectures tend to resemble traditional infrastructure (e.g., low use of serverless and high reliance on network security controls). IAM mostly ad hoc with little-to-no federation.

Level 2: Repeatable - Repeatable. Policy-/checklist-based and relies more on manual or simple tooling. High variability between projects; not coordinated across deployments. Initial use of infrastructure as code (Terraform/CloudFormation), but security not consistently engaged in design/review. Federation on some accounts, but limited use of MFA due to difficulties supporting teams (especially on the command line).

Level 3: Defined - Defined. Policies and central coordination in place. Some initial security automation still executed manually. Some third-party tooling (orchestration with other tools), Federation on most accounts with widespread MFA, but still gaps on consistency. Security starting to review and promote use of CloudFormation/Terraform. CSPM/CNAPP (CSP or third party) in use.

Level 4: Capable - Capable. Strong centralized security management with consistent enforcement. Automation and guardrails across multiple deployments. Expanding library. Big shift from manual management and execution to running security operations with centralized platforms with centralized management and reporting. Consistent use of federation and MFA, with some gaps supporting toolchains.

Level 5: Efficient - Efficient. All major activities centrally managed, covering all of the CSMM domains. Integrated into infrastructure-as-code (IaC) environment. Built into the stack with provisioning automation. Federation and MFA working consistently across toolchains (e.g., command-line support).

Description

Control automation: Partially Automated
AWS control specification: * Pass if >70% of compute resources (instances/container tasks/Lambda functions) are tagged with an associated CF stack
Azure control specification: none
GCP control specification: none
Third-party (CSPM/CNAPP) control specification: none