Just got paged from a dashboard alert, and it got me thinking about how Recorded Future categorizes its intel. I've been using it more for correlating external threat IPs with our internal Prometheus scrape targets (weird traffic spikes from known bad IPs is a fun alert to build). But I keep tripping over the "Rule" vs "List" terminology in the portal.
From my late-night tinkering, here's how I've mapped it out:
**Lists** are the static (or manually updated) collections. They're your building blocks. Think of them like a static dashboard panel's query.
* A list of IP addresses known for C2 traffic.
* A list of domains associated with a specific threat actor.
* You create these by applying filters or uploading your own data. They hold the raw "indicators."
**Rules** are the dynamic, continuously updating logic. This is where it feels like setting up a PromQL alert rule.
* A rule is a *saved search* that automatically runs against Recorded Future's live data stream.
* It defines the logic (e.g., "Risk Criticality > 90 AND is Malware"), and the resulting set of indicators is your live "List."
* The key difference: the contents of the list generated by a Rule can change automatically as the intelligence changes.
So, a **List** can be a fixed snapshot, or it can be the *output* of a **Rule**. You'd typically use a Rule when you want your blocklist or watchlist to stay current without manual updates. It's like the difference between a hard-coded list of IPs in a config file versus a Prometheus query that populates a list variable based on current metrics.
For my use case, I have a **Rule** that populates a dynamic "List" of high-risk IPs. That list is then fed into a script that updates a firewall group. If I just used a static List, I'd have to manually re-export and update it every day.
Does that match everyone else's understanding? How are you all using Rules vs. Lists in your workflows?
zzz
Sleep is for the weak
Great analogy comparing it to PromQL alert rules, that's spot on. Your tinkering is right on the money. The one nuance I'd add from a pipeline perspective is thinking of **Lists as the "artifact"** and **Rules as the "build job."**
You can schedule a Rule to run hourly, daily, etc., and it outputs/snapshots a fresh List version. That's how you get that continuous update. It means you can treat the output List as a dependency for something else downstream, like syncing to a firewall blocklist. The Rule is the logic engine, the List is the packaged result.
So yeah, static vs dynamic is the core, but that artifact vs job relationship really clicked for me when automating this stuff. Ever tried piping a Rule-generated List into an external system automatically? That's where the fun starts.
pipeline all the things
"artifact vs build job" is a solid way to frame it. That pipeline view is exactly where the hidden costs creep in.
If you're piping a Rule-generated List to an external system on a schedule, you're paying for the compute to run that Rule *and* the egress traffic every single time it refreshes, even if only one IP changed. You can burn a surprising amount just syncing a 10,000-entry blocklist to five different firewalls every hour.
Makes me wish there was a diff/patch API for these output Lists. You end up building your own delta-check logic to avoid moving the whole artifact.
Cloud costs are not destiny.
You're spot on with the PromQL analogy. Thinking of a Rule as a saved, scheduled query is exactly right.
One nuance I've run into is that the static vs dynamic distinction can blur a bit. You can manually edit a Rule-generated List, but then you break the link back to its parent Rule. It becomes a static snapshot. This is useful for creating a fixed baseline for comparison, but it's a one-way trip.
From an optimization standpoint, this also means you can't retroactively apply a logic change from the Rule to those manually tweaked versions. You have to rebuild the artifact from scratch.
Your static vs dynamic mapping is fine for day one. But you're missing the real cost: rules are a vendor lock-in tax. Once you've built a dozen core rules, migrating that logic out of their proprietary builder to another tool is a full rewrite. Lists you can at least export as CSVs.
So sure, rules are dynamic. They're also debt.