Open findings from STIG compliance assessment of this environment, with the reason each remains open and what would close it. A POA&M exists so that residual risk is stated and accepted deliberately rather than discovered later; an item here is a decision, not an oversight.
Every finding traces to a scan report committed under scans/. Control references are
the CCI and NIST SP 800-53 Rev. 5 mappings published in the DISA benchmark content.
As of: 2026-09-23
| Host | Assessed | Remediated | Open | Reference |
|---|---|---|---|---|
| RHEL01 | 2026-09-16 | 2026-09-20 | 17 | scan · method |
| WS01 | 2026-09-17 | 2026-09-22 | 7 (+1 residual) | scan · method |
| DC01 | 2026-09-18 | Deferred | 138 | scan |
Seven rules remain open out of 148 at baseline. They fall into two groups: three with no remediation path in this environment, and four awaiting certificate content newer than the current DoD distribution tool provides.
| ID | Rule | STIG ID | CAT | Control |
|---|---|---|---|---|
| WS01-001 | Credential Guard must be running | WN11-CC-000075 | I | CCI-000366 · CM-6 b |
| WS01-002 | Domain-joined systems must use Windows 11 Enterprise | WN11-00-000005 | II | CCI-000366 · CM-6 b |
| WS01-003 | Multifactor authentication for local and network access | WN11-SO-000251 | II | CCI-000765 · IA-2 (1) |
WS01-001 and WS01-002 are one finding expressed twice. Credential Guard is a Windows 11 Enterprise and Education feature; WS01 runs Pro. Microsoft’s Enterprise evaluation image was past its expiration date at download and enforced hourly shutdowns, so Pro was substituted during the build. The policy values are set and the platform prerequisites are satisfied — virtualization-based security and HVCI both run on this host — but the edition gates the feature itself.
Risk: LSA credential material is not isolated in a VSM enclave, so credential-theft techniques that read LSASS memory are not mitigated by this control on this host. Partially offset by HVCI, the deny-logon rights that keep privileged domain accounts off the workstation entirely, and network isolation.
Closure: a Windows 11 Enterprise license. Not planned for this lab.
WS01-003 requires DoD CAC/PIV infrastructure — card issuance, middleware, and a reader — which does not exist in an isolated virtual environment with no physical smart card hardware.
Risk: authentication is single-factor. Offset by a 15-character domain minimum, 20 characters for privileged and service accounts, a 3-attempt lockout, and no route from the lab to any other network.
Closure: out of scope. Would require physical PKI hardware.
| ID | Rule | STIG ID | CAT | Control |
|---|---|---|---|---|
| WS01-004 | DoD Root CA certificates in Trusted Root store | WN11-PK-000005 | II | CCI-000185 · IA-5 (2) |
| WS01-005 | External Root CA certificates in Trusted Root store | WN11-PK-000010 | II | CCI-000185 · IA-5 (2) |
| WS01-006 | DoD Interoperability cross-certificates in Untrusted store | WN11-PK-000015 | II | CCI-002470 · SC-23 (5) |
| WS01-007 | CCEB Interoperability cross-certificates in Untrusted store | WN11-PK-000020 | II | CCI-002470 · SC-23 (5) |
DoD certificates were introduced through InstallRoot 5.6, the current NIPR release, transferred into the isolated segment and verified by SHA-256 and Authenticode signature before execution. It installed DoD Root CA 3, 4, and 5, 45 intermediates, and two Interoperability cross-certificates.
STIG V2R10 tests these four rules against specific certificate thumbprints, and the set it expects is newer than the trust-anchor payload the tool ships. WN11-PK-000005 requires DoD Root CA 3, 5, and 6; Root CA 6 is not in the payload. The cross-certificate rules name particular certificates by expiry that the payload does not contain.
This is a version gap between the distribution tool and the benchmark, not a misconfiguration on the
host. Running the tool elevated also fails its own trust-anchor verification offline —
Unable to find a valid TAMP message — because it builds the validation path against the machine
store it is about to populate.
Risk: certificate paths chaining to DoD Root CA 6 do not validate, and the specific interoperability cross-certificates named by the benchmark are not explicitly distrusted. Low in practice: this host contacts no DoD PKI-protected service and has no route off the lab segment.
Closure: source the current PKCS#7 certificate bundles directly from the DoD Cyber Exchange rather
than relying on the tool payload, and import with certutil -addstore to Root and Disallowed.
Scheduled for the next maintenance window.
| ID | Item | Severity | Status |
|---|---|---|---|
| WS01-008 | System volume encrypted at XTS-AES 128, Used Space Only | Informational | Open |
WN11-00-000030 passes: the volume is encrypted, protection is on, and pre-boot authentication is enforced by TPM+PIN with the recovery password escrowed to Active Directory. No rule in this benchmark tests the encryption algorithm or the conversion type, so the scan does not flag this.
It is recorded anyway. The volume was already fully encrypted at XTS-AES 128 by Windows’ automatic
Device Encryption before hardening began, in a suspended state with no key protectors. Remediation
added protectors and resumed protection rather than decrypting and re-encrypting, because a
full-volume rewrite on this host had previously coincided with an unrecoverable shell failure
(documented in ws01-stig-gpo.md) and the rule tests protection status alone.
Risk: used-space-only conversion leaves previously deleted sectors unencrypted, and DoD prefers XTS-AES 256. Data-at-rest exposure is limited to the virtual disk file on the host; the VM holds no production or personal data.
Closure: offline chkdsk /f /r, snapshot, decrypt, re-encrypt at XTS-AES 256 with full-volume
conversion, re-escrow. Deferred maintenance.
17 rules remain open out of 258 at baseline, itemised in the post-remediation scan summary.
| Category | Count | Summary |
|---|---|---|
| Platform substitution | 1 | Rocky Linux 9 in place of RHEL 9; one rule tests Red Hat-specific packaging |
| Filesystem layout | 6 | Separate partitions for /var, /var/log, /var/log/audit, /var/tmp, /home, /tmp — requires a rebuild, not a configuration change |
| Missing lab infrastructure | 7 | Filed as controls depending on services this environment does not run: a remote log collector (4 rules), a second DNS server (1), and smart card PKI for certificate mapping (1). The seventh, rsyslog_remote_access_monitoring, was filed here in error — see below |
| Risk-based deferral | 2 | Accepted with stated reasons |
| Benchmark self-conflict | 1 | scap-security-guide 0.1.82 contains rules demanding mutually exclusive SSH MAC orderings; see rhel01-remediation.md |
The filesystem-layout items close at next rebuild. Of the infrastructure items, the four log-forwarding rules would close with remote log forwarding from RHEL01 to SIEM01. The collector now exists, but forwarding from RHEL01 is not planned, so they remain open. The DNS and PKI items remain open with no planned closure.
Misclassified: rsyslog_remote_access_monitoring. Grouped with the log-forwarding rules at
the time of remediation on the strength of its title. Its OVAL definition in
scap-security-guide 0.1.82 tests /etc/rsyslog.conf and /etc/rsyslog.d/*.conf for selector
lines covering auth.*, authpriv.*, and daemon.* that write to a file or forward — a local
destination satisfies it, and no remote host is required. “Remote access” in the title refers to
the access methods being logged, not to where the logs go. The current configuration fails on
auth.* and daemon.*; authpriv.* already matches. Closable without new infrastructure; not
remediated, and left open with its classification corrected.
| ID | Item | Status |
|---|---|---|
| ENV-001 | DC01 STIG remediation deferred | Open — not scheduled |
| ENV-002 | SIEM01 excluded from compliance scanning while holding audit records | Accepted — risk stated |
| ENV-003 | KALI01 excluded from compliance scanning | Accepted — assessment platform, no applicable STIG |
| ENV-004 | DISA GPO package v2r8 against benchmark V2R10 | Open — compensating policy in place |
| ENV-005 | Splunk transport and certificates | Accepted — no lab certificate authority |
ENV-001 — DC01 remediation deferred. DC01 was assessed and its baseline is committed
(dc01-baseline-20260918.md): 42.74%, 138 failed rules.
Remediation is deferred rather than attempted.
DC01 is the sole domain controller in this environment, with no replication partner to fail over to. The Windows Server 2025 STIG’s authentication controls — LDAP signing and channel binding, SMB signing, NTLM restrictions, and Kerberos encryption-type constraints — alter the authentication path that every other host depends on, including the scanner service account, the workstation’s secure channel, time synchronisation for the Linux hosts, and the administrative access used to perform the remediation itself. Applying them without a second domain controller and a validated rollback plan for each cross-host dependency exceeds the risk tolerance for this phase.
Risk: the domain controller runs at its assessed baseline. Offset by network isolation, no inbound path from outside the lab segment, and the domain-wide password and lockout policy strengthened during workstation remediation.
Closure: stand up a second domain controller, then apply the Server 2025 STIG GPO to the Domain Controllers OU in stages with cross-host dependency validation between each. Not scheduled.
ENV-004 — GPO package version drift. DISA’s published Windows 11 STIG GPO package is at v2r8
while the SCAP benchmark used for assessment is V2R10. Three rules present in V2R10 have no
corresponding setting in the package and were confirmed failing after a clean import. A
supplemental GPO (Lab - STIG V2R10 Supplement) supplies them.
Closure: adopt the v2r10 GPO package when DISA publishes it, then retire the supplemental GPO. Until then the supplement is the compensating control, and its name records why it exists.
ENV-002 — SIEM01 unhardened while holding audit records. SIEM01 was excluded from compliance scanning as the monitoring platform, before it held any data. It now stores WS01’s Security, PowerShell, and Sysmon records, so a compromise of SIEM01 or of the Splunk administrator account would allow the evidence of activity on WS01 to be read or deleted (AU-9). Splunk runs as an unprivileged service account, its web interface requires TLS, and the host firewall admits only the lab subnet, but the operating system carries no STIG baseline.
Risk: audit records for the forwarding host are protected by one administrator credential and an unhardened host. Offset by network isolation and by the source logs remaining on WS01.
Closure: an assess-only OpenSCAP baseline of SIEM01, then remediation compatible with Splunk. Not scheduled.
ENV-005 — Splunk transport and certificates. Forwarded events travel from WS01 to SIEM01 on
port 9997 without encryption (SC-8). Splunk Web uses a self-signed certificate, and the forwarder’s
own startup log reports that it does not verify the server certificate and still uses the default
pass4SymmKey. All four have the same fix — a lab certificate authority issuing certificates to
SIEM01 and the forwarder — and none of it exists in this lab.
Risk: a host on the lab segment could read or alter events in transit to SIEM01. The segment has no route to any other network.
Closure: build a lab CA, issue certificates, enable TLS with server-certificate verification on
9997, and set a unique pass4SymmKey. Not scheduled.
Splunk’s health monitor also reports an empty allowedDomainList in alert_actions.conf, which
would let alert emails be sent to any domain. No SMTP server is configured and SIEM01 has no route
off the lab segment, so no alert email can leave; recorded here for completeness and closed by
setting an allowed-domain list if email alerting is ever enabled.
Three findings in this POA&M were identified by reading the OVAL definitions behind the rules rather than the rule titles — the BitLocker protection-status test, the certificate thumbprint tests, and the per-profile evaluation of user-scope registry rules. Rule titles describe intent; the OVAL describes what is actually measured, and the two differ often enough that remediation planned from titles alone tends to be either insufficient or unnecessarily destructive.
This is a training environment, not an accredited system. The format follows RMF POA&M practice under NIST SP 800-37 so the artifact is recognisable, but no authorising official, milestone dates, or resource estimates are asserted.