CCSP · Domain 4
Cloud Application Security
About 17% of the exam
Secure SDLC in the cloud
- Requirements
- Design
- Develop
- Test
- Deploy
- Operate and maintain
- Dispose
- Requirements
- security and compliance needs captured early
- Design
- threat model, architecture review
- Develop
- secure coding, peer review, SAST
- Test
- DAST, IAST, penetration, abuse cases
- Deploy
- pipeline gates, signed artifacts, IaC
- Operate
- RASP, WAF, logging, patching
Shift left: a flaw found in requirements costs a fraction of one found in production
Training and awareness
- Developers assume on-premises trust boundaries
- Cloud APIs replace the network perimeter
- Multitenancy changes isolation assumptions
- Encryption and key handling are code concerns
- Provider services are still your responsibility
- Common pitfalls: hardcoded secrets, open defaults
- Awareness for developers, role training for leads
Threat modeling
- STRIDE
- spoofing, tampering, repudiation, disclosure, DoS, elevation
- DREAD
- damage, reproducibility, exploitability, affected, discoverability
- PASTA
- seven stages, risk-centric, business aligned
- ATASM
- architecture, threats, attack surfaces, mitigations
- Attack trees
- goal at root, paths below
- Data flow diagram
- trust boundaries drawn explicitly
Model at design; every later phase inherits the threats you named
OWASP and common vulnerabilities
Access and identity
- Broken access control tops the list
- Identification and authentication failures
- Username enumeration through error messages
- Timing differences leak user existence
- JWT none algorithm forges tokens
Input and injection
- Injection: SQL, command, LDAP, NoSQL
- Cross-site scripting, defeated by CSP
- SSRF reaches internal metadata endpoints
- Insecure deserialization of untrusted objects
- Race conditions need atomic operations
Design and operations
- Insecure design, missing threat model
- Security misconfiguration and defaults
- Vulnerable and outdated components
- Cryptographic failures, weak or absent
- Logging and monitoring failures
Secure coding controls
- Validate input server side, always
- Parameterized queries, never string building
- Output encoding for the context
- Content Security Policy without unsafe-inline
- Salted slow hashes: bcrypt, Argon2
- Generic errors, detailed logs
- Allowlists for outbound requests
- Fail securely, deny by default
Testing methods
- SAST
- source code, early, white box
- DAST
- running app, black box, staging
- IAST
- agent inside the running app
- RASP
- runtime self-protection in production
- SCA
- third-party components and licenses
- Fuzzing
- malformed inputs, crash discovery
- Penetration test
- human adversary, scoped, authorized
- Abuse case testing
- misuse the feature on purpose
API security
- REST and SOAP: both need authentication
- API gateway: authenticate, authorize, throttle
- Rate limiting, adaptive to behavior
- Object-level authorization on every call
- Schema validation of requests
- TLS everywhere, mutual TLS for services
- Inventory APIs, retire shadow endpoints
- Version and deprecate deliberately
Identity and secrets in apps
- OAuth 2.0 delegates, OIDC authenticates
- PKCE for mobile and single-page apps
- Short-lived tokens with narrow scope
- JWT: verify signature, expiry, audience
- Secrets from a managed vault, rotated
- Never in code, images or repositories
- Workload identity instead of static keys
- SAML assertions time-bounded, replay rejected
A secret in a container image is public to anyone who can pull the image
Software supply chain
- SBOM lists every component
- Pin dependencies, verify integrity
- Private registries beat dependency confusion
- Signed commits, branch protection
- Scan base images, dependencies, runtime
- Multi-stage builds drop build tools
- Trusted registries only
- Open source needs the same scrutiny
Application architecture
- WAF in front of web tier
- API gateway as choke point
- Service mesh gives mutual TLS
- Sandbox untrusted code and uploads
- Application virtualization and containers
- Message queues need per-consumer authorization
- Circuit breakers for third-party dependencies
- XML and JSON gateways validate structure
Verified secure software
- ISO/IEC 27034
- application security controls, ONF and ANF
- FIPS 140-3
- validated cryptographic modules
- Common Criteria
- evaluation assurance levels
- OWASP ASVS
- verification requirements by level
- OWASP SAMM
- maturity model for programs
- Approved APIs
- vetted, documented, supported
- Code signing
- authenticity and integrity of releases
Cloud-native delivery practices
- DevSecOps: SAST, DAST, SCA in pipeline
- Infrastructure as code, scanned before deploy
- Immutable deployments eliminate drift
- Feature flags need lifecycle management
- Chaos engineering includes security failures
- GitOps repository is a critical asset
- Blue-green for fast rollback
- Least privilege for pipeline identities
Rapid recall: which test when
- Before merge
- SAST and code review
- Dependencies
- SCA against known vulnerabilities
- Running in staging
- DAST, black box
- Inside the app under test
- IAST agent
- In production
- RASP, WAF, monitoring
- Human adversary
- penetration test
- Unknown inputs
- fuzzing for crashes
- Container images
- scan base, layers, runtime
Reference strip: lifecycle, threats, tests, controls
SDLC
- Requirements, design, develop, test
- Deploy, operate, dispose
- Threat model at design
- Security gates in the pipeline
Threat models
- STRIDE categories, DREAD scoring
- PASTA, ATASM, attack trees
- Trust boundaries on data flows
Tests
- SAST, DAST, IAST, RASP
- SCA, fuzzing, penetration
- Abuse cases and misuse cases
Controls
- Input validation, parameterized queries
- CSP, output encoding, secure headers
- Gateway, WAF, service mesh, sandbox
- Vaulted secrets, workload identity
Standards
- OWASP Top 10, ASVS, SAMM
- ISO 27034, FIPS 140-3
- Common Criteria EALs
- SBOM and signed artifacts
Quick exam traps
- Trap: DAST finds flaws in source code before it runs
- Trap: OAuth 2.0 is an authentication protocol
- Trap: Client-side validation is sufficient input validation
- Trap: A WAF replaces secure coding
- Trap: Storing JWTs in browser local storage is safe
- Trap: PKCE is only needed when a client secret exists
- Trap: Secrets in a private container image are protected
- Trap: Threat modeling belongs in the testing phase
cybercertprep.com · original revision sheet written from the public body of knowledge