Chapter 8 — Security architecture and engineering: supervised case analysis
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 The case"]
N2["8.2 Causes"]
N3["8.3 Recommendations"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 The case"]
N2["8.2 Causes"]
N3["8.3 Recommendations"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 The case]
|
v
[8.2 Causes]
|
v
[8.3 Recommendations]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) analyse an incident under supervision; (2) separate causes from symptoms; (3) recommend design changes.
8.1 The case
Ines gives Owen a supervised case from Thornbury's history, anonymised. A call centre agent changed a tenant's bank details for rent refunds after a caller passed basic identity questions. The refund went to a criminal's account. The tenant noticed weeks later. Owen reads the call notes, system logs and the investigation report. He builds a timeline first, then lists symptoms, such as the refund going astray, and separates them from causes. Ines reviews each step and challenges his early assumptions about who was at fault.
8.2 Causes
Owen identifies causes at several levels. The identity questions used information that criminals can find, such as date of birth and address. The system allowed bank details to change and a refund to be issued on the same day with no notification to the tenant. The agent was measured on call handling time, which discouraged extra checks. No single person failed; the design made the fraud easy. He references Saltzer and Schroeder's (1975) separation of privilege, which suggests that sensitive changes need more than one independent condition.
8.3 Recommendations
Owen recommends: confirming bank changes through a code sent to the tenant's registered phone or email; a seven-day hold on refunds after bank changes; automatic notification to the tenant of any change; and adjusting call centre measures so that verification time is not penalised. He estimates the cost and effect of each. Kwame and the head of finance accept all four. Ines notes that case analysis is valuable when it changes the design, not when it simply assigns blame to the agent involved.
Worked example
Owen analyses an anonymised refund fraud case, identifies design causes using separation of privilege and recommends four accepted changes.
Synthetic case. The case is synthetic; Saltzer and Schroeder (1975) is real.
Errors and limits
Historical cases have missing evidence. Holds can delay genuine refunds.
Exercises
- EX036 — Weak questions. Why were the identity questions weak? Rubric: 3 = criminals can find date of birth and address;; 2 = public data;; 1 = vague;; 0 = none.
- EX037 — System cause. What system design enabled the fraud? Rubric: 3 = same-day bank change and refund without notification;; 2 = same day;; 1 = vague;; 0 = none.
- EX038 — Principle. Which principle did Owen apply? Rubric: 3 = separation of privilege;; 2 = separation;; 1 = least privilege;; 0 = none.
- EX039 — Measure change. Why adjust call centre measures? Rubric: 3 = handling time targets discouraged extra checks;; 2 = incentives;; 1 = vague;; 0 = none.
- EX040 — Refund hold. How long is the refund hold after a bank change? Rubric: 3 = seven days;; 2 = seven;; 1 = vague;; 0 = none.
Synthesis
Supervised case analysis finds design causes behind incidents and turns them into accepted changes.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →