Lesson map
Lesson 46 published. Map, example, EX136.
flowchart TD
N0["Learning outcomes"]
N1["46.1 Implementation in the mirror"]
N2["46.2 The assurance case"]
N3["46.3 Late scope changes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX136"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["46.1 Implementation in the mirror"]
N2["46.2 The assurance case"]
N3["46.3 Late scope changes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX136"]
[Learning outcomes]
|
v
[46.1 Implementation in the mirror]
|
v
[46.2 The assurance case]
|
v
[46.3 Late scope changes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX136]
Learning outcomes
You will (1) implement and verify the capstone slice in a lab mirror; (2) build an assurance case linking claims to evidence; (3) manage scope changes late in a project.
46.1 Implementation in the mirror
Sofia implements the capstone slice in a lab mirror of the back office using synthetic validators and passengers. She configures ingestion with device certificates, replay detection and signed tariff loading; fare calculation with versioned tariffs; and dispute handling with dual approval. She reruns the verification suites from chapters 30 and 40, adapted to the new design, and adds tests for findings from the independent review. All in-scope security requirements now have passing tests, with two documented exceptions where the lab cannot reproduce production hardware.
46.2 The assurance case
An assurance case is a structured argument that a system meets its security claims, supported by evidence. Sofia's top claim is that the back-office slice protects fare integrity and passenger privacy within the stated scope. Sub-claims cover authentic inputs, correct calculation, controlled disputes and protected data. Each sub-claim links to requirements, controls, verification results and review findings. NIST SP 800-160 Vol. 1 Rev. 1 emphasises assurance as evidence-based confidence. The case makes gaps visible: one sub-claim relies only on design review, so she adds a test.
46.3 Late scope changes
Two months before submission, Corvia asks her to add refunds to the capstone. Sofia assesses the change: refunds would need new requirements, threat analysis and tests, risking the quality of everything else. She proposes instead to document how the architecture would extend to refunds, without implementing it, and to list it as future work. Her supervisor and Daniel agree. Managing scope means protecting the quality of committed work; saying no with a reasoned alternative is a professional skill, not a failure to cooperate.
Worked example
Sofia implements the slice in a lab mirror with passing tests, builds an assurance case that exposes a sub-claim lacking tests, and declines a late refund addition with a documented extension plan.
Synthetic case. The lab mirror, assurance case and request are synthetic; SP 800-160 Vol. 1 Rev. 1 is real.
Errors and limits
Assurance cases can give false confidence if evidence is weak. Lab exceptions must be validated later in production.
Exercises
- EX136 — Lab exceptions. How many requirements could not be tested in the lab, and why?
Show marking criteria
Rubric: 3 = two, because the lab cannot reproduce production hardware;; 2 = count and reason;; 1 = vague;; 0 = none. - EX137 — Assurance gap. What gap did the assurance case reveal?
Show marking criteria
Rubric: 3 = one sub-claim relied only on design review; a test was added;; 2 = review only;; 1 = vague;; 0 = none. - EX138 — Scope response. How did Sofia respond to the late refund request?
Show marking criteria
Rubric: 3 = proposed documenting the extension as future work instead of implementing;; 2 = alternative;; 1 = accepted;; 0 = none.
Synthesis
A capstone becomes convincing when implementation, verification and an assurance case link every claim to evidence within a protected scope.
Continue studying — chapter 46 of 50
← Chapter 45 (draft) · Course chapter index · Chapter 47 (draft) →