CCSO cheat sheet
CCSO · Keep the key ideas within reach.
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.
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.
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.
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.
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.
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.
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.
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.