CCSO study materials
CCSO study resources

CCSO cheat sheet

CCSO · Keep the key ideas within reach.

Quick reference

Cloud Governance, Risk, and Compliance

  • Shared responsibility does not transfer compliance accountability: the customer always owns data classification, access decisions, and regulatory evidence, while the provider owns physical and hypervisor controls.

  • Control inheritance maps provider attestations (SOC 2 Type II, ISO/IEC 27001, PCI DSS AOC) to customer frameworks; inherited controls still require customer-side configuration evidence to be audit-valid.

  • A cloud control matrix (CCM) maps each framework requirement to a technical or procedural control and a named owner; unmapped requirements are treated as gaps, not assumed coverage.

  • Risk register entries carry likelihood, impact, inherent risk, residual risk, and a treatment decision (mitigate, transfer, avoid, accept); residual risk above appetite requires documented sign-off.

  • Policy-as-code enforces guardrails at deploy time; preventive controls (deny policies) block noncompliant resources, detective controls (config rules) flag drift, corrective controls auto-remediate.

  • Data residency and sovereignty obligations constrain region selection, replication targets, and support-personnel access; contractual terms must match the actual deployment topology.

  • Evidence freshness matters: continuous compliance monitoring produces timestamped, scoped artifacts, whereas point-in-time screenshots decay and are commonly rejected in audits.

  • Third-party and supply-chain risk extends to marketplace images, SaaS integrations, and subprocessors; each requires due diligence and periodic reassessment tied to data sensitivity.

Quick reference

Cloud Architecture and Shared Responsibility

  • IaaS: customer owns OS, runtime, middleware, applications, and data. PaaS: customer owns applications, data, and identity configuration. SaaS: customer owns data, identity, and usage governance.

  • The provider is always responsible for physical security, hardware, and the virtualization layer; the customer is always responsible for data classification and identity/access decisions.

  • A trust boundary exists wherever control or authentication changes: account-to-account, VPC-to-internet, tenant-to-tenant, and control-plane-to-data-plane.

  • Defense in depth layers preventive, detective, and responsive controls so a single control failure does not expose data; each layer assumes the layer above has failed.

  • Landing zone design defines account/vault structure, network segmentation, logging aggregation, and guardrails before workloads deploy; retrofitting is costly and error-prone.

  • Control plane (management APIs) and data plane (workload traffic) have distinct threat models; compromise of the control plane typically yields full resource takeover.

  • Blast radius is bounded by account isolation, network segmentation, and least-privilege roles; a flat single-account architecture maximizes blast radius.

  • Well-architected reviews evaluate security alongside reliability, cost, and operational excellence; security findings must be prioritized against business impact, not severity alone.

Quick reference

Identity, Access, and Privileged Account Management

  • Federation via SAML 2.0 or OIDC centralizes authentication in an IdP; the cloud provider holds no passwords, and deprovisioning at the IdP revokes cloud access.

  • Role assumption (STS) issues short-lived credentials; long-lived access keys are the primary credential-leak vector and should be inventoried and eliminated.

  • Least privilege is achieved through permission-set scoping, condition keys (source IP, MFA present, resource tags), and permissions boundaries rather than broad managed policies.

  • Privileged access requires MFA, just-in-time elevation with approval, session recording, and time-bound expiry; standing admin rights are a recurring audit finding.

  • Separation of duties prevents one identity from both requesting and approving privileged access or from modifying its own audit trail.

  • Identity federation for workloads (instance profiles, workload identity, OIDC trust to CI systems) removes static secrets from pipelines and code.

  • Access reviews are periodic, owner-attested recertifications of entitlements; orphaned accounts and unused roles are removed at review, not deferred.

  • Break-glass accounts are sealed, monitored, alerted on use, and tested on a schedule; their credentials are excluded from normal federation paths.

Quick reference

Data Protection, Encryption, and Key Management

  • Encryption at rest uses provider-managed, customer-managed, or customer-supplied keys; customer-managed keys enable revocation and independent audit of key use.

  • Envelope encryption: a data key encrypts the data, and a root/master key encrypts the data key; rotating the root key does not require re-encrypting data.

  • Key rotation limits the volume of data protected by a single key version; automatic rotation periods are configured per key and old versions remain for decryption.

  • Key custody determines control: HSM-backed keys provide FIPS 140-2/3 validated modules, and multi-region or multi-tenant key stores trade availability against isolation.

  • TLS 1.2+ with strong cipher suites protects data in transit; certificate pinning and mTLS are used for service-to-service trust where the network is not trusted.

  • Data classification (public, internal, confidential, restricted) drives encryption, retention, and access requirements; unclassified data defaults to the highest handling tier.

  • Tokenization and format-preserving encryption reduce PCI scope by replacing card data with non-sensitive surrogates while preserving referential integrity.

  • Crypto-shredding destroys keys to render encrypted data unrecoverable; it satisfies deletion obligations only if key destruction is provable and backups are covered.

Quick reference

Cloud Network Security and Segmentation

  • Security groups are stateful, instance-level allow lists; network ACLs are stateless, subnet-level allow/deny lists evaluated in numbered order.

  • Default-deny egress prevents data exfiltration and command-and-control callbacks; allow lists should name destinations and ports explicitly.

  • Private subnets route outbound traffic through NAT gateways; public subnets host only load balancers and bastion-free entry points.

  • VPC peering and transit gateways extend the network; segmentation requires explicit route and firewall policy at each hop, not implicit trust between connected networks.

  • Private endpoints (interface and gateway endpoints) keep service traffic off the public internet and are a common control for data-exfiltration resistance.

  • Web application firewalls inspect L7 traffic for injection and bot patterns; DDoS protection is a separate L3/L4 service and does not replace WAF.

  • Micro-segmentation applies identity-aware policy between workloads, replacing perimeter trust; east-west traffic inspection catches lateral movement.

  • DNS filtering and egress logging detect tunneling and beaconing; unmonitored DNS is a frequent exfiltration channel.

Quick reference

Workload, Container, and Application Security

  • Container images are scanned for OS and library CVEs at build and continuously in the registry; admission control blocks images failing policy or lacking signatures.

  • Containers are not a security boundary by default; isolation relies on namespaces, cgroups, seccomp, and user-namespace or sandboxed runtimes.

  • Kubernetes RBAC, network policies, pod security standards, and admission webhooks are the primary cluster guardrails; the API server is the highest-value target.

  • Secrets are injected at runtime from a secret manager; baking secrets into images or environment files in source control is a critical finding.

  • Immutable, signed images with pinned digests prevent tag-mutation attacks; mutable latest tags defeat reproducibility and provenance.

  • CI/CD pipelines are production credentials: pipeline identities need scoped, short-lived tokens and protected branches, because pipeline compromise equals deployment compromise.

  • Serverless functions require least-privilege execution roles, dependency scanning, and input validation; function-level IAM over-permissioning is a common weakness.

  • Runtime protection (file integrity, syscall anomaly, egress behavior) detects post-exploitation activity that static scanning cannot see.

Quick reference

Logging, Monitoring, and Incident Response

  • Centralize logs in an account or vault separate from workloads, with write-once retention (object lock) so a compromised workload cannot delete its own trail.

  • Audit logs (control-plane API calls) are distinct from data-plane, network flow, and application logs; each answers different investigation questions.

  • Detection engineering converts threat models into queries and alerts; every alert needs an owner, a runbook, and a tested false-positive rate.

  • Mean time to detect (MTTD) and mean time to respond (MTTR) are the operational metrics; log coverage gaps directly inflate MTTD.

  • Incident response phases: preparation, detection and analysis, containment, eradication, recovery, and post-incident lessons learned.

  • Containment options include credential revocation, key rotation, network isolation, and snapshot preservation; evidence must be captured before remediation destroys it.

  • Alert fatigue is measured by actionable-alert ratio; tuning thresholds and suppressing known-benign patterns preserves analyst attention.

  • Regulatory breach notification timelines (for example 72 hours under GDPR) start at awareness, so detection latency consumes the notification window.

Quick reference

Cloud Security Operations, Automation, and DevSecOps

  • Shift left moves security checks into design, code review, and build; shift right adds runtime detection and response, and both are required.

  • Infrastructure as code enables policy-as-code scanning (for example plan-time evaluation) so misconfigurations are blocked before provisioning.

  • CI/CD gates fail the build on critical findings; warn-only gates accumulate risk because findings are rarely revisited after merge.

  • Automated remediation uses event-driven functions to revert drift (public buckets, open security groups) and must log the action and its trigger.

  • Golden images and hardened baselines reduce configuration variance; drift detection compares running state to the declared baseline continuously.

  • Software bill of materials (SBOM) and artifact signing establish provenance and enable rapid response when a dependency vulnerability is disclosed.

  • Secrets management automation rotates credentials on schedule and on suspicion; manual rotation is skipped under pressure.

  • Security metrics for operations include patch latency, percentage of workloads with current agents, policy compliance rate, and mean remediation time.