Chapter 14 — Privacy foundations | Bachelor's 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 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Personal data in CTI"]
  N2["14.2 Redaction before sharing"]
  N3["Lab — redacting a sample"]
  N4["14.3 Reading the result"]
  N5["14.4 Minimisation and retention"]
  N6["14.5 Patient data"]
  N7["14.6 Pseudonymisation versus anonymisation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Personal data in CTI"]
  N2["14.2 Redaction before sharing"]
  N3["Lab — redacting a sample"]
  N4["14.3 Reading the result"]
  N5["14.4 Minimisation and retention"]
  N6["14.5 Patient data"]
  N7["14.6 Pseudonymisation versus anonymisation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Personal data in CTI]
    |
    v
[14.2 Redaction before sharing]
    |
    v
[Lab — redacting a sample]
    |
    v
[14.3 Reading the result]
    |
    v
[14.4 Minimisation and retention]
    |
    v
[14.5 Patient data]
    |
    v
[14.6 Pseudonymisation versus anonymisation]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) identify personal data in intelligence products; (2) redact it before sharing; (3) distinguish victim data from adversary infrastructure; (4) apply minimisation and retention.

14.1 Personal data in CTI

Phishing samples contain recipients' names and addresses; incident notes mention staff; logs hold device owners. Under data-protection law these are personal data, and in a hospital some may relate to patients, which carries stricter duties.

Amara keeps personal data out of her notes wherever she can, using roles such as "ward administrator" instead of names. When a name is needed, for example to contact a recipient, it stays in the incident ticket with restricted access rather than in intelligence notes that are shared more widely.

14.2 Redaction before sharing

Before sending a sample to HSSC, remove staff emails, phone numbers and any patient identifiers. Replace them with labels so the analytic meaning survives: "[staff-email] received the message".

Amara checks attachments and embedded links too, since a phishing message may include the recipient's name in a URL or a document. Redaction is reviewed by a second person before anything is sent, because once shared, information cannot be recalled from every member. Labels are consistent, so several samples can still be compared after redaction.

Lab — redacting a sample

"""Lab 4 (ch 14): redact email addresses and phone numbers from a synthetic incident note before sharing."""
import re
note = ("Phish reported by j.okoro@halden-health.example at 09:14; caller back on +44 20 7946 0958. "
        "Sender domain portal-login.example; reply-to billing@portal-login.example.")
internal = re.compile(r"[\w.+-]+@halden-health\.example")
phone = re.compile(r"\+\d[\d ]{8,}\d")
out = internal.sub("[staff-email]", note)
out = phone.sub("[phone]", out)
print(out)
print("adversary address kept:", "billing@portal-login.example" in out)

Run with python3 lab_redact.py. Verified output:

Phish reported by [staff-email] at 09:14; caller back on [phone]. Sender domain portal-login.example; reply-to billing@portal-login.example.
adversary address kept: True

14.3 Reading the result

The staff email and phone number are replaced by placeholders. The adversary's sending address is kept, because it is the indicator other members need. The script reports "adversary address kept: True", confirming it did not over-redact.

Amara adds tests for other personal details, such as names in greetings, to the script. Over-redaction would remove what HSSC members need; under-redaction would expose staff. Checking both directions is part of every change to the script, and a sample of each batch is still reviewed by a person.

14.4 Minimisation and retention

Collect only what the question needs and keep it only as long as needed. A retention period for raw phishing samples — say 90 days — limits exposure if HCHT's own systems are breached.

Amara's import deletes raw samples automatically when the period ends, keeping only the extracted indicators and a redacted summary. The retention period is agreed with the data protection officer and recorded in the team's procedures. If an investigation needs a sample for longer, the reason and the new date are recorded, so exceptions are visible.

14.5 Patient data

Never share patient data through intelligence channels. If an incident involves patient records, the data protection officer leads, and notifications follow law, not CTI habits.

Amara checks every sample for patient details before any other processing, and stops if she finds any. Intelligence work needs indicators and techniques, not patient records, so there is never a reason to send them to HSSC. If a phishing message contains patient information, the incident team and the officer handle it under HCHT's data-protection procedures, separately from the intelligence work.

14.6 Pseudonymisation versus anonymisation

Replacing a name with a stable label is pseudonymisation: the data can still be linked back by whoever holds the key, so it remains personal data under GDPR. True anonymisation removes any reasonable means of re-identification. Most CTI sharing achieves only the former, so access controls still matter.

Amara's redaction script uses fixed placeholders rather than stable labels, so HSSC members cannot link a placeholder to a person even across many samples. Where linkage matters, for instance to show that the same staff member was targeted twice, the key stays at HCHT and is shared with no one.

Worked example

A phishing email's body includes a fake invoice listing a real HCHT consultant's name. Amara's automated redaction misses it because it only matches emails and phone numbers. Her manual review catches it, and she adds a step: every shared sample gets a human read for names before release.

Synthetic case. The sample is invented.

Errors and limits

Pattern-based redaction misses names and free text. Automate the easy cases; review the rest by hand.

Exercises

EX040 — Over-redaction. Why must the adversary's sending address be kept?
Show marking criteria
Rubric: 3 = it is the shared indicator others need; not victim data; 2 = partial; 1 = redact all; 0 = none.
EX041 — Missed name. What process change followed the missed consultant name?
Show marking criteria
Rubric: 3 = mandatory human review for names before release; 2 = vague; 1 = none needed; 0 = none.
EX042 — Pseudonyms. Is data with stable placeholder labels anonymous under GDPR?
Show marking criteria
Rubric: 3 = no, pseudonymised, still personal data if linkable; 2 = no; 1 = yes; 0 = none.

Synthesis

Find personal data, redact with care, keep the indicators, minimise, retain briefly and never route patient data through CTI.

Continue studying — chapter 14 of 40

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →