◇ OpenCyber Academy
Engineering · Chapter 37 · English

Chapter 37 — Threat intelligence and OSINT: operations

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 37 — Threat intelligence and OSINT: operations

Lesson map

Lesson 37 published. Map, example, EX109.

flowchart TD
  N0["Learning outcomes"]
  N1["37.1 Runbooks"]
  N2["37.2 On-call"]
  N3["37.3 Retractions"]
  N4["37.4 Suspected TLP breach"]
  N5["37.5 Reporting"]
  N6["Practice note — blameless reviews"]
  N7["Handover notes"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX109"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["37.1 Runbooks"]
  N2["37.2 On-call"]
  N3["37.3 Retractions"]
  N4["37.4 Suspected TLP breach"]
  N5["37.5 Reporting"]
  N6["Practice note — blameless reviews"]
  N7["Handover notes"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX109"]

[Learning outcomes]
    |
    v
[37.1 Runbooks]
    |
    v
[37.2 On-call]
    |
    v
[37.3 Retractions]
    |
    v
[37.4 Suspected TLP breach]
    |
    v
[37.5 Reporting]
    |
    v
[Practice note — blameless reviews]
    |
    v
[Handover notes]
    |
    v
[Worked example] --> [Exercise EX109]

Learning outcomes

You will (1) write runbooks for routine and abnormal Lantern operations; (2) define on-call responsibilities; (3) handle partner incidents such as leaked or retracted data; (4) report operational metrics to management.

37.1 Runbooks

Routine: daily review of collector health, reject spikes and certificate expiry. Abnormal: partner feed stops; poisoned indicators detected; enrichment provider outage; TLP breach suspected. Each runbook lists symptoms, checks, actions, escalation and closure steps.

Kofi writes each runbook so that an engineer who has never seen the problem can follow it at three in the morning. Steps say what to check and what a normal result looks like, not just which command to run. After each real use, the engineer notes any step that was unclear or wrong, and the runbook is updated that week.

37.2 On-call

One engineer is on call per week with a documented handover. Pages fire only for conditions needing action within an hour; everything else goes to a daily queue. Alert fatigue is a reliability risk.

Kofi reviewed a month of pages and found that half were for conditions that could wait until morning, such as a single reject spike from a minor partner. Moving those to the daily queue halved the pages without missing anything urgent. The handover note lets the next engineer pick up open issues without having to ask what happened during the week.

37.3 Retractions

Partners sometimes retract indicators published in error. Lantern must remove them from enforcement promptly, record the retraction and inform downstream recipients who received them. STIX 2.1 supports revocation through the revoked property on a new object version.

Lantern treats a revoked version as an instruction to remove the indicator from every enforcement point and to stop scoring it. The original object remains in the archive, marked revoked, so analysts can see that it was once published and withdrawn. Forwarding the revocation to every member who received the indicator is tracked in the sharing log, which is how the worked example knows exactly which two members to inform.

37.4 Suspected TLP breach

If restricted content appears where it should not, the runbook says: contain (remove access), assess what was exposed, notify the originator as the agreement requires, and review the gate. Honesty with partners protects the relationship that NIST SP 800-150 describes as the basis of sharing.

Kofi's runbook names who leads each step and the deadline set in each partner agreement. Assessment uses the access log to show exactly who saw the material and when. A partner told quickly and accurately usually stays in the community; one who hears from someone else may not.

37.5 Reporting

Monthly: availability against SLO, objects processed, reject rates, time-to-enforcement percentiles, false-positive tickets, partner feedback sent and received.

Kofi's report puts each figure next to its target and last month's value, with a sentence explaining any large change. Reject rates are broken down by partner, which makes quality problems visible to the people who can fix them. The report goes to the CTI lead and the SOC manager, and a shorter version with aggregate figures only goes to partners who have asked for it. Each figure states its source and period.

Practice note — blameless reviews

After incidents, reviews focus on how the system allowed the error. Engineers who fear blame hide near-misses, which removes the data needed to improve.

Handover notes

Each on-call week ends with a written handover listing open issues, partner contacts engaged and anything unusual, so the next engineer does not rediscover context during a page.

Worked example

A partner revokes 40 indicators published by mistake. Lantern processes the revoked versions within 12 minutes, removes the blocks and forwards revocations to the two community members that received them. The monthly report records the event and time to revoke.

Synthetic case. The retraction is invented.

Errors and limits

Runbooks rot; test them in drills. Paging for everything ensures nothing is noticed.

Exercises

Synthesis

Runbooks for routine and abnormal work, humane on-call, prompt revocation, honest breach handling and regular metrics.

Continue studying — chapter 37 of 50

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