Reading a CIS Benchmark report

The first CIS Benchmark scan of a cloud account is usually demoralising. Hundreds of failures, no obvious order, and a compliance percentage that looks bad enough to be alarming. The instinct is either to fix everything or to conclude the tool is too noisy to use.

Both are wrong. A benchmark report is a checklist applied without knowledge of your environment. Some of what it flags is genuinely urgent, some is worth doing eventually, and some does not apply to you at all. The skill is telling them apart quickly.

What the report is and is not

The CIS Benchmarks are consensus configuration guidance. They describe a hardened baseline for a platform, written to be broadly applicable, which means they are necessarily conservative and context-free.

They are not a risk assessment. A benchmark cannot know that a particular account holds no sensitive data, or that a control it recommends is already implemented differently elsewhere in your architecture. That judgement is yours to add.

The scoring reflects this. Most benchmarks distinguish two levels:

• Level 1 is intended to be broadly applicable, with limited impact on functionality. Treat these as the working baseline.
• Level 2 is for environments with higher security requirements, and the recommendations often have real operational cost. These deserve a deliberate decision rather than automatic adoption.

Some items are also marked as not scored or manual, meaning they cannot be checked automatically and require someone to look.

Triage in four passes

Rather than reading top to bottom, sort the findings four times.

Pass one: exposure

Anything that makes a resource reachable from the internet when it should not be, or that exposes credentials. Public storage buckets, security groups open to the world on administrative ports, publicly accessible databases, credentials in metadata or user data.

These are the findings where the gap between "flagged" and "exploited" is smallest. Fix them this week.

Pass two: identity

Root or global administrator accounts without multi-factor authentication. Access keys that have never been rotated. Permissive policies granting broad administrative rights. Users with credentials that have not been used in months but remain active.

Identity findings are the second priority because they determine how bad any other problem becomes.

Pass three: evidence

Audit logging disabled, log integrity validation off, logs writable by the accounts they cover, retention shorter than policy. These do not create an exposure by themselves, but they determine whether you could investigate one.

They also tend to be cheap to fix and are the findings most likely to matter in an audit.

Pass four: everything else

Encryption settings on resources that hold nothing sensitive. Recommendations for services you do not use. Password policy items on an account where humans authenticate through your identity provider and never use platform passwords at all.

This pass is mostly about deciding what to formally exclude, which is a real activity rather than an admission of defeat.

Excluding findings properly

A finding you have decided not to fix should be recorded as an exception, not left failing. An exception needs three things: what is excluded, why, and when it will be reviewed.

"Password complexity policy not enforced" is a reasonable exclusion if no human ever authenticates locally. It is not a reasonable exclusion if someone simply found it inconvenient.

Recording exceptions matters for two reasons. It stops the same finding being re-triaged every month, and it turns an ignored failure into a documented risk decision, which is what an auditor is looking for.

The compliance percentage

The headline score is the least useful number in the report. It weights a public database and a missing tag equally, and it moves most when you fix whichever category has the most instances.

An account can be at 60 percent with nothing seriously wrong, or at 90 percent with an open administrative port. Track the count of unresolved high-severity findings and the age of the oldest one instead. Both are harder to game and both correspond to something real.

If you must report a percentage upward, report it alongside the number of accepted exceptions, so that the two move in a way that makes sense.

Making the second scan easier than the first

The first pass is always the largest, because it contains everything that accumulated before anyone was looking. What matters is whether the next one is smaller.

Three things make that happen:

Fix the class, not the instance. Twenty buckets with public access blocked individually will become twenty-one. Blocking public access at the account level, with exceptions by exemption, fixes it permanently.

Move controls left. If a finding is caused by how resources are created, fix the template or the module rather than the deployed resource. A hardened default costs nothing per deployment.

Scan continuously, not before audits. A monthly report where you compare against last month is actionable. An annual report with four hundred findings is a project nobody wants to start.

What a good state looks like

You will not reach zero findings, and a report claiming zero usually means the scope is too narrow. A healthy position looks like:

• No unresolved findings in the exposure or identity categories.
• Logging complete and protected, with retention matching policy.
• A written, dated list of accepted exceptions with owners.
• A trend line where new findings are caused by new deployments rather than by old ones resurfacing.

That last point is the real test. If the same finding keeps returning, the fix went to the instance instead of the cause.