CCAS study materials
CCAS study resources

CCAS cheat sheet

CCAS · Keep the key ideas within reach.

Quick reference

Cloud Application Architecture and Design Security

  • Shared responsibility model: the provider secures the cloud (physical, hypervisor, managed service internals); the customer secures what runs in the cloud (data, identities, configuration, application code).

  • Trust boundaries must be drawn wherever data crosses an authentication or authorization boundary - between tiers, tenants, VPCs, or the internet - and every crossing needs an explicit control.

  • Defense in depth layers controls so no single failure is sufficient: WAF → API gateway authN/authZ → service-level authorization → data-layer row/column controls → encryption at rest.

  • Least privilege applies to architecture as well as identity: each microservice gets its own service account and scoped role, never a shared admin credential.

  • Multi-tenant isolation options, in increasing strength: shared tables with tenant ID filtering, schema-per-tenant, database-per-tenant, and separate accounts/subscriptions per tenant.

  • Stateless services scale horizontally and simplify key rotation and session security; state belongs in a managed store with its own access controls.

  • Blast radius reduction: segment networks into subnets/security groups per tier, use private endpoints for managed services, and deny egress by default.

  • Design for failure of security controls: if the WAF or token introspection service is unavailable, default to deny rather than fail-open.

Quick reference

Security, Identity, Authentication, and Access Management for Cloud Applications

  • OIDC builds authentication on OAuth 2.0 and adds the ID token (a signed JWT); OAuth 2.0 alone is an authorization delegation framework, not an authentication protocol.

  • OAuth 2.0 flows: authorization code with PKCE for public clients (SPA, mobile); client credentials for machine-to-machine; implicit and resource owner password flows are deprecated.

  • JWT validation requires checking signature against the issuer's JWKS, then iss, aud, exp, nbf, and alg (reject 'none' and algorithm confusion).

  • Access token lifetimes should be short (minutes); refresh tokens are long-lived, stored securely, rotated on use, and bound to the client.

  • RBAC grants permissions by role; ABAC evaluates attributes (user, resource, environment) in policy - ABAC handles finer-grained and context-dependent decisions.

  • Federation: SAML 2.0 for enterprise SSO, OIDC for modern apps; SCIM automates user and group provisioning/deprovisioning across the IdP and applications.

  • Workload identity: cloud-native identity (IAM roles for service accounts, managed identities, workload identity federation) avoids static secrets in code or config.

  • Privileged access: require MFA, just-in-time elevation, and session recording for admin roles; separate admin accounts from daily-use accounts.

Quick reference

Cloud Application Security Standards, Frameworks, and Governance

  • ISO/IEC 27017 and 27018 extend ISO 27001 with cloud-specific and public-cloud privacy (personally identifiable information) controls.

  • SOC 2 reports on the trust services criteria (security, availability, processing integrity, confidentiality, privacy); a Type II report covers a period and tests operating effectiveness.

  • CSA Cloud Controls Matrix (CCM) is a cloud-specific control catalog mapped to ISO 27001, NIST, PCI DSS, and HIPAA; the STAR program registers provider assessments.

  • NIST CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond, Recover.

  • Policy as code (e.g., OPA/Rego, cloud-native organization policies) enforces guardrails at deploy time and is version-controlled and reviewed like application code.

  • Governance artifacts: data classification scheme, acceptable use policy, risk register, exception process with expiry, and control ownership matrix.

  • Continuous compliance: map each control to an automated check, record evidence on a schedule, and alert on drift rather than relying on annual audits only.

  • Regulatory drivers to know: GDPR (EU personal data), HIPAA (US health), PCI DSS (card data), and data residency requirements that constrain region choice.

Quick reference

Secure Software Development Lifecycle and DevSecOps in the Cloud

  • Shift left: threat modeling at design, SAST on commit, SCA on dependencies, DAST in a test environment, and infrastructure-as-code scanning on every pull request.

  • Threat modeling with STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) produces concrete mitigations per component.

  • SAST analyzes source without executing it and has higher false positives; DAST exercises a running app and finds runtime and configuration issues SAST misses.

  • Software supply chain: pin dependency versions, generate an SBOM (SPDX or CycloneDX), sign artifacts, and verify provenance (e.g., SLSA levels, Sigstore).

  • Pipeline hardening: ephemeral build agents, least-privilege CI tokens scoped per job, secrets from a vault at runtime, and no long-lived cloud keys in CI variables.

  • Security gates should fail the build on critical findings; lower-severity findings are triaged with a documented SLA rather than blocking every merge.

  • IaC scanning catches public buckets, open security groups, unencrypted volumes, and over-broad IAM before anything is deployed.

  • Branch protection plus mandatory review, signed commits, and protected deployment environments prevent unreviewed code from reaching production.

Quick reference

Cloud Data Protection, Encryption, and Key Management

  • Encryption states: at rest (storage/volume/database), in transit (TLS 1.2+ with strong cipher suites), and in use (confidential computing enclaves, tokenization).

  • Envelope encryption: a data key encrypts the data, and a key encryption key (KEK) in a KMS encrypts the data key; rotate the KEK without re-encrypting all data.

  • KMS key types: customer-managed keys give control over policy and rotation; provider-managed keys are simpler but the customer cannot restrict their use.

  • Key rotation limits blast radius of a leaked key; disabling or scheduling deletion of a key renders enveloped data unrecoverable - deletion should have a waiting period.

  • Secrets management differs from key management: secrets (passwords, API tokens, connection strings) belong in a secrets manager with rotation and short TTLs, not in code or images.

  • Data classification (public, internal, confidential, restricted) drives which encryption, retention, and access controls apply.

  • Tokenization replaces sensitive values with non-sensitive tokens mapped in a vault; format-preserving encryption keeps the original data shape for legacy systems.

  • Crypto-shredding: destroying the per-tenant key makes that tenant's data unreadable, satisfying erasure requests without rewriting storage.

Quick reference

API Security and Application Integration Security

  • OWASP API Security Top 10 categories to know: broken object level authorization (BOLA), broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, and security misconfiguration.

  • BOLA is the top API risk: every object access must verify that the caller owns or is entitled to the requested object ID, not just that the caller is authenticated.

  • API gateway responsibilities: authentication, rate limiting, schema validation, request/response logging, and routing - but authorization to specific resources is enforced in the service.

  • Rate limiting and quotas defend against credential stuffing, scraping, and resource exhaustion; return 429 with Retry-After and limit by key, IP, and user.

  • Never expose internal object identifiers without authorization checks; prefer opaque or unguessable IDs and validate all parameters against a schema.

  • For integrations: use signed requests (HMAC) or mutual TLS between services, validate webhook signatures, and verify the sender before processing events.

  • GraphQL specifics: disable introspection in production, enforce query depth and complexity limits, and apply field-level authorization.

  • API inventory and versioning: deprecate old versions on a schedule, document every endpoint, and treat shadow APIs as an attack surface to discover and retire.

Quick reference

Cloud Application Security Testing and Vulnerability Management

  • Vulnerability lifecycle: discover → validate/triage → prioritize → remediate → verify → close; track every finding with an owner and a due date.

  • CVSS base score measures severity; prioritization must also weigh exploitability (EPSS), known exploitation (CISA KEV), internet exposure, and data sensitivity.

  • Scan types: SAST (source), SCA (dependencies), DAST (running app), container/image scanning (layers and OS packages), IaC scanning, and cloud security posture management (CSPM).

  • False positives must be triaged with justification and suppressed, not ignored; re-scan after remediation to confirm the fix.

  • Penetration tests are point-in-time and scoped; continuous scanning plus bug bounty or vulnerability disclosure programs provide ongoing coverage.

  • Remediation SLAs commonly tier by severity (e.g., critical in days, high in weeks, medium in a quarter), adjusted by exploitability and exposure.

  • Dependency risk: track transitive dependencies, monitor for new CVEs in already-deployed components, and maintain an SBOM to answer 'are we affected?' quickly.

  • Cloud-native testing includes configuration drift detection and attack path analysis across IAM, network, and storage exposure.

Quick reference

Cloud Application Logging, Monitoring, and Incident Response

  • Log sources to centralize: application logs, authentication events, API gateway access logs, cloud control-plane audit logs (e.g., CloudTrail, Activity Log), and network flow logs.

  • Logs must be tamper-evident: write to a centralized, append-only store with restricted write access, integrity hashing, and retention aligned to compliance.

  • Never log secrets, tokens, passwords, or full PII; redact at the logging library and test redaction in CI.

  • Detection: define signals (failed login spikes, unusual data egress, privilege changes, new admin roles) and alert on them with thresholds tuned to reduce noise.

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

  • Containment in cloud often means revoking credentials/keys, isolating the instance from the network, and snapshotting evidence before remediation.

  • Forensics: preserve logs and disk images, maintain chain of custody, and know provider responsibilities for platform-level logs.

  • Metrics that matter: mean time to detect (MTTD) and mean time to respond (MTTR); run tabletop exercises and game days to validate the runbook.

Quick reference

Cloud Application Deployment, Runtime, and Container Security

  • Container image hygiene: minimal base images, no secrets baked in, non-root user, read-only root filesystem, and pinned image digests rather than mutable tags.

  • Kubernetes controls: RBAC least privilege, network policies default-deny, Pod Security Standards (restricted), admission controllers (e.g., OPA Gatekeeper, Kyverno) to reject non-compliant workloads.

  • Secrets in Kubernetes: use external secret stores or sealed/encrypted secrets; native Secrets are base64-encoded, not encrypted, unless encryption at rest is enabled.

  • Runtime detection covers process execution, file integrity, and outbound connections; it complements image scanning, which only sees the artifact at build time.

  • Serverless and PaaS: the provider patches the runtime, but the customer owns function permissions, environment variables, dependency versions, and event-source authorization.

  • Immutable infrastructure: rebuild and redeploy rather than patching running hosts; this removes configuration drift and simplifies rollback.

  • Deployment safety: canary or blue/green releases, automated rollback on health or error-rate thresholds, and signed images verified at admission.

  • Supply chain at runtime: verify image signatures and provenance at admission, and restrict which registries a cluster may pull from.