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](ssp-annex-a-ism-residual-risk.md); [Architecture design v2](diskless-fleet-design-v2.pdf); [Design errata](design-v2-errata.md); [STIG deviation register](stig-deviations.md); [Backlog / POA&M source](TODO.md) |

> **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](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](../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](ssp-annex-a-ism-residual-risk.md#3-residual-risk-register)**.
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](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](ssp-annex-a-ism-residual-risk.md) for the ISM control
cross-reference and the full residual-risk register.*