◇ OpenCyber Academy
Professional · Chapter 3 · English

Chapter 3 — Authorized practice and evidence handling

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 — Authorized practice and evidence handling

Lesson map

Lesson 03 published. Map, example, EX011.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Authorisation"]
  N2["3.2 TLP 2.0"]
  N3["3.3 Data protection"]
  N4["3.4 Evidence"]
  N5["3.5 Approval needed"]
  N6["3.6 OSINT boundaries"]
  N7["3.7 Records"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX011"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Authorisation"]
  N2["3.2 TLP 2.0"]
  N3["3.3 Data protection"]
  N4["3.4 Evidence"]
  N5["3.5 Approval needed"]
  N6["3.6 OSINT boundaries"]
  N7["3.7 Records"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX011"]

[Learning outcomes]
    |
    v
[3.1 Authorisation]
    |
    v
[3.2 TLP 2.0]
    |
    v
[3.3 Data protection]
    |
    v
[3.4 Evidence]
    |
    v
[3.5 Approval needed]
    |
    v
[3.6 OSINT boundaries]
    |
    v
[3.7 Records]
    |
    v
[Worked example] --> [Exercise EX011]

Learning outcomes

You will (1) work within written authorisation; (2) apply TLP 2.0 and data-protection rules; (3) handle evidence with provenance; (4) recognise actions that need legal or management approval.

3.1 Authorisation

Priya's role description and the IT security policy list what she may do: read intelligence sources, search BIB logs, draft requests, share sanitised items with FSSG. Anything else needs approval. The written list protects Priya as much as it limits her. Searching BIB's email logs for an FSSG indicator is covered, so she does not need to ask each time. Requesting a takedown, buying a feed or contacting police is not covered, so those go to her manager. When a task falls between the two, she asks first and records the answer.

3.2 TLP 2.0

CLEAR: public. GREEN: community. AMBER: BIB and its clients on need-to-know. AMBER+STRICT: BIB only. RED: named people. Priya stores items with labels and checks before forwarding. The TLP labels decide where each item can travel once it reaches BIB. An FSSG item marked AMBER can reach a client only when that client needs it to protect itself, while AMBER+STRICT items stay inside BIB. A RED item stays with the people named on it, even if her manager asks for a copy. Priya checks the label before every forward, not after the item has already gone out.

3.3 Data protection

Logs and emails contain personal data of staff and clients. Under the GDPR-style rules BIB follows, she uses only what is needed, keeps extracts briefly and removes personal details before sharing. In practice this means a log search for an FSSG sender domain returns only matching rows, not whole mailboxes. Extracts she keeps for a ticket are deleted when the ticket closes. Before a sender domain goes back to FSSG, she removes client names, staff addresses and anything else that would identify a person. The compliance officer can inspect these practices at any time, for example during a regulator's review.

3.4 Evidence

When a phishing email is reported, she saves the original message file, records who reported it and when, and computes a hash of the file. Analysis uses a copy. Each of the four evidence steps has its own reason in this routine. The original file keeps headers that a forwarded copy may lose, and the reporter and time show where the item came from. The hash lets anyone later confirm that the file has not changed. Working on a copy means a mistake during analysis cannot damage the only original, which matters if the case reaches police.

3.5 Approval needed

Contacting police, requesting takedowns, notifying regulators, buying intelligence services, or engaging with suspected criminals. Each goes through management and, where needed, legal advice. These actions can bind BIB legally, cost money or alert criminals, so Priya cannot take them alone. For the lookalike domain in Chapter 5 she asks IT to block it but asks management to approve the takedown request. In the fraud case, management reports to the bank and police while Priya supplies the timeline that supports both reports.

3.6 OSINT boundaries

Public sources only, within terms of service, no fake accounts, no closed forums, no attempts to identify private individuals. Each of the five OSINT rules closes a specific risk for BIB and for Priya. Fake accounts breach platform terms and are deceptive, and closed forums expose BIB to criminals and possible legal trouble. Identifying private individuals is outside every requirement and would intrude on their privacy. That is why the forum claim about broker data in Chapter 5 is checked through FSSG rather than by Priya visiting the forum herself.

3.7 Records

A simple log: item, source, label, action, date. One row per item lets Priya answer simple but important questions later, such as where a domain came from and who received it. For the forwarded client email, the row would read: the sender domain, the client report, GREEN, shared with FSSG, and the date. The ticket system in Chapter 6 later replaces this log with richer fields. Later reviews and FSSG questions about an item can then be answered from the log rather than from Priya's memory of it.

3.8 Mistakes

If something is shared wrongly, report it at once and ask recipients to delete it. Speed matters more than embarrassment when something has been shared too widely. If an AMBER+STRICT item reached a client by mistake, Priya would tell her manager the same day, ask the client to delete it and inform the source. The cause goes into her records, so the same slip does not happen again. Hiding a mistake would damage FSSG's trust in BIB far more than the slip itself would.

Chain of custody

If an incident may lead to legal action, evidence handling must show who held each item and when. Priya records every transfer of the saved email file — to the IT manager, to an external responder — with date, recipient and purpose.

Worked example

A client forwards a suspicious email claiming to come from BIB. Priya saves the original, hashes it, removes the client's details from her working notes and shares the sender domain with FSSG at GREEN. The compliance officer decides whether the client must be told anything further.

Synthetic case. The email is invented.

Errors and limits

Policies need updating as the role grows.

Exercises

Synthesis

Work inside written authority, apply TLP and data protection, preserve evidence and escalate actions that need approval.

Continue studying — chapter 03 of 12

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