Chapter 11 — Supervised laboratory | Professional Threat intelligence and OSINT

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 11 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Lab rules"]
  N2["Lab — brief release check"]
  N3["11.2 Reading the result"]
  N4["11.3 Fixing"]
  N5["11.4 Why each check"]
  N6["11.6 Extending"]
  N7["11.7 Holding is safe"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Lab rules"]
  N2["Lab — brief release check"]
  N3["11.2 Reading the result"]
  N4["11.3 Fixing"]
  N5["11.4 Why each check"]
  N6["11.6 Extending"]
  N7["11.7 Holding is safe"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX051"]

[Learning outcomes]
    |
    v
[11.1 Lab rules]
    |
    v
[Lab — brief release check]
    |
    v
[11.2 Reading the result]
    |
    v
[11.3 Fixing]
    |
    v
[11.4 Why each check]
    |
    v
[11.6 Extending]
    |
    v
[11.7 Holding is safe]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes

You will (1) run an automated pre-release check on a brief; (2) fix failures before release; (3) explain each check's purpose; (4) extend checks responsibly.

11.1 Lab rules

Offline, synthetic, standard library. The supervisor reviews outputs and the corrected brief. Offline and synthetic means the lab cannot leak anything real: the brief, the staff address and the domains are invented for teaching. Using only the standard library keeps the script runnable on a locked-down work machine. The supervisor's review covers both the first failing output and the corrected brief, so learners show the fix rather than just describing it. The same rules apply to any extension a learner adds, including new test cases, which must also use invented content only.

Lab — brief release check

"""Lab (ch 11): assemble a one-page brief and refuse to release it if checks fail (synthetic)."""
brief = {"tlp": "TLP:GREEN", "bluf": "Phishing against broker portals is likely to continue this month.",
         "confidence": "moderate", "actions": ["Block 3 sender domains", "Remind staff about portal logins"],
         "text": "Sample sent to j.smith@bramwell.example was reported."}
checks = [("label valid", brief["tlp"] in {"TLP:CLEAR", "TLP:GREEN", "TLP:AMBER", "TLP:AMBER+STRICT", "TLP:RED"}),
          ("bottom line first", bool(brief["bluf"])),
          ("confidence stated", brief["confidence"] in {"low", "moderate", "high"}),
          ("actions listed", len(brief["actions"]) > 0),
          ("no staff email", "@bramwell.example" not in brief["text"])]
for name, ok in checks:
    print(f"{name}: {'pass' if ok else 'FAIL'}")
print("release" if all(ok for _, ok in checks) else "HOLD: fix failures before release")

Run with python3 lab_brief.py. Verified output:

label valid: pass
bottom line first: pass
confidence stated: pass
actions listed: pass
no staff email: FAIL
HOLD: fix failures before release

11.2 Reading the result

The brief has a valid TLP:GREEN label, a bottom line first, a confidence level and listed actions. It fails one check: the text contains a staff email address at bramwell.example. The script holds the release until the failure is fixed. The output shows four passes before the failure, so the problem is specific and easy to find. The failing line names the check, not the address, which keeps the output itself safe to paste into a ticket. Because the final line reads 'HOLD: fix failures before release', nobody can mistake a partly passing brief for one ready to send.

11.3 Fixing

Replace "j.smith@bramwell.example" with "a staff member". Rerun: all checks pass and the script prints "release". Rerunning the script after the fix matters as much as the edit itself. A replacement could introduce a new problem or miss a second address, and only a second run shows that all five checks pass. Priya saves both outputs, the failing run and the passing run, in the ticket. That record is what the supervisor reads before signing off the corrected brief.

11.4 Why each check

Label: wrong or missing labels cause leaks. Bottom line: busy readers act on the first sentence. Confidence: readers need to know how sure we are. Actions: intelligence without action is news. Staff email: personal data does not belong in a GREEN community product. Each check guards against a failure that already appears in the book. A wrong label could send FSSG detail beyond its audience. A missing bottom line wastes the reader's first sentence; a missing confidence hides uncertainty; an empty action list produces news rather than intelligence. The staff address would breach the sanitising rule for anything shared at GREEN.

11.5 Limits of checks

The script finds email addresses only for BIB's domain; it misses names and client addresses. A human read remains mandatory. The staff-email check tests only for '@bramwell.example' in the text. A name such as 'Jo Smith' written without an address, a client's postal address or a staff member's personal email at another domain would all pass. That is why the supervisor and Priya still read every brief, and the script output is evidence of a check, not proof of safety.

11.6 Extending

Students may add a check for phone numbers, or for probability words outside the agreed scale. Each new check gets a test case. A test case is two short pieces of text: one that should fail and one that should pass. For phone numbers, 'call 01632 960123' should fail and 'call the help desk' should pass. Priya's own extension flags any probability word outside BIB's scale, tested with 'probable' failing and 'likely' passing, as shown in the worked example. Without a failing test, a broken check could pass every brief and nobody would notice the gap in the release process.

11.7 Holding is safe

The script holds rather than releases when anything fails — a fail-closed design. Failing closed means a mistake in the brief or the script leads to a delay, not a leak. If the TLP field were missing, the brief would be held rather than sent unlabelled. The cost is that a correct brief may occasionally wait for a fix, which is acceptable for products going to FSSG or management. Priya treats a HOLD as a normal outcome of the check, not as a failure of her work.

11.8 Lab report

Record the first run, the fix, the second run and one proposed extension with its test case. The report shows the whole cycle in order: what failed first, what was changed, what passed second, and how the check could grow. Including a test case for the extension proves it works rather than only describing it. Learners also note any limit they found, such as names without email addresses passing the staff-email check. Dates and times of both runs are recorded, so the order of failure, fix and success can be shown to the supervisor.

11.9 Supervisor sign-off

The supervisor signs only after reading the corrected brief. Signing only after reading means the supervisor's signature confirms the brief, not just the script's output. A passing run does not prove the text is safe, as the limits of the checks show. The signature goes into the lab record alongside both runs, so an assessor can see who approved the brief and when. If the supervisor finds a problem the script missed, Priya fixes it, reruns the check and asks for a fresh signature.

Running in practice

After the lab, Priya runs the check on every real brief before release, on her work machine, with the output saved to the ticket.

Worked example

Priya extends the check to flag any probability word not on BIB's scale. Her test brief uses "probable" and the check fails as intended; she rewrites it as "likely" and the brief passes.

Synthetic case. The brief and extension are invented teaching material.

Errors and limits

Automated checks catch patterns, not meaning.

Exercises

EX051 — Lab failure. Which check failed and why?
Show marking criteria
Rubric: 3 = no staff email; address in text; 2 = check only; 1 = label; 0 = none.
EX052 — Fix and rerun. How is the failure fixed and confirmed?
Show marking criteria
Rubric: 3 = replace with role; rerun shows release; 2 = one; 1 = ignore; 0 = none.
EX053 — Check purposes. Explain why the confidence check exists.
Show marking criteria
Rubric: 3 = readers need to know certainty; 2 = partial; 1 = decoration; 0 = none.
EX054 — Missed by script. Name something the script would miss.
Show marking criteria
Rubric: 3 = names, client addresses, other domains; 2 = vague; 1 = vague; 0 = none.
EX055 — New check. Propose a new check with a test case.
Show marking criteria
Rubric: 3 = check + failing test + passing test; 2 = check + one test; 1 = check only; 0 = none.

Synthesis

Automate simple pre-release checks, hold on failure, fix and rerun, and keep a human read for what scripts miss.

Continue studying — chapter 11 of 12

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →