Assessment week on a virtualization platform usually looks the same. Someone exports the user list, screenshots a dozen settings pages, copies a slice of the audit log into a spreadsheet and pastes it all into a document. The assessor reads it, asks follow-up questions nobody can answer from the screenshots, and three months later the whole exercise starts again. This post covers what assessors are actually asking for, why that approach fails them, and how Victor produces evidence they can check for themselves.

What assessors actually ask for#

Most US federal and defense assessments, and many commercial ones, are built on NIST SP 800-53 Revision 5, “Security and Privacy Controls for Information Systems and Organizations.” It is a catalog of controls grouped into families, each with a two-letter identifier. For the management plane of a virtualization platform, a handful of families do most of the work:

Family What the assessor wants to see on the platform
AC Access Control Who has accounts, what they can do and where, that inactive accounts are disabled, the consent banner (AC-8), session lock (AC-11), lockout (AC-7)
AU Audit and Accountability That events are recorded, forwarded, timestamped correctly and protected from tampering (AU-9, AU-10)
CM Configuration Management The baseline configuration, the component inventory, what changed
IA Identification and Authentication Multi-factor for privileged users (IA-2(1)), password and authenticator management (IA-5)
SC System and Communications Protection TLS on every listener (SC-8), FIPS-validated cryptography (SC-13), protection at rest (SC-28)
SI System and Information Integrity Monitoring, patch currency, integrity of software and information (SI-7)

How they assess is described in the companion publication, NIST SP 800-53A Rev. 5, “Assessing Security and Privacy Controls in Information Systems and Organizations.” Its assessment methods are examine, interview and test. Screenshots only partly serve the first and don’t help with the other two.

Why screenshots fail#

A screenshot of a settings page has four problems an assessor will notice:

  • No provenance. Nothing ties the image to a particular system, time or build. It could come from a staging environment, or last year.
  • No completeness. A screenshot of the user list shows the first page. A pasted audit log shows the rows someone chose. The assessor can’t tell what was left out.
  • No integrity. Images and spreadsheets can be edited, and nothing would show it.
  • No repeatability. The next assessment needs new screenshots, taken by hand, with the same gaps.

What assessors want instead is evidence that is complete for a stated period, generated by the system rather than transcribed, machine-readable, and verifiable without trusting whoever handed it over.

Victor’s Security & Compliance Center#

The Security & Compliance Center is part of Victor Community. It is under Administration › Security & compliance, behind the shield icon in the header. It runs every security check Victor makes about itself and shows each one with a status (pass, warning, fail, not applicable), the evidence in words and as data, the NIST SP 800-53 rev 5 controls it supports, and how to fix it. The checks only read; nothing on the page changes the system.

There are eight categories:

Category Examples of what is checked Typical controls
Identity and access MFA for org-wide admins, stale accounts, grants to disabled principals, break-glass accounts, number of admins, API token age IA-2(1), AC-2(3), AC-6(5), IA-5
Sessions and account policy Consent banner, idle lock ≤ 15 min, lockout, password policy, inactivity disable AC-8, AC-11, AC-7, IA-5(1), AC-2(3)
Cryptography FIPS mode, master key, TLS versions and suites per listener, certificate expiry, evidence key stored SC-13, SC-28, SC-8, SC-17
Audit Recording, forwarding to a target, target health, clock skew, database role, hash chain verification AU-2, AU-5, AU-8, AU-9, AU-10
Platform Engines reachable, engine versions, required engine extensions SI-4, SI-2, CM-2, CM-6
Data protection Victor’s own backups scheduled and recent, old snapshots with no expiry CP-9, CP-10
Supply chain Tagged release vs development build, SBOM present, FIPS build CM-8, SR-4, SA-10, SR-11
Health advisor Every other advisor finding, as a check (critical fails, the rest warn) By rule (CP-2, SI-2, AU-8 …)

Session and password checks are compared against a government profile: the DoD account policy and the Application Security and Development STIG’s session limits. For example, sessions.password-policy fails if the policy is weaker than 15 characters with complexity, 5 remembered and a 60-day maximum age.

Victor evaluates the posture every hour and keeps one score per day for 400 days. The score is the share of applicable checks that pass, with a warning counting half. The Trend view lists the days a check got worse or better, which answers the assessor’s “when did this change?” without anyone reconstructing it.

The mapping states which controls a check supports. It is not a claim that the control is implemented for your system. That still depends on your organization’s processes, people and the rest of the boundary.

The evidence package, file by file#

Download evidence package in the console, or one command, produces a single ZIP:

victorctl security evidence --from 90d -o q3.zip

--from takes RFC 3339, a date or an age like 90d; --to defaults to now. The audit extract defaults to the last 30 days and is capped at 366 days and 100,000 events (the manifest notes a cut). Inside:

File What it gives the assessor
report.html The readable report: summary per category, every check with status, evidence, controls and fix, who generated it and when, Victor’s version, the signing key. Prints to PDF from any browser
checks.json Every check, machine-readable, with evidence as text and data
access-review.csv Every account and group with each grant: role and privileges, object and path, inheritance, account state, last sign-in, second factors, break-glass. Accounts without grants are listed too
audit/events.csv, audit/events.json The audit log for the period, newest first
audit/chain/ extract.json, rows.jsonl, records.jsonl: the hash-chain rows and signed checkpoints that prove the extract is complete and unaltered
inventory/certificates.json Victor’s certificate, the certificates engines trust, the evidence key
inventory/credentials.json Master key algorithm and ID, sealed secrets per holder, API tokens (metadata only, never secrets), service accounts, second factors
config/settings.json, config/system.json Settings, sign-in providers, audit targets, clusters, listeners, with secrets redacted
sbom.cdx.json The running build’s Go modules as CycloneDX 1.5
versions.json Victor’s build and each engine’s version
enterprise/ Victor Enterprise only: OSCAL and STIG checklist (below)
signing-key.pem, README.txt The public half of the signing key; how to verify
manifest.json, manifest.sig Every file’s SHA-256 and size, generation time, who, the period, the key; and its Ed25519 signature

Generating a package is itself audited, with the period and the archive hash. The access review answers AC-2 account review questions directly. The configuration and SBOM answer CM-2 and CM-8. The audit extract and its chain answer AU-9.

Signing and offline verification#

Each package is signed with Ed25519 by the site’s evidence key. The key is generated on first use and stored in Postgres, sealed with the master key. Its fingerprint (sha256: plus the SHA-256 of the public key’s DER SubjectPublicKeyInfo) appears on the page, in victorctl security posture -o json as evidenceKey, and in every package.

The practice is simple: record the fingerprint once, out of band, and give it to the assessor separately from any package. Then:

victorctl security verify q3.zip --key-fingerprint sha256:3f9a…

verify needs no server and no network. It checks that the manifest’s Ed25519 signature is valid and was made by the pinned key; the SHA-256 of every byte of the archive before the manifest, so names, timestamps and headers are covered as well as content; every listed file’s hash and size; and that nothing extra is in the archive and the ZIP structure is exactly what Victor writes. Any changed, added or removed byte fails with exit code 1. It then verifies the audit chain section: rows link from a signed checkpoint, each record matches its row, each event of the period is present, and every event in audit/events.json matches its record.

An assessor who doesn’t want to run victorctl can check the files with standard tools. manifest.json lists each SHA-256 for sha256sum, and OpenSSL 3 checks the signature:

base64 -d manifest.sig > manifest.sig.bin
openssl pkeyutl -verify -pubin -inkey signing-key.pem -rawin \
  -in manifest.json -sigfile manifest.sig.bin

Compare the fingerprint of signing-key.pem with the one you recorded. A key inside the package proves nothing on its own.

How the audit chain works, and why to save checkpoints#

The audit log is append-only for Victor’s own database role. The hash chain adds evidence against everyone else: a superuser, the schema owner, or someone holding the backup files. Victor maps it to AU-9, AU-9(3), AU-10 and SI-7.

  • Every event gets a SHA-256 digest over all its stored columns, and each chain row hashes the previous row’s hash with the event’s digest. Editing, reordering, inserting or deleting an event breaks the chain from that point.
  • Every minute with new events, Victor writes a checkpoint: the head of the chain, signed with Ed25519 when a master key is set. Without a master key the chain is kept but unsigned, and the audit.chain check warns.
  • The task leader verifies the whole chain daily. A failure is an error event, which reaches SIEM targets and alarms, and fails the audit.chain check.

One attack the chain alone can’t catch is cutting the newest events and checkpoints off the end. What remains is a shorter chain that verifies on its own. The defence is to keep a checkpoint somewhere the attacker can’t reach:

victorctl audit verify --fingerprint sha256:3f9a… --save-checkpoint cp-2026-10-01.json
# next quarter
victorctl audit verify --expect-checkpoint cp-2026-10-01.json

If the saved checkpoint is no longer in the chain, verification reports truncated. A checkpoint from an earlier evidence package serves the same purpose, and so do the events already forwarded to your SIEM. Pin --fingerprint from a copy kept elsewhere; without it, verification trusts the key stored in the database, which someone with owner rights could replace.

Posture in CI#

The same checks run from the command line, so drift can fail a pipeline instead of waiting for the next assessment:

victorctl security posture                       # every check, worst first
victorctl security posture --status fail         # only failures
victorctl security posture --family IA -o json   # one control family, with evidence
victorctl security posture --fail-on fail        # exit 3 when any check fails
victorctl security trend --days 30               # score by day, what changed

--fail-on warn is stricter. Run it after configuration changes (Terraform applies, upgrades) with a service-account token that holds only security.read, and keep the JSON output as a build artifact.

Roles for assessors#

Give the assessor their own account, not a shared admin login. Victor ships a sample role, Security auditor (sample-security-auditor), with read access plus security.read, security.evidence, events.read and permissions.read. Grant it on the organization (the default when no --object is given):

victorctl permission add user:assessor --role sample-security-auditor

The assessor can then read the inventory, the posture and every event, generate evidence packages and ask “why can this person do that?”, and they change nothing:

victorctl permission explain vm.power.off --principal user:jordan --object vm-12

That covers the interview and test methods as well: the assessor can verify an access claim on the spot instead of taking it on trust.

Enterprise additions#

Victor Enterprise adds two machine-readable files to the enterprise/ directory of every package, generated from the live configuration:

  • An OSCAL component definition. OSCAL, the Open Security Controls Assessment Language, is NIST’s set of “open, machine-readable formats available in XML, JSON, and YAML” for control-based assessments. It has control, implementation and assessment layers. A component definition sits in the implementation layer. It “represents a description of the controls that are supported in a given implementation” of a product, and vendors are among those expected to publish them. Victor writes OSCAL 1.2.3 JSON against NIST SP 800-53 rev 5, which a system security plan tool can import instead of someone retyping control statements.
  • A DISA STIG Viewer checklist (.ckl) for the Application Security and Development STIG (V6R3). Rules Victor can assess itself are filled in as Not a Finding or Open. Every other rule is left Not Reviewed for the assessor.

Enterprise also adds fail-closed audit, audit capacity checks, Splunk HEC forwarding and CAC/PIV sign-in. If an Enterprise license lapses past its grace period, these features turn read-only: what is configured keeps working but can’t be changed, and compliance export is refused. A license never stops VMs.

A quarterly evidence routine#

  1. Confirm victorctl security posture --fail-on fail exits 0, or document each failure with its remediation plan.
  2. Review victorctl security trend --days 90 for checks that got worse, and explain each one.
  3. Run victorctl audit verify --expect-checkpoint against last quarter’s saved checkpoint, then save a new one with --save-checkpoint and store it off the system.
  4. Generate the package: victorctl security evidence --from 90d -o q3.zip.
  5. Verify it yourself: victorctl security verify q3.zip --key-fingerprint sha256:….
  6. Review access-review.csv with system owners. Remove grants that no longer make sense, and record the review.
  7. Hand the assessor the ZIP. Send the key fingerprint through a separate channel.
  8. Archive the ZIP, the checkpoint and the verification output together.

What it does not claim#

The checks state what Victor found when they ran. They support the controls named and are not a certification, an ATO or a validated configuration. They cover Victor’s management plane: accounts, sessions, cryptography, audit, engines and its own build. They don’t cover guest operating systems, the hypervisor hosts’ OS hardening beyond what the checks list, your network, physical security or your procedures. The OSCAL and STIG outputs (Enterprise) are a starting point that still needs your assessor’s judgment. The evidence key proves that a package came from the Victor holding that key and hasn’t changed since; it doesn’t prove that the system was configured well.

Where Victor fits#

The Security & Compliance Center, the signed evidence package and the hash-chained audit log are in Victor Community. Victor Enterprise adds OSCAL and STIG checklist output for regulated environments. The aim is to replace assessment-week screenshots with a file the assessor can verify without having to trust the person who handed it over.

Explore security and compliance