How does Liberty91 automate threat intelligence?

Liberty91 uses AI agents to continuously monitor hundreds of cybersecurity sources in real-time. Our AI collects, analyzes, and reports on every cyber event relevant to your organization based on your threat profile, sector, geography, and technology stack. The platform delivers actionable reports, IOCs, detection rules (Sigma), and STIX bundles automatically.

What is the difference between threat intelligence and threat hunting?

Threat intelligence is about understanding the threat landscape — who the adversaries are, what tools they use, and what they target. Threat hunting is the proactive search for threats already inside your network. Liberty91 focuses on threat intelligence: collecting and analyzing external threat data so your team can prioritize hunting and defense efforts effectively.

Does Liberty91 integrate with SIEM and SOAR platforms?

Yes. Liberty91 integrates with SIEM, SOAR, TIP, and ticketing systems. It outputs intelligence in industry-standard formats including STIX bundles and Sigma detection rules, and connects through email, Slack, Microsoft Teams, and thousands of other platforms.

How is Liberty91 different from Recorded Future or Feedly?

Unlike enterprise-priced platforms like Recorded Future ($100K–$300K+/year), Liberty91 is affordable and accessible to organizations of all sizes. Unlike Feedly, which focuses on collection, Liberty91 provides end-to-end automation: collection, analysis, reporting, IOC extraction, and detection rule generation — all tailored to your specific threat profile.

Industry2026-04-1412 min read

A Practitioner’s Guide to the Intelligence Lifecycle.

Q: What is cyber threat intelligence?

Cyber threat intelligence (CTI) is the collection, analysis, and dissemination of information about current and potential cyber threats. It helps organizations understand who is targeting them, how, and why — enabling proactive defense rather than reactive response. Liberty91 automates the entire CTI lifecycle using AI.

If you type “what is cyber threat intelligence” into a search engine, you'll get dozens of definitions. Most of them are correct. None of them are particularly useful.

Here's the definition I use: CTI is the product of collecting, processing, and analysing information about cyber threats in a way that is relevant to a specific organisation's decisions.

Three things matter in that definition. First, it's a product of a process— not just data, not just a feed, not just a report. Second, it involves analysis— someone has made a judgment call about what the data means. Third, it's relevant to a specific organisation— generic threat reporting that could apply to anyone isn't intelligence; it's information.

This distinction between intelligence and information is the foundation of everything else in this series. Get it right, and the rest follows logically. Get it wrong, and you'll build a CTI programme that produces a lot of noise and very little signal.

The intelligence lifecycle in practice

Every CTI training programme teaches the intelligence lifecycle. I've reviewed six of the most referenced ones — from CREST-accredited courses to FIRST's community curriculum to Mandiant's competencies framework — and they all agree on the basic structure. It's the closest thing to consensus in a field that argues about almost everything else.

The lifecycle has six phases. Here's what each one looks like in practice, not just in theory.

Abstract hexagonal structure with six interconnected segments, each glowing in a different shade from deep navy to bright orange, representing the six phases of the intelligence lifecycle

1. Direction: Knowing what intelligence you need

This is the phase that separates intelligence programmes from monitoring programmes. Direction means defining Priority Intelligence Requirements (PIRs) — specific questions that your organisation needs answered to make decisions.

A good PIR looks like: “What threat actors are actively targeting the financial services sector in the GCC region using supply chain compromise techniques?” A bad PIR looks like: “Keep us updated on cyber threats.”

The first gives your team a clear target. The second gives them permission to report on anything, which means they'll report on everything, which means nobody will read it.

In my experience, fewer than half of CTI teams have formally documented PIRs. Many operate on informal understanding — “the CISO cares about ransomware” — which works until the CISO's priorities shift and nobody tells the CTI team for three months.

Direction requires a conversation between the CTI team and its stakeholders. That conversation is uncomfortable because it forces both sides to be specific about what they need and what they can deliver. But without it, you're navigating without a map.

2. Collection: Gathering the raw material

Collection is where most teams spend the majority of their time. And it's where most teams' problems start.

The sources available to a CTI team broadly fall into categories:

Open-source intelligence (OSINT): Publicly available information — news, social media, security blogs, paste sites, code repositories, government advisories
Technical feeds: Structured threat data — IP reputation lists, malware sample databases, indicator feeds from ISACs and vendors
Dark web sources: Forums, marketplaces, paste services on Tor and other networks
Human intelligence (HUMINT): Information from trusted relationships — peer organisations, law enforcement contacts, industry working groups
Internal telemetry: Your own security logs, incident data, and detection results

The challenge isn't access to sources. It's managing the volume. A typical CTI team might subscribe to 10–50 threat feeds, monitor a dozen news and blog sources, track several dark web forums, and receive alerts from multiple vendor products. The firehose is real, and it runs 24/7.

What I've learned — and what most training skips — is that the quality of your collection isn't measured by how many sources you have. It's measured by how well your sources map to your PIRs. If your PIRs focus on specific threat actors targeting your sector and geography, a single well-curated source might be worth more than twenty generic feeds.

3. Processing: Making data usable

Processing is the unglamorous middle child of the lifecycle. It involves normalising data formats, deduplicating indicators, enriching raw data with context, and structuring everything so it can be analysed.

This is also the phase where automation has the clearest, most uncontroversial value. A human being manually reformatting IOCs from twenty different feed formats into a consistent schema is not doing intelligence work. They're doing data entry. And they're doing it slower and less consistently than a machine would.

I'll be honest about my bias here: I built Liberty91 partly because I watched too many skilled analysts spend their mornings on processing work that should have been automated years ago. But regardless of what tool you use, the principle holds — processing is compute work, not intelligence work, and it should be treated accordingly.

4. Analysis: The step that makes it intelligence

This is where intelligence happens. Analysis is the application of human judgment, experience, and structured techniques to processed data. It's where you move from “here are the facts” to “here's what they mean for us.”

Good analysis involves:

Contextualisation: Placing information within your organisation's specific threat profile
Assessment: Making confidence-rated judgments about what the data means (“We assess with moderate confidence that...”)
Implication: Explaining what the analysis means for your organisation's decisions
Recommendation: Suggesting specific actions based on the assessment

Most CTI output skips directly from collection to dissemination — processed data goes out the door as a “report” without the analysis step. The analyst didn't have time. The morning brief was due at 9 AM. The SOC needed those IOCs immediately.

This isn't laziness. It's a structural time problem. We'll dig deep into analytical tradecraft — including Analysis of Competing Hypotheses, cognitive biases, and structured analytic techniques — in Part 3 of this series.

5. Dissemination: Getting intelligence to the people who need it

You've produced intelligence. Now it needs to reach the right people, in the right format, at the right time.

Abstract network of nodes with intelligence radiating outward from a central point to different-shaped receivers, representing different stakeholder types

Different stakeholders need different formats:

SOC analysts need tactical indicators they can immediately query in their tools
Security architects need operational context about how adversaries are attacking
CISOs and executives need strategic assessments that inform budget and programme decisions
Incident responders need rapid, focused intelligence about specific threats during active incidents

A ten-page strategic assessment delivered to a SOC analyst during an incident is useless. A list of IOCs delivered to a CISO during budget planning is equally useless. Format matters. Timing matters. Knowing your audience matters.

Part 7 in this series will focus entirely on reporting, stakeholder management, and how to make intelligence impossible to ignore.

6. Feedback: The phase everyone skips

Feedback closes the loop. It's the mechanism by which stakeholders tell the CTI team whether the intelligence was useful, timely, and relevant. It informs the next round of Direction — refining PIRs, adjusting collection priorities, changing output formats.

Almost nobody does this well. Reports go out into the void. Silence is interpreted as satisfaction. The CTI team continues producing what they've always produced, and wonders why leadership keeps questioning the programme's value.

If you take one thing from this post, let it be this: build a feedback mechanism. A monthly fifteen-minute conversation with your top three stakeholders asking “Was our intelligence useful last month? What would have been more useful?” will do more for your programme than any tool purchase.

Intelligence vs information: a practical test

To summarise, here's how to test whether your CTI team produces intelligence or information:

Driven by: Intelligence is driven by Priority Intelligence Requirements. Information is driven by whatever seems relevant today.
Contains: Intelligence contains assessed judgments with confidence levels. Information contains facts and data without assessment.
Answers: Intelligence answers “So what?” and “Now what?” Information answers “What happened?”
Tailored to: Intelligence is tailored to a specific organisation's context. Information is generic, applicable to anyone.
Feedback loop: Intelligence has an active feedback loop where stakeholders confirm relevance. Information disappears into the void.

If your team's output looks more like information than intelligence, you're not failing. You're likely overwhelmed. The fix isn't “try harder” — it's structural. We'll explore what that structural fix looks like throughout this series.

What's next

This is the first of eight posts in the “CTI from the Trenches” series. Each week, I'll cover a core aspect of CTI practice from a practitioner's perspective — warts, opinions, and all.

Coming up:

Part 2: Where intelligence actually comes from (and why 50 feeds ≠ intelligence)
Part 3: How to think like an intelligence analyst
Part 4: Threat actors, attribution, and when it matters
Part 5: MITRE ATT&CK, Diamond Model, and making frameworks work
Part 6: Tools, platforms, and the build-vs-buy decision
Part 7: Reporting, stakeholders, and the PIR problem
Part 8: The future of CTI — AI, automation, and what analysts should learn

See you next week.

This is Part 1 of the “CTI from the Trenches” series. Next: Where Intelligence Actually Comes From →