Chapter 23 — Security architecture and engineering: threat and failure analysis | Engineering Security architecture and engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 23 — Security architecture and engineering: threat and failure analysis

Lesson map

Lesson 23 published. Map, example, EX067.

flowchart TD
  N0["Learning outcomes"]
  N1["23.1 STRIDE on the model"]
  N2["23.2 Fault tree for revenue loss"]
  N3["Lab — Fault tree for unreconciled revenue"]
  N4["23.3 Combining views"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX067"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["23.1 STRIDE on the model"]
  N2["23.2 Fault tree for revenue loss"]
  N3["Lab — Fault tree for unreconciled revenue"]
  N4["23.3 Combining views"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX067"]

[Learning outcomes]
    |
    v
[23.1 STRIDE on the model]
    |
    v
[23.2 Fault tree for revenue loss]
    |
    v
[Lab — Fault tree for unreconciled revenue]
    |
    v
[23.3 Combining views]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX067]

Learning outcomes

You will (1) threat-model the back office with STRIDE; (2) build a fault tree for a critical failure; (3) combine threat and failure views into prioritised risks.

23.1 STRIDE on the model

Using the data-flow model from chapter 22, Sofia and two engineers walk each element through STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege, following Shostack (2014). They find that the ingestion interface accepts records from any device presenting a certificate from the internal authority, including retired validators; that refund decisions are not logged with the approver's identity, enabling repudiation; and that a burst of malformed records could exhaust the journey-construction queue. Each threat gets an owner, a proposed mitigation and a link to the requirement it affects.

23.2 Fault tree for revenue loss

Threat modelling asks what attackers can do; failure analysis asks how the system can fail, whatever the cause. Sofia builds a fault tree for the top event that a day's fare revenue cannot be reconciled. It occurs if tap records are lost or if the fare calculation is wrong. Records are lost if both the validator buffer overflows and the upload link is down for long enough. She assigns synthetic probabilities and computes the top-event probability with AND and OR gates, assuming independence. The lab below shows the calculation and which branch dominates.

Lab — Fault tree for unreconciled revenue

# Fault tree for "day's revenue cannot be reconciled" with synthetic daily probabilities (independence assumed).
p_buffer_overflow = 0.02
p_link_down_long = 0.05
p_records_lost = p_buffer_overflow * p_link_down_long          # AND gate
p_tariff_change_day = 0.10
p_calc_error_given_change = 0.08
p_calc_error = p_tariff_change_day * p_calc_error_given_change  # AND gate
p_top = 1 - (1 - p_records_lost) * (1 - p_calc_error)            # OR gate
print(f"records lost      {p_records_lost:.4f}")
print(f"calculation error {p_calc_error:.4f}")
print(f"top event         {p_top:.4f}  (~{p_top*365:.1f} days/year)")

Run with python3 lab_fta.py. Verified output:

records lost      0.0010
calculation error 0.0080
top event         0.0090  (~3.3 days/year)

23.3 Combining views

The fault tree shows that calculation errors after tariff changes dominate the risk, more than lost records. The threat model shows that a malicious tariff table pushed through a compromised vendor account could cause exactly that failure. Combining the two views, Sofia rates signed and verified tariff tables as the top mitigation, because it addresses both accidental and malicious causes of the most likely failure. She notes that independence assumptions in fault trees can understate risk when one cause, such as a power cut, triggers several branches at once.

Worked example

Sofia runs a STRIDE session finding three threats, builds a fault tree for unreconciled revenue and prioritises signed tariff tables because both analyses point to tariff errors.

Synthetic case. Threats, probabilities and the fault tree are synthetic; Shostack (2014) is real.

Errors and limits

Fault-tree probabilities are often guesses; their ranking is more useful than absolute values. STRIDE can miss threats outside the model.

Exercises

EX067 — Retired validators. Which spoofing threat did the STRIDE session find? Rubric: 3 = retired validators with internal certificates could still submit records;; 2 = retired devices;; 1 = vague;; 0 = none.
EX068 — Dominant branch. Which branch dominated the fault tree in the lab? Rubric: 3 = fare calculation error after tariff change;; 2 = calculation;; 1 = lost records;; 0 = none.
EX069 — Independence caveat. Why can independence assumptions understate risk? Rubric: 3 = a common cause like a power cut can trigger several branches together;; 2 = common cause;; 1 = overstate;; 0 = none.

Synthesis

Threat modelling and fault trees together reveal which mitigations reduce both malicious and accidental failure.

Continue studying — chapter 23 of 50

← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →