1. Security concepts relevant to cloud computing
1.1. Cryptography & key management
1.1.1. Using symmetric, asymmetric or envelope encryption plus lifecycle controls (creation, rotation, revocation) to protect data in transit, at rest and in memory.
1.1.1.1. Cloud customers must choose between provider-managed (KMS, HSM-as-a-service) or customer-managed keys and understand concepts like BYOK, split-knowledge, geo-pinning of keys, and FIPS‐140 compliance
1.2. Identity & access control
1.2.1. Policies and mechanisms that authenticate who/what (users, workloads, services) and authorize what they can do.
1.2.1.1. Expect questions on federated identity (SAML/OIDC), least-privilege IAM roles, privilege escalation risks, and how IAM differs across SaaS / PaaS / IaaS
1.3. Data & media sanitization
1.3.1. Securely erasing data from disks, snapshots or backups by overwriting, cryptographic erase or physical destruction.
1.3.1.1. In multi-tenant clouds you rarely destroy the hardware, so CCSP focuses on crypto-shred, retention policies, and verifying provider end-of-life processes.
1.4. Network security
1.4.1. Virtual firewalls, security groups, micro-segmentation, traffic inspection and zero-trust routing to protect east-west & north-south flows.
1.4.1.1. Know constructs such as NSGs / VPC security groups, geofencing, WAF, DDoS shields, and how SDN enables policy-as-code
1.5. Virtualization security
1.5.1. Hardening the hypervisor, securing containers, serverless runtimes and short-lived (“ephemeral”) compute instances
1.5.1.1. Topics include VM escape, snapshot tampering, container image signing, runtime quarantine, and minimal-attack-surface serverless functions
1.6. Common threats
1.6.1. Canonical cloud attack vectors: misconfigurations, insecure APIs, account hijacking, data loss, DoS, supply-chain issues.
1.6.1.1. CCSP expects you to map threats to controls—e.g., API abuse → rate limiting + auth, misconfiguration → CSPM, account hijack → MFA & key rotation
1.7. Security hygiene
1.7.1. Continuous patching, baseline hardening, configuration drift management, and automated compliance checks
1.7.1.1. Emphasises “immutable infrastructure” & DevSecOps pipelines where images are rebuilt, not patched in place; CIS benchmarks, Golden AMIs, etc.
2. Design Principles of Secure Cloud Computing
2.1. Cloud-secure data lifecycle
2.1.1. Protect data from create → store → use → share → archive → destroy.
2.1.1.1. Apply classification, encryption, DLP and crypto-erase at every state; map each state to controls provided by the CSP.
2.2. Cloud-based BC/DR
2.2.1. Architect resilience so workloads survive site, zone or provider failure.
2.2.1.1. Use multi-AZ / multi-region replication, IaC for “push-button” recovery, RTO/RPO in SLAs, and test fail-overs regularly
2.3. Business Impact Analysis (BIA)
2.3.1. Quantify how outages hurt revenue, reputation and safety.
2.3.1.1. Justify cloud spend (ROI), set tiered recovery objectives, and choose the right deployment model (pilot-light vs. active-active).
2.4. Functional security requirements
2.4.1. Non-functional needs—portability, interoperability, vendor lock-in limits.
2.4.1.1. Demand open APIs, data-export formats, encrypted backups you can move to another CSP; reference ISO 19941 guidance
2.5. Responsibilities by service model
2.5.1. Know who secures what in SaaS, PaaS, IaaS.
2.5.1.1. In SaaS the provider owns everything except data & identity; in IaaS the customer secures OS, middleware, data; exam questions often hinge on this split
2.6. Cloud design patterns
2.6.1. Prescriptive blueprints such as SANS 12 principles, AWS Well-Architected, CSA Enterprise Architecture.
2.6.1.1. Recognise patterns like least privilege, defense-in-depth, fault isolation, secure by default and where to apply them in diagrams
2.7. DevOps / DevSecOps security
2.7.1. Embed security controls into CI/CD pipelines and immutable infrastructure
2.7.1.1. Use IaC scanning, image signing, automated testing, and shift-left practices so every commit is security-checked before deployment
3. Evaluate Cloud Service Providers
3.1. Standards-based security controls
3.1.1. ISO/IEC 27017 – code-of-practice for information-security controls in cloud; ISO/IEC 27018 – protection of PII in public cloud.
3.1.1.1. Shows the provider’s management system and technical controls align with internationally accepted cloud-specific best practice
3.2. Industry/sector compliance
3.2.1. PCI-DSS (payment card data), HIPAA/HITECH (PHI), FedRAMP (US federal workloads), GDPR readiness, CSA STAR attestation.
3.2.1.1. Confirms the CSP can inherit or extend the compliance posture you need, reducing your control-implementation burden.
3.3. System / sub-system product certifications
3.3.1. Common Criteria (CC) EAL1-EAL7 evaluations for cryptographic modules, hypervisors, HSMs; FIPS 140-2/3 validation for crypto modules.
3.3.1.1. Gives objective assurance that the building-block components inside the CSP (e.g., KMS, VPN gateways) meet rigorous government-recognised security levels
3.4. Assurance reporting
3.4.1. SOC 1 / SOC 2 Type II, ISO/IEC 27001 certificate, penetration-test summaries
3.4.1.1. Provides audit evidence you can map to your own control framework and due-diligence files.
3.5. Contractual controls & SLAs
3.5.1. RPO/RTO, uptime %, support response times, breach-notification windows, right-to-audit clauses, data-location guarantees.
3.5.1.1. Turns “paper compliance” into legally enforceable commitments; directly addresses CCSP’s functional security requirements (portability, reversibility, lock-in).
3.6. Operational transparency
3.6.1. Security-incident response processes, change-management cadence, patch SLAs, vulnerability-scan cadence, “trust center” portals.
3.6.1.1. You must monitor provider hygiene continuously (CCSP Domain 5) — look for real-time dashboards or API feeds.
3.7. Financial & viability checks
3.7.1. Credit rating, market share, roadmap, mergers/acquisitions, data-center investment plans.
3.7.1.1. A secure but insolvent provider is still a risk; CCSP stresses vendor lock-in and exit planning.
4. Cloud-computing definitions
4.1. NIST: on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal effort.
5. Roles and responsibilities
5.1. Cloud Service Customer
5.1.1. The organisation that uses cloud services to run its workloads and store its data.
5.1.1.1. • Classify & protect its data • Configure services securely (IAM, encryption, logging) • Monitor usage & pay bills • Execute BIA / BC-DR planning • Ensure compliance with laws that apply to the data it owns
5.2. Cloud Service Provider
5.2.1. The entity that owns and operates the cloud infrastructure and delivers services (IaaS, PaaS, SaaS) to customers
5.2.1.1. • Secure physical & virtual infrastructure • Provide multi-tenancy isolation & availability SLAs • Offer compliant services (ISO 27017 / PCI DSS, etc.) • Supply logs, evidence, breach notifications • Maintain resilient operations & incident response
5.3. Cloud Service Partner
5.3.1. A third-party that supports adoption or operation of the service (consultant, integrator, auditor, MSP, developer).
5.3.1.1. • Design & integrate secure architectures • Perform independent security audits or assessments • Assist with migration, DevOps, automation • Provide specialised managed-security capabilities
5.4. Cloud Service Broker
5.4.1. Intermediary that aggregates, customises, or arbitrates services between provider and customer.
5.4.1.1. • Enforce customer-specific policies (e.g., CASB) • Negotiate SLAs & pricing • Provide unified billing, identity, or encryption gateways • Monitor service performance & compliance on behalf of customer
5.5. Regulator / Certifying Body
5.5.1. Government agency or industry authority that sets and enforces legal or sector-specific requirements
5.5.1.1. • Publish statutes, regulations, or frameworks (GDPR, HIPAA, PCI-DSS) • Conduct audits, issue compliance certifications or fines • Define breach-notification and data-residency obligations
6. Key Cloud-Computing Characteristics
6.1. On-demand self-service
6.1.1. Customers can provision or de-provision compute, storage, or apps automatically without human interaction.
6.1.1.1. Security controls (e.g., IAM, tagging, guardrails) must be automated too, because humans aren’t in the request loop.
6.2. Broad network access
6.2.1. Services are reachable over standard networks and accessible via heterogeneous clients (laptops, phones, APIs).
6.2.1.1. Increases attack surface → requires strong transport encryption, API security, and zero-trust network assumptions
6.3. Resource pooling
6.3.1. The provider’s physical/virtual resources are shared across customers and dynamically assigned as needed
6.3.1.1. Multi-tenant isolation, hypervisor hardening, and noisy-neighbor controls are core exam themes.
6.4. Rapid elasticity & scalability
6.4.1. Capacity can expand or shrink automatically, appearing unlimited to the consumer.
6.4.1.1. Security tools (e.g., logging, monitoring, key management) must scale at the same pace and support ephemeral assets.
6.5. Measured service
6.5.1. Usage is metered, monitored, and reported—enabling pay-as-you-go billing and capacity planning
6.5.1.1. Logs and billing data become valuable forensic/oversight artifacts; cost anomalies often flag security incidents.
6.6. Multi-tenancy (implied by pooling)
6.6.1. Multiple customers share the same infrastructure while remaining logically isolated.
6.6.1.1. Drives exam topics on data segregation, encryption, and secure VM/container architectures
7. Cloud “Building-Block” Technologies
7.1. Virtualization
7.1.1. A hypervisor abstracts physical CPU, memory and I/O so multiple isolated VMs or containers can run on one host.
7.1.1.1. Enables multi-tenancy, elastic scaling and rapid provisioning—the heart of IaaS.
7.1.1.1.1. VM escape threats, hypervisor hardening, container isolation, snapshot / image security.
7.2. Storage
7.2.1. Pooled disk or object systems that can be carved out on demand and accessed over the network.
7.2.1.1. Provides endlessly “elastic” capacity and durability tiers (block, file, object) for apps & backups.
7.2.1.1.1. Encryption at rest, lifecycle/retention, replication across regions, secure deletion, performance tiers.
7.3. Networking (SDN)
7.3.1. Software-defined switches, routers and firewalls that are programmable via APIs.
7.3.1.1. Allows rapid creation of virtual networks, micro-segmentation, load balancers, and global any-cast delivery
7.3.1.1.1. Zero-trust design, security groups/NSGs, VPC peering, routing isolation, DDoS protection.
7.4. Databases
7.4.1. Managed relational, NoSQL and analytics engines delivered “as-a-service.”
7.4.1.1. Give apps instantly scalable, highly available data layers without admin overhead.
7.4.1.1.1. Encryption keys, IAM roles, parameter-store secrets, backup/restore, multi-AZ replication, query auditing.
7.5. Orchestration / Automation
7.5.1. Tools (e.g., Kubernetes, Terraform, CloudFormation) that declaratively build and manage cloud stacks.
7.5.1.1. Turns infrastructure into code so environments scale and heal automatically.
7.5.1.1.1. DevSecOps shift-left, mutable vs. immutable deployments, continuous compliance, policy-as-code (OPA).
8. cloud reference architecture
8.1. Cloud-computing activities
8.1.1. End-to-end actions that happen in a cloud life-cycle: service development, provisioning, subscription, consumption, monitoring, and decommissioning.
8.1.1.1. Gives you a process view—so you can map security controls (e.g., code scanning during development, IAM during provisioning, logging during monitoring).
8.2. Cloud-service capability types (application, platform, infrastructure)
8.2.1. Granular resources customers actually use—e.g., message queues (application), runtimes (platform), or VM instances (infrastructure)
8.2.1.1. Helps you decide which security controls move to the provider: the deeper you go (IaaS→PaaS→SaaS) the more you inherit
8.3. Cloud-service categories (SaaS, PaaS, IaaS)
8.3.1. Bundles of capability types packaged into the familiar “as-a-service” models.
8.3.1.1. Foundation of the shared-responsibility model questions—know who secures OS, middleware, data, etc., in each category.
8.4. Cloud-deployment models (public, private, hybrid, community, multi-cloud)
8.4.1. Where the service physically and logically runs and who may access it.
8.4.1.1. Affects compliance scope and network architecture; the exam loves scenarios where data sovereignty dictates the model.
8.5. Cloud shared considerations (interoperability, portability, reversibility, availability, security, privacy, resiliency, performance, governance, maintenance & versioning, SLAs, auditability, regulatory, outsourcing)
8.5.1. Cross-cutting non-functional attributes that must be baked into designs no matter which service model or provider you pick.
8.5.1.1. Each item translates to a security or contractual control—e.g., portability → data-export format, auditability → API log access
8.6. Impact of related technologies (AI/ML, blockchain, IoT, containers, edge, confidential computing, DevSecOps, quantum)
8.6.1. Emerging tech that either consumes cloud or changes how cloud is built and secured.
8.6.1.1. You’re expected to know new threat surfaces—e.g., side-channels in confidential computing, container escape in Kubernetes.