8.1 Security Controls Implementation (Domain 3.4)

Security Controls Implementation

Domain 3.4 asks you to plan and implement security controls for cloud platforms and infrastructure. After Domain 3.1–3.3 establish components, data-center design, and risk analysis, 3.4 is where those risks become concrete control selections. The outline groups four control families: physical and environmental protection (on-premises), system, storage, and communication protection, identification, authentication, and authorization in cloud environments, and audit mechanisms (log collection, correlation, packet capture).

Why Controls Implementation Matters

Cloud does not eliminate the classic control catalog; it redistributes who operates which control and changes the mechanisms available. A public IaaS tenant still needs host hardening and network security groups. A private cloud or colocation edge still needs cages, UPS, and HVAC. A SaaS-heavy enterprise still needs identity federation, MFA, and tenant audit logs. Exam stems often hide the service model: the correct control for “who patches the guest OS?” differs from “who validates the data-center fire suppression system?”

Shared responsibility reminder: CSPs typically deliver physical facility controls for multi-tenant public cloud regions, baseline isolation of the hypervisor and fabric, and platform logging services. Customers implement guest OS and application hardening on IaaS, configure storage encryption and network isolation inside their tenancy, design identity and authorization policy, and turn on, export, and monitor the audit trails that cover their assets. Accountability for risk acceptance remains with the customer organization even when a control is operated by the CSP.

Physical and Environmental Protection (On-Premises)

Even in a “cloud-first” program, physical and environmental protection remains exam-relevant for private clouds, colocation, edge sites, branch connectivity, backup media vaults, and hybrid management planes. Domain 3.2 already covered data-center design; Domain 3.4 emphasizes controls in operation—the protective measures you plan, implement, and verify.

On-premises focus in cloud programs: Treat hybrid interconnects (MPLS/VPN termination rooms), private cloud racks, and “break glass” console rooms as high-value physical targets. An attacker with physical access to a hypervisor console or backup appliance can bypass many logical IAM controls. Inventory where management-plane devices and HSM/TPM hardware live and apply stricter physical controls there.

Public cloud physical layer: Customers rarely tour every region, but evaluation still includes provider facility assurance (certifications, SOC reports, contractual physical security claims). Do not invent access rights to CSP cages; do require evidence that physical and environmental controls meet your risk appetite for the data classes you place in that region.

Exam traps: (1) Applying “badge the public cloud rack yourself” as a customer operational task for multi-tenant public IaaS. (2) Ignoring physical risk at the customer-owned edge while encrypting everything in the region. (3) Forgetting that environmental failures (cooling loss, power events) are availability incidents that BC/DR and facility controls both address.

System, Storage, and Communication Protection

These three pillars form the logical defense-in-depth layer for cloud platforms and infrastructure.

System Protection

System protection covers compute instances, containers, serverless execution environments, hypervisors (where you operate them), and management hosts.

In IaaS, the customer typically owns guest OS hardening. In PaaS/SaaS, system protection shifts toward correct platform configuration, runtime policies, and avoiding insecure dependencies rather than patching the underlying host.

Storage Protection

Storage protection spans object, block, file, and database storage—ephemeral and persistent.

Threats differ by storage type: object stores suffer misconfigured public ACLs and excessive identity grants; block volumes suffer snapshot sprawl and attached-to-wrong-VM risks; file shares suffer broad SMB/NFS exposure. Map controls to the storage type in the stem.

Communication Protection

Communication protection secures network paths among users, workloads, storage, and administrative planes.

Management plane communication deserves special emphasis: API endpoints, console access, and orchestration channels are high-value. Prefer private connectivity options, conditional access, MFA, and continuous monitoring of management API calls. A perfectly segmented data plane with an open management API is not a secure design.

Integrated example: A payment API on IaaS uses hardened golden images, customer-managed keys for data volumes, private subnets with no public IPs, a load balancer terminating TLS, security groups allowing only the load balancer and bastion, and storage accessible only via private endpoints. That single design touches system, storage, and communication protection together—the exam often rewards the answer that completes the weakest of the three layers in the scenario.

Identification, Authentication, and Authorization in Cloud Environments

Cloud identity is frequently the primary attack surface. Domain 3.4 expects you to distinguish identification, authentication, and authorization, then apply them to both human and non-human (workload, service, pipeline) principals.

Identification Practices

• Prefer unique, named identities for humans; ban shared admin accounts for day-to-day work.
• Inventory service principals, managed identities, API keys, and robots with the same rigor as users.
• Use a consistent identity lifecycle: joiners, movers, leavers; disable stale principals automatically.
• Align identity sources: enterprise directory → cloud IdP → workload identities with clear trust boundaries.

Authentication Practices

Authorization Practices

• Least privilege by default; start from deny and grant minimum actions and resources.
• Prefer role-based models with attribute or condition constraints (time, IP, MFA strength, resource tags).
• Separate duty planes: billing, identity admin, network admin, and application deploy roles should not collapse into one super-admin for everyone.
• Review resource policies (bucket policies, key policies) that can grant access outside identity-role grants.
• Automate access reviews and remove standing privilege where just-in-time elevation is available.
• Treat CI/CD deploy roles as highly privileged identities—constrain environments, require approvals, and log every use.

Common cloud IAM failures the exam likes: long-lived access keys in code repositories; wildcard * actions on production accounts; public anonymous access to storage “for testing”; disabled MFA on root/owner accounts; federated login without group claim mapping that recreates over-broad roles; service accounts with owner rights used by every microservice.

AuthZ vs network controls: Security groups are not a substitute for application and IAM authorization. Network segmentation reduces exposure; authorization prevents an authenticated-but-unauthorized principal from reading sensitive data once on the network. Defense in depth uses both.

Audit Mechanisms: Log Collection, Correlation, and Packet Capture

Audit mechanisms close the control loop: without evidence of activity, physical locks, hardened systems, and IAM policies cannot be verified or investigated. Domain 3.4 highlights three mechanisms: log collection, correlation, and packet capture.

Log Collection

Collection design rules: enable the right trails (many services default to incomplete data-plane logging); centralize into a durable store; synchronize time; capture both allow and deny; alert on changes to logging configuration itself; retain according to investigation and compliance needs while applying privacy minimization where logs hold personal data.

Segregation: Producers should be append-only to the archive. Compromised production admins must not be able to silently wipe the only copy of evidence. Prefer a dedicated logging account or project with separate administrators.

Correlation

Correlation links events across sources into meaningful incidents. A single failed login is noise; the same identity succeeding from a new country, then disabling a storage logging trail, then bulk-reading objects is a story. Techniques include:

• Time-window joins on identity, session ID, and resource ID
• Baseline and anomaly detection (volume, geography, time of day)
• Enrichment with asset inventory, classification tags, and threat intelligence
• SIEM or cloud-native analytics rules mapped to response playbooks

Correlation without quality collection fails; collection without correlation fails at human scale. CCSP expects both.

Packet Capture

Packet capture (full or filtered) records network traffic for deep investigation, protocol analysis, and sometimes compliance evidence. In cloud:

Flow logs and metadata are continuous, lighter-weight relatives of packet capture. Use them for always-on visibility; escalate to packet capture for deep dives. Do not claim you can mirror another tenant’s packets on a public multi-tenant cloud.

Exam Approach and Common Traps

1. Identify the layer (physical, system, storage, network, identity, audit).
2. Identify the service model and who can implement the control.
3. Prefer defense in depth answers that fix the specific failure mode in the stem.
4. For identity stems, separate weak AuthN from weak AuthZ.
5. For audit stems, check whether evidence is collected, protected, and correlated—not only “logging exists.”

Common traps:

• Assuming customers operate public cloud facility HVAC and cages day to day.
• Encrypting storage while leaving public network exposure and anonymous access.
• Equating VPN presence with strong authorization.
• Storing mutable security logs under the same privilege boundary as production root.
• Continuous full packet capture of everything as the default “best” answer without privacy, cost, or scope constraints.