Chapter 39 — Threat intelligence and OSINT: maintainability | 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 39 — Threat intelligence and OSINT: maintainability

Lesson map

Lesson 39 published. Map, example, EX115.

flowchart TD
  N0["Learning outcomes"]
  N1["39.1 Maintenance burden"]
  N2["39.2 Documentation for successors"]
  N3["39.3 Technical debt register"]
  N4["39.4 Standards evolution"]
  N5["39.5 Simplicity"]
  N6["Practice note — bus factor"]
  N7["Deprecation policy"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX115"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["39.1 Maintenance burden"]
  N2["39.2 Documentation for successors"]
  N3["39.3 Technical debt register"]
  N4["39.4 Standards evolution"]
  N5["39.5 Simplicity"]
  N6["Practice note — bus factor"]
  N7["Deprecation policy"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]

[Learning outcomes]
    |
    v
[39.1 Maintenance burden]
    |
    v
[39.2 Documentation for successors]
    |
    v
[39.3 Technical debt register]
    |
    v
[39.4 Standards evolution]
    |
    v
[39.5 Simplicity]
    |
    v
[Practice note — bus factor]
    |
    v
[Deprecation policy]
    |
    v
[Worked example] --> [Exercise EX115]

Learning outcomes

You will (1) measure and reduce maintenance burden; (2) document Lantern for successors; (3) manage technical debt explicitly; (4) plan for standards evolution (STIX/TAXII versions, ATT&CK releases).

39.1 Maintenance burden

Track hours spent on partner format changes, dependency updates, incident fixes and analyst requests. If maintenance consumes most of the team's time, new features should wait.

Kofi's team logs time against these categories in their ticketing system. After one quarter the figures showed partner format changes taking more effort than expected, mostly because each partner's parser had its own code. That finding led to a shared parser with per-partner configuration, which cut the effort noticeably the following quarter. The categories are reviewed once a year.

39.2 Documentation for successors

Architecture overview, ADRs, runbooks, partner configuration guide, data dictionary and a "first week" guide. Kofi tests documentation by asking a new engineer to add a synthetic partner using only the docs.

The new engineer reads the documents without help and writes down every question. Those questions show where the documents assume knowledge that only the current team has. Kofi keeps the documents in the same repository as the code, so a change that alters behaviour must also update the description in the same review.

39.3 Technical debt register

Each shortcut is recorded with its cost, risk and a target date: "Proxy integration uses polling instead of the vendor's push API; risk low; revisit Q3". Debt hidden in code comments is forgotten.

Kofi reviews the register at each planning meeting. Items whose target date has passed are either scheduled, given a new date with a reason or accepted as permanent with the risk recorded. The register also shows the team's total debt at a glance, which helps when arguing for time to pay some of it back.

39.4 Standards evolution

ATT&CK publishes new versions periodically, renaming or deprecating techniques. Lantern stores the ATT&CK version alongside each mapping and runs a migration report when a new version appears. STIX and TAXII versions are tracked similarly; supporting 2.1 does not guarantee compatibility with a future version.

The worked example shows the effect: fourteen mappings needed new technique identifiers, and the migration report found all of them in minutes. Analysts then checked each one by hand, because a renamed technique sometimes splits into two and the right choice depends on the evidence.

39.5 Simplicity

The simplest design that meets requirements is easiest to maintain. Remove unused features found during validation.

Kofi removed the daily digest feature after validation showed nobody read it, along with its template, its scheduled job and its tests. The code base became smaller and the next dependency update touched fewer files. Each feature kept should have a user who would notice its removal. A design that adds options for possible future needs usually leaves code that nobody remembers how to change safely.

Practice note — bus factor

If only one person understands the firewall push, Lantern has a bus factor of one. Pairing and rotation spread knowledge.

Deprecation policy

Features unused for two quarters are announced as deprecated, given a removal date and then deleted, with partners told when an export format is affected.

Worked example

The new engineer adds a synthetic partner in 90 minutes using the guide, noting two unclear steps. Kofi fixes the guide. Separately, an ATT&CK update deprecates a technique used in 14 mappings; the migration report lists them and analysts remap them in an afternoon.

Synthetic case. Timings and counts are invented.

Errors and limits

Documentation that describes intentions rather than reality misleads. Pinning ATT&CK versions forever leaves mappings outdated.

Exercises

EX115 — Docs test. How did Kofi test documentation quality? Rubric: 3 = new engineer adds synthetic partner using only docs; gaps fixed; 2 = review by peer; 1 = vague; 0 = none.
EX116 — Debt entry. Write a technical-debt register entry for a hard-coded polling interval. Rubric: 3 = description, cost/risk, target date; 2 = two parts; 1 = comment only; 0 = none.
EX117 — ATT&CK version. Why store the ATT&CK version with each mapping? Rubric: 3 = techniques change/deprecate; enables migration report; 2 = partial; 1 = unnecessary; 0 = none.

Synthesis

Measure maintenance, document for strangers, register debt, track standards versions and keep designs simple.

Continue studying — chapter 39 of 50

← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →