Infrastructure configuration assessment

How Infrastructure Defense checks the security configuration of each host against controls aligned with CIS benchmark sections, and how to tune profiles, thresholds and exceptions.

Infrastructure Defense evaluates the security configuration each Sentinel Host reports against a catalog of more than 60 controls aligned with CIS benchmark sections. Each host gets a compliance percentage, each control maps to the PCI DSS requirement it supports, and open critical and high misconfigurations feed the Viking Exposure Score. This page covers what is checked and how to tune it.

What is checked

Every control records the expected value next to what the host reported, so a failure explains itself. The agent reports facts only: a fact an older agent does not report counts as not applicable, not as a failure.

Profiles and thresholds

Each host policy selects the profile its hosts are held to: the WASViking baseline, or CIS Level 1 with stricter thresholds and the additional Level 1 controls. Thresholds such as password length, inactivity lock and account lockout can be tuned per policy, and individual checks can be switched off.

Two thresholds follow the units of the platform they are checked against. The inactivity lock is set in seconds, the unit of the Windows machine policy (900 is 15 minutes). The lockout control also asks that a locked account stays locked for 15 minutes or more; a lock that holds until an administrator unlocks the account passes.

Exceptions

An approver can accept the risk of a failing control for a stated reason until a date. The control then counts as passed with exception, stays visible as an accepted risk, and returns to the open list when the exception expires. Accepted risks do not add to the Viking Exposure Score.

Hardening actions

A few findings carry a hardening action that a person with the Remediate permission can send to the host: disable SMBv1, require Network Level Authentication, turn off LLMNR, and apply the kernel network hardening. The agent applies the documented change and reports a fresh inventory, and the finding closes on that evidence. For other changes, such as a registry value, a service state or an approved script, see Mitigate a finding without a patch.

Where to see the results

The Configuration Assessment screen is the place to work the findings from detection to the proven fix. A remediation flow at the top counts what is identified, what is in the agent's queue, what was applied and waits for validation, and what got fixed in the last 30 days; every number, and every tile under it (severities, hosts affected, accepted risks, failed fixes, hosts reporting late), is a filter. The list can be narrowed by search, severity, host, operating system, category, stage of the fix, kind of fix, CIS control, PCI requirement and detection period, in pages, and exported as CSV under the same filters. Opening a finding shows a panel with the expected and the reported setting side by side, the evidence, the recommendation, the stage of the fix and its history, and the actions: apply the agent's fix (with a confirmation first), schedule a mitigation, or accept the risk with a reason and an end date. A fix the agent applied does not close the finding; only a later inventory that proves the control does. A view per host compares the exposure of each machine and leads to its findings.

The Infrastructure Compliance screen, opened from the compliance percentage on the Overview or on an asset, lists every assessed host against every control. Each host has its own view with the expected value and what the host reported for every control, and the CSV export carries the full host by control matrix. The Infrastructure Defense PDF report includes per-host compliance.

How it affects the score

Open critical and high misconfigurations add a bounded factor to the Viking Exposure Score, so posture does not outweigh a real vulnerability backlog. The other factors are in Viking Exposure Score.