Chapter 18 — Threat intelligence and OSINT: controls
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 From note to change"]
N2["18.2 Change request contents"]
N3["18.3 Verification"]
N4["18.4 Rollback"]
N5["18.5 Review dates"]
N6["18.6 Avoiding overload"]
N7["18.7 Mitigation ideas from ATT&CK"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 From note to change"]
N2["18.2 Change request contents"]
N3["18.3 Verification"]
N4["18.4 Rollback"]
N5["18.5 Review dates"]
N6["18.6 Avoiding overload"]
N7["18.7 Mitigation ideas from ATT&CK"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 From note to change]
|
v
[18.2 Change request contents]
|
v
[18.3 Verification]
|
v
[18.4 Rollback]
|
v
[18.5 Review dates]
|
v
[18.6 Avoiding overload]
|
v
[18.7 Mitigation ideas from ATT&CK]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) convert intelligence into control changes through owners; (2) write a change request with evidence; (3) verify controls after change; (4) plan rollback.
18.1 From note to change
Intelligence becomes protection only when a control changes: a DNS block, an email rule, an endpoint rule, a configuration fix. Lena drafts; owners decide and implement through change management.
Lena's notes and matches change nothing on their own; the DNS filter, email gateway and endpoint tools do. Owners decide because they know what a change will affect, and change management records each change so it can be reviewed or undone. The worked example below shows a DNS block passing through this route.
18.2 Change request contents
Intelligence summary with source and TLP, affected asset, proposed change, expected effect, possible side effects, verification method, rollback plan and review date.
Each part answers a question the owner would otherwise have to ask. Source and TLP show how much to trust the request; side effects and rollback show what could go wrong and how to undo it; verification shows how everyone will know it worked; and the review date makes sure the change is revisited rather than left in place indefinitely.
18.3 Verification
After a DNS block, a test lookup from an approved test machine should fail. After an email rule, a harmless test message matching the rule should be quarantined. Results are attached to the change.
A test from an approved machine proves the control is active without anyone visiting the fraud page. For an email rule, a harmless message built to match the rule shows that the gateway catches it. Attaching the result means the change record shows evidence of success, not just that the change was made.
18.4 Rollback
If a block breaks a service, the owner removes it quickly. The plan says how and who approves.
A block on a domain that turns out to be used by a supplier could stop invoices or deliveries the same day. Naming who approves removal in advance means the owner does not wait for Lena or the manager at a busy moment. The block's record helps the service desk find the cause when users report a site as unreachable. The rollback steps are tested with the verification, so the owner knows removal works before it is ever needed in a hurry.
18.5 Review dates
Domain and address blocks are reviewed after a set period; techniques-based rules are reviewed when ATT&CK or the threat changes.
Domains and addresses change hands, so a block based on last month's fraud page may later hit an innocent site. A rule built on a technique, such as filtering phishing attachments, stays useful as long as the technique is in use. The two kinds of control therefore need different review triggers. Each review asks whether the control still matches a current threat and whether its hits justify keeping it.
18.6 Avoiding overload
Owners receive many requests. Lena bundles low-urgency indicator blocks into a weekly change and keeps single urgent changes for genuine emergencies.
A weekly bundle gives owners one change to review instead of many small ones, and keeps the emergency route credible. If every block were labelled urgent, owners would stop treating urgent requests as special. The fraud domains in the worked example were applied in the evening change window rather than as an emergency. Bundled changes still list each indicator with its own source and review date, so one can be removed without undoing the rest.
18.7 Mitigation ideas from ATT&CK
Technique pages list mitigations. For T1566, filtering and user training; for T1078, multi-factor authentication. These guide proposals but must be adapted to CMS tools.
Adapting the mitigation means turning it into something CMS can do with its own tools. Filtering for T1566 becomes a rule in CMS's email gateway, and multi-factor authentication for T1078 builds on the identity provider and the case for including part-time library workers. The ATT&CK page supplies the idea; the proposal supplies the details. Lena cites the ATT&CK page in the change request, so the owner can read the original mitigation text.
Measuring effect
After a month, check whether the control did anything: blocked lookups counted by the DNS filter, quarantined messages counted by the gateway. A control with zero hits may still be worthwhile, but the count informs the review decision.
Worked example
Lena requests a DNS block for the two fraud domains, with an MCX source at TLP:GREEN, verification by test lookup and rollback by removing the entries. The network team applies it in the evening change window. Her test lookup fails as expected; she attaches the result.
Synthetic case. The change is invented.
Errors and limits
Verification proves the control is active, not that it stops every variant.
Exercises
- EX052 — Change contents. List six items in Lena's change request. Rubric: 3 = six of summary/source/TLP, asset, change, effect, side effects, verification, rollback, review; 2 = four; 1 = two; 0 = none.
- EX053 — Verify email rule. How can an email rule be verified safely? Rubric: 3 = harmless test message matching rule quarantined; 2 = partial; 1 = real phish; 0 = none.
- EX054 — Bundling. Why bundle low-urgency blocks weekly? Rubric: 3 = reduce owner overload; reserve urgent path; 2 = partial; 1 = no reason; 0 = none.
Synthesis
Turn intelligence into owner-approved changes with evidence, verify them, plan rollback and review over time.
Continue studying — chapter 18 of 30
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →