CrowdStrike CCCS study materials
CrowdStrike CCCS study resources

CrowdStrike CCCS: Cloud Threat Detection, Response, and Compliance

CrowdStrike CCCS · Work through your exam, one topic at a time.

All guide sections

Cloud Threat Detection, Response, and Compliance

This domain asks how cloud attacks are detected, contained and evidenced. The key insight: most cloud attacks never touch a host, so agent-only detection misses them - control-plane activity in CloudTrail, Activity Log and Audit Logs is the primary signal.

Detection

Cloud indicators of attack target API behaviour: logging disabled (StopLogging), an access key created for another principal, a policy rewritten to *, snapshot or bucket sharing with an external account, mass secret retrieval, or a role assumed from an unexpected network path. Falcon correlates these control-plane events with endpoint telemetry in the Threat Graph; human-led hunting in OverWatch and managed response provide the escalation path when no analyst is watching.

Response

Real Time Response gives an interactive session on a running sensor host: run scripts, pull files, kill processes, and network-contain the host by isolating it from the network while keeping the sensor channel open. For agentless assets, response is API-driven: revoke sessions or disable keys, detach or restrict the instance, snapshot volumes for forensics before termination, and preserve logs to separate storage. Falcon Fusion automates these steps into workflows so containment is consistent rather than improvised.

Compliance as continuous evidence

Frameworks such as CIS Benchmarks, PCI DSS, HIPAA, SOC 2, NIST 800-53 and ISO 27001 map to individual posture controls. A compliant score is a point-in-time evaluation; drift, new resources and exception handling must be re-evaluated. Findings should be traceable to control IDs and exportable as evidence, and accepted risks recorded as documented exceptions rather than suppressed.

Worked example

CloudTrail shows StopLogging, then CreateAccessKey for a different user, then GetSecretValue across many secrets from an unfamiliar IP. Reasoning: these are control-plane IOAs, not host events - a sensor on an unrelated VM would show nothing. Response order is preserve the trail and logs, disable the created key and revoke active sessions, contain the source principal, then scope blast radius by checking what the secrets unlocked. Terminating instances first destroys evidence.

Traps that cost marks

Relying on endpoint detection for serverless or API-only attacks; destroying an instance before snapshotting; assuming compliance dashboards self-refresh across new accounts; treating a single benign-looking API call as noise when it chains into privilege escalation.