◇ OpenCyber Academy
Engineering · Chapter 21 · English

Chapter 21 — Threat intelligence and OSINT: requirements

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 21 — Threat intelligence and OSINT: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 PIRs"]
  N2["21.2 From PIR to system requirement"]
  N3["21.3 Verifiable wording"]
  N4["21.4 Non-functional requirements"]
  N5["21.5 Traceability matrix"]
  N6["Practice note — Requirement reviews"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 PIRs"]
  N2["21.2 From PIR to system requirement"]
  N3["21.3 Verifiable wording"]
  N4["21.4 Non-functional requirements"]
  N5["21.5 Traceability matrix"]
  N6["Practice note — Requirement reviews"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 PIRs]
    |
    v
[21.2 From PIR to system requirement]
    |
    v
[21.3 Verifiable wording]
    |
    v
[21.4 Non-functional requirements]
    |
    v
[21.5 Traceability matrix]
    |
    v
[Practice note — Requirement reviews]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) collect priority intelligence requirements (PIRs) from stakeholders; (2) turn PIRs into system requirements; (3) write requirements that are verifiable; (4) maintain traceability.

21.1 PIRs

Priority intelligence requirements are questions decision-makers need answered: "Which adversaries target electricity distributors in our region?" "Are our OT vendors being targeted?" They direct collection and analysis and should be reviewed each quarter.

Kofi gathered BEN's questions by asking the CISO, the SOC lead and the head of network operations what they would want to know before their next major decision. Many answers overlapped, and five questions covered most of what was asked. A question nobody can act on is dropped, however interesting it seems to the analysts.

21.2 From PIR to system requirement

A PIR about OT vendors implies requirements: ingest vendor advisories; tag objects with vendor names; alert when a campaign mentions a tagged vendor. Each is a "shall" statement with a verification method.

Kofi writes the verification method next to each statement as he writes it: a test with synthetic data, an inspection of configuration or a measurement from production logs. If he cannot say how a statement would be checked, the wording is not yet precise enough. Each requirement also names the question it serves, so its purpose stays visible after the people who asked have moved on.

21.3 Verifiable wording

"The system shall be fast" cannot be verified. "Lantern shall deliver indicators with confidence ≥ 70 to IT DNS enforcement within 30 minutes of ingestion for 95% of indicators per month" can.

The second version names the population, the threshold, the destination, the time limit and the share that must meet it, and the period over which it is judged. Lantern's logs record ingestion and delivery times, so the figure can be computed each month without extra effort. Kofi rewrote a dozen vague statements in this form; three turned out to be impossible to measure with current logging, which became work items of their own.

21.4 Non-functional requirements

Confidentiality (TLP enforcement), integrity (signature verification where offered), availability (99.5% monthly), privacy (no personal social-media collection), retention and auditability are requirements too, not afterthoughts.

Each of these is written and tested like any functional statement. The privacy requirement, for example, is checked by inspecting the source register and the collector code for any social media connector. Availability is measured from health checks every minute. Leaving such needs unwritten tends to mean they are discovered during an incident or an audit, when changing the design is far more expensive.

21.5 Traceability matrix

A table links PIRs → requirements → design elements → tests. When a PIR is retired, its requirements can be reviewed for removal.

Kofi keeps the table in a spreadsheet generated from tags in the requirements document and test names, so it updates itself rather than relying on someone to edit it. Gaps stand out: a requirement with no test, or a design element that serves no requirement. When the quarterly review retired one question about a regional actor, the table showed two enrichment sources that existed only for it, and both were later dropped.

Practice note — Requirement reviews

Requirements are reviewed with the stakeholders who own them. The SOC lead signs off on timeliness, the privacy officer on minimisation, the OT engineer on approval gates. A requirement without an owner is a candidate for deletion.

Worked example

Kofi converts the OT vendor PIR into four requirements and writes a test for each, such as "Given a synthetic advisory naming vendor V, Lantern raises an alert to the OT channel within 15 minutes."

Synthetic case. Vendor V, its advisory and the 15-minute timing are invented.

Errors and limits

Requirements that copy a vendor's product features are not stakeholder needs. Too many PIRs means none are priorities.

Exercises

Synthesis

Ask decision-makers, derive verifiable shalls, include non-functional needs, and trace everything.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →