Chapter 9 — Cloud and container security: tools and methods
Lesson map
Lesson 09 published. Map, example, EX033.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Methods"]
N2["9.2 Benchmarks"]
N3["9.3 Fairway's policy"]
N4["9.4 Frequency"]
N5["9.5 Reviewing tools"]
N6["Comparing tools"]
N7["Starting small"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX033"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 Methods"]
N2["9.2 Benchmarks"]
N3["9.3 Fairway's policy"]
N4["9.4 Frequency"]
N5["9.5 Reviewing tools"]
N6["Comparing tools"]
N7["Starting small"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX033"]
[Learning outcomes]
|
v
[9.1 Methods]
|
v
[9.2 Benchmarks]
|
v
[9.3 Fairway's policy]
|
v
[9.4 Frequency]
|
v
[9.5 Reviewing tools]
|
v
[Comparing tools]
|
v
[Starting small]
|
v
[Worked example] --> [Exercise EX033]
Learning outcomes
You will (1) choose methods for checking cloud configuration; (2) use benchmarks; (3) plan regular checks.
9.1 Methods
Settings can be checked by reading exports, by provider policy tools, or by scanners. Tomás starts with exports and a simple script. Reading exports suits Fairway's size: four buckets and a single cluster can be checked with a short script that anyone on the team can read. Provider policy tools add rules Tomás had not thought of, and scanners cover more ground but produce more output to review. Starting simple means the team understands every result before adding tools.
9.2 Benchmarks
The CIS Benchmarks for cloud providers include storage recommendations such as blocking public access and enabling logging. CSA CCM v4 lists matching controls. Benchmarks give Fairway an outside reference, so the policy is not just Grace's and Tomás's opinion. Mapping each rule to a CIS recommendation and a CCM area lets auditors and the insurer see it matches common practice. Tomás reads the benchmark text himself rather than relying on summaries, since recommendations change between versions. The mapping is stored with the policy so auditors can follow it without asking Tomás.
9.3 Fairway's policy
Grace and Tomás write a storage policy with four rules: block public access, encrypt, version and log access, except for the assets bucket's public read. Each rule answers a gap from March or from verification: public access caused the incident, encryption and versioning were missing on driver-photos, and logging made the timeline possible. The single exception, public read for assets, is written into the policy with its reason, so the check can treat it as approved rather than as a failure.
9.4 Frequency
Checks run daily; changes between runs are caught by the alert from chapter 14. Daily checks catch slow drift, such as a new bucket created without logging, while the alert catches the dangerous change within minutes. A public policy set at 16:41 would have waited until the next morning's check; the alert closes that window. Each daily run saves its output, so trends over weeks are visible. The daily run is scheduled early in the morning, before most developers start making changes. If the run itself fails, it posts a failure message rather than staying silent, so a broken check is noticed the same day.
9.5 Reviewing tools
They test a provider tool but keep their script, because it is simple and understood. Their test on a staging account found the provider tool matched the script's findings and suggested two more settings, including object ownership controls. Grace keeps the script as the main check because every team member can read and change it. The tool's extra findings become candidate rules for the next policy review. Their test notes record what each method found, how long it took and how readable the output was. Those notes help the next policy review decide whether the provider tool should take on more of the checking.
Comparing tools
Tomás tests the provider's policy tool on a staging account. It finds the same issues as his script plus two settings he had not considered, such as object ownership controls. He adds these to the policy as future rules. The comparison shows that a simple script and a richer tool can complement each other: the script is easy to explain, and the tool reveals what the script misses.
Starting small
Grace prefers four well-enforced rules over forty ignored ones.
Evidence from checks
Each daily run saves its output with a date, building a history auditors can review.
Budget
The script approach costs only staff time.
Review cycle
The policy is reviewed yearly.
Worked example
Tomás maps each of the four rules to a benchmark recommendation and a CCM v4 control area, which helps Grace explain the policy to auditors.
Synthetic case. Synthetic.
Errors and limits
A benchmark is a starting point; adapt it to the system.
Exercises
- EX033 — Methods. Name three ways to check settings. Rubric: 3 = exports, provider tools, scanners; 2 = two; 1 = one; 0 = none.
- EX034 — Policy rules. List the four storage rules. Rubric: 3 = block public, encrypt, version, log; 2 = three; 1 = two; 0 = none.
- EX035 — Exception. Which exception applies? Rubric: 3 = assets bucket public read; 2 = partial; 1 = vague; 0 = none.
- EX036 — Mapping value. Why map rules to benchmarks? Rubric: 3 = explain to auditors; 2 = partial; 1 = vague; 0 = none.
Synthesis
Write a short policy grounded in benchmarks and check it often.
Continue studying — chapter 09 of 18
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →