◇ OpenCyber Academy
Technical · Chapter 6 · English

Chapter 6 — Threat intelligence and OSINT: system model

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 6 — Threat intelligence and OSINT: system model

Lesson map

Lesson 06 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Sources"]
  N2["6.2 Processing"]
  N3["6.3 Storage"]
  N4["6.4 Outputs"]
  N5["6.5 Owners"]
  N6["6.6 Weak points"]
  N7["6.7 Kill chain view"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Sources"]
  N2["6.2 Processing"]
  N3["6.3 Storage"]
  N4["6.4 Outputs"]
  N5["6.5 Owners"]
  N6["6.6 Weak points"]
  N7["6.7 Kill chain view"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]

[Learning outcomes]
    |
    v
[6.1 Sources]
    |
    v
[6.2 Processing]
    |
    v
[6.3 Storage]
    |
    v
[6.4 Outputs]
    |
    v
[6.5 Owners]
    |
    v
[6.6 Weak points]
    |
    v
[6.7 Kill chain view]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes

You will (1) draw the college's CTI system as sources, processing, storage and outputs; (2) identify who owns each part; (3) map the system to STIX and TAXII concepts; (4) find weak points.

6.1 Sources

ESX's TAXII 2.1 collection, ESX email alerts, a national education advisory page, the help desk's reports of suspicious messages, and college logs.

Each source is listed with its owner, its format and how often it arrives. ESX's TAXII collection supplies STIX objects automatically, while its email alerts arrive in a mailbox someone must read. Help-desk reports and college logs are internal sources, and they often show whether an external item matters to Ashgrove at all. Tomás records each source's TLP habits too, since ESX labels every item while the national advisory page publishes only CLEAR material.

6.2 Processing

Tomás's scripts validate and normalise indicators; his supervisor reviews relevance and grades sources; requests go to system owners.

Splitting the work this way keeps judgment with the person accountable for it. Scripts catch malformed or duplicate indicators quickly, but they cannot decide whether a report on another college applies to Ashgrove. The supervisor's grade and relevance call are recorded in the platform, so later readers can see who decided what, and why. When the supervisor is away, routine relevance calls wait for her return, while urgent items go to the IT security manager instead.

6.3 Storage

A small threat intelligence platform stores STIX 2.1 objects: indicators, attack patterns, reports and relationships, each with a TLP marking definition.

Storing objects in STIX keeps relationships visible, such as which indicators belong to which report or attack pattern. The TLP marking travels with each object, so an export to ESX can be filtered by label automatically. Tomás checks that imported objects keep their markings, because a lost label could lead to a wrong share. Indicators also carry their valid_from time from the source, which the expiry rules later use to decide when an entry should leave the block lists.

6.4 Outputs

DNS filter and email gateway block lists, notes to owners, monthly summaries for management and feedback to ESX.

Each of these outputs has a different reader and a different timing. Block lists go to the network and email teams as configuration requests; notes go to individual owners; the monthly summary goes to management. Feedback to ESX closes the loop, telling the community which items matched, which were wrong and which were withdrawn. Each output is listed in the configuration register or the reporting calendar, so a missing one is noticed quickly. Feedback to ESX is sent at least monthly, even when nothing matched.

6.5 Owners

The network team owns the DNS filter; the email team the gateway; the supervisor the platform; Tomás the scripts.

Writing the owners on the diagram shows where Tomás must send a request rather than act himself. It also shows that Tomás owns only the scripts, so their documentation and testing are his responsibility. When an owner changes jobs, the diagram and the configuration register are both updated in the same week. The supervisor owns the platform, so platform upgrades and user accounts are her decisions, not Tomás's.

6.6 Weak points

Single-person knowledge of scripts; email alerts arriving in a personal inbox; no check that block lists actually loaded.

Each weak point on the list has a matching fix. Script knowledge is shared through runbooks and code review; the alert inbox became a shared mailbox with two readers; loaded lists are tested with a lookup after each change. The diagram is redrawn after each fix, so the next review starts from the current design. The loaded-list check is now part of every block request, through the test lookup required after each change.

6.7 Kill chain view

Mapping outputs to the Hutchins et al. phases shows coverage: email blocks act at delivery; DNS blocks at command and control; account resets after exploitation. No output addresses reconnaissance — a gap to discuss.

Laying the kill chain over the diagram is how Tomás found that no output addresses reconnaissance. Lookalike-domain searches in certificate transparency logs could move some coverage earlier, before phishing messages are sent. Whether that is worth the effort is a decision for the supervisor, so Tomás presents the gap rather than a solution.

6.8 Diagram

One page, boxes and arrows, names of owners on each box.

The diagram for Ashgrove shows five source boxes, the scripts, the platform and four kinds of output, with arrows between them. Owners' names sit inside each box, so readers can see who to call. Tomás keeps the editable file in the team repository, so each change is recorded with its date. Arrows show direction of flow, from sources through the scripts and the platform to each output and back to ESX as feedback. A dashed arrow marks the help-desk reports, which arrive by forwarded email rather than through any automated feed.

Using the model in training

New placement students study the diagram on their first day. Tracing one indicator from an ESX alert to a DNS block, naming each owner on the way, teaches the whole flow in less than an hour. Asking them where they think the flow could break often surfaces fresh weak points that long-serving staff no longer notice.

Worked example

Drawing the model reveals that ESX email alerts go only to the supervisor's inbox. When she was ill for a week, nobody read them. The team creates a shared mailbox with two readers and records the change.

Synthetic case. The discovery is invented.

Errors and limits

Models show structure, not quality; pair them with evaluation.

Exercises

Synthesis

Model sources, processing, storage and outputs with owners; use the model to find weak points and coverage gaps.

Continue studying — chapter 06 of 18

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →