Project Alpha

A mock system engineered through the NIST SP 800-160 Vol 1 Systems Security Engineering (SSE) process

Introduction

Project Alpha is a mock system built to demonstrate applying NIST SP 800-160 Volume 1's Systems Security Engineering (SSE) process, from stakeholder needs and requirements definition through architecture, design, risk analysis, and verification, as a worked example across future write-ups. Where the site's existing reference system takes a compliance-first view of security controls, Project Alpha takes an engineering-first view: security requirements are derived and traced through the system life cycle rather than checked off against a baseline after the fact.

System Concept

Project Alpha is deliberately staged. It starts as a single laptop with simple use cases and grows through successive materiel release (MR) cycles, each one adding scope, users, interfaces, and complexity, until it becomes a system of systems. Every MR gets its own pass through the SSE process below, so later write-ups can show how requirements, architecture, and risk posture change as the system matures rather than treating it as fixed from the outset.

Materiel Release Roadmap

  • MR1: A single laptop with simple use cases. The baseline system this case study starts from.
  • MR2 and beyond: [Content to be added] Each subsequent release incrementally increases scope and complexity, working toward a system of systems.

System Boundary

The boundary is the line that says what Project Alpha is and what it is not. It gets drawn once per release and then redrawn as the system grows, so what follows is a working definition rather than a fixed one. At MR1 there is very little to draw: one laptop, no interconnects, so the boundary is the device and the environment of operation is just wherever it happens to sit and whoever is using it.

Inside the boundary

[Content to be added]

Outside the boundary

[Content to be added]

Interfaces crossing the boundary

At MR1 there are no interconnects, so nothing crosses the boundary yet and the interface list is empty by design rather than by omission.

[Content to be added]

Trust boundaries and assumptions

[Content to be added]

Boundary changes by release

  • MR1: [Content to be added] A single laptop with no interconnects.
  • MR2 and beyond: [Content to be added]

SSE Technical Processes

[Content to be added]

Security Requirements & Risk Analysis

Requirements will start life in a spreadsheet, or similar. A stretch goal is trialling a proper requirements management tool such as DOORS (if a trial license is available) or an equivalent, and maaaybe adding MBSE. Both are kept deliberately lightweight as I'm time poor (new puppy is killing me) and being a novice with tools like Rhapsody and Cameo; the goal is a usable, traceable requirements set for Project Alpha, nothing fancy.

[Content to be added]

NIST SP 800-53 Control Mapping

[Content to be added]

Future References

Related NIST publications this case study is expected to draw on as it's fleshed out:

  • NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, the overarching risk management process this SSE effort feeds into.
  • NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, the control catalog referenced in the mapping above.
  • NIST SP 800-53A Rev. 5: Assessing Security and Privacy Controls in Information Systems and Organizations, for verifying controls once they're mapped.
  • NIST SP 800-53B: Control Baselines for Information Systems and Organizations, for selecting the LOW/MODERATE/HIGH baseline Project Alpha targets.
  • NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security, if Project Alpha's design extends to an OT/ICS boundary.
  • NIST SP 800-160 Vol. 2 Rev. 1: Developing Cyber-Resilient Systems: A Systems Security Engineering Approach, extending the Volume 1 SSE process above with cyber resiliency techniques.
  • NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, for the acquisition and supplier side of the system life cycle.
  • NIST SP 800-218: Secure Software Development Framework (SSDF), for any software components built as part of the system.