Nomad - Threat Intelligence Framework
I have been working on a new project for a while. The biggest issue I have is the amount of data that is produced on products, breaches, leaks, latest news, the newest exploit code. There is a lot, and if you a re reading this post you probably already know that.
My issue, and other may share it, is the lack of specific threat intelligence for me and my organisation. Every organisation is different, some larger organisations will have a threat intelligence team. I set out to try and create threat intelligence that is specific to me. Not specific to my current employer but with the goal to create something that can be use by anyone with minor tweaks or the basis of something bigger.
I set out to create a simple framework. Starting small and building upon the foundation. My goals were the following:
- Platform agnostic
- Modular
- Organisation agnostic
- Creates actionable insights and intelligence, consistently
The framework tries to utilise agentic methods that LLMs can use to move away from just a task and move to a job that the AI can do. Nomad is something that I am still working on and is very much a "get something done and iterate" framework.
The Architecture
Breaking the architecture down into its single parts seems like the logical way top process the entire framework. You can utilise one or all of the parts, you can use one specific LLM prompt, create an entire workflow using a custom web framework, the choice really quite open. Let me break down some of the ideas behind the architecture.
To keep everything as clear for the LLM (other applications that are consuming it) using JSON is the most logical choice. Telling the LLM to create means it is universally accepted in any format. I did think about using markdown for all processing, but that then it is not showing the specific format that another application may need/want. The storage from the LLM in reporting etc. is asked for in markdown as it is the easiest format to work with when creating reports or storing.
Ingestion
So far I have only prototyped the Orchestrator and the RSS Agent. RSS is abundant and there are many good security sites that provide an RSS feed. Taking some of the feeds to test and see how the LLM categorises them is helpful during troubleshooting and iteration (and cheaper).
Because RSS is a standard and n8n has its own specific RSS reader it made it easy to prototype this specific agent workflow. Starting small I am able to get a JSON item for each entry - that way the processing is easier.
Normalise & Dedupe
Different sources describe the same issue in different ways. Two issues I did run up against were duplications of the same material and normalise.
To normalise some of the terminology and while this method is far from failproof I tried to get Nomad to standardise on names: e.g., “ICS” → “Ivanti Connect Secure”) and formats titles as:
<Vendor> <Product> – <short vuln> – <CVE-…>.
Secondly duplications, using a dedup key which is a deterministic hash of lowercase(title + source_url). If two items collide (or are >0.9 similar), one survives. This cuts noise without hiding genuinely new facts.
Enrichment
This agent is still something I am trying to really get to work within my n8n prototype. It works but I have not tested it a scale and over time just yet.
The deterministic intent behind this - it adds only what can be verified from authority: CVSS/EPSS scores, whether it’s on KEV (and when), exploitation status and normalised affected products/versions.
If we can’t prove it, we leave it null. We also grade source reliability and information credibility (Admiralty model) and explain why.
The Orchestrator
A tiny rule engine makes one decision per item:
- TECHNICAL_ALERT if it’s KEV, EPSS over a threshold, or actively exploited and it touches something we run. The logical step is to allow it to assign to other teams or simply just flag to the human in the loop.
- CISO_REPORT if it’s materially important (e.g., very high CVSS or sector-specific impact) but not something ops needs to action right now.
- WATCHLIST if it’s credible but early (e.g., “patch pending” or no exposure today).
- DROP if the source is weak or the link doesn’t resolve.
The point is to turn interesting into actionable. Every actionable route comes with next steps rather based on the audience that is reading it.
Outputs
- Technical Alert: one-screen, operator-ready. What to patch, who owns it, due-by, detection hints, and the evidence link. No fluff.
- CISO Weekly: plain-English summary of what mattered, what moved risk up/down, and where SLAs are at risk.
- Watchlist Digest: short follow-ups with explicit “verify on <date>” tasks so nothing drifts.
- Evidence Vault: we persist the raw artefacts (URL + exact HTML/text snapshot + hash) for traceability and future hunts.
Why is it like this?
- Platform & organisation agnostic: each agent is just “JSON in → JSON out”. You can run them in n8n, Airflow, a serverless queue, or a shell script. Swap the LLM, keep the contract.
- Modular: if you already have an enrichment service or SIEM lookups, plug them in. If you don’t care about KEV, change the routing rule. Small, testable pieces.
- Actionable by default: the only useful intelligence is the kind that ends with a ticket, a patch, or a detection. Everything else goes to watchlist with a check-back date.
What it is not
It’s not a threat feed aggregator, although the framework is technically designed that you could take items from it and do that. What I am trying to do with this framework is to try and take information and relate it to the needs of the user or organisation or both.
What’s next
I’m getting the entire system working as one workflow, right now it is just two elements. The foundation is there. The framework in theory works, I just need to make it work.
campbellmcgregor