CCSK · Domain 8
Related Technologies and Strategies
About 10% of the exam
The Cloud Controls Matrix
- Control matrix
- a control framework built for cloud
- Identity domain
- provisioning and privileged access
- Virtualization domain
- tenant isolation and hardening
- Cryptography domain
- encryption and key lifecycle
- Change control domain
- baselines and authorized change
- Mappings
- one control satisfies several standards
- Responsibility model
- provider and customer split per control
- Implementation guidance
- how to apply each control
The control matrix gives you a cloud-shaped control set already mapped to the standards your auditor will name
Questionnaire and registry
- The questionnaire turns controls into questions
- Providers publish answers in the registry
- Level one is a self-assessment
- Level two adds an independent audit
- Continuous adds ongoing automated monitoring
- A free listing lowers the barrier
Reading a registry listing
- Check the version and the date
- Look for answers citing inherited controls
- Compare answers between competing vendors
- Unverified answers still carry risk
- Missing responses are themselves a signal
- Use it to shape your questions
Security in the delivery pipeline
- Security tests run in the pipeline
- Fail the build on critical findings
- Developers own the defects they create
- Guardrails beat gates for speed
- Feedback fast enough to act on
- Security as code, reviewed like code
Declared infrastructure
- Declared state reviewed before deployment
- Policy as code checks the template
- Drift detection compares running to declared
- Secrets never committed to the repository
- Shared modules carry hardened defaults
- The pipeline identity is highly privileged
Software supply chain
Artifacts
- Sign every build output
- Record provenance for each artifact
- Store the bill of materials
Dependencies
- Pin versions and verify hashes
- Watch for typosquatted packages
- Mirror upstream into a trusted registry
Build system
- Build machines are production systems
- Isolate build from deploy credentials
- Assurance levels rise with controls
Artificial intelligence risks
Model attacks
- Evasion with small crafted perturbations
- Inversion reconstructs training data
- Extraction clones the model behavior
Data attacks
- Poisoned training data embeds backdoors
- Provenance of datasets stays unclear
- Sensitive records memorized by the model
Application attacks
- Prompt injection overrides the instructions
- Retrieved content is untrusted input
- Agents given more agency than needed
Securing AI workloads
- Separate instructions from retrieved content
- Ground the model in trusted sources
- Scope tool permissions to read only
- Rate limit and monitor query patterns
- Inventory models like any dependency
- Sign model artifacts and record builds
- Use a recognized adversarial taxonomy
Zero trust as a strategy
- Never trust the network location
- Verify identity, device and context
- Authorize each request independently
- Assume breach and limit blast radius
- Telemetry feeds every access decision
- A journey rather than a product
Edge, devices and confidential computing
- Edge shortens latency, widens attack surface
- Constrained devices cannot run agents
- Update paths have to be signed
- Confidential computing protects data in use
- Attestation proves the enclave is genuine
- Quantum readiness starts with crypto inventory
Strategy failures
- Adopting a framework without mapping
- Models deployed with no inventory
- Pipeline treated as non-production
- Zero trust bought as a product
- New technology outside the risk register
Know the order
- Inventory the technology
- Map to controls
- Assess the new risk
- Add guardrails
- Monitor and reassess
New technology gets the same treatment as old technology: inventory it, map it to controls, then govern what remains
Rapid recall: framework terms
- Cloud control framework
- the cloud controls matrix
- Questionnaire built from it
- the assessment questionnaire
- Public assurance registry
- the STAR registry
- Self-assessed listing
- STAR level one
- Independently audited listing
- STAR level two
- Techniques against models
- an adversarial threat taxonomy
- Build integrity levels
- a supply chain assurance framework
- Signed build evidence
- artifact provenance attestation
Reference strip: frameworks, delivery, supply chain, AI, strategy
Frameworks
- Control matrix domains
- Questions derived from controls
- Registry listings and levels
- Mappings to other standards
Delivery
- Security tests in the pipeline
- Policy as code checks
- Drift detection on deployment
- Signed and reproducible builds
Supply chain
- Bill of materials retained
- Pinned and verified dependencies
- Trusted internal registry
- Build systems treated as production
Artificial intelligence
- Poisoning, evasion, inversion, extraction
- Prompt injection through retrieval
- Least agency for tools
- Model inventory and provenance
Strategy
- Zero trust as an approach
- Confidential computing for data in use
- Crypto inventory for quantum readiness
- Reassess as technology shifts
Quick exam traps
- Trap: The control matrix replaces the need for any other framework
- Trap: A self-assessed registry entry has been checked by an auditor
- Trap: Prompt injection is prevented by better system instructions alone
- Trap: A model that never saw a record cannot reveal it
- Trap: Zero trust is a product you deploy at the perimeter
- Trap: Build pipelines are development systems and need lighter controls
- Trap: Confidential computing removes the need to encrypt at rest
cybercertprep.com · original revision sheet written from the public body of knowledge