diskless-workstation/docs/irap-sar.md

Security Assessment Report (SAR) — Diskless Fleet Boot System

Field	Value
System assessed	Diskless Fleet Boot System ("the fleet")
SSP version assessed	v0.3 (2026-07-10) + Annex A v0.3
Assessment type	Initial IRAP security assessment (design + implementation review; limited effectiveness witnessing)
Assessment period	2026-07-10
Assessor	IRAP Assessor (engaged)
Report version	1.0
Companion outputs	Plan of Action & Milestones (this assessment); SSP Annex A risk register

---

1. Executive summary and determination

The Diskless Fleet Boot System is an unusually well-architected endpoint platform whose central security proposition — stateless, diskless hosts that return to a cryptographically verified known-good state on every boot, with all host identity anchored in hardware (TPM) and no per-host secrets in any artifact — is sound, clearly documented, and in several areas demonstrably implemented and bench-verified. The engineering culture evidenced by the documentation set is a material strength: findings are recorded honestly (including a false-clean compliance scan and an ineffective application-control configuration, both self-identified and fixed), deviations are registered and justified, and verification claims are dated and traceable.

Determination: the system is NOT yet recommended for a production Authority to Operate. The assessor recommends the AO consider a time-limited interim authorisation for continued lab/pre-production operation only, with a production ATO contingent on closure of the conditions in §7.

The determination rests on four grounds:

1. The assessed configuration is not the target configuration. The system's headline preventive controls — 802.1X EAP-TLS network authentication and MACsec link protection — are disabled in the current build (disable_dot1x=true), have never been bench-verified end-to-end (R-01), and the EAP-TLS trust anchor is a placeholder (R-08). The security architecture's value is contingent on these controls; until they are demonstrated operating, the assessment of them is a design review only.
2. A known privileged back-door existed in lab builds — since removed. debug_shell=true baked a passwordless root shell (R-02). Remediated 2026-07-11 (poam-hardening, POA&M P-02): the debug_shell variable and its debug-shell.service provisioner were deleted from the template — no build can bake it. Assessor to verify absence on the assessed digest (P-02 M2).
3. Boot-chain signing is proven but not the standing posture. Secure Boot enforcement of the signed UKI (and signed iPXE chain) has been verified on real hardware — a significant achievement — but unsigned/SB-off builds remain possible and db enrolment is not fleet-wide (R-13).
4. The governance layer required for authorisation does not yet exist. No Authorising Officer, System Owner, or CISO is appointed; the data classification is unconfirmed; there is no Incident Response Plan, continuous-monitoring plan, or approved security documentation set. An ATO cannot be granted without an AO, and the applicable ISM control baseline cannot be finalised without a confirmed classification.

None of these grounds indicates architectural weakness; all are completion and assurance gaps, most already self-identified in the SSP's own risk register. The assessor broadly concurs with the SSP Annex A risk register (ratings and treatments), with the adjustments and additional findings at §5.

2. Scope and methodology

2.1 What was assessed

• The authorisation boundary as defined in SSP §2.3: the running workstation host — signed UKI, dracut initramfs (802.1X/MACsec module), dm-verity/erofs root, tmpfs overlay, TPM-backed identity, STIG-hardened OS configuration, kiosk, and the in-image fleet-agent telemetry client.
• Boundary crossings (a)–(g) per SSP §2.3, including the new v0.3 management-plane interface (outbound-only mTLS to the fleet-manager).

2.2 What was explicitly out of scope (connected systems)

The lab serving stack (DHCP/HTTP/NVMe-oF target, audit collector), the server-side fleet-management plane (fleet-manager, admin UI, InfluxDB, Traefik), the TPM enrolment broker and step-ca fleet CA, the RADIUS/802.1X authenticator infrastructure, the Wazuh SIEM node, the network fabric, and facility physical security. These each require their own authorisation; the host's dependence on them is assessed here only at the interface. See finding F-01 and risk R-14 — the AO should note that the host system's authorisation is materially dependent on connected systems that are currently unauthorised.

2.3 Method and evidence base

• Document review: SSP v0.3, Annex A v0.3, architecture design v2 + errata, fleet-management design, TPM enrolment design, STIG deviation register, secure-boot key procedure, backlog/POA&M source (TODO.md).
• Implementation-of-record review: the repository is the implementation (Packer template, dracut module, provisioners, CI workflows). Control implementation statements were checked against the code and build gates (e.g. the roothash coupling gate, the 0-rules-evaluated STIG scan guard, the lsinitrd content assertions).
• Verification evidence review: dated bench-verification records for the test boot path (2026-06-15/17), hardened build boot/login (2026-06-19/20), audit offload end-to-end (2026-06-20), Wazuh decode+alert (2026-06-27), Secure Boot enforcement on hardware (2026-06-20/22), fapolicyd overlay effectiveness (2026-07-04), and fleet-agent TPM-mTLS telemetry (2026-07-10).
• Not witnessed by the assessor: the bench verifications above were reviewed as records, not independently witnessed; the secure path (802.1X/ MACsec) has no verification record to review. Witness points for the follow-up assessment are listed in §7.2.

2.4 Limitations and caveats

1. ISM control-identifier currency. The SSP self-declares its ISM-NNNN identifiers as representative of a January 2026 baseline. The reconciliation of every identifier against the May 2026 ISM release remains open and is carried as POA&M item P-17. Control intent mappings were assessed and are sound; individual numbers in Annex A must not be quoted to the AO as final.
2. Classification not confirmed. The assessment assumes the SSP's working classification of STARFLEET ROUTINE / STARFLEET RESTRICTED. If the kiosk renders or the workstation can reach STARFLEET SECRET data, the control baseline changes materially (approved cryptography becomes mandatory — R-06 escalates from Medium to a blocking finding; gateway and media controls tighten).
3. Point-in-time. This SAR reflects the system at 2026-07-10, lab configuration, pre-production.

3. Assessment results by ISM guideline area

Effectiveness scale: Effective (implemented and operating as intended, with evidence) · Partially effective (implemented with material gaps or lab-only scope) · Ineffective (present but not achieving the control objective) · Not implemented · Alternative control (objective met by a justified compensating mechanism) · Not assessed (no visibility / out of scope).

ISM guideline area	Assessed effectiveness	Basis
Security documentation	Partially effective	High-quality SSP/annex/registers exist and are maintained; but no IRP, no continuous-monitoring plan, no AO approval, roles unappointed.
Cyber security roles	Not implemented	AO / System Owner / CISO all TBA. Blocking for authorisation.
OS & application hardening	Effective (current build)	STIG applied + bench-verified with a credible tailoring and deviation register; SELinux enforcing with three minimal documented local modules; fapolicyd allow-listing verified effective on the overlay root (post-2026-07-04 fix); USBGuard enforcing + verified; minimal install; kiosk lockdown. Residual: enable_stig must be confirmed on in production CI (R-03).
File integrity / anti-malware	Alternative control — accepted	dm-verity continuous block-level verification of a signed, reproducible root supersedes AIDE; immutable root + allow-listing + RAM-only overlay is a justified compensating posture for endpoint AV. The assessor accepts both N/A justifications.
Authentication (machine)	Partially effective	Design (EAP-TLS, non-exportable TPM key, cert in NV, no baked credentials) is strong and the same identity is demonstrated working for agent mTLS on hardware. But the 802.1X path itself is unverified and disabled in builds (R-01) and the RADIUS trust anchor is a placeholder (R-08) — the control is not currently operating.
Authentication (privileged users)	Partially effective	Key-only single admin, root locked, staff_u confinement with sudo role transition — good. No human MFA on host SSH; NOPASSWD sudo; fleet-generic non-rotatable key (R-05). Management-plane admin MFA (WebAuthn passkeys) is effective but sits in a connected system.
System management / patching	Partially effective	Reproducible, digest-pinned, atomic rebuild/redeploy model is excellent change control; signing keys correctly held outside repo/build. Gaps: patch cadence/SLA undefined (R-10); debug shell (R-02); actuator path deferred (R-15).
Event logging & monitoring	Partially effective	Centralised auditd offload verified end-to-end; Wazuh SIEM decode+alert verified; health telemetry adds operational visibility. Gaps: both log-offload hops plaintext, retention/archival unconfigured, Wazuh default credentials (R-07).
Networking	Partially effective	Port-based 802.1X design + segmentation + outbound-only agent are sound but the enforcement path is unverified (R-01); host firewall disabled (R-09).
Communications / link protection	Not assessed → design sound	MACsec implementation exists but has never been observed operating (MKA survival across switch-root specifically flagged by the system's own documentation as unverified).
Cryptography	Partially effective	Modern STIG crypto policy, TPM-held keys, HSM/CI signing keys. AACA/AACP conformance not asserted, FIPS off, NVMe/TCP root and log transport plaintext (R-04, R-06, R-07). Acceptable at STARFLEET ROUTINE on an isolated LAN; not above.
ICT equipment & media	Effective	Diskless/no-remanence posture is inherent and genuine; Secure Boot + signed UKI + dm-verity verified enforcing on hardware. Residual is default posture (R-13) and no remote attestation (R-11).
Supply chain / artifact integrity	Effective	FROM-scratch artifact, SHA256SUMS, digest pinning, reproducible builds, roothash hard gate in CI.

4. Strengths worth the AO's attention

1. Statelessness as a control. No persistent local state, RAM-only overlay, per-boot return to a verified root — this structurally eliminates whole ISM control families (media sanitisation, data remanence, endpoint backup) and sharply limits persistence for an attacker.
2. Hardware-anchored identity, one key three uses. Non-exportable TPM key backing 802.1X, the NVMe hostnqn, and management-plane mTLS, with human-anchored enrolment (OOB fingerprint + admin mTLS approval, no auto-issue). See also observation F-06 on cross-protocol key reuse.
3. Verification culture. The false-clean STIG scan (datastream/CPE mismatch evaluating 0 rules) and the inert fapolicyd overlay guard were both found by the team's own effectiveness testing and fixed with build-time guards. This is exactly the behaviour an assessor wants to see, and it raises confidence in the other dated verification claims.
4. Honest deviation management. The STIG tailoring + per-build deviations report with a triaged register (REVIEW rows driven to 0–1) is a model pattern; waivers carry justifications rather than hiding findings.
5. Recovery posture. Rollback = revert one digest-pinned manifest commit; compromised host recovery = reboot. Respond is structurally strong even before an IRP exists.

5. Assessor findings

5.1 Concurrence with the SSP risk register

The assessor concurs with the ratings, compensating controls, and treatments for R-01 through R-15 in Annex A §3, with these adjustments:

• R-01 (secure path unverified) — concur High, emphasise centrality. This is the pivotal finding of the assessment. Until the swtpm + hostapd + FreeRADIUS bench demonstrates port authorisation, MACsec establishment, MKA survival across switch-root, and NVMe root mount over macsec0, the system's primary network-preventive control set is unassessed. It must be witnessed, not just recorded, at the follow-up assessment.
• R-08 (placeholder RADIUS CA) — concur Medium, but couple to R-01. These close together or not at all: a verified secure path against a placeholder trust anchor is not a verified control.
• R-06 (AACA/AACP not asserted) — concur Medium at STARFLEET ROUTINE, with the explicit caveat that this becomes a blocking finding if the classification is confirmed STARFLEET SECRET or above (see §2.4.2).
• R-14 (management plane unauthorised connected system) — concur Medium. The host-side exposure limitation (outbound-only, telemetry-only, commands inert) is genuine and was verified on hardware; however the host now trusts a new CA (step-ca) whose key protection is unassessed. The AO should treat the fleet CA as part of the system's effective trust boundary even though it is administratively a connected system.
• R-15 (deferred actuators) — concur Low, with a hard condition: enabling any actuator (reboot/drain/kiosk_url) without a delta assessment of the command authorisation path would invalidate this SAR's characterisation of the agent as read-only.

5.2 Additional assessor findings (not in the SSP register)

ID	Finding	Severity	Detail / recommendation
F-01	Assessed build ≠ production configuration. Partly remediated 2026-07-11 (poam-hardening, POA&M P-03). A fail-closed production profile now exists: the CI "Production build gate" aborts unless SB_KEY/SB_CERT/FLEET_CA are set (no unsigned fallback, no placeholder CA), enable_stig=true is enforced by Packer variable validation, and debug_shell is deleted from the template. Two of the five toggles remain unpinned in the standing CI: disable_dot1x is still true (blocked on the P-01 secure-path bench) and production artifacts are not yet distinctly tagged (P-03 M2).	High → Medium (residual)	Complete P-03: flip disable_dot1x=false after the P-01 bench and add distinct production-artifact tagging; make the follow-up assessment target that artifact digest. Individual toggles are tracked (R-01/02/03/08/13).
F-02	SSH host keys regenerate every boot. The ephemeral overlay means sshd host keys are new each boot, so administrators can never pin a host key — every connection is effectively trust-on-first-use, and a MITM of admin SSH on the LAN is undetectable by the client. Remediation IMPLEMENTED 2026-07-11 (poam-hardening, POA&M P-17): the SSH host CA treatment (Design A, broker-mediated) — fleet-ssh-hostcert gets each host's per-boot key signed by the fleet SSH CA via the enrol-broker host plane (TPM-identity mTLS) at boot; admins trust the fleet via one @cert-authority line. step-ca stays behind the single front door; fail-open (bare key if the broker/CA is unreachable).	Medium → Low (once bench-verified)	Bench-verify end-to-end (broker↔step-ca SSH-CA contract, host principal policy, SELinux for the root cert-installer) per docs/ssh-host-certificate-design.md; roll the @cert-authority anchor to admin workstations. A stable TPM-resident host key (Design B) is a deferred option, not required.
F-03	Time source is unauthenticated. chrony syncs solely from a DHCP-handed lab NTP server with no NTS or symmetric-key authentication. Certificate validity decisions (EAP-TLS, agent mTLS, future log TLS) depend on host time; an attacker on the pre-auth segment who can spoof DHCP/NTP could shift time to resurrect expired/revoked certificates. Remediation IMPLEMENTED 2026-07-11 (secure-ntp, POA&M P-18): NTS (RFC 8915) — the serving NTP server presents a fleet-CA-signed NTS-KE cert; the host (secure_ntp=true) verifies it against radius-ca.pem and syncs authenticated time (server name derived at runtime from the DHCP domain — no baked FQDN), and no longer mixes in the unauthenticated DHCP source. A DHCP/DNS spoofer can now only DoS, not shift the clock.	Low–Medium → Low (once bench-verified)	Bench-verify (chronyc authdata NTS cookies, tcp/4460, cold-clock nocerttimecheck, STIG chrony) per docs/secure-ntp-design.md; issue the per-environment NTS server cert. Compensating meanwhile: isolated LAN + cert-serial inventory gate.
F-04	Enrolment broker pre-auth endpoint lacks abuse controls. The one unauthenticated CSR endpoint is human-gated for issuance (good) but the SSP records no rate-limiting/queue-flooding controls; a flooded pending-approval queue is a plausible denial/enrolment-confusion vector. Noted inside R-14's treatment text; called out here so it is not lost in the connected-system SSP.	Low (host) / Medium (plane)	Carry explicitly into the management-plane SSP: rate limiting, pending-CSR TTL and queue caps, and alerting on anomalous CSR volume.
F-05	Fleet-wide availability depends on a single NVMe/TCP target. Every running host's root filesystem is served by one unreplicated SPDK process; its failure stalls or kills the entire fleet (the system's own analysis, TODO #6). For a fleet whose stated recovery model is "reboot", loss of the root target defeats that model. Availability of the root service is a security property of this system.	Medium	Add to the register (availability class). The drain-gated long-lived target design mitigates operational restarts; structural treatment is the already-identified multipath/ANA replica design plus documented RTO. Note ctrl_loss_tmo tuning as the cheap interim mitigation.
F-06	Cross-protocol reuse of the TPM identity key. The same key authenticates EAP-TLS, derives the NVMe hostnqn, and authenticates agent mTLS ("one identity, three stages"). This is an explicit, documented design choice with real benefits (one enrolment, one revocation point); the residual concern is cross-protocol signing-oracle exposure (a signature obtained in one protocol context being replayable in another) and a single revocation event disabling all three functions at once.	Low (observation)	No change required at STARFLEET ROUTINE. Document a short analysis in the SSP: confirm the protocols' signed structures are domain-separated (TLS 1.2 vs 1.3 CertificateVerify context strings largely provide this), and document the operational plan for the revocation blast radius.
F-07	No continuous assurance that runtime posture matches assessed posture. SELinux-permissive and version-drift are surfaced via fleet-agent telemetry (good), but nothing yet alerts on: Secure Boot state, debug-shell presence, or fapolicyd non-enforcing. The system has the telemetry channel to make assessed-posture drift visible fleet-wide.	Low	Extend agent facts to include SB state (SecureBoot EFI var), fapolicyd enforcement, and cmdline hash; alert on drift in the manager. Complements R-13.
F-08	DNS/DHCP are untrusted inputs by design — but the pattern is undocumented and two flows escape it. The architecture consistently authenticates endpoints above name resolution (manager → mTLS; NTP → NTS, post-P-18; UKI → Secure Boot signature; NVMe root → dm-verity), so DNSSEC/DoT would add little and is not recommended. However: (a) the kiosk URL is plain HTTP — a DNS or DHCP (option-15 domain) spoofer serves an arbitrary page fullscreen on every workstation's only user interface, with the Chromium policy's PNA allowance to the loopback host-info agent as reachable attack surface; (b) a spoofer can serve an older, still-validly-signed UKI (rollback) — Secure Boot does not prevent this; the design's anti-rollback mechanisms (dbx revocation / TPM monotonic counter, design v2 §6) are unimplemented and unmentioned in the register; (c) the plaintext audit offload is DNS-spoofable today — closed as a side effect of P-09's TLS, but that coverage was untraceable until now.	Medium (driver: kiosk content flow)	POA&M P-24. State the "DNS/DHCP untrusted; authenticate above resolution" principle explicitly in the SSP; serve the kiosk over TLS with a fleet-CA-signed cert (CA pinned via Chromium policy) rather than deploying DNSSEC; record the UKI-rollback residual against R-13 with the design-§6 anti-rollback treatment; cross-reference P-09 for the audit-stream closure.

6. Essential Eight maturity (assessor view)

The SSP's self-assessment (§6) is broadly fair. Assessor adjustments: application control is genuinely strong post-2026-07-04 (and, notably, was over-claimed before that fix — the honest correction is credited); "restrict admin privileges" and "MFA" should both be read as partial until the host SSH access model gains rotation and the management plane is authorised; "patching" remains process-only until R-10 defines an SLA. Against Essential Eight maturity levels, the system sits at approximately ML1–ML2 overall with individual mitigations (application control, user application hardening) performing at ML3-like strength — but E8 maturity formally requires the whole mitigation strategy set at level, so no formal level claim above ML1 should be made yet.

7. Recommendation to the Authorising Officer

7.1 Determination

• Production ATO: not recommended at this time.
• Interim authorisation (lab/pre-production, isolated LAN, no production data): recommended, valid for a defined period (suggest ≤ 6 months), conditional on the POA&M being maintained and on no production or classified data being processed.

7.2 Conditions precedent for a production ATO

The following must be closed, then verified at a delta assessment at which the assessor witnesses (not merely reviews) the evidence:

1. Witness the secure-path bench test (R-01 + R-08): real RADIUS CA; port Authorized; macsec0 addressed; MKA survives switch-root; NVMe root mounted over macsec0; lease renewal on macsec0 past expiry.
2. Production build profile (F-01): a signed, SB-enforcing, STIG-on, debug-shell-off, dot1x-on build produced by CI with hard assertions; assessor verifies sbverify on UKI + iPXE, mokutil --sb-state on sample hosts, absence of the debug shell, and a valid STIG deviations report with 0 unjustified REVIEW rows on the assessed digest (R-02, R-03, R-13).
3. Governance: AO/System Owner/CISO appointed; data classification confirmed by the System Owner; IRP, continuous-monitoring plan and log-retention policy authored and approved (R-12, §2.1 gaps).
4. Log transport and retention (R-07): TLS on both offload hops; retention configured; Wazuh credentials rotated and dashboard/API restricted.
5. ISM reconciliation (P-17): Annex A identifiers reconciled to the May 2026 ISM, unmapped new controls dispositioned.
6. Management plane: either a granted authorisation for the connected system (R-14) or an AO-accepted interim risk position covering the fleet CA's key protection specifically.
7. Witness re-verifications: reproducible build (two builds, identical verity root hash — including post-semanage policy-store stability); fapolicyd denial of a novel binary on the overlay root; USBGuard mass-storage block with console HID intact; agent actuators inert (R-15).

Items R-04, R-05, R-09, R-10, R-11, F-02, F-03, F-05, F-08 may, at the AO's discretion, be accepted as residual risk with POA&M target dates for a production ATO at STARFLEET ROUTINE on an isolated/managed network, given the compensating controls recorded in Annex A. They are not recommended for indefinite acceptance.

7.3 Revocation triggers the AO should set

• Enabling fleet-agent actuators without a delta assessment (R-15 / §5.1).
• Processing data above the confirmed classification.
• Any unsigned or SB-off build deployed outside the lab (R-13 / F-01).
• Lapse of the POA&M review cadence (suggest quarterly).

---

End of SAR. The consolidated remediation plan with owners, milestones and target dates is at irap-poam.md.