Chapter 10 — Threat intelligence and OSINT: orientation | Technologist 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.

Chapter 10 — Threat intelligence and OSINT: orientation

Lesson map

Lesson 10 published. Map, example, EX028.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Definitions"]
  N2["10.2 The technologist's role"]
  N3["10.3 Models"]
  N4["10.4 Standards"]
  N5["10.5 OSINT rules"]
  N6["10.6 Where OSINT helps CMS"]
  N7["Career path"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX028"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 Definitions"]
  N2["10.2 The technologist's role"]
  N3["10.3 Models"]
  N4["10.4 Standards"]
  N5["10.5 OSINT rules"]
  N6["10.6 Where OSINT helps CMS"]
  N7["Career path"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]

[Learning outcomes]
    |
    v
[10.1 Definitions]
    |
    v
[10.2 The technologist's role]
    |
    v
[10.3 Models]
    |
    v
[10.4 Standards]
    |
    v
[10.5 OSINT rules]
    |
    v
[10.6 Where OSINT helps CMS]
    |
    v
[Career path]
    |
    v
[Worked example] --> [Exercise EX028]

Learning outcomes

You will (1) define CTI and OSINT for a technologist role; (2) place the role within a security team; (3) name the core models and standards; (4) state the ethical rules for OSINT.

10.1 Definitions

Cyber threat intelligence is analysed information about threats that supports defensive decisions. Open-source intelligence is intelligence derived from publicly available information collected lawfully. NIST SP 800-150 describes how organisations share threat information to strengthen defences.

The word analysed is what separates intelligence from the lists Lena receives. An MCX list of fraud domains becomes intelligence once someone has judged its relevance to CMS and tied it to a decision, as the permit-payment note in chapter 5 showed. The OSINT definition adds a condition that matters as much as usefulness: the information must be public and gathered lawfully.

10.2 The technologist's role

Lena's tasks: collect from approved sources, validate and normalise indicators, match them against logs, maintain the indicator store, draft short notes and support analysts. She does not decide blocks on critical systems or publish attribution.

Every task on that list prepares information for someone else to decide on. Lena's matching may show that ws-114 looked up a fraud domain, but whether to block it on a critical system belongs to the owner. Attribution is left out because naming an actor publicly needs evidence and authority far beyond a work-study post.

10.3 Models

The intrusion kill chain (Hutchins, Cloppert and Amin, 2011) splits intrusions into phases, showing where defenders can act. The Diamond Model (Caltagirone, Pendergast and Betz, 2013) describes each event by adversary, capability, infrastructure and victim. MITRE ATT&CK catalogues observed techniques.

Each of the three models answers a different question for Lena. The kill chain asks where in an intrusion CMS can act, the Diamond Model asks what is known about one event and what is missing, and ATT&CK gives a shared name for each technique. Lena already uses ATT&CK identifiers such as T1566 and T1190 in her asset list and notes.

10.4 Standards

STIX 2.1 is the data format; TAXII 2.1 the exchange protocol; FIRST TLP 2.0 the sharing labels.

Each standard covers one part of the exchange with MCX. STIX defines how an indicator and its relationships are written, as in the bundle from chapter 4; TAXII defines how CMS collects those bundles from MCX; and TLP tells Lena how widely each item may travel once it arrives. Using shared standards means Lena's scripts can read a bundle from any MCX member without a custom parser for each council. The TLP labels mean the same thing to every member, so an AMBER item from a neighbouring city carries the same limits at CMS as it did where it was written. When a sender departs from a standard, as with the dangling reference in chapter 4, the standard gives Lena a clear basis for asking them to fix it.

10.5 OSINT rules

Use only approved sources and methods. Follow each site's terms of service. Do not create fake accounts, join closed groups, or collect personal data beyond the need. Data-protection law applies to public personal data.

These rules apply even when breaking them would be easy, for example joining a closed forum where fraud kits are discussed. A fake account there would breach the site's terms and could expose CMS legally, whatever the intent. The worked example below shows the personal-data rule applied to residents who complained about fraud texts.

10.6 Where OSINT helps CMS

Certificate-transparency logs for lookalike domains, public vulnerability advisories, official government alerts, and passive DNS through approved services. These answer CMS questions without touching adversaries.

Each of these sources answers a question that CMS already has. Certificate-transparency logs show new certificates for names resembling Corvale's, which often appear before a fraud page goes live. Advisories answer whether the portal software is affected, and passive DNS shows when a lookalike first resolved, all without CMS touching the suspicious infrastructure. Lena records which approved service answered each question, so a finding can be repeated by a colleague later.

Career path

Technologists often move into analyst roles after building strong data-handling habits. Writing clear notes, asking good questions and respecting handling rules matter as much as scripting skill in that progression.

Worked example

A colleague suggests searching social media for the names of people who complained about fraud texts to "see who was targeted". Lena points out that CMS needs the fraud domains, not residents' identities; she collects the domains from CMS's own complaint form instead, where residents agreed to share details.

Synthetic case. The suggestion is invented.

Errors and limits

Public information can be wrong or planted; validate before use.

Exercises

EX028 — Role boundary. Name two tasks outside a technologist's authority at CMS. Rubric: 3 = deciding blocks on critical systems, publishing attribution; 2 = one; 1 = matching logs; 0 = none.
EX029 — Social media idea. Why did Lena reject searching residents' social media? Rubric: 3 = unnecessary personal data; complaint form gives what's needed lawfully; 2 = partial; 1 = acceptable; 0 = none.
EX030 — Useful OSINT. List three OSINT sources that help CMS without touching adversaries. Rubric: 3 = three of CT logs, advisories, government alerts, passive DNS; 2 = two; 1 = one; 0 = none.

Synthesis

Know the definitions, your role, the models and standards, and the ethical limits of OSINT.

Continue studying — chapter 10 of 30

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →