Chapter 7 — Threat intelligence and OSINT: controls and verification
Lesson map
Lesson 07 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Requests"]
N2["7.2 Choosing controls"]
N3["7.3 Process controls"]
N4["7.4 Verification"]
N5["7.5 Collateral damage"]
N6["7.6 Review"]
N7["7.7 Recording"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Requests"]
N2["7.2 Choosing controls"]
N3["7.3 Process controls"]
N4["7.4 Verification"]
N5["7.5 Collateral damage"]
N6["7.6 Review"]
N7["7.7 Recording"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[7.1 Requests]
|
v
[7.2 Choosing controls]
|
v
[7.3 Process controls]
|
v
[7.4 Verification]
|
v
[7.5 Collateral damage]
|
v
[7.6 Review]
|
v
[7.7 Recording]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) turn intelligence into control requests; (2) choose controls by indicator and technique; (3) verify controls after change; (4) avoid collateral damage.
7.1 Requests
Each request states intelligence and source, label, the control change, expected benefit, side effects, verification and review date. A complete request lets the owner decide without asking questions. For the MFA pilot, the intelligence was FSSG reports of credential phishing against three brokers, labelled GREEN. The change was MFA on brokers' remote email for a pilot group; the benefit was blocking stolen passwords; the side effect was extra login steps. Verification through sign-in logs and a review date completed the request before IT acted.
7.2 Choosing controls
Sender domains to the email gateway; malicious domains to DNS filtering; hashes to endpoint protection; technique intelligence to configuration — for example, multi-factor authentication on the client portal against Valid Accounts (T1078), and call-back verification against payment fraud. Matching the indicator to the control that can use it saves effort. A sender domain is useless in endpoint protection, and a file hash is useless in the email gateway. Technique intelligence often matters more than indicators, because indicators change quickly. The call-back step against payment fraud works whatever domain the fraudster uses next, which no indicator list can promise.
7.3 Process controls
Not all controls are technical. Business email compromise is best countered by verification procedures, dual approval for payments and staff awareness. The fraud case in Chapter 8 shows clearly why technical controls alone fall short. The lookalike email contained no malware and no link, so the gateway, DNS filtering and endpoint tools saw nothing unusual. Only the call-back on the second request stopped the payment. Dual approval would add a second person who checks the bank details, and awareness helps finance staff recognise the pretext before anyone pays.
7.4 Verification
Technical: test lookups, harmless test messages, configuration checks. Process: ask operations to confirm call-backs happened for the month's bank-detail changes. Each test produces a record that can go into the ticket. A test lookup of a blocked domain shows the DNS filter answering as expected, and a harmless test message shows the gateway quarantining a blocked sender. For the call-back control, operations shows the call log for each bank-detail change that month, which proves the step actually happened. Every verification record names who performed the test and when, so the result can be repeated by someone else later.
7.5 Collateral damage
Blocking a domain used by an insurer partner would disrupt business; check with operations first. A lookalike domain and a partner's real new domain can look alike in certificate-transparency results. Blocking an insurer's domain would stop policy documents and premium notices reaching brokers. That is why Priya checks with operations, and with marketing for domains that resemble BIB's own, before asking IT to block. The check costs minutes; a wrong block costs a working day. Any domain that turns out to belong to a partner is noted, so the same question does not need asking next month.
7.6 Review
Blocks expire; process controls are reviewed annually. Expiry stops the block lists growing forever with stale indicators that cause false positives later. Each block in the register carries a review date, after which IT removes it unless Priya renews it with fresh evidence. Process controls such as call-back verification last longer, so an annual review with operations is enough to confirm they still fit the work. When a block expires without renewal, IT records its removal in the register so the history of each indicator stays complete.
7.7 Recording
The control register lists every change made because of intelligence. Each row records the change, the intelligence behind it, the owner, the verification and the review date. The register is what lets Priya show, in her portfolio, twelve control changes traced to intelligence over six months. It also supports expiry, since IT can see which blocks are due for removal without searching old tickets. Without the register, nobody could tell which settings came from intelligence and which came from ordinary IT administration, so reviews would stall.
7.8 Measuring effect
Count blocked connections, quarantined messages and prevented fraudulent payments reported by operations. These counts need care if they are to give an honest picture of the controls' effect. A blocked connection might be a staff member mistyping a domain, not an attack. A prevented fraudulent payment is the strongest measure, but it depends on operations reporting it, as with the two prevented attempts in her portfolio review. Priya reports each figure with its source so readers can judge its weight.
7.9 ATT&CK mitigations
Technique pages list mitigations that can inspire requests, adapted to BIB's tools. For Valid Accounts (T1078), the mitigation pages point to multi-factor authentication, which became the MFA request for brokers' remote email. Priya adapts each idea to what BIB actually runs and can afford. A mitigation that needs tools BIB lacks becomes a note for the managing director's quarterly half-page rather than a request to IT. Each request that came from a mitigation page cites that page, so reviewers can check the original guidance against what BIB changed.
Staff awareness as a control
Awareness sessions using current, real-looking but synthetic examples help staff spot pretexts. Short monthly reminders beat a long annual course. Priya supplies the examples from intelligence; the help desk delivers them in team meetings. Reports of suspicious messages from staff are counted as a sign that awareness is working, and each report receives a thank-you reply.
Worked example
Priya requests multi-factor authentication for brokers' remote email access, citing FSSG reports of credential phishing against three brokers. IT enables it for a pilot group. Verification: sign-in logs show the second factor requested for each pilot login. A month later, failed sign-ins from flagged addresses no longer succeed.
Synthetic case. The pilot is invented.
Errors and limits
A control's absence of alerts does not prove it works; test it.
Exercises
- EX031 — BEC controls. Which controls best counter business email compromise? Rubric: 3 = verification call-backs, dual approval, awareness; 2 = two; 1 = firewall; 0 = none.
- EX032 — Process verification. How can a process control be verified? Rubric: 3 = confirm call-backs happened for actual changes; 2 = partial; 1 = assume; 0 = none.
- EX033 — Partner domain. Why check with operations before blocking a domain? Rubric: 3 = may be partner insurer; business disruption; 2 = partial; 1 = no need; 0 = none.
- EX034 — MFA verification. How was the MFA pilot verified? Rubric: 3 = sign-in logs show second factor per login; 2 = partial; 1 = vague; 0 = none.
- EX035 — Register. Why keep a register of intelligence-driven changes? Rubric: 3 = traceability, review, evidence of value; 2 = partial; 1 = no reason; 0 = none.
Synthesis
Request controls with evidence, include process controls, verify technically and procedurally, avoid collateral damage and record changes.
Continue studying — chapter 07 of 12
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →