Planning and Implementing Security Controls

What it is

Security controls treat the risks found in risk analysis. For cloud infrastructure the outline groups them into four families: physical and environmental protection, system, storage and communication protection, identification, authentication and authorization, and audit mechanisms.

Each family is split between provider and customer according to the service category. Planning means choosing controls, assigning ownership and confirming they work.

How it works

Choosing controls from frameworks

NIST SP 800-53 Rev 5 provides a catalogue of controls grouped into families such as AC (access control), AU (audit and accountability), PE (physical and environmental protection), SC (system and communications protection) and IA (identification and authentication). The CSA Cloud Controls Matrix maps cloud controls to these and other frameworks and shows which party typically owns each.

Controls are also classed by function: preventive, detective, corrective, deterrent, compensating and recovery.

Physical and environmental protection

For on-premises and private cloud, the organization runs these controls; in public cloud the provider does and the customer verifies them through audit reports.

System, storage and communication protection

Defense in depth matters most here: a misconfigured storage policy should still leave data encrypted, and a compromised instance should still be blocked from other subnets.

Identification, authentication and authorization

• Identification: every user, service and workload has a unique identity, preferably from a central identity provider through federation.
• Authentication: MFA for all human users, phishing resistant methods for administrators, short lived credentials for workloads.
• Authorization: least privilege roles, separation of duties, policy based conditions such as source network, time or device, and regular access reviews.

Cloud authorization is policy driven. A role policy might allow a backup service to read a bucket but never delete from it:

{
  "Statement": [
    { "Effect": "Allow", "Action": ["storage:GetObject", "storage:ListBucket"], "Resource": "backup-bucket/*" },
    { "Effect": "Deny", "Action": "storage:DeleteObject", "Resource": "backup-bucket/*" }
  ]
}

The names are generic; explicit deny overriding allow is a common pattern across providers.

Audit mechanisms

In SaaS, customers usually get only the audit logs the provider exposes. Contracts should state which logs are available, in what format and for how long.

Verifying controls

Controls are verified through configuration monitoring (cloud security posture management tools compare settings with a baseline), vulnerability scans, penetration tests where the provider permits them, internal audit and the provider's third-party reports.

A worked example

A healthcare startup runs on IaaS. Its risk register lists ransomware deleting backups, data exposure through storage, and stolen admin credentials.

It plans controls across the families: backup storage in a separate account with deny delete policies and object lock; encryption at rest with customer managed keys; MFA for all administrators with no long lived keys; management plane and storage access logs sent to a security account and correlated in a SIEM. Physical controls are covered by reviewing the provider's SOC 2 report.

How the exam asks about this

• "A customer needs evidence of the physical controls at a public cloud provider's data centers. What should it use?" The provider's independent audit report, such as SOC 2.
• "Packet capture is not available on a shared cloud network. What is the BEST alternative?" Flow logs or the provider's traffic mirroring feature.
• "Which control BEST prevents an attacker who compromised one instance from reaching database servers?" Network segmentation with restrictive security group rules.