04 - Cloud Application Security (Domain 4, 17%)¶

Domain Overview¶

Domain 4 covers building, deploying, and operating applications securely in the cloud. It overlaps with CISSP Domain 8 but emphasizes cloud-specific patterns: microservices, APIs, containers, serverless, DevSecOps, supply chain, and cloud-native IAM for applications.

Cloud SDLC and DevSecOps¶

Cloud SDLC Phases¶

1. Requirements - Including security and compliance requirements
2. Design - Threat modeling (STRIDE, PASTA), architecture review
3. Implementation - Secure coding, code review, secrets management
4. Testing - SAST, DAST, IAST, SCA, manual review
5. Deployment - IaC, CI/CD with security gates
6. Operations - Runtime protection, monitoring, vuln management
7. Disposal - Decommission with data destruction

DevSecOps Principles¶

• Security integrated into pipelines (shift left)
• Automation of security testing
• Shared responsibility for security across teams
• Continuous feedback and improvement
• Policy as code (OPA, Sentinel, Cedar)

CI/CD Pipeline Security¶

• Pipeline as code (Jenkins, GitHub Actions, GitLab CI, Azure DevOps)
• Pipeline secrets vaulted (vault for OIDC tokens, no static creds)
• Least privilege for pipeline service accounts (workload identity federation)
• Required gates:
• Secret scanning (TruffleHog, Gitleaks)
• SAST (SonarQube, CodeQL, Snyk Code, Semgrep)
• SCA (Dependabot, Snyk, Mend)
• IaC scanning (Checkov, tfsec, Terrascan, OPA)
• Container image scanning (Trivy, Snyk Container)
• License compliance check
• Optional: DAST against staging
• Signed artifacts (Sigstore Cosign, GPG)
• Provenance attestations (SLSA framework)
• Branch protection (required reviewers, status checks, no direct push to main)
• Immutable artifact registries

SLSA (Supply chain Levels for Software Artifacts)¶

Software Bill of Materials (SBOM)¶

• Standard formats: SPDX, CycloneDX
• Required by US Executive Order 14028 for federal software
• Enables rapid impact assessment for new CVEs
• Generated by SCA tools

Common Cloud Application Vulnerabilities¶

OWASP Top 10 (2021)¶

1. Broken Access Control
2. Cryptographic Failures
3. Injection (SQL, NoSQL, OS, LDAP)
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)

OWASP API Security Top 10 (2023)¶

1. Broken Object Level Authorization (BOLA)
2. Broken Authentication
3. Broken Object Property Level Authorization
4. Unrestricted Resource Consumption
5. Broken Function Level Authorization
6. Unrestricted Access to Sensitive Business Flows
7. Server Side Request Forgery (SSRF)
8. Security Misconfiguration
9. Improper Inventory Management
10. Unsafe Consumption of APIs

OWASP Serverless Top 10¶

• Function event injection
• Broken auth
• Insecure deployment configuration
• Over-privileged function permissions
• Inadequate monitoring
• Insecure third-party dependencies
• Insecure secret storage
• Improper exception handling
• Functions execution flow manipulation
• Improper resource consumption

Cloud Application Architectures¶

Monolithic (legacy)¶

• Single deployable unit
• Easier to secure perimeter, harder to scale parts independently
• Often migrated to cloud lift-and-shift

Microservices¶

• Decomposed into independently deployable services
• Service-to-service communication (HTTP/gRPC)
• Independent scaling and deployment
• Security: identity per service, mTLS, API gateways, service mesh
• Operational overhead

Event-Driven¶

• Services communicate via events (queues, streams)
• Loose coupling
• Security: authenticate event sources, validate event payloads, don't trust events from outside trust boundary

Serverless¶

• Event-triggered functions
• No server management
• Per-function IAM
• Cold starts and visibility limits

Cloud-Native vs Cloud-Hosted¶

• Cloud-native: designed for cloud (microservices, managed services, IaC, ephemeral)
• Cloud-hosted: traditional app moved to cloud (lift-and-shift)

Sandboxing and Application Virtualization¶

Sandboxing¶

• Isolated execution environment
• Container isolation
• Process sandboxing (seccomp, AppArmor, SELinux)
• Browser sandboxes
• File detonation sandboxes (Cuckoo, vendor solutions)

Application Virtualization¶

• Application packaged with dependencies, runs without modifying host
• Examples: Docker containers, App-V, ThinApp
• Reduces conflicts and dependency issues

Cryptography in Cloud Applications¶

TLS Everywhere¶

• Encrypt all in-transit traffic, including internal service-to-service
• TLS 1.2 minimum, TLS 1.3 preferred
• Strong cipher suites (PFS via ECDHE)
• Certificate management automated (ACM, Key Vault, cert-manager)

Mutual TLS (mTLS)¶

• Both client and server present certificates
• Service mesh implements automatically (Istio, Linkerd)
• Workload identity tied to certificates

JSON Web Tokens (JWT)¶

• Compact tokens for claims
• Header.Payload.Signature (or Encryption)
• Common in OAuth/OIDC
• Best practices:
• Short expiration
• Server-side validation of signature
• Audience and issuer claims checked
• Avoid storing sensitive data in JWT (visible)
• Use asymmetric (RS256) over symmetric (HS256) for distributed systems

Code Signing¶

• Sign binaries, container images, infrastructure code
• Sigstore Cosign, GPG, vendor signing
• Verify before deployment

Encryption Libraries¶

• Use vetted libraries (libsodium, OpenSSL, BoringSSL, Bouncy Castle)
• Cloud KMS SDKs (KMS encrypts/decrypts via API call)
• Avoid implementing crypto from scratch

Identity and Access Management for Cloud Apps¶

Federated Identity¶

• SAML 2.0 - Browser-based SSO, XML, common for enterprise SaaS
• OAuth 2.0 - Authorization framework, delegated access
• OIDC - Authentication on top of OAuth, modern web/mobile
• SCIM - User provisioning automation

OAuth 2.0 Flows¶

Application Identity Patterns¶

• Workload identity federation - Cloud-native; service account auth without static credentials
• Managed identities (Azure) - System or user-assigned
• IAM roles (AWS) - Assumed by EC2/EKS/Lambda
• Service accounts (GCP) - Workload Identity for GKE

Best practices¶

• No hardcoded credentials anywhere
• No long-lived access keys for workloads (use workload identity)
• Short-lived tokens for users (refresh on activity)
• MFA enforced (phishing-resistant: FIDO2/WebAuthn passkeys)
• Conditional access (geo, device posture, risk-based)
• Principle of least privilege at IAM policy level
• Periodic access reviews

Role of API Gateway in IAM¶

• Centralized authentication enforcement
• Token validation
• Rate limiting per identity
• Routing to backend services
• Logging/auditing of access

API Security¶

API Gateway Capabilities¶

• Authentication and authorization
• Schema validation (OpenAPI / JSON Schema)
• Rate limiting and quotas
• Caching
• Routing and request transformation
• Logging and analytics
• WAF integration

API Authentication Methods¶

REST API Security Best Practices¶

• Authenticate every request
• Authorize at object level (BOLA = top API risk)
• Validate input (schema, types, lengths, ranges)
• Output encoding
• Rate limit per identity, not just per IP
• Version APIs (deprecation gracefully)
• Use HTTPS only, HSTS
• CORS carefully (allowlist origins)
• Hide internal errors (no stack traces in responses)
• Log access without sensitive data
• Inventory all APIs (shadow APIs are risky)
• API gateway in front for control

GraphQL Security¶

• Query depth and complexity limits (prevent DoS)
• Introspection disabled in production
• Authorization at field level
• Avoid exposing sensitive types

gRPC Security¶

• TLS or mTLS by default
• Authentication via metadata or interceptors
• Authorization via interceptors

Secrets Management¶

Best practices¶

• Vault all secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
• Workload identity for retrieval (no long-lived secrets to access secret manager)
• Rotation (automatic where supported)
• Audit logging of secret access
• No secrets in source code, configuration files, environment variables (when avoidable), CI/CD logs

Secret scanning¶

• TruffleHog, Gitleaks, GitHub Advanced Security secret scanning
• Pre-commit hooks (gitleaks, detect-secrets)
• CI/CD gates

Verification and Validation¶

Pre-deployment¶

• SAST (source code review tools)
• SCA (dependency analysis)
• IaC scanning
• Container image scanning
• Manual code review for high-risk changes
• Threat modeling

Pre-production / staging¶

• DAST (running app testing)
• Penetration test before major releases
• Synthetic transactions
• Performance and load testing

Production¶

• RASP (runtime app self-protection)
• WAF
• API gateway controls
• Continuous monitoring (logs, metrics, traces)
• Anomaly detection

Functional Validation¶

• Unit tests (with security test cases)
• Integration tests
• End-to-end tests
• Misuse case testing (negative cases)

Application Architecture Considerations¶

Multi-Tenancy in SaaS Applications¶

• Logical isolation (tenant_id in every query)
• Database isolation: row-level security, schema-per-tenant, or DB-per-tenant
• Identity isolation: tenant-scoped tokens
• Encryption: optional per-tenant keys for sensitive customers
• Pen testing for cross-tenant attack paths

Stateless Design¶

• Cloud-native principle
• Session state externalized (Redis, database)
• Enables horizontal scaling
• Security: protect external state stores

Idempotency¶

• Operations safely repeatable
• Important for distributed systems
• Implement via idempotency keys

Container Application Security¶

(Detailed in Domain 3 also)

• Image scanning
• Image signing
• Pod Security Standards
• Network policies
• Workload identity
• Runtime protection
• Admission controls

Common Exam Pitfalls¶

• Treating API key as MFA-equivalent (it isn't)
• Forgetting BOLA as the #1 API risk
• Choosing OAuth alone for authentication (it's authorization)
• Hardcoding secrets (always wrong)
• Not validating event sources in event-driven architectures
• Skipping IaC security scanning
• Forgetting that managed services still need customer-side IAM and config
• Picking signed-URL approach when service principal would be more durable

Quick Reference: Auth Decision¶