Chapter 23 — Human factors and cyber policy: threat and failure analysis
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Attack sequences"]
N2["23.2 Classifying errors"]
N3["23.3 Defences by type"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Attack sequences"]
N2["23.2 Classifying errors"]
N3["23.3 Defences by type"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Attack sequences]
|
v
[23.2 Classifying errors]
|
v
[23.3 Defences by type]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) analyse how social engineering attacks unfold; (2) classify human errors; (3) design defences for each failure type.
23.1 Attack sequences
Aiko analyses a realistic sequence: an attacker researches Greyford staff online, sends a field engineer a message impersonating a pump vendor about an urgent firmware issue, follows up with a phone call and asks the engineer to approve a remote session. Hadnagy (2018) describes such multi-step pretexting. Each step offers a chance to stop the attack: limiting what staff publish, verifying vendor contacts, calling back on known numbers and requiring approval from a second person for remote sessions. She draws the sequence as a timeline with each defensive opportunity marked.
23.2 Classifying errors
Aiko uses the distinction between slips, lapses and mistakes set out by Reason (1990). A slip is a wrong action, such as clicking the wrong button; a lapse is a memory failure, such as forgetting to lock a screen; a mistake is a wrong plan, such as believing a fake vendor is genuine. Each needs a different defence: slips need forgiving interfaces, lapses need reminders or automation, and mistakes need better information or verification. Classifying errors stops the default response of more training for every problem.
23.3 Defences by type
Aiko maps defences. For slips, the report button has an undo and a confirmation for sending sensitive files externally. For lapses, screens lock automatically and security keys remove forgotten passwords. For mistakes, vendor requests require callback verification, and staff receive short guidance on common pretexts. She also notes violations, deliberate rule-breaking, which often signal unworkable rules rather than bad intent, as Adams and Sasse (1999) found. Violations prompt her to review rules before reinforcing them. She presents the mapping as a table that the security team can extend when new incidents occur, so that each future failure is classified before a response is chosen.
Worked example
Aiko analyses a multi-step pretext, classifies errors as slips, lapses and mistakes, and maps defences to each, treating violations as signals.
Synthetic case. The attack is synthetic; Hadnagy (2018), Reason (1990) and Adams and Sasse (1999) are real.
Errors and limits
Error categories overlap in practice. Attackers adapt to known verification steps.
Exercises
- EX067 — Pretext steps. Which steps make up the vendor pretext? Rubric: 3 = online research, impersonating email, follow-up call, remote session request;; 2 = three;; 1 = vague;; 0 = none.
- EX068 — Lapse defence. What defends against lapses? Rubric: 3 = reminders or automation such as auto-lock;; 2 = automation;; 1 = training;; 0 = none.
- EX069 — Violations as signals. What do violations often signal? Rubric: 3 = unworkable rules rather than bad intent;; 2 = rule design;; 1 = malice;; 0 = none.
Synthesis
Classifying failures guides the right defence for each, and violations point to rules that need redesign.
Continue studying — chapter 23 of 50
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →