Lion Cipher Lab

Score threat-feed quality, and catch a poisoned indicator feed

• Threat Intel Analyst
• Advanced
• ~100 min
• Free · no account required

Why it matters

Threat intelligence is the one part of security that most teams consume entirely on trust. A feed arrives, it is full of addresses and domains and hashes, somebody wires it into a firewall or a proxy or a SIEM watchlist, and from that moment an outside party has write access to a control that can take your company off the internet -- and nobody ever measures whether the feed was any good. This lab replaces that trust with arithmetic, and then it shows you what the arithmetic is protecting you from. First you build a scorecard, because the questions that actually matter about a feed are not…

What you'll learn

• scoring a FEED instead of an indicator: precision, recall, median lead time, uniqueness vs overlap, volume and churn, hit rate in your own network, and expiry hygiene -- all computed, not asserted
• the number that decides a renewal: true hits per 1,000 indicators carried, where a feed 20.3x the size delivered 29.5 against another feed's 909.4
• reading lead time properly: a NEGATIVE median means the feed is telling you about things you already saw, and a very large POSITIVE one is usually staleness rather than prescience
• measuring circular reporting: how 'four independent feeds agree' collapses to one original report once you count ORIGINS instead of feeds, and why a confidence score that rises with feed count is trivially gameable
• poisoning a block pipeline, framed defensively: what an attacker submits to a community feed so that YOUR automation causes YOUR outage -- your egress address, a CDN edge, a resolver, a sinkhole, shared hosting, a /16
• measuring blast radius in sessions, hosts, users AND business processes, and seeing why session volume is the wrong impact metric for a careful attacker's targets
• the counter-intuitive one: blocking a researcher sinkhole protects nothing and deletes the only signal identifying your own infected machines
• nine guardrails -- bogon/special-use, own and partner allowlisting, popularity allowlisting, prefix-size sanity, shared-hosting and CDN detection, sinkhole exclusion, robust burst detection on the feed, provenance weighting, and a staged monitor-only rollout -- each PRICED in true positives lost
• the guardrails' own failure modes: the over-broad allowlist, the popularity allowlist during a real supply-chain compromise, and poison that is invisible per-indicator and obvious in aggregate
• what you cannot measure in production without ground truth, what to substitute (your own telemetry as the arbiter), and the pro rule that no external party ever writes directly to a blocklist

Steps in this lab

1. The thesis, and which labs this is NOT
2. The words you need, defined once
3. Open a terminal and check Python (zero-assumption setup)
4. Build the corpus: six feeds, 1,437 truths, and 60 days of your own traffic
5. Create scorecard.py and read the six numbers that decide a renewal
6. The payoff: the biggest feed is not the best feed, and by how much
7. Uniqueness and overlap: how much of feed B is just feed A
8. Circular reporting: four feeds agreeing is not four sources
9. Create guardrails.py, and meet the two ways a feed goes wrong
10. Blast radius: what auto-blocking those twenty entries would actually do
11. Nine guardrails, and the bill for each one
12. G4 and G5: two guardrails that are almost right
13. G7 and G8: stop scoring the entry, start scoring the feed
14. G9: the staged rollout, and exactly how much it buys you
15. Failure mode (i) and (ii): the allowlist that is too broad, and the one that hides a real breach
16. Failure mode (iii): poison that is invisible per indicator and obvious in aggregate
17. Failure mode (iv): what you cannot measure without ground truth -- and the good news
18. The whole pipeline, measured -- and the bill
19. Why this, not that
20. When NOT to auto-block from a feed at all
21. How a pro does it differently

Open the full interactive lab →