Chapter 26 — Threat intelligence and OSINT: architecture alternatives | Engineering 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 26 — Threat intelligence and OSINT: architecture alternatives

Lesson map

Lesson 26 published. Map, example, EX076.

flowchart TD
  N0["Learning outcomes"]
  N1["26.1 Three options"]
  N2["26.2 Criteria and weights"]
  N3["26.3 Portability"]
  N4["26.4 Hybrid answers"]
  N5["26.5 Review dates"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX076"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["26.1 Three options"]
  N2["26.2 Criteria and weights"]
  N3["26.3 Portability"]
  N4["26.4 Hybrid answers"]
  N5["26.5 Review dates"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX076"]

[Learning outcomes]
    |
    v
[26.1 Three options]
    |
    v
[26.2 Criteria and weights]
    |
    v
[26.3 Portability]
    |
    v
[26.4 Hybrid answers]
    |
    v
[26.5 Review dates]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX076]

Learning outcomes

You will (1) compare build, buy and community-platform options for CTI; (2) run a weighted trade study; (3) assess lock-in and data portability through STIX/TAXII support; (4) record the decision and its review date.

26.1 Three options

Option A: extend Lantern in-house. Option B: buy a commercial threat-intelligence platform. Option C: adopt an open-source community platform such as MISP and integrate it with BEN's controls. Each can ingest feeds and share with partners; they differ in cost, control, staffing and support.

Kofi describes each option by what BEN would have to do itself. In-house means BEN writes and maintains everything. A commercial product shifts maintenance to a vendor but limits how far BEN can change it. A community platform brings a large user base and free software, while BEN still runs and secures the servers.

26.2 Criteria and weights

Kofi agrees criteria with stakeholders before scoring: interoperability (STIX/TAXII 2.1), TLP enforcement, OT approval workflow, total cost over five years, staffing burden, data residency, and exit cost. Weights sum to 100. Agreeing weights first prevents the favourite option from shaping the criteria.

Kofi ran the weighting session with the CTI lead, the network operations manager and the privacy officer, and each argued for the criteria closest to their work. The final weights were recorded with a sentence explaining each, so later readers can see why OT workflow counted for more than user-interface polish.

26.3 Portability

If a platform cannot export everything as standard STIX 2.1 bundles, leaving it later means losing history. Exit cost is a real criterion, not a footnote.

Kofi tested portability for each option with the synthetic dataset: load a few thousand objects, export them and compare the export with the original. One option dropped relationship objects on export, which would have broken the links analysts depend on. That result lowered its score more than any feature list could have raised it. The test takes an afternoon and should be repeated before any contract is signed.

26.4 Hybrid answers

Trade studies often end in hybrids: a community platform for partner sharing plus a thin in-house service for OT approvals and firewall pushes. Hybrids add integration work, which must be scored too.

In the worked example the hybrid wins, but the integration it needs is real work: the community platform must hand approved blocks to the in-house service, and both must agree on identifiers. Kofi estimated that effort in engineer-weeks and added it to the cost criterion. Without that step a hybrid looks like the best of both options at no extra price, which is rarely true.

26.5 Review dates

Markets and staffing change. The decision record sets a review date — for example in two years — and the triggers that would force an earlier review, such as loss of the only engineer who knows the in-house code.

Kofi also lists what evidence the review would need: costs actually incurred, partner feedback on sharing and time spent on maintenance. Collecting those figures from the start makes the review a comparison rather than a debate. A decision that is never revisited tends to be defended long after it stops fitting.

Worked example

Scores (out of 100): A 68, B 71, C 74. Option C wins narrowly on interoperability and cost but scores lower on OT workflow. Kofi recommends C plus a small in-house OT approval service, notes that the margin is within scoring uncertainty, and asks the panel to judge the OT risk explicitly.

Synthetic case. Scores and options are illustrative; no vendor is evaluated.

Errors and limits

Close scores are ties in practice; say so. Vendor demonstrations on vendor data prove little; test with synthetic BEN-like data.

Exercises

EX076 — Weights first. Why must criteria weights be agreed before options are scored? Rubric: 3 = prevents biasing criteria toward a favourite; 2 = fairness vaguely; 1 = order irrelevant; 0 = none.
EX077 — Exit cost. How does STIX 2.1 export capability affect exit cost? Rubric: 3 = full standard export lowers cost/preserves history; lack raises it; 2 = partial; 1 = unrelated; 0 = none.
EX078 — Narrow margin. Scores of 71 and 74 differ by three points. How should Kofi present that? Rubric: 3 = within uncertainty; treat as near-tie; surface key qualitative risk; 2 = mention closeness; 1 = clear winner; 0 = none.

Synthesis

Agree weights first, score portability, accept hybrids with their integration cost, and set a review date.

Continue studying — chapter 26 of 50

← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →