Chapter 20 — Human factors and cyber policy: foundational cases

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Studying cases"]
  N2["20.2 Common factors"]
  N3["20.3 Lessons for small organisations"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 Studying cases"]
  N2["20.2 Common factors"]
  N3["20.3 Lessons for small organisations"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 Studying cases]
    |
    v
[20.2 Common factors]
    |
    v
[20.3 Lessons for small organisations]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) analyse published accounts of social engineering; (2) identify common human factors in incidents; (3) draw lessons for small organisations.

20.1 Studying cases

Nadia studies how social engineering is described in Hadnagy (2018) and in the Verizon DBIR. Common patterns include impersonating a trusted authority, creating urgency, exploiting helpfulness and using information gathered from public sources. She builds a synthetic case for Ashcombe based on these patterns: a caller posing as a council auditor asks a branch assistant to email a list of members with overdue fines, claiming a deadline that afternoon. The case lets her analyse factors without using any real incident. Dr Prescott approves the case.

20.2 Common factors

Nadia lists the human factors in the synthetic case: authority pressure from a claimed council role; urgency from the deadline; helpfulness, since assistants want to assist officials; and the lack of a procedure for data requests. She notes that the assistant is not foolish; the situation was designed to exploit normal, good intentions. She also identifies organisational factors: no clear owner for data requests and no easy way to check whether the auditor exists. Most factors lie in the system rather than in the person.

20.3 Lessons for small organisations

Small organisations like Ashcombe lack security teams, so lessons must be simple. Nadia proposes three: a rule that member data are never sent in response to a phone call; a single named contact who verifies any official request; and a culture where staff can say no to pressure without fear. She notes that the ENISA cybersecurity culture guidelines emphasise organisational culture and leadership support. These lessons cost little, which matters for a public library with tight budgets. Managers discuss them at a staff meeting.

Worked example

Nadia builds a synthetic impersonation case, identifies personal and organisational factors and proposes three simple lessons.

Synthetic case. The case is synthetic; Hadnagy (2018), the DBIR and the ENISA guidelines are real.

Errors and limits

Synthetic cases may miss real details. Simple rules have exceptions.

Exercises

• EX058 — Pressure types. Which pressures did the caller use?
  Show marking criteria

  Rubric: 3 = authority and urgency;; 2 = two;; 1 = vague;; 0 = none.
• EX059 — Where factors lie. Where do most factors lie in the case?
  Show marking criteria

  Rubric: 3 = in the system rather than the person;; 2 = system;; 1 = the assistant;; 0 = none.
• EX060 — Named contact. What does the named contact do?
  Show marking criteria

  Rubric: 3 = verifies any official request;; 2 = verify;; 1 = vague;; 0 = none.

Synthesis

Cases show that social engineering exploits good intentions and missing procedures.

Continue studying — chapter 20 of 40

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →