Security configuration assessment

Security configuration assessment (SCA) checks a host's settings against a declared policy of hardening controls and scores it. Three seed policies ship out of the box, and you can author your own. The sensor never judges anything itself — it reports raw facts, and the server is the only thing that decides pass or fail.

The three seed policies

Seventy-six checks in total, covering account lockout, service minimisation, logging, encryption and network hardening, each written independently against well-known, public hardening controls rather than lifted from any single vendor's benchmark text.

Authoring your own policy

A policy is a set of checks, each with an id, a title, a compliance map, a condition (all, any or none of its rules), one or more typed rules, and a remediation string. A rule has a kind — file, registry, command or process — and a matcher such as exists, absent, equals, contains, regex, absent_or_zero, running, not_running or exit_code_zero.

The console's authoring form, on the consolidated /xdr/policy page, takes a policy key, a title, a platform, a framework label, and the checks themselves as a JSON array — the same generic-JSON-authoring convention the console already uses elsewhere for policy settings.

How a check evaluates

A policy's score is the percentage of applicable checks (pass or fail, excluding not-applicable and not-checked) that passed. A policy with zero applicable checks scores 0 rather than reading as a clean host — a policy that could not be evaluated at all must never look identical to one that was evaluated and found clean.

Viewing results and drilling into a check

The SCA results panel lists policy, framework, score pill and evaluated-at for every run. Selecting View checks on a result opens a modal with the per-check breakdown — check ID, status and evidence — with error always shown as Not checked, never as a plain failure, matching the abstain-not-guess discipline above.

What is not built yet

• No per-host-group enable or disable. A policy applies tenant-wide, to every host of the matching platform. There is no server route to scope a policy to a subset of hosts, so a policy is on for every eligible host or authored differently if you want a narrower footprint.
• No CSV export. Unlike vulnerabilities, SCA results have no export route today.
• The SCA fact list is not yet delivered through the policy bundle. A sensor derives what facts to collect by re-reading the applicable policies from the API today, rather than from a resolved list in its bundle check-in — a documented follow-up, not something that affects correctness (a fact the sensor never reports still evaluates honestly as Not checked, never a false pass).

Who can manage this

Reading SCA policies and results needs xdr:sca.read; authoring a policy needs xdr:sca.write. Both are seeded correctly alongside the rest of this wave's permissions.

What to read next

1. The signed policy bundle — the SCA section the bundle now carries, and what it does and does not deliver yet.
2. File integrity monitoring — the other new fact-collection surface on the same consolidated page.
3. How findings map to DORA and ISO 27001 — for the same caution about citing a platform mapping in a formal audit without checking it first.