# 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](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)

> **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](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](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](../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](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](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 **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](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.*