Chapter 10 — Threat intelligence and OSINT: control configuration
Lesson map
Lesson 10 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Formats"]
N2["10.2 Choosing points"]
N3["10.3 Expiry"]
N4["10.4 Requests"]
N5["10.5 Allow lists"]
N6["10.6 Testing"]
N7["10.7 Change windows"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Formats"]
N2["10.2 Choosing points"]
N3["10.3 Expiry"]
N4["10.4 Requests"]
N5["10.5 Allow lists"]
N6["10.6 Testing"]
N7["10.7 Change windows"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[Learning outcomes]
|
v
[10.1 Formats]
|
v
[10.2 Choosing points]
|
v
[10.3 Expiry]
|
v
[10.4 Requests]
|
v
[10.5 Allow lists]
|
v
[10.6 Testing]
|
v
[10.7 Change windows]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) prepare indicator lists in formats controls accept; (2) choose enforcement points by indicator type; (3) set expiry and review on each entry; (4) document configuration requests.
10.1 Formats
The DNS filter accepts one domain per line; the email gateway accepts sender domains and attachment hashes through its management interface; the firewall accepts address objects. Tomás prepares each list from the platform export and validates it before handing it over.
Validation catches entries that would fail to load or block too much, such as a domain with a space or a whole top-level domain. Each control needs its own format, so one platform export becomes three separate lists. Tomás checks the line count of each list against the platform export before attaching it to the request.
10.2 Choosing points
Domains to DNS; sender domains to email; hashes to email attachment scanning and endpoint; addresses only when not shared hosting. Techniques inform configuration too: intelligence on macro-laden attachments (User Execution, T1204) supports quarantining macro documents from outside.
Addresses on shared hosting can serve hundreds of unrelated sites, so blocking one would cut off legitimate services, as the revision-site case showed. Domains and hashes are more specific and sit better at DNS and email. The macro example shows how technique intelligence can support a broad rule rather than one indicator at a time.
10.3 Expiry
Every entry carries an expiry date: 30 days for addresses, 90 for domains, longer for hashes. Lists without expiry grow until they break things.
The periods follow how quickly each type of indicator changes hands: addresses are reassigned fastest, domains less often and file hashes never. When an entry expires, the platform flags it for review rather than renewing it automatically. Tomás renews only entries that ESX or another source has reported again since the original item. The expiry date is set from the indicator's valid_from time, not from the date it reached Ashgrove.
10.4 Requests
Tomás drafts; the owning team configures. The request includes list, source, TLP, reason, expiry and verification plan.
Including the verification plan means the owning team knows in advance how success will be tested. The TLP marking tells them whether the list can be shared with suppliers who manage the control. Tomás attaches the validated list to the request rather than pasting entries into the ticket text, so nothing is mistyped. The source and reason let the owning team check the request against the original intelligence if they wish. The owning team replies in the same ticket once the change is loaded.
10.5 Allow lists
Some domains must never be blocked: the learning platform, examination boards, the student loan service. An allow list checked before every export prevents accidents.
These services are ones students and staff cannot work without, and some sit on shared cloud platforms that also appear in feeds. Tomás's export script compares every entry against the allow list and removes matches before the request is drafted. The file-sharing domain caught in the worked example shows the check working on a real export.
10.6 Testing
After loading, a test lookup of one blocked domain from a test machine must fail; a test of an allowed domain must succeed.
The test lookup proves that the list loaded and that the control acts on it. Testing an allowed domain at the same time shows that the change did not break ordinary access. Tomás records both results with the time and the test machine used, and attaches them to the configuration request. If either test fails, the change is rolled back and the request reopened with the test result attached.
10.7 Change windows
Large list changes happen outside exam periods, when disruption would hurt most.
During exams, a wrong block could stop students reaching an examination board or the learning platform at the worst moment. Urgent single entries can still be added in those weeks after the owning team agrees. Tomás checks the college calendar before scheduling any large update and notes the chosen window in the request. Exam periods are taken from the college calendar each term, because they differ between courses and campuses. Tomás asks the network team to confirm the window in writing before he schedules anything.
10.8 Documentation
The configuration register lists every list, owner, last change and expiry policy.
When a block causes a complaint, the register shows at once which list holds the entry, who owns it and when it last changed. It also shows the expiry rules for each list, so reviewers can check that old entries are being removed. Tomás updates the register in the same ticket as each change. The register is kept in the team repository with the runbooks, so every edit is tracked and reversible. The network and email teams can read it at any time, including during out-of-hours calls.
10.9 Size limits
Some tools cap list size. When near the cap, remove expired entries first rather than raising the cap blindly.
Expired entries are the safest to remove because their sources no longer support them. Raising the cap without that cleanup only delays the problem and keeps stale indicators that can block legitimate services. Tomás reports the list size to the owning team each month, so the cap is never reached by surprise. The monthly size report shows the number of entries per list, how many expire within thirty days and the product's cap.
Worked example
Tomás's export includes a file-sharing domain from a vendor feed. The allow-list check stops it: lecturers use that service to share materials. He removes it from the request and reports the feed's error to the vendor through his supervisor.
Synthetic case. The domain and feed are invented.
Errors and limits
Controls vary by product; read their documentation before formatting.
Exercises
- EX037 — Expiry periods. State expiry periods for addresses and domains and why they differ. Rubric: 3 = 30 vs 90 days; addresses reassigned faster; 2 = numbers; 1 = same; 0 = none.
- EX038 — Allow-list catch. What did the allow-list check prevent? Rubric: 3 = blocking lecturer file-sharing service; 2 = partial; 1 = vague; 0 = none.
- EX039 — Macro intelligence. Which control does T1204 macro intelligence support? Rubric: 3 = quarantine external macro documents; 2 = partial; 1 = firewall; 0 = none.
- EX040 — Exam timing. Why avoid large list changes during exams? Rubric: 3 = disruption most harmful; 2 = partial; 1 = no reason; 0 = none.
Synthesis
Format lists for each control, pick enforcement points by type, add expiry, check allow lists and test after loading.
Continue studying — chapter 10 of 18
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →