Lion Cipher Lab
Measure threat-feed timeliness and catch dead-on-arrival indicators
- Threat Intel Analyst
- Intermediate
- ~60 min
- Free · no account required
Why it matters
A feed can ship a hundred thousand indicators a day and still be useless, because by the time its indicators reach you the attacker's domains are already sinkholed and its IPs are already reassigned. Volume dashboards hide this completely -- they count rows, not freshness. The number that actually decides whether a feed is worth paying for (or trusting) is how long its indicators take to get to you, and how many are already dead when they land. Learn to measure the lag between "first seen in the wild" and "arrived in my pipeline," and you can tell a fast, small feed from a huge,…
What you'll learn
- Measuring feed TIMELINESS: the ingest lag between first_seen (observed in the wild) and published (when the feed listed it)
- Computing median and p90 ingest lag per feed, and a dead-on-arrival rate (expired/retracted/sinkholed on arrival)
- Segmenting dead-on-arrival by indicator type -- a burned domain/IP is not the same as a file hash, which does not expire
- Handling missing, self-reported first_seen timestamps honestly (count them, do not silently drop)
- Normalizing timestamps to UTC so clock/timezone skew between sources does not distort the lag
- Ranking feeds by ACTIONABLE freshness instead of raw indicator count -- and seeing the two rankings disagree
Steps in this lab
- The axis you're measuring: timeliness, not quality or aging
- Two clocks every indicator carries (and one you add)
- Generate three synthetic feeds and measure them
- Read the lag: median, p90, and the timestamps that were missing
- Dead on arrival -- and why you must segment by indicator type
- The decision: rank by actionable freshness, not by count
- Honest limits: timeliness is necessary, not sufficient