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.1 (DRAFT — pre-assessment)
Date	2026-06-19
Author / maintainer	System Owner (delegate)
Status	Lab / pre-production. 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)

1. UEFI Secure Boot measures and verifies the UKI signature (vendor/Secure Boot key) before execution.
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 0x81010001); the client certificate is read from TPM NV index 0x01800001.
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. 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. The system is functional in a lab configuration. Several controls are partial or deferred and are tracked as residual risks with treatment plans (Annex A §3). The security-critical path (802.1X/MACsec) is implemented but not yet bench-verified end-to-end and is currently disabled in test builds (disable_dot1x=true) — this is the single largest gate on a production authorisation.

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).
• System hardening: DISA STIG baseline via OpenSCAP/SSG with a documented tailoring; SELinux enforcing; fapolicyd application allow-listing (the exec guard for the writable RAM overlay that dm-verity cannot cover); key-only SSH, root login disabled, hardened ciphers/MACs/KEX; kiosk lockdown (single locked browser, no shell/navigation).
• 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; NVMe/TCP and audit offload plaintext on the isolated LAN; NOPASSWD key-only admin; placeholder RADIUS CA. See Annex A residual risks.

5.3 Detect

• auditd enabled with STIG audit rules; kernel audit=1 + audit_backlog_limit in the signed cmdline.
• Centralised log offload via rsyslog (audisp-syslog → rsyslog omfwd, disk-assisted queue) to a dedicated audit collector (serving/audit-collector/).
• Gaps: offload currently plaintext (TLS planned, R-07); offload is local site only; no SIEM correlation/alerting defined yet.

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 one trusted kiosk binary) executables run.
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 (NOPASSWD, see R-05); no per-host/rotatable model 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 temporarily report-only / disabled in CI (enable_stig=false).	Medium	Treat — re-enable 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; no per-host or rotatable access model.	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, single-site, no SIEM alerting.	Medium	Treat — TLS offload + monitoring on roadmap.
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.	Low–Medium	Accept (isolated LAN) / treat with explicit allow-rules.

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.