How to Build a Threat Intelligence Feed Without a Big Budget

Most threat intelligence programs fail the same way. Someone signs up for a dozen feeds, dumps them into a shared folder, and nobody looks again. The feed becomes a chore, the chore becomes guilt, and the guilt gets deleted during the next cleanup sprint.

Small teams can dodge that. Treat threat intel as a pipeline with a deliberately narrow output, not as a library you are supposed to read. You are not trying to understand every adversary. You are trying to answer three questions: what is aimed at us, what does it look like on our systems, and what should we change this week? Anything that does not help answer those is noise, however free it is.

Start With the Decisions, Not the Feeds

Before you collect a single indicator, write down what you would actually do with one. For a team of two or three, honest answers look like this:

• Block a domain, IP, or file hash at the DNS filter, proxy, or mail gateway
• Write or tune a detection rule in your SIEM or EDR
• Add an actor, malware family, or tool to a watchlist and hunt for it
• Patch faster because something is being exploited in the wild
• Brief a customer or an executive with something more useful than "threats exist"

If a source cannot plausibly support one of those actions, cut it. A feed you cannot act on will only make you feel behind.

The Free Sources That Earn Their Place

Free does not mean worthless, but it does mean uneven. Pick one or two from each category and stop.

• Exploitation context: CISA's Known Exploited Vulnerabilities catalog, NVD data, and vendor advisories tell you which bugs are being used rather than merely scored.
• Malware and infrastructure: the abuse.ch projects (URLhaus, MalwareBazaar, Feodo Tracker), AlienVault OTX, PhishTank, and open blocklists cover a lot of ground. Each has its own licence and rate limits, so read them.
• Detection content: Sigma rules, community YARA repositories, and open Suricata rulesets give you something to run today instead of something to read.
• Open reporting: vendor research blogs, national CERT advisories, and a handful of well-run newsletters. This is where you learn about a campaign before it has tidy indicators attached.
• Community chatter: the security corner of Mastodon and Bluesky moves faster than any feed. Follow practitioners, not aggregators that repost headlines.

That is five categories and maybe fifteen sources. It is enough. Adding more rarely improves decisions; it just makes the pipeline harder to maintain.

Collection and Normalization Without a Platform

You need somewhere to put things and a schedule to fetch them. A small VM, a container, or a directory synced by a scheduled job is fine. Pull each source with a script on a timer, and always store the raw copy with a retrieval timestamp before you touch it. Raw data is your audit trail when a normalized record looks wrong.

Normalize into a schema you can explain to a colleague in one sentence: indicator, type, first seen, last seen, source, confidence, context, expiry. A CSV file or a SQLite table handles this at small scale. If you want a real interface, MISP and OpenCTI are open source and do deduplication, tagging, and sharing for you — but they are applications to run and upgrade, not a shortcut around thinking about your data model. If you are not ready to operate one, do not.

Two habits that matter

First, deduplicate on the indicator and keep the list of sources that reported it. Three independent sources on the same domain is meaningful; one source repeated is not. Second, never let a script write straight into a blocklist. Write to a staging table and let something review it.

Enrichment on a Shoestring

Enrichment just means adding context so a human can triage an indicator in ten seconds instead of two minutes. Most of what you need is free and public: RDAP and WHOIS registration data, DNS resolution and reverse lookups, ASN and netblock ownership from public routing data, certificate transparency logs to spot domains sharing a certificate, and file metadata for hashes. Free geolocation databases are approximate, so treat them as a hint rather than a fact.

Resolve indicators when they arrive and re-check periodically. Many malicious domains are parked or sinkholed, and a domain that resolved to a hosting provider last month may resolve nowhere today. That change is itself useful context.

A few cautions. An IP address tells you where infrastructure is hosted, not where the operator sits, so do not write "attacker in country X" into a report. Passive DNS and sandbox services often have free tiers with strict rate limits; cache responses locally and stay inside their terms. Script the boring parts too — a twenty-line job that appends ASN and registration date to every row saves more analyst time than any dashboard.

Score, Filter, Expire

Two failure modes kill small programs: too much noise reaching a human, and a blocklist that never shrinks. Scoring and time-to-live fix both.

Score each indicator on source reliability, how many independent sources reported it, how recent it is, and whether it touches technology you actually run. Anything below your threshold stays in the database and never reaches an inbox. Above it, the indicator goes into a queue with one line of context.

Expiry matters more than most teams expect. Domains and IPs used for delivery and command-and-control rotate quickly, so keep them for weeks rather than years. File hashes can live longer, but only while they keep appearing in telemetry. Set expiry by indicator type and enforce it automatically. A stale blocklist eventually blocks something you need, and the first person to notice will be a user filing a ticket.

Turning Feeds Into Work

Match before you block. Run new indicators against proxy, DNS, and endpoint logs; if something hits, you either have an incident or a false positive, and you want to know which before you deploy a rule. Retro-hunting is the highest-value habit here: run this week's indicators against the last ninety days of logs. Finding a beacon you missed in March is worth a month of reading feeds.

Then route by risk. Low-risk blocks, such as known-bad domains in DNS filtering, can be automated with a change record. Anything touching authentication, payment paths, or production infrastructure should go to a human first. And when the indicator is really a behaviour — a parent process spawning a script interpreter, a service registered from a temp directory — write a detection rule instead of a string match. Behaviours survive infrastructure rotation; single indicators do not.

Keep It Small and Sustainable

Give the pipeline one owner and thirty minutes a week. That slot is for reviewing the queue, deciding on the handful of items that matter, and confirming the collection jobs actually ran. Silent cron failures are the most common way these systems die, so add a heartbeat alert that fires when a source has not updated in twice its expected interval.

Once a month, prune. Drop sources that produced nothing actionable, delete indicators past expiry, and look at two numbers: how many indicators turned into a detection or a block, and how many blocks caused a false positive. If the first number is zero, your sources are wrong for your environment. If the second is climbing, your thresholds are too loose.

None of this replaces professional incident response when something real happens, and it is not a substitute for patching, backups, and access control. It is triage support: a small, honest pipeline that tells you what to do next week, built from free data and a few scripts.

Photo: AlphaTradeZone / Pexels