Tightening Stig hardening
This commit is contained in:
Audiobuzz
+261
@@ -0,0 +1,261 @@
|
||||
# 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.*
|
||||
Reference in New Issue
Block a user