diskless-workstation/docs/ssp.md

System Security Plan (SSP) — Diskless Fleet Boot System

Protective marking: OFFICIAL: Sensitive (sample marking — set per the organisation's classification of the highest-sensitivity data the system handles; an SSP that describes the security architecture is normally marked at or one level above the system's data classification.)

A&A framework: Australian Government — Protective Security Policy Framework (PSPF) + ASD Information Security Manual (ISM). This document is the System Security Plan required by the ISM Guidelines for cyber security documentation and is the primary input to the IRAP security assessment and the Authorising Officer's authorisation (ATO) decision.

Field	Value
System name	Diskless Fleet Boot System ("the fleet")
Document type	System Security Plan (SSP)
Version	0.2 (DRAFT — pre-assessment)
Date	2026-06-27
Author / maintainer	System Owner (delegate)
Status	Lab / pre-production. STIG hardening applied + bench-verified; UEFI Secure Boot signing verified enforcing on real hardware (VM HTTP + EliteBook 820 PXE); secure path (802.1X/MACsec) not yet bench-verified.
Companion documents	Annex A — ISM control cross-reference & residual risk; Architecture design v2; Design errata; STIG deviation register; Backlog / POA&M source

Currency caveat (read before relying on control numbers). This SSP and its annex are drafted against the ISM structure as understood to a January 2026 baseline. The engagement specifies the May 2026 ISM. The ISM is reissued on a quarterly cadence and control identifiers are added, retired and renumbered between releases. Every ISM-NNNN identifier in Annex A is therefore representative and MUST be validated by the IRAP assessor against the actual May 2026 release before the assessment is relied upon. The intent of each control mapping is stable; the number may not be.

---

1. Purpose and scope

This SSP describes the security architecture, the security controls implemented, and the residual risk of the Diskless Fleet Boot System — a fleet of diskless workstations that network-boot a signed, immutable operating system over the wire and hold no persistent local state. It supports an Australian Assessment and Authorisation (A&A) process: it is the document an IRAP assessor evaluates to produce the Security Assessment Report (SAR), and that the Authorising Officer (AO) uses to make a risk-based Authority to Operate (ATO) decision.

In scope: the boot chain (UEFI HTTP boot → signed UKI → dracut initramfs → network authentication → encrypted root mount → verified read-only OS), the runtime workstation OS image, the host's cryptographic identity (TPM), and the hardening baseline applied to the image.

Out of scope (separately authorised): the lab serving stack (DHCP/HTTP/ NVMe-oF target, audit collector — serving/), the 802.1X authenticator/RADIUS infrastructure, the certificate enrolment authority, the network fabric, and physical security of the facility. These are dependencies referenced here but carry their own security documentation and authorisation.

2. System description

2.1 Overview

Each host is diskless: it has no installed operating system and no writable persistent storage that participates in identity. At power-on it performs UEFI HTTP boot, fetches a signed Unified Kernel Image (UKI), and assembles a running system whose root filesystem is an immutable, cryptographically verified image mounted over the network. All host identity is derived at runtime from a hardware Trusted Platform Module (TPM); nothing host-specific exists in any build artifact.

A release is a signed UKI plus a root image, packaged together as a FROM-scratch OCI artifact image and pinned by digest in a deployment manifest. One commit = one release = one digest = one manifest entry.

2.2 Boot and trust chain (control flow)

Boot transport (two paths, auto-selected): HTTP-boot-capable firmware fetches the UKI directly over UEFI HTTP boot. Firmware without HTTP boot (e.g. HP EliteBook 820 G4) falls back to PXE → iPXE → HTTP (dnsmasq serves iPXE over TFTP, which chainloads the same UKI). Both land on the same signed UKI. Lab status: Secure Boot is currently OFF and the UKI/iPXE are unsigned — signing is wired in CI and the key procedure is documented (secure-boot-keys.md) but not yet enforced (residual R-03/signing in Annex A).

1. UEFI Secure Boot (when enabled) measures and verifies the UKI signature against the enrolled db key before execution. On the PXE/iPXE path the iPXE binary is likewise verified against db; only the fleet's own db need be enrolled (no Microsoft CA / shim).
2. UKI (systemd-stub) carries the kernel, the --no-hostonly initramfs, and an immutable, signed kernel command line (includes the dm-verity root hash and STIG kernel parameters). No GRUB.
3. Initramfs (dracut) brings up the NIC and performs 802.1X EAP-TLS network authentication using a private key held in the TPM (persistent handle 0x81000100); the client certificate is read from TPM NV index 0x01800100.
4. On authorisation, MACsec is established on the access link (link-layer encryption/integrity); the host then obtains an IP on the MACsec interface via DHCP.
5. The host connects its root over NVMe/TCP, maps it through dm-verity (block-level integrity against the signed root hash in the UKI cmdline), and mounts the erofs read-only root.
6. A tmpfs (RAM) volatile overlay (systemd.volatile=overlay) provides the writable layer. It is discarded at power-off — the host returns to a known, verified state every boot.
7. switch-root into the real system; NetworkManager renews the DHCP lease so the network-mounted root stays alive; the host derives its NVMe hostnqn from the TPM certificate serial and (kiosk builds) launches the locked-down kiosk.

2.3 Authorisation boundary

The authorisation boundary is the running workstation host: the UKI, the initramfs and its custom 802.1X/MACsec dracut module, the verified erofs root, the tmpfs overlay, the TPM-backed identity, and the hardened OS configuration. The boundary's external interfaces are: (a) the access link (802.1X-controlled port, MACsec-encrypted); (b) the NVMe/TCP root storage session; (c) outbound audit log forwarding; (d) the kiosk application endpoint the browser renders; (e) the boot transport (UEFI HTTP boot, or PXE/TFTP→iPXE) that delivers the UKI; and (f) USB/peripheral ports, now mediated by USBGuard (§5.2). Each crossing is a control point addressed in Annex A.

2.4 Data and classification

• Data at rest in the artifact: none that is host-specific or sensitive. The image is generic to the whole fleet by design (Architecture invariant #1 — no per-host state in any artifact, ever).
• Host identity / key material: the EAP-TLS private key never leaves the TPM; the certificate is read from TPM NV. Signing keys for the UKI are CI/HSM-held and never enter the build VM or the repository.
• Data in transit: access link protected by MACsec; NVMe/TCP root and audit-log offload currently plaintext on an isolated lab LAN (see residual risk R-04, R-07 in Annex A).
• Data at rest in the overlay: ephemeral, RAM-only, discarded at power-off.

The system's data classification governs this SSP's marking and the required ISM control set. The classification of the data rendered by the kiosk application and accessible from the workstation must be confirmed with the System Owner; this draft assumes an OFFICIAL / OFFICIAL: Sensitive working classification and should be re-baselined if the system processes PROTECTED or above (which raises additional ISM control obligations, e.g. ASD-approved cryptography enforcement, gateway controls, and stricter media handling).

3. Security governance and A&A roles

Role	Responsibility (PSPF/ISM)	Assignment
Authorising Officer (AO)	Accepts residual risk; grants/denies/revokes the ATO.	TBA — appoint before assessment
System Owner	Accountable for the system's security posture and this SSP.	TBA
Chief Information Security Officer (CISO)	Organisational cyber security oversight; advises the AO.	TBA
IRAP Assessor	Independent assessment of control implementation effectiveness; produces the SAR.	Engaged for assessment
System Manager / Administrators	Day-to-day operation, patching, incident response, continuous monitoring.	Fleet platform team
Build / release pipeline owner	Integrity of the CI build, signing, and digest-pinned deployment.	Fleet platform team

4. A&A process and status

This system follows the ISM A&A lifecycle:

1. Define the system, its boundary and data classification (this SSP §2).
2. Select the applicable ISM controls (Annex A, driven by classification).
3. Implement the controls (this SSP §5–§6; the codebase is the implementation of record).
4. Assess — IRAP assessor evaluates effectiveness → Security Assessment Report (SAR).
5. Authorise — AO weighs residual risk (Annex A risk register) → ATO.
6. Monitor — continuous monitoring and a maintained Plan of Action & Milestones (POA&M) (this repo's TODO.md is the working POA&M source).

Current status: Pre-assessment DRAFT (v0.2, updated 2026-06-27). The system is functional in a lab configuration. Progress since v0.1 (2026-06-20): DISA STIG hardening applied and bench-verified on a real build (kiosk, key-only SSH, audit offload, DHCP-named host, NVMe/verity root all good with hardening on); USBGuard device control enabled + verified; admin confined to staff_u; UEFI Secure Boot signing verified enforcing end-to-end on real hardware (CI-signed UKI under SB on a VM/HTTP, and the signed iPXE→UKI chain under SB on an EliteBook 820 G4/PXE, with db/KEK/PK enrolled via fleet-sb-enroll); and — newly — a Wazuh SIEM (dedicated multi-node, agentless) ingesting the fleet auditd stream with a custom decoder/rules, decode + alert bench-verified 2026-06-27, lifting the "Detect" pillar from log-collection-only to analysis + alerting. Several controls remain partial or deferred, tracked as residual risks with treatments (Annex A §3). The largest remaining gates on a production ATO: (a) the secure path (802.1X/MACsec) is implemented but not yet bench-verified and is disabled in test builds (disable_dot1x=true, R-01); (b) a lab-only passwordless-root debug shell must be removed (R-02). Boot-chain signing / Secure Boot — a major v0.1 gate — is now demonstrated on hardware; the residual (R-13) is reduced to making signed + Secure-Boot-on the standing default for every production host/build.

5. Security control implementation — by ISM cyber security principle

The ISM organises controls under four principles: Govern, Protect, Detect, Respond. Annex A gives the line-by-line control cross-reference; this section summarises the implementation posture.

5.1 Govern

• Documented architecture (design v2 + errata), enforced architecture invariants (CLAUDE.md), and a maintained backlog/POA&M.
• Reproducible, digest-pinned releases; one release = one digest = one manifest commit; rollback = revert the commit.
• Signing keys held outside the repo and build VM (CI/HSM).
• Gaps: formal SRMP, IRP, and continuous-monitoring plan to be authored; A&A roles to be appointed (§3).

5.2 Protect

• Identity & authentication: mutual 802.1X EAP-TLS with a non-exportable TPM key; network access controlled at the switch port.
• Link protection: MACsec on the access link.
• Boot & OS integrity: Secure Boot + signed UKI with an immutable cmdline; dm-verity read-only root (continuous cryptographic integrity); erofs immutable filesystem; reproducible build (verity hash is a pure function of inputs). Signing is wired in CI (sbsign/ukify via SB_KEY/SB_CERT secrets) with a documented PK/KEK/db key + enrolment procedure (secure-boot-keys.md) and a baked, efitools-free enrolment helper (fleet-sb-enroll); not yet enforced in the lab (SB OFF, unsigned — see Annex A).
• System hardening (DISA STIG applied + bench-verified 2026-06-20): STIG baseline via OpenSCAP/SSG with a documented tailoring + per-build deviations report; all REVIEW rows triaged. SELinux enforcing; fapolicyd application allow-listing (the exec guard for the writable RAM overlay dm-verity cannot cover); USBGuard enforcing (ImplicitPolicyTarget=block + a hardware-independent HID/hub allowlist + LinuxAudit — verified blocks USB mass storage while keeping console input; device/removable-media control); key-only SSH, root login disabled, hardened ciphers/MACs/KEX (note: STIG crypto policy drops ed25519 → admin key must be ECDSA/RSA); kiosk lockdown (single locked browser, no shell/navigation); postfix removed (no local MTA — audit-failure notification rides the remote offload, not email).
• Privileged access: single key-only wheel admin, root locked. The admin is now confined to the staff_u SELinux user with a sudoers role/type transition (sysadm_r/sysadm_t) so privilege elevation re-labels the SELinux context (STIG selinux_context_elevation_for_sudo). Still NOPASSWD (the account is passwordless/key-only) and fleet-generic — see R-05.
• No persistent attack surface: diskless; overlay discarded each boot; no per-host secrets in the image.
• Gaps / decisions: FIPS OFF (lab phase); host firewall disabled (the workstation; the serving host's ufw is configured); NVMe/TCP and audit offload plaintext on the isolated LAN; NOPASSWD admin; placeholder RADIUS CA; signing not yet enforced (SB OFF). See Annex A residual risks.

5.3 Detect

• auditd enabled with STIG audit rules; kernel audit=1 + audit_backlog_limit in the signed cmdline. USBGuard device events logged via the LinuxAudit backend. auditd space_left_action repointed to syslog (no local MTA), so audit-volume alerts ride the remote offload.
• Centralised log offload via rsyslog (audisp-syslog → rsyslog omfwd, disk-assisted queue) to a dedicated audit collector (serving/audit-collector/). Bench-verified end-to-end 2026-06-20 (records reach the collector, per-source-host files).
• SIEM analysis + alerting (Wazuh) — the collector relays the auditd stream to a dedicated multi-node Wazuh instance (wazuh1.bitasylum.org); ingestion is agentless (no agent/state in the diskless image, invariant #1). A custom fleet-auditd decoder + rules handle the STIG name_format=hostname (node= prefix) and surface events in the fleet_audit group with severity by type (auth, privilege/USER_CMD, SELinux/AVC). Decode + alert bench-verified 2026-06-27 (wazuh-logtest + a live sudo surfacing USER_CMD/CRED_* in the dashboard). Config is declarative (serving/siem/, mounted via /wazuh-config-mount).
• Gaps: both offload hops (host→collector, collector→Wazuh) currently plaintext (TLS planned, R-07); log retention/archival (ISM) not yet configured; default Wazuh credentials to be rotated before production.

5.4 Respond

• Known-good recovery is inherent: a host returns to a verified state on reboot; a bad release is rolled back by reverting one manifest commit (digest pin).
• Gaps: formal Incident Response Plan, log-retention policy, and break-glass/forensics procedure (the diskless model complicates live forensics — RAM overlay is volatile) to be authored.

6. Essential Eight alignment (indicative)

The Essential Eight is mitigation guidance, not a substitute for the ISM, but the AO will expect a maturity view:

Mitigation	Posture	Notes
Application control	Strong	fapolicyd allow-listing + immutable verified root; only RPM-trusted (plus two trusted local binaries: kiosk-session, fleet-sb-enroll) executables run. USBGuard enforces device control on USB ports.
Patch applications	Process	Patching = rebuild + re-sign + redeploy a new digest; cadence/SLA to be defined.
Configure MS Office macros	N/A	No office suite; kiosk is a locked browser.
User application hardening	Strong (kiosk)	Chromium locked down via enterprise policy; no plugins/shell/nav.
Restrict admin privileges	Partial	Single key-only wheel admin, root locked, now SELinux-confined to staff_u with a sudo role/type transition (NOPASSWD, see R-05); no per-host/rotatable model or admin-MFA yet.
Patch operating systems	Process	Same rebuild/redeploy model; immutable image means uniform, atomic OS updates.
Multi-factor authentication	Strong (machine)	Host auth is certificate + TPM-bound key (something-the-machine-has, non-exportable). Human admin MFA to be addressed for the management plane.
Regular backups	N/A (by design)	Diskless, stateless hosts hold nothing to back up; recoverability is re-provisioning from a pinned digest. Backup applies to serving-side state, out of scope here.

7. Residual risk summary

The full residual-risk register is Annex A §3. The headline residual risks the AO must explicitly accept or treat before a production ATO:

ID	Residual risk	Rating (pre-treatment)	Disposition
R-01	Secure path (802.1X/MACsec) not yet bench-verified; currently disabled in test builds.	High	Treat — verify before production authorisation.
R-02	debug_shell=true bakes a passwordless root shell on a tty.	High	Treat — must be removed before production (lab-only).
R-03	STIG hardening applied + bench-verified (2026-06-20); residual is that CI ships unsigned, Secure Boot OFF and enable_stig must be confirmed on for production builds.	Medium	Treat — confirm enable_stig=true in CI + enforce signing/SB before assessment.
R-04	NVMe/TCP root traffic plaintext on the lab LAN.	Medium	Accept (isolated LAN) / treat for production.
R-05	NOPASSWD key-only admin (now staff_u-confined); no per-host/rotatable access model or admin-MFA.	Medium	Accept with compensating controls / roadmap.
R-06	FIPS off; ASD-approved-cryptography conformance not yet asserted.	Medium	Treat — required for PROTECTED+; revisit with signing.
R-07	Audit-log offload plaintext on both hops (host→collector, collector→Wazuh); log retention not yet configured. SIEM analysis + alerting now in place (Wazuh, decode+alert bench-verified 2026-06-27).	Low–Medium	Treat — TLS both hops + ISM retention/archival + rotate Wazuh creds before production.
R-08	Placeholder RADIUS CA in the repo; real trust anchor not yet provisioned.	Medium	Treat — environment-specific, before production.
R-09	Host firewall disabled (workstation).	Low–Medium	Accept (isolated LAN) / treat with explicit allow-rules.
R-13	Boot-chain signing not yet the standing default. Signing + Secure Boot enforcement verified end-to-end on hardware (VM HTTP UKI 2026-06-20; 820 PXE signed iPXE→UKI 2026-06-22), but unsigned/SB-OFF lab builds are still possible (CI signs only when SB_KEY/SB_CERT are set) and not all hosts have db enrolled.	Low	Treat — make signed + Secure-Boot-on the default for all production builds/hosts (set CI secrets; enrol db fleet-wide).

Each is detailed, ISM-cross-referenced, rated and assigned a treatment in Annex A.

8. Continuous monitoring and maintenance

• Build-time assurance: every release is reproducible (verity hash verified stable across two builds), the UKI/rootfs roothash coupling is a hard CI gate, and the STIG scan publishes a report + a deviations register per build.
• Runtime monitoring: auditd + centralised log offload; host returns to a verified state each boot.
• POA&M: docs/TODO.md is the live working POA&M; items feed Annex A treatments. The SSP and Annex A are re-baselined at each material architecture change and at each scheduled A&A review.

---

End of SSP. See Annex A for the ISM control cross-reference and the full residual-risk register.