OpenCyber AcademyLesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Framing the decision"]
N3["1.3 Expected cost"]
N4["Lab — comparing options"]
N5["1.4 Lab result"]
N6["1.5 Beyond money"]
N7["1.6 Sensitivity"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Framing the decision"]
N3["1.3 Expected cost"]
N4["Lab — comparing options"]
N5["1.4 Lab result"]
N6["1.5 Beyond money"]
N7["1.6 Sensitivity"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The case]
|
v
[1.2 Framing the decision]
|
v
[1.3 Expected cost]
|
v
[Lab — comparing options]
|
v
[1.4 Lab result]
|
v
[1.5 Beyond money]
|
v
[1.6 Sensitivity]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) frame application-security decisions as choices under uncertainty; (2) compare options using expected cost; (3) account for non-financial harms; (4) document decisions for accountability.
1.1 The case
Hannah Brooks is product security lead at the fictional Northbridge Bank and a postgraduate student at the fictional Calder College, tutored by Dr Ravi Menon. In February, a routine update of a third-party analytics software development kit (SDK) in Northbridge's mobile banking app began sending approximate device location to the SDK vendor. Nobody reviewed SDK updates; the update arrived automatically with a dependency refresh. A privacy engineer noticed the new network traffic 19 days later. No account data was exposed, but customers' location data had gone to a third party without a lawful basis. The bank reported the incident to its data protection regulator. Hannah's course follows her as she decides how the bank should govern third-party code in its apps.
1.2 Framing the decision
Hannah's board asks: what should we do about third-party SDKs? She frames three options: continue without review; review every SDK update before release; or remove third-party SDKs and build analytics in-house.
The February incident had already shown the cost of the first option: an analytics SDK update began collecting location data, and nobody at Northbridge noticed for nineteen days. The board wanted options it could compare, so Hannah describes each one in the same terms: what it costs to run, what it would have caught in February, and what it would change for the mobile teams.
1.3 Expected cost
For each option she estimates the annual cost of the control, the probability of a similar incident in a year and its impact (fines, remediation, customer trust), using the February incident and industry reports as anchors.
Every probability is an estimate, so she writes down where each one came from and who she asked. The impact figure of 900k combines remediation work, the regulator's likely response and an allowance for customers leaving. She keeps the inputs in a small table the board can question, rather than presenting a single total.
Lab — comparing options
"""Expected annual cost of three SDK-governance options (synthetic estimates, GBP thousands)."""
options = {"no review": (0, 0.30, 900), "review on update": (60, 0.08, 900), "remove SDKs, in-house analytics": (220, 0.02, 900)}
for name, (cost, p, impact) in options.items():
print(f"{name:32} control {cost:4}k + {p:.2f} x {impact}k = {cost + p * impact:6.1f}k")
Run with python3 lab_decision.py. Verified output:
no review control 0k + 0.30 x 900k = 270.0k
review on update control 60k + 0.08 x 900k = 132.0k
remove SDKs, in-house analytics control 220k + 0.02 x 900k = 238.0k
1.4 Lab result
With an impact of 900k, "no review" has an expected cost of 270k (0.30 × 900k). "Review on update" costs 60k plus 0.08 × 900k, totalling 132k. Removing SDKs costs 220k plus 0.02 × 900k, totalling 238k. On these estimates, reviewing updates is cheapest overall.
The ranking holds only as long as the estimates are roughly right, which is why the next step tests how far they can move. Hannah also notes that the 60k for review is mostly staff time, which the bank can measure after the first year.
1.5 Beyond money
Some harms are not well captured in money: customer trust, regulatory relationships, and the bank's duty to treat customers fairly. Hannah lists these alongside the numbers and notes that they strengthen the case for review rather than changing the ranking.
She does not convert trust into a money figure, because any number she chose would look more precise than it is. Instead, the board paper keeps a separate short list of harms that the expected-cost table leaves out, so the directors weigh them openly when they decide.
1.6 Sensitivity
If the incident probability without review were 0.15 instead of 0.30, "no review" would cost 135k, almost tied with review. Hannah shows the board this sensitivity so they see the decision depends on her estimates.
She also checks the other direction: if the review control cost twice as much, it would still be cheaper than having no review at all. The board can therefore see which estimates matter most to the choice and which ones barely move it. The directors agree that the estimates should be revisited after a year of data from the review process.
1.7 Accountability
The decision, options, estimates and sensitivity are recorded and signed by the chief information security officer (CISO), so later reviewers can see what was known and why the choice was made.
The record also names the estimates most likely to be wrong and when they will be checked, so a later review can compare them with what actually happened. Hannah stores it with the February incident report, because the two documents explain each other. When the evaluation in chapter 6 reports, she adds its results to the same file.
Worked example
The board approves "review on update" plus a plan to reduce the number of SDKs over two years. Hannah sets up a review process (chapter 5) and an evaluation (chapter 6) to check whether the estimates hold.
Synthetic case. Northbridge Bank, Calder College, the SDK, its vendor and all figures are synthetic.
Errors and limits
Probability estimates for rare events are uncertain; present ranges and sensitivities, not single numbers.
Exercises
- EX001 — February incident. Summarise the February incident.
Show marking criteria
Rubric: 3 = SDK update sent location to vendor; unreviewed; found after 19 days; reported to regulator; 2 = partial; 1 = one; 0 = none. - EX002 — Three options. What were the three options?
Show marking criteria
Rubric: 3 = no review; review on update; remove SDKs; 2 = two; 1 = one; 0 = none. - EX003 — Lab totals. Give the expected cost of each option.
Show marking criteria
Rubric: 3 = 270k, 132k, 238k; 2 = two; 1 = one; 0 = none. - EX004 — Sensitivity. What happens if the no-review probability is 0.15?
Show marking criteria
Rubric: 3 = 135k, near tie; 2 = partial; 1 = vague; 0 = none. - EX005 — Non-financial harms. Name two harms not well captured in money.
Show marking criteria
Rubric: 3 = trust, regulator relationship, fairness (two); 2 = one; 1 = vague; 0 = none.
Synthesis
Frame choices, compare expected costs with sensitivity, add non-financial harms and record the decision.