◇ OpenCyber Academy
Bachelor's · Chapter 5 · English

Chapter 5 — Security literacy

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 5 — Security literacy

Lesson map

Lesson 05 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 Neighbouring practices"]
  N2["5.2 CIA at TRB"]
  N3["5.3 Permission"]
  N4["5.4 Dual-use"]
  N5["5.5 Framework map"]
  N6["5.6 Ethics"]
  N7["5.7 Applied note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Neighbouring practices"]
  N2["5.2 CIA at TRB"]
  N3["5.3 Permission"]
  N4["5.4 Dual-use"]
  N5["5.5 Framework map"]
  N6["5.6 Ethics"]
  N7["5.7 Applied note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[Learning outcomes]
    |
    v
[5.1 Neighbouring practices]
    |
    v
[5.2 CIA at TRB]
    |
    v
[5.3 Permission]
    |
    v
[5.4 Dual-use]
    |
    v
[5.5 Framework map]
    |
    v
[5.6 Ethics]
    |
    v
[5.7 Applied note]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) place authorized testing among security practices; (2) name CIA with TRB examples; (3) refuse unauthorized work.

5.1 Neighbouring practices

Architecture, monitoring, IR and authorized testing reinforce each other. Testing without logging is theatre; logging without testing misses unknown unknowns. At TRB, a test that reaches ledger-db from the web tier only helps if the monitoring team can show whether they saw it, and incident responders know what they would do next. Sam therefore sends each finding to architecture for the design fix, to monitoring for a detection question and to IR for a playbook check. A finding that improves all three is worth far more than one that only adds a line to a report.

5.2 CIA at TRB

Confidentiality of customer data; integrity of ledgers and payments; availability of online banking. Findings are judged by which they threaten. The connection from the web tier to ledger-db threatens integrity first, because the ledger records balances and payments; a leaked statement template threatens confidentiality; a scan that slows online banking threatens availability. Naming the property makes severity arguments concrete. Sam adds the threatened property as a field in every FindingsDesk ticket so owners can see at a glance which promise to customers is at risk, and boards can count findings by property rather than by tool.

5.3 Permission

Written ROE from owners. Bug bounties cover only their published scope. Friends' banks are never practice targets. At TRB, the ROE is signed by the owners of the systems in the /26 and names exclusions such as SWIFT. A bug bounty that covers the public website does not cover the internal API behind it, and a friend's offer to 'let you try' on another bank's system grants nothing, because the friend does not own that system. Sam keeps a copy of the signed ROE open during every window and stops if a target cannot be traced to it.

5.4 Dual-use

This curriculum teaches scoping, measurement and reporting — not exploit code for real products. The same knowledge that helps defenders can help attackers, so the course draws its line at artefacts: it teaches how to plan, measure and report authorized tests, and how techniques are named for detection, but it never provides working exploit code for real products. Sam's labs follow the same rule. A learner who finishes the course can scope a TRB engagement and rank its findings, but holds nothing that could be pointed at someone else's bank.

5.5 Framework map

SP 800-115 (planning), PTES (stages), WSTG (web), ATT&CK (techniques), TIBER-EU/CBEST (threat-led finance). Each framework answers a different question. SP 800-115 tells Sam how to plan and run an assessment; PTES describes the stages from pre-engagement to reporting; WSTG gives test cases for web applications such as online banking; ATT&CK names techniques so findings can be linked to detection; TIBER-EU and CBEST describe intelligence-led red teaming for financial institutions under regulatory oversight. Using one framework where another belongs, such as treating CBEST as a web checklist, produces confused plans.

5.6 Ethics

Customer harm and payment integrity outrank curiosity and resume screenshots. In practice the ordering decides real choices. If a test might corrupt a payment record, it stops, however interesting the result would be. If a screenshot would show customer data, it is not taken, even for a portfolio. Sam writes the expected customer impact of each method card before a window, and any card with possible payment-integrity impact needs the ledger owner's named approval. Curiosity is satisfied in the synthetic lab, where nothing real can be harmed.

5.7 Applied note

The refusal script is role-played with a staff member playing an impatient director. Sam must keep tone respectful while not yielding. Video reviews show whether he smiles nervously into agreement; those clips are deleted after coaching but the lesson stays. The director in the role-play asks Sam to 'just quickly check' a host outside the /26. Sam's script names the ROE clause, offers to raise a scope change with the owner and gives a realistic time for approval. Practising the exact words makes them available under real pressure.

5.8 Framework flashcards

Sam's deck has one card per framework: SP 800-115, PTES, WSTG, ATT&CK, TIBER-EU, CBEST — purpose and what it is not. Misusing CBEST as a web checklist is a common card-back answer. The card for TIBER-EU, for instance, says it frames threat-intelligence-led red teaming for financial entities and is not a vulnerability scanning standard. Writing the 'what it is not' side forces Sam to understand each framework's purpose rather than its name, and the deck is reviewed whenever a framework publishes a new version.

5.9 Home lab boundary

Sam's home lab uses RFC1918 and never TRB DNS. Mixing VPN into homework is a reported near-miss if it happens. Private RFC1918 ranges at home cannot collide with TRB's addressing if Sam never connects the bank VPN while experimenting. Using TRB DNS from home would leak internal names and could send lab traffic toward the bank. If a mix-up happens, he reports it as a near-miss so the boundary rule can be improved rather than quietly hoping no one noticed.

5.10 Declining a hacking demo

Sam declines a meetup invitation to demo "how we hacked our bank" even though the work was authorized. Screenshots travel. He offers instead a talk on ROE design with synthetic examples. The organisers accept. Dual-use restraint includes what you refuse to present. A screenshot of an authorized TRB finding still shows real hostnames, versions and weaknesses that may not yet be fixed. Once shown on a meetup screen, it cannot be withdrawn. The ROE talk shares the reusable lesson without the bank's details.

The ROE talk uses only documentation-range demos. Sam's slide deck is public; his TRB screenshots are not. Documentation ranges such as 198.51.100.0/24 make it impossible for a demo to point at a real host, and synthetic findings carry no information about TRB's systems. Before publishing, Sam checks every slide for internal names, ticket IDs and real addresses. His TRB screenshots stay inside FindingsDesk, where access is controlled and logged, and are deleted when the engagement's retention period ends. The public deck is reviewed by the ROE owner once before release.

Worked example (synthetic TRB)

A classmate asks Sam to "try the bank's login from home". Sam refuses and points to the course boundary.

Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.

Errors and limits

This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.

Exercises

Synthesis

Literacy is CIA, permission, frameworks and ethical refusal.

Continue studying — chapter 05 of 40

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