CIS Benchmark assessment | Firemind
CIS Benchmark

Scored control by control.With the evidence behind every result.

Your accounts assessed against the CIS Benchmark, read-only, with the failures that matter ranked ahead of the ones that do not.

AWS today
Azure and Google Cloud following
Read-only assessment
Evidence per control
Benchmark severity carried through
Promoted standing actions
The problem

The most widely used technical baseline, and the hardest to keep on top of by hand.

Each control needs evidence gathered from a different service, and the picture changes every time someone deploys.

The IT Operations Engine gathers that evidence read-only, scores every control, and tells you which failures matter most.

What a benchmark report has to do

  • Return a pass or a fail per control, with the evidence attached rather than asserted
  • Carry the benchmark's own severity, so the counts read as direction rather than as a single score
  • Cover identity and access, logging, monitoring, networking and storage in one pass
  • Change nothing while it assesses
  • Give every failure a remediation path, not just a red row
What we do

Gather the evidence, score the control, rank the failure.

The engine assesses each account against the CIS Benchmark for the cloud in question and reports each control with its evidence. Failures carry a remediation path, executed under your authority model where it is a configuration change and raised as a pull request where it touches code.

Identity and access
Logging
Monitoring
Networking
Storage

Find, fix, keep green

    • Find - The engine assesses each account against the CIS Benchmark for the cloud in question: identity and access, logging, monitoring, networking and storage controls. Each control returns a pass or a fail with the evidence attached, and the report carries the benchmark's own severity so the counts can be read as direction rather than as a single score. Assessment runs read-only and makes no changes.
    • Fix - Every failed control carries a remediation path. Where the fix is a configuration change, such as enabling a log, tightening a security group or turning on default encryption, the engine makes it under your authority model. Where the fix touches code, it raises the pull request.
    • Keep green - The assessment runs on a cadence, so the second report shows movement, and each approved fix can be promoted to a standing action that resolves the same failure on its own next time.

Want the benchmark report before anything changes?

Three accounts, one benchmark, read-only. Enough to judge the shape of it.

Scope a pilot →
How it starts

Three accounts, one benchmark, read-only.

Enough to show the shape of the report before it runs estate-wide.

  • Name the version and level

    You choose which benchmark version and level you adopt. The engine assesses against the version you name.

    • Your choice of level, not ours
    • We recommend the current release
    • Assessed as written
  • Read-only scoring

    Three accounts assessed across identity and access, logging, monitoring, networking and storage. Each control returns a pass or a fail with its evidence.

    • Evidence attached to every result
    • Benchmark severity carried through
    • Nothing in the estate is changed
  • Then the failures get closed

    Configuration fixes run under your authority model, code fixes arrive as pull requests, and an approved fix can be promoted to a standing action.

    • Logs enabled, groups tightened, encryption defaulted
    • Pull request where the change belongs in code
    • The same failure resolves itself next time
What stays with you

Which benchmark version and level you adopt.

The engine assesses against the version you name. We recommend the current release.

You gain:

  • AWS today, with Azure and Google Cloud benchmarks following the same pattern.
  • Severity comes from the benchmark itself, so a count of failures is not flattened into one number.
  • The second report is the useful one, because it shows movement.

FAQ

Questions.

AWS today, with Azure and Google Cloud benchmarks following the same pattern.

Start with three accounts and one benchmark.

Read-only, scored control by control, with the evidence attached. Nothing is changed until you have seen the report.

Your benefits:

  • Evidence per control - not a score you have to take on trust.
  • Benchmark severity - carried through, so failures rank themselves.
  • Read-only first - nothing changes while it assesses.
  • Promoted fixes - the same failure resolves itself next time.

What happens next?

Talk.

A focused discussion about which benchmark version and level you hold yourself to.

Assess.

Three accounts, read-only, scored control by control.

Close.

Failures remediated under your authority model, then kept closed.

No obligation. Just a focused discussion about your benchmark position.

We'll only use your details to respond to your enquiry. No newsletters unless you ask for them.