◇ OpenCyber Academy
Rapid course · Chapter 3 · English

Chapter 3 — Human factors and cyber policy: systems, data and dependencies

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 3 — Human factors and cyber policy: systems, data and dependencies

Lesson map

Lesson 03 published. Map, example, EX027.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Mapping systems"]
  N2["3.2 Data and people"]
  N3["Lab — Counting systems each role can reach"]
  N4["3.3 Single points of failure"]
  N5["3.4 Simple fixes"]
  N6["3.5 Checking the fixes"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX027"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Mapping systems"]
  N2["3.2 Data and people"]
  N3["Lab — Counting systems each role can reach"]
  N4["3.3 Single points of failure"]
  N5["3.4 Simple fixes"]
  N6["3.5 Checking the fixes"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]

[Learning outcomes]
    |
    v
[3.1 Mapping systems]
    |
    v
[3.2 Data and people]
    |
    v
[Lab — Counting systems each role can reach]
    |
    v
[3.3 Single points of failure]
    |
    v
[3.4 Simple fixes]
    |
    v
[3.5 Checking the fixes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX027]

Learning outcomes

You will (1) map the systems, data and people a small charity depends on; (2) find points where one person or mistake can cause harm; (3) choose simple fixes.

3.1 Mapping systems

Ruth maps Riverbend's systems on one page: shared email accounts, the donations spreadsheet, an online bank account, a volunteer rota app and the charity's social media pages. Beside each she writes who uses it and what data it holds. The donations spreadsheet holds donor names and addresses; the rota app holds volunteer phone numbers; the bank account can make payments. Mapping helps Ruth see where personal data and money sit, which are the things attackers most want and the things whose loss would hurt the charity most.

3.2 Data and people

Ruth notes how data move between people. Volunteers copy donor details from paper forms into the spreadsheet. The treasurer approves payments after the coordinator forwards invoices by email. Staff post updates on social media using one shared password. At each handover, a deceptive message or simple error could cause harm. She counts how many systems each person can access and finds that the treasurer, a retired volunteer, can reach almost everything, while some staff who need access to the rota do not have it.

Lab — Counting systems each role can reach

# Systems each role can reach (synthetic): email, spreadsheet, bank, rota, social media.
access = {"treasurer": {"email", "spreadsheet", "bank", "rota", "social"}, "coordinator": {"email", "spreadsheet", "rota"},
          "warehouse volunteer": {"spreadsheet"}, "staff (rota needed)": {"email"}}
for r, s in access.items(): print(f"{r}: {len(s)} of 5")

Run with python3 lab_access.py. Verified output:

treasurer: 5 of 5
coordinator: 3 of 5
warehouse volunteer: 1 of 5
staff (rota needed): 1 of 5

3.3 Single points of failure

Ruth finds two single points of failure. Only the treasurer can approve payments, so if she is away, invoices wait and pressure builds, which attackers can exploit with urgent fake invoices. Only one volunteer knows the social media password, so if that account is taken over, nobody else can recover it quickly. She also notes that the bank account sends alerts only to the treasurer's personal email. Each single point means that one absence, one mistake or one deception could cause lasting harm.

3.4 Simple fixes

Ruth chooses simple fixes. A second trustee is authorised to approve payments, always after a callback for any bank change. Social media accounts get individual logins with two-step verification and recovery details held by the charity manager. Bank alerts go to a shared charity mailbox as well as the treasurer. Donor data in the spreadsheet are limited to what is needed for thank-you letters. Each fix costs little and removes a point where one person or mistake could cause serious harm.

3.5 Checking the fixes

Ruth checks that each fix works. She asks the second trustee to approve a small test payment with a callback, confirms that a test bank alert reaches the shared mailbox and logs into social media with her own account to confirm two-step verification works. She records each check with the date. Callum reminds her that checking fixes is part of the job, because many security changes are made with good intentions but never confirmed, and they quietly fail when they are needed most.

Worked example

Ruth maps systems and data, counts access by role, finds payment and social media single points of failure and checks simple fixes.

Synthetic case. Systems and data are synthetic.

Errors and limits

Maps go out of date. Second approvers need training.

Exercises

Synthesis

Mapping systems, data and people reveals single points of failure that simple fixes can remove.

Continue studying — chapter 03 of 04

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →