Chapter 24 — Threat intelligence and OSINT: controls | Bachelor's 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.

Lesson map

Lesson 24 published. Map, example, EX070.

flowchart TD
  N0["Learning outcomes"]
  N1["24.1 From technique to mitigation"]
  N2["24.2 The control request"]
  N3["24.3 Side effects"]
  N4["24.4 Verification"]
  N5["24.5 Decay"]
  N6["24.6 Detection as a control"]
  N7["Prioritising requests"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX070"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["24.1 From technique to mitigation"]
  N2["24.2 The control request"]
  N3["24.3 Side effects"]
  N4["24.4 Verification"]
  N5["24.5 Decay"]
  N6["24.6 Detection as a control"]
  N7["Prioritising requests"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]

[Learning outcomes]
    |
    v
[24.1 From technique to mitigation]
    |
    v
[24.2 The control request]
    |
    v
[24.3 Side effects]
    |
    v
[24.4 Verification]
    |
    v
[24.5 Decay]
    |
    v
[24.6 Detection as a control]
    |
    v
[Prioritising requests]
    |
    v
[Worked example] --> [Exercise EX070]

Learning outcomes

You will (1) map techniques to mitigations using ATT&CK; (2) write an intelligence-driven control request; (3) estimate the cost and side effects of a control; (4) verify that a control works.

24.1 From technique to mitigation

Each ATT&CK technique page lists mitigations — for phishing, user training, filtering and restricting web content; for valid accounts, multi-factor authentication and privileged account management. These are starting points, not prescriptions.

Amara checks each suggested mitigation against what HCHT already has, so that a request asks only for what is missing. For valid accounts, multi-factor authentication is in place for staff but not for some supplier accounts, so the request focuses there. Mitigations that would conflict with clinical work are discussed with the system owner before being proposed.

24.2 The control request

A good request states: the intelligence (with source and TLP), the technique, the proposed control, the expected benefit, side effects, owner and a deadline. It does not demand; it informs the owner's decision.

Amara uses a short template for every request, which makes it easy for owners to compare requests and decide quickly. The TLP label shows how far the owner may pass on the intelligence. Owners can accept, change or decline the request, and their decision is recorded with the reason. Declined requests are not failures; they show where intelligence and operational needs differ.

24.3 Side effects

Blocking macros in documents stops one delivery route but may break a laboratory spreadsheet used daily. Ask owners about impact before proposing.

Amara learned this when a proposed macro block was found to affect a spreadsheet the laboratory uses to record test results. The owner suggested signing the laboratory's own macros and blocking unsigned ones instead, which stops the same delivery route without disrupting work. Asking first turned a rejected request into a better control, and the laboratory team now raise similar concerns early.

24.4 Verification

After a control is applied, test it safely: send a harmless test document through the filter, or confirm a blocked domain fails to resolve. Record the test.

Amara writes the test steps into the request, so the owner knows what will be checked. Tests use harmless files and known test domains, never real malicious samples, and they run in agreement with the owner. A control that fails its test is reported to the owner immediately with the evidence, and the request stays open until a retest passes.

24.5 Decay

Controls decay: exceptions are added, rules disabled during outages and never re-enabled. Recheck quarterly.

Amara schedules a quarterly check of every control created from intelligence, comparing its current configuration with the recorded one. Exceptions are listed with their owner and reason; any without a reason are raised with the owner. In her first check she found a blocked domain that had been removed during an outage and never restored, and she reported it at once. The check takes about two hours each quarter.

24.6 Detection as a control

Not every risk can be prevented. Where prevention would break clinical work, a detection rule plus a rehearsed response may be the right control. The request then names who receives alerts, how fast they must act and what they will do, so the detection does not become an unread dashboard.

Amara drafts such requests with the clinical system owners. The requests name the alert recipients, who are reachable at all hours, and describe a short response that does not interrupt patient care, such as isolating a workstation while a clinical colleague continues on another. The response is rehearsed once with the owners before the rule goes live.

Prioritising requests

Owners receive many requests. Rank yours by technique frequency, HCHT exposure and the cost of the control, and send few strong requests rather than many weak ones. A short cover note explaining the ranking helps owners plan their own work around it.

Worked example

Intelligence shows a sector wave using malicious document attachments (User Execution, T1204). Amara drafts a request to the email team: quarantine macro-enabled attachments from external senders, with an exception process for two known suppliers. The team accepts; Amara verifies with a harmless test file and logs the result.

Synthetic case. The wave and suppliers are invented.

Errors and limits

Mitigations listed on ATT&CK vary in strength. Prefer controls you can test.

Exercises

EX070 — Request contents. List five elements of an intelligence-driven control request.
Show marking criteria
Rubric: 3 = five of intelligence/source/TLP, technique, control, benefit, side effects, owner, deadline; 2 = three; 1 = one; 0 = none.
EX071 — Laboratory spreadsheet. Why ask owners before proposing a macro block?
Show marking criteria
Rubric: 3 = may break critical workflow; exceptions needed; 2 = partial; 1 = no need; 0 = none.
EX072 — Verify a block. How can Amara safely verify a domain block?
Show marking criteria
Rubric: 3 = test resolution/connection from a test device fails; record; 2 = partial; 1 = assume; 0 = none.

Synthesis

Map techniques to mitigations, ask with evidence, weigh side effects, verify and recheck.

Continue studying — chapter 24 of 40

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