Cloud Security Maturity Model 2.0
Browse Cloud Security...
LOG-04.2: Cloud-native threat detectors are enabled
LOG-04.2: Cloud-native threat detectors monitor management plane and other sources for signs of cloud attacks. These are different than traditional threat detectors because they look for cloud platform activity—not necessarily network or workload activity—to indicate potential attacks. For this control objective, threat detectors beyond those built into the cloud platform's built-in threat monitoring service should be enabled (e.g., custom detectors, not just GuardDuty or Defender). These detectors can be implemented natively in the cloud platform, but will typically be run from an external SIEM or cloud detection and response (CDR) platform. Thus, this detector is difficult to automatically assess, unless the assessment tool itself includes the capability.
  • Control automation: Either
  • AWS control specification: Not effectively automatable in AWS
  • Azure control specification: Sentinel is running with default detectors (behavioral analytics) running
  • GCP control specification: Chronicle enabled with built-in detectors running
  • Third-party (CSPM/CNAPP) control specification: CSPM tool includes CDR capabilities with integrated threat detectors
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: Either
  • AWS control specification: Not effectively automatable in AWS
  • Azure control specification: Sentinel is running with default detectors (behavioral analytics) running
  • GCP control specification: Chronicle enabled with built-in detectors running
  • Third-party (CSPM/CNAPP) control specification: CSPM tool includes CDR capabilities with integrated threat detectors