Chapter 35 — Capstone proposal

Chapter 35 — Capstone proposal

Lesson map

Lesson 35 published. Map, example, EX103.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 Choosing the capstone"]
  N2["35.2 Scope and deliverables"]
  N3["35.3 Evaluation and agreement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX103"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["35.1 Choosing the capstone"]
  N2["35.2 Scope and deliverables"]
  N3["35.3 Evaluation and agreement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX103"]

[Learning outcomes]
    |
    v
[35.1 Choosing the capstone]
    |
    v
[35.2 Scope and deliverables]
    |
    v
[35.3 Evaluation and agreement]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX103]

Learning outcomes

You will (1) propose a capstone that improves a trust service; (2) define scope, deliverables and evaluation; (3) obtain partner agreement.

35.1 Choosing the capstone

Priya proposes a capstone: a certificate and key inventory with automated discovery, expiry monitoring and owner alerts for Tidewell, building on lessons from the catalogue outage and the leaked-key exercise. The problem is clear, the partner needs it and the scope fits one academic year. She states the aim: every certificate and key in scope is listed with an owner, and no certificate expires without at least two alerts thirty and seven days before. She checks with Grace that the aim matches the consortium's priorities.

35.2 Scope and deliverables

In scope are public and internal TLS certificates and keys in the key service; out of scope are staff security keys and supplier-held keys. Deliverables are a discovery script that scans authorised hosts for certificates, an inventory database, an alerting service, documentation and a handover to Grace's team. The tools use the standard library and existing scanners; no cryptographic primitives are implemented. She lists risks, such as access to internal networks, with mitigations. She also writes a short data-handling plan for the scan results.

35.3 Evaluation and agreement

Priya defines evaluation: discovery finds all certificates in a test environment seeded with known certificates; alerts fire correctly for synthetic expiry dates; and staff can use the inventory without help after a short training. Grace signs the proposal, including authorisation to scan listed hosts. Dr. Echeverría approves it with one change: add a measure of false alerts, since noisy alerts would undermine adoption. Priya adds the false-alert target to the evaluation plan, aiming for fewer than one false alert per month, and agrees with Grace how alerts will be reviewed.

Worked example

Priya proposes a certificate and key inventory with discovery and alerts, scopes it, defines evaluation and obtains signed partner authorisation, adding a false-alert measure.

Synthetic case. The capstone is invented.

Errors and limits

Scanning beyond authorised hosts is not allowed even for good purposes. Overly broad scope threatens delivery.

Exercises

• EX103 — Capstone aim. State the capstone's aim. Rubric: 3 = every in-scope certificate and key listed with owner; no expiry without alerts at 30 and 7 days;; 2 = aim;; 1 = vague;; 0 = none.
• EX104 — Out of scope. What is out of scope? Rubric: 3 = staff security keys and supplier-held keys;; 2 = one;; 1 = vague;; 0 = none.
• EX105 — Added measure. What change did Dr. Echeverría require? Rubric: 3 = add a measure of false alerts;; 2 = false alerts;; 1 = vague;; 0 = none.

Synthesis

A capstone proposal with clear aim, scope, deliverables, evaluation and authorisation sets up a useful and feasible project.

Continue studying — chapter 35 of 40

← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →