OpenCyber AcademyLesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Benchmarks"]
N2["Lab — Lab — account checklist"]
N3["26.2 Lab result"]
N4["26.3 Interpreting"]
N5["26.4 Prioritising"]
N6["26.5 Tracking"]
N7["Adapting the benchmark"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Benchmarks"]
N2["Lab — Lab — account checklist"]
N3["26.2 Lab result"]
N4["26.3 Interpreting"]
N5["26.4 Prioritising"]
N6["26.5 Tracking"]
N7["Adapting the benchmark"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Benchmarks]
|
v
[Lab — Lab — account checklist]
|
v
[26.2 Lab result]
|
v
[26.3 Interpreting]
|
v
[26.4 Prioritising]
|
v
[26.5 Tracking]
|
v
[Adapting the benchmark]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) assess cloud accounts against a benchmark-style checklist; (2) interpret pass and fail results; (3) prioritise by risk; (4) track improvement.
26.1 Benchmarks
The CIS Benchmarks provide consensus configuration recommendations for cloud accounts and Kubernetes. Samuel uses a small subset adapted for Westmere, keeping each item's reason.
Adapting means choosing the items that apply to Westmere's services and leaving out those that do not, while keeping each item's original reasoning. Samuel's subset has a column for the benchmark reference, so auditors can see where each check came from and how it was interpreted. Items he leaves out are listed with the reason. Reviewers can challenge those reasons.
Lab — Lab — account checklist
"""Score synthetic account settings against a small CIS-style checklist (stdlib only)."""
checks = {"root/owner account has MFA": True, "no root access keys": True, "audit logging all regions": False,
"storage public access blocked": True, "password policy length >= 14": False,
"default network has no open admin ports": False, "log files encrypted": True}
passed = sum(checks.values())
for c, ok in checks.items(): print(f"[{'PASS' if ok else 'FAIL'}] {c}")
print(f"score {passed}/{len(checks)} = {100*passed/len(checks):.0f}%")
Run with python3 lab_cis.py. Verified output:
[PASS] root/owner account has MFA
[PASS] no root access keys
[FAIL] audit logging all regions
[PASS] storage public access blocked
[FAIL] password policy length >= 14
[FAIL] default network has no open admin ports
[PASS] log files encrypted
score 4/7 = 57%
26.2 Lab result
Four of seven checks pass: owner account MFA, no owner access keys, storage public access blocked and log files encrypted. Three fail: audit logging in all regions, password policy length at least 14, and the default network having no open administration ports. The score is 57%.
The failures cluster in the account's networking and logging, which is consistent with an account created before guardrails existed. The passing items, such as MFA and encrypted logs, cover the owner account and storage. Samuel checks each failure against the account's history before recommending changes.
26.3 Interpreting
A percentage hides differences in importance. Open administration ports and missing logging matter more than password length, since staff sign in through the identity provider rather than local passwords.
Two accounts could both score 57% while one has open administration ports and the other only a short password policy. Reporting the individual results, not just the score, prevents that confusion. Samuel shows the score for trends but makes decisions from the list of failures. Samuel adds a severity to each item.
26.4 Prioritising
Fix open ports first, then logging (already planned centrally), then password policy for the few local accounts.
Open administration ports are reachable from the internet and invite automated attacks, so they come first. Logging is already being fixed through the organisation-wide configuration. The password policy affects only break-glass and a few local accounts, so it is real but less urgent. The order follows exposure: ports reachable from anywhere first, missing evidence second, a weak policy affecting very few accounts last. Samuel records the reasons beside the order so the team can revisit it if circumstances change, for example if more local accounts are created.
26.5 Tracking
The checklist runs monthly; results are charted per account.
Charts per account show whether each one improves or slips. A new account should start at full marks because the automated creation process applies the baseline. A drop in an established account suggests a manual change that bypassed review, which the team investigates. Each month's results are stored with the date and the checklist version, so changes in the score can be traced to either a real change in the account or a change in the checklist itself. A drop is investigated within the week.
26.6 Limits
Benchmarks cover common settings, not Westmere-specific risks such as role paths.
The role path from support-cy to cluster-admin would pass every benchmark item, because each permission involved is ordinary. Benchmarks also say nothing about secrets in images. Westmere's own checks fill these gaps, which is why Samuel added them to the checklist. Samuel's adapted checklist adds Westmere-specific checks for exactly these reasons, as described below. Even so, he presents the benchmark score as one input among several, alongside the role graph, the registry review and the control tests, rather than as a single measure of how secure an account is.
Adapting the benchmark
Samuel selects benchmark items relevant to Westmere's services and records why others were left out, for example items for services the university does not use. Each selected item keeps its benchmark reference so auditors can trace it. He also adds two Westmere-specific checks that no benchmark covers: no role path from support accounts to administrator roles, and no repository with anonymous pull. The checklist is reviewed every year when new benchmark versions are published, and changes are noted in its history.
Worked example
The open administration ports belong to a default network created with the account and never used. Deleting the default network in all accounts removes the issue and simplifies the environment; the guardrail now prevents default networks in new accounts.
Synthetic case. Results are synthetic.
Errors and limits
Passing a benchmark is not the same as being secure.
Exercises
- EX076 — Lab score. What was the score and which checks failed?
Show marking criteria
Rubric: 3 = 4/7; logging, password, open ports; 2 = two; 1 = one; 0 = none. - EX077 — Weighting. Why does password length matter less here?
Show marking criteria
Rubric: 3 = staff use identity provider; 2 = partial; 1 = vague; 0 = none. - EX078 — Ports fix. How were the open ports fixed?
Show marking criteria
Rubric: 3 = deleted unused default networks; 2 = partial; 1 = vague; 0 = none.
Synthesis
Use benchmarks as a baseline and prioritise by real risk.
Continue studying — chapter 26 of 40
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →