CSPCC cheat sheet

Shared responsibility model: the provider secures the cloud (physical, hypervisor, managed-service internals); the customer secures what they put in and configure in the cloud (data, identities, guest OS, network rules).

Service models shift the boundary: IaaS leaves OS patching and host firewall to the customer; PaaS moves runtime and middleware to the provider; SaaS leaves configuration, identity, and data governance to the customer.

Deployment models: public, private, hybrid, and multi-cloud differ in blast radius, control, and compliance scope; hybrid adds a connective layer (VPN, dedicated interconnect, identity federation) that itself becomes attack surface.

Well-architected pillars relevant to security: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability; security design trade-offs are documented per pillar, not in isolation.

Design patterns: defense in depth (independent layers), least privilege, fail-safe defaults, separation of duties, and zero trust (no implicit trust from network location; verify every request).

Blast radius control: segmentation by account/project/subscription, network zones, and separate environments (dev/test/prod) limits lateral movement; account-level isolation is a stronger boundary than a VPC alone.

Stateless vs stateful components: stateless tiers scale horizontally and are replaced, not repaired; stateful stores require encryption, backup, and snapshot protection as part of design.

Availability math: availability of serial components multiplies (0.999 x 0.999 ≈ 0.998), so chained dependencies lower overall availability; redundancy reduces single points of failure but adds credential and configuration sprawl.

Design review artifacts: data flow diagram, trust boundaries, asset inventory, and threat model are produced before build; changes to any of them trigger re-review.

Governance defines decision rights and accountability; it is distinct from management (execution). Typical artifacts: policy hierarchy, RACI, exception process, and control ownership register.

Policy hierarchy: high-level policy (intent) → standards (mandatory requirements) → procedures (steps) → guidelines (recommended). Cloud policies must cover acquisition, acceptable use, data classification, and provider exit.

Risk = likelihood x impact; a risk register records owner, inherent risk, controls, residual risk, and treatment (mitigate, transfer, avoid, accept). Risk acceptance requires documented authority at the right level.

Third-party/provider risk: due diligence includes certifications (ISO/IEC 27001, SOC 2), subprocessor lists, data residency, breach notification terms, and right-to-audit clauses.

Cloud concentration risk: over-reliance on one provider or one region for critical services; mitigations include exit plans, portable data formats, and tested failover.

Control frameworks map to each other: ISO/IEC 27001 (ISMS requirements), NIST CSF (identify/protect/detect/respond/recover plus govern in CSF 2.0), CIS Controls, and cloud-specific benchmarks.

Metrics and reporting: KPIs (control coverage, patch latency), KRIs (leading risk indicators such as unowned accounts), and board-level risk appetite statements.

Shared responsibility must be reflected in contracts: the provider's security responsibilities are documented in the service agreement, not assumed from marketing material.

Authentication vs authorization: authentication proves identity (password, key, federated assertion); authorization decides permitted actions (policies, roles, ACLs).

Federation standards: SAML 2.0 and OpenID Connect for human SSO; OAuth 2.0 for delegated authorization (not authentication by itself). SCIM automates user provisioning/deprovisioning.

Cloud IAM primitives: principal (user, group, role, service account), policy document (effect, action, resource, condition), and trust policy for role assumption. Evaluation order is typically explicit deny > explicit allow > implicit deny.

Least privilege mechanics: start from deny, grant narrow actions on specific resources with conditions (source IP, MFA present, time), review unused permissions, and remove standing admin.

Credential hygiene: no long-lived access keys where role assumption or workload identity is available; rotate secrets; store in a managed secret store; never in source code, images, or CI logs.

MFA: phishing-resistant factors (FIDO2/WebAuthn, passkeys) are preferred for privileged access; SMS and voice are weak. Enforce step-up authentication for sensitive operations.

Privileged access management: just-in-time elevation, break-glass accounts with monitored use, session recording, and separation of duties between requester and approver.

Identity lifecycle: joiner/mover/leaver processes, orphaned account detection, periodic access recertification, and group-based entitlements instead of per-user grants.

Workload identity: instance profiles, service accounts with workload identity federation, and short-lived tokens replace embedded static credentials for applications and pipelines.

Data classification tiers (public, internal, confidential, restricted) drive encryption, access, retention, and residency requirements; classification must cover metadata and backups, not just primary stores.

Encryption states: at rest (disk/object/database), in transit (TLS 1.2+; prefer TLS 1.3), and in use (confidential computing enclaves). Each state has separate key and access controls.

Key management: customer-managed keys vs provider-managed keys; envelope encryption uses a data key wrapped by a key encryption key. KMS/HSM choice affects auditability, rotation, and residency.

Crypto-shredding: destroying the key renders ciphertext unrecoverable; useful for erasure requests but requires key-per-data-subject or key-per-tenant design.

Privacy principles: lawfulness, purpose limitation, data minimization, accuracy, storage limitation, integrity/confidentiality, accountability. Privacy by design and by default are explicit requirements under GDPR Article 25.

Data subject rights: access, rectification, erasure, restriction, portability, objection. Cloud implementations need discovery across regions and replicas, plus documented response timelines (GDPR: one month, extendable).

Cross-border transfer mechanisms: adequacy decisions, standard contractual clauses, binding corporate rules; residency controls include region-pinned storage and tenant isolation.

Data loss prevention: labeling/tagging, pattern and ML detection, egress controls, and blocking of sensitive data to unmanaged destinations; tokenization and masking reduce exposure in non-production.

Backup and deletion: soft delete, versioning, immutability (object lock/WORM), and verified restore tests; deletion must propagate to snapshots, replicas, caches, and logs.

Virtual network segmentation: subnets, route tables, security groups (stateful, instance-level) and network ACLs (stateless, subnet-level); default deny inbound and explicit egress allowlists.

Public vs private exposure: load balancers, NAT gateways, and bastion/SSM-style access replace direct public IPs on instances; private endpoints/service endpoints keep traffic off the internet.

Hybrid connectivity: site-to-site VPN (IPsec) and dedicated private circuits; encrypt over the circuit if the provider link is not inherently private, and terminate in a controlled transit VPC/hub.

DDoS and edge: anycast scrubbing, CDN/WAF in front of origin, rate limiting, and origin shielding so the origin only accepts traffic from the edge.

WAF rules: OWASP-style managed rule sets plus custom rules; WAF is not a substitute for input validation and must be tuned to avoid false positives on APIs.

DNS security: DNSSEC, registrar lock, and separate DNS accounts; DNS is a control plane and hijacking it redirects all traffic.

Container and orchestration network: network policies (default deny pod-to-pod), private control plane endpoints, and node metadata access restrictions (IMDSv2-style session tokens).

Logging network telemetry: VPC flow logs, DNS query logs, and firewall logs feed detection; flow logs record metadata, not payload.

Shift left: threat modeling at design, SAST on source, SCA on dependencies, secret scanning on commits, DAST on running environments, and IaC scanning on templates before deploy.

CI/CD pipeline is a high-value target: isolate build runners, use short-lived federated credentials (OIDC to cloud) instead of stored keys, sign artifacts, and verify provenance (SLSA-style attestations).

Secure SDLC gates: code review required, branch protection, signed commits, dependency pinning, and blocking builds on critical findings rather than advisory-only reporting.

Secrets management: external secret stores injected at runtime, rotation, and detection of committed secrets with immediate revocation; history rewriting does not remove leaked secrets from caches.

Infrastructure as code: policy-as-code (OPA/Rego, cloud native policy engines) enforces guardrails; drift detection catches console changes that bypass pipelines.

Runtime protection: RASP, eBPF/agent-based workload monitoring, immutable containers, minimal base images, and admission control that rejects unsigned or privileged workloads.

API security: authentication and authorization per endpoint, schema validation, rate limiting, and inventory of shadow/zombie APIs; OWASP API Top 10 covers BOLA and broken auth as leading risks.

Supply chain: SBOM generation, vulnerability scanning of images, and vendor dependency review; a compromised build dependency bypasses application-layer controls.

Telemetry sources: control-plane audit logs (who changed what), data-plane logs, flow logs, host/agent logs, and application logs; centralize into a SIEM/log lake with integrity protection.

Detection engineering: map detections to a framework (MITRE ATT&CK), tune alerts, and track false positive rate; cloud-specific signals include IAM policy changes, key deletion scheduling, and public bucket ACLs.

Cloud incident response phases: prepare, detect/analyze, contain, eradicate, recover, post-incident. Cloud adds provider communication, API-based containment, and evidence preservation across accounts.

Containment primitives: revoke/rotate credentials, disable keys, detach policies, isolate instance via security group, snapshot volumes for forensics before termination.

Evidence handling: capture logs and snapshots with hashes and chain of custody; account for provider-held logs (request them early, retention may be short).

Forensics in cloud: live response is often limited; prefer memory capture where supported, disk snapshots, and control-plane log reconstruction; understand data residency of forensic copies.

Runbooks and game days: documented roles (incident commander, comms, forensics), escalation paths, and tested playbooks; tabletop exercises validate provider contact and legal notification paths.

Metrics: MTTD and MTTR, alert backlog, and coverage of critical log sources; log retention must exceed the detection and investigation window.

Assurance reports: SOC 1 (financial controls), SOC 2 (security, availability, confidentiality, processing integrity, privacy), SOC 3 (public summary). Type I is design at a point in time; Type II covers operating effectiveness over a period.

ISO/IEC 27001 certifies the ISMS; ISO/IEC 27017 and 27018 add cloud-specific and personally identifiable information in public cloud guidance.

Scope and carve-outs: read the report's system description, complementary user entity controls (CUECs), and subservice organizations; provider compliance does not make the customer compliant.

Regulatory mapping: GDPR (EU personal data), HIPAA (US health, with BAA), PCI DSS (cardholder data, applies to the customer's environment), FedRAMP (US federal authorization), and sector rules.

Cloud contracts: data processing agreement, subprocessor notification, breach notification timelines, data return/deletion on exit, audit rights, liability caps, and service-level credits.

Audit evidence in cloud: configuration exports, API logs, access reviews, and continuous compliance tooling; evidence must be reproducible and tied to a control ID.

Jurisdiction and legal hold: data location determines applicable law; litigation hold suspends deletion schedules and must be honored across backups and third parties.

Exit and portability: documented data extraction formats, transition assistance, and destruction certification at contract end.