Dissertation Defense: Engineering Cyber Resilience in Spacecraft Flight Software
I held my defense last week and it went well. The dissertation is now published. Roughly the first half covers material I've written about here in the paper summaries -- the rest is new, and there's a lot of it.
The work is organized around four research questions: what attack surfaces matter most for mission integrity in contemporary flight software; what minimum testable requirements preserve mission-critical control and availability; how to embed resilience in the architecture itself; and how to measure cyber resilience quantitatively across architectures. The new chapters below answer them.
Chapter 4: Requirements Derivation
The requirements paper covered the workflow at a high level. The dissertation takes it further: applying secure-by-component to the Command and Data Handling subsystem in full, decomposing it into secure blocks, and generating testable "shall" statements with explicit verification approaches and traceability back to threats. The output is a per-component requirements set with verification criteria attached, ready to hand to an implementation team.
Chapter 5: Alcyone Architecture
Alcyone moves from "blueprint" to design of record. Five subsystems with bounded interfaces -- Command and Data Handling, Supervision and Recovery, Support Services, Standards-Shaped External Interfaces, and Runtime/HAL -- each mapped to specific Chapter 4 requirements. The chapter also covers Rust's safety guarantees, type-system contracts, and adoption constraints, plus a head-to-head against cFS and F' on which security properties each architecture provides, which Alcyone adds, and where the trade-offs sit.
Chapter 6: Experimental Evaluation
Five experiments. Experiment 1 is the headline: 13 paired adversarial scenarios, Alcyone versus a cFS baseline.
- Onboard detection: 12 (Alcyone) vs 3 (cFS)
- Mean detection time over detected scenarios: 0.83 s vs 7.80 s
- Mean resilience ratio (functionality retained relative to nominal): 0.941 vs 0.722
- Mean blast radius: 1.3 vs 3.0 mission functions
The other four experiments characterize the result: Experiment 2 maps cyber resilience to NIST goals; Experiment 3 sweeps attack intensity to find threshold behavior; Experiment 4 varies attack timing across mission phases; and Experiment 5 ablates the IDS configuration to show which detectors actually carry the detection performance.
Chapter 7: Discussion
Four research questions answered: threat landscape and salient surfaces, minimum and testable requirements, an architecture that embeds resilience by construction, and how to evaluate it.
The technical implications are about enforcement surfaces and evidence integrity -- making security claims that point at something in the code rather than something in the prose. The operational implications are bigger: budgeted autonomous response (the spacecraft gets N seconds to act before deferring to ground), reuse and risk as program gates, and what would have to change in acquisition standards for any of this to actually show up in a flight program.
Chapter 8: Conclusion
Four contributions: a threat-informed methodology, a worked secure-by-component application, the Alcyone architecture, and a quantitative evaluation framework that produces the kind of evidence cyber resilience claims usually lack. The implications point at where the work needs to go next -- formal verification of FSW components, hardware-rooted trust, and compromised-node resilience for multi-spacecraft architectures.