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](irap-poam.md) (this assessment); SSP [Annex A](ssp-annex-a-ism-residual-risk.md) 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](irap-poam.md).*