RedSheep SecurityRedSheepSecurity
Intermediate — Lesson 22 of 12

Building a Threat Intelligence Program

13 min read

Building a cyber threat intelligence program from scratch is one of the most impactful initiatives a security organization can undertake — and one of the most commonly misexecuted. Too many organizations start by purchasing expensive threat feeds and platforms before defining what intelligence they actually need. This lesson covers how to build a CTI program methodically, from defining requirements through measuring value, using established maturity models to guide growth.

Learning Objectives

  • Assess CTI program maturity using the CREST model and identify appropriate next steps for each maturity level
  • Define intelligence requirements that align with organizational risk and decision-making needs
  • Plan CTI staffing, tooling, and processes appropriate to program maturity
  • Integrate CTI with adjacent security functions (SOC, IR, Hunt, Vulnerability Management)
  • Measure and communicate program value to justify continued investment

Starting from Zero

When an organization has no formal CTI function, intelligence happens informally — a SOC analyst googles a suspicious IP, an IR lead reads a vendor blog, a CISO hears about a breach at a peer organization. Starting a CTI program means formalizing and systematizing these activities.

Where to Begin

Do not start with tools. Start with three questions:

  1. What decisions does our organization need intelligence to support? (This defines your requirements)
  2. What threats are most relevant to our sector, geography, and technology stack? (This defines your collection focus)
  3. Who will consume intelligence, and what format do they need it in? (This defines your products)

A single analyst with clearly defined requirements and a focused collection plan will produce more value than a team of five with expensive platforms but no defined mission.

First 90 Days

A practical starting plan for a new CTI program:

Timeframe Actions
Days 1-30 Identify stakeholders and conduct requirement interviews. Catalog existing intelligence sources (vendor reports, ISAC membership, OSINT). Establish a basic intelligence workflow using existing tools (email, wiki, spreadsheet).
Days 31-60 Produce first intelligence products aligned to identified requirements. Establish a weekly threat brief for security leadership. Begin systematic tracking of threat actors relevant to your sector. Set up automated IOC ingestion from one or two trusted feeds.
Days 61-90 Solicit feedback from consumers. Refine requirements based on what proved useful. Document your processes. Begin planning for tooling and scaling based on demonstrated value.

CTI Maturity Models

CREST Cyber Threat Intelligence Maturity Model

CREST (the Council for Registered Ethical Security Testers, a UK-based accreditation body) published a widely-referenced CTI maturity model that defines four levels. Each level describes capabilities across multiple dimensions including planning, collection, analysis, and dissemination.

Level Name Characteristics
Level 1 Initial Ad hoc intelligence activities. No formal CTI function. Reactive — intelligence consumed only during incidents. Relies on vendor-provided intelligence without customization.
Level 2 Defined Formal CTI function established. Intelligence requirements defined. Basic collection and analysis processes documented. Regular reporting cadence. IOC-focused with some tactical analysis.
Level 3 Managed Mature collection, analysis, and dissemination processes. Strategic, operational, and tactical intelligence produced. Structured analytic techniques applied. TIP deployed. CTI integrated with SOC, IR, and hunt. Threat modeling aligned to organizational risk.
Level 4 Optimized CTI drives security strategy. Predictive analysis and forecasting. Automated intelligence pipelines. Active participation in sharing communities. Continuous improvement through feedback loops and metrics. CTI informs investment decisions and risk management at the board level.

Most organizations beginning a CTI program are at Level 1. The goal is not to jump to Level 4 immediately — each level must be built on the foundation of the previous one. Attempting to deploy advanced tooling at Level 1 maturity leads to expensive shelfware.

Defining Requirements

Intelligence requirements are the foundation of a CTI program. Without defined requirements, you collect everything, analyze nothing systematically, and produce intelligence that may not align with organizational needs.

Requirement Hierarchy

Requirements cascade from strategic to tactical:

Standing Intelligence Requirements (SIRs) define broad, enduring intelligence needs aligned to organizational strategy. Example: "What nation-state threat actors are targeting the defense industrial base?"

Priority Intelligence Requirements (PIRs) define specific, prioritized intelligence questions that support current decision-making. Example: "Is APT41 actively targeting companies in our supply chain using VMware vulnerabilities?"

Essential Elements of Information (EEIs) define the specific data points that answer PIRs. Example: "What CVEs is APT41 exploiting in VMware products? What are the associated IOCs? What detection methods are effective?"

Gathering Requirements

Conduct structured interviews with key stakeholders:

  • CISO / Security leadership: What keeps you up at night? What decisions require intelligence support? What threats would have the greatest business impact?
  • SOC leadership: What types of alerts are hardest to triage? What threats are you least confident you can detect? Where do you need more context?
  • Incident response: What threat actors have we encountered? What intelligence would have helped during past incidents? What do you need during the first hour of an incident?
  • Vulnerability management: Which vulnerabilities are being exploited in the wild? How do we prioritize patching based on threat activity?
  • Hunt team: What adversary behaviors should we be hunting for? What gaps exist in our detection coverage?

Document requirements formally, assign priority levels, and review them quarterly.

Staffing a CTI Program

Analyst Roles and Skills

CTI programs need analysts with complementary skill sets. As a program grows, roles typically differentiate:

Role Focus Key Skills
Tactical Analyst IOC analysis, detection rule creation, feed management SIEM query writing, indicator analysis, malware triage, tool administration
Operational Analyst Campaign tracking, threat actor profiling, incident support OSINT collection, infrastructure analysis, structured analysis, report writing
Strategic Analyst Threat landscape assessment, trend analysis, risk forecasting Geopolitical awareness, analytical writing, briefing skills, strategic thinking
CTI Engineer Automation, platform management, data pipelines Python scripting, API integration, TIP administration, STIX/TAXII

A one-person program requires a generalist who can operate across all these areas. As the program grows to two to three people, the first split is typically between a tactical/operational analyst and an operational/strategic analyst. An engineer role becomes necessary when the volume of intelligence processing exceeds what can be handled manually.

Essential Analyst Skills Across All Roles

  • Critical thinking and resistance to cognitive bias
  • Clear written and verbal communication
  • Familiarity with MITRE ATT&CK framework
  • Understanding of networking, operating systems, and attack techniques
  • OSINT collection and evaluation
  • Intellectual curiosity and self-directed learning

Tooling

Threat Intelligence Platforms (TIPs)

A TIP is the central system for managing, analyzing, and disseminating intelligence. Options span from free and open-source to expensive commercial platforms:

Open Source / Free:

Platform Strengths Considerations
MISP Widely adopted, strong sharing features, extensive integrations, active community Requires server administration, UI can be complex
OpenCTI Modern UI, native STIX 2.1 support, knowledge graph visualization, strong analytics Resource-intensive (requires Elasticsearch, Redis, RabbitMQ), steeper infrastructure requirements

Commercial:

Platform Strengths Considerations
ThreatConnect Mature platform, strong workflow automation (Playbooks), integrated analytics Enterprise pricing, significant implementation effort
Anomali Strong feed aggregation (ThreatStream), SIEM integration, STIX/TAXII native Pricing scales with data volume, requires dedicated administration
Recorded Future Extensive automated collection, natural language processing, risk scoring Premium pricing, value depends on use case alignment

Platform selection guidance: At Level 1-2 maturity, start with MISP or OpenCTI. They are free, capable, and will force you to develop the processes and workflows that make any TIP valuable. Commercial platforms add value at Level 3+ when you have the processes and staffing to leverage their advanced features.

Intelligence Feeds: Commercial vs. Open Source

Open source feeds provide baseline coverage at no cost. Examples include abuse.ch (URLhaus, MalwareBazaar, ThreatFox), AlienVault OTX, CISA advisories, and vendor blogs. Their limitations include variable quality, lack of context, high false-positive rates for some feeds, and no service-level guarantees.

Commercial feeds (e.g., CrowdStrike, Mandiant, Recorded Future, Intel 471) provide curated, contextualized intelligence with defined quality standards. They are expensive but reduce the analytical burden on your team. The value of commercial feeds increases with organizational maturity — a Level 1 program may not be able to operationalize the volume of intelligence a premium feed provides.

Recommendation: Start with two to three high-quality open source feeds and your ISAC's shared intelligence. Add commercial feeds when you have the processes and tooling to operationalize them and can demonstrate ROI.

Processes: Daily, Weekly, Monthly Cycles

Consistent processes transform ad hoc intelligence consumption into a systematic program.

Daily

  • Review overnight alerts and incidents for intelligence value
  • Check priority intelligence sources (ISAC alerts, vendor advisories, OSINT monitoring)
  • Update active campaign tracking with new indicators or developments
  • Push relevant IOCs and detection rules to SOC/SIEM
  • Produce flash alerts for urgent threats

Weekly

  • Deliver weekly threat briefing to security leadership
  • Review and update intelligence requirements
  • Assess ongoing campaigns and hunt operations
  • Evaluate new intelligence sources and feeds
  • Team knowledge sharing and skill development

Monthly

  • Produce monthly strategic threat landscape assessment
  • Review program metrics and KPIs
  • Update threat actor profiles and priority rankings
  • Conduct quarterly intelligence requirement reviews (every third month)
  • Assess tooling effectiveness and identify gaps

Measuring Program Value

Demonstrating CTI program value is essential for continued funding and organizational support. Measure both operational output and strategic impact.

Operational Metrics

Metric What It Measures
Indicators shared with SOC Volume of actionable intelligence operationalized
Detections generated from CTI Alerts triggered by intelligence-provided indicators or rules
Mean time to intelligence How quickly intelligence reaches consumers after collection
Hunt findings driven by CTI Number of hunt operations that originated from intelligence and produced findings
IR support engagements How frequently CTI supports active incidents
Requirements coverage Percentage of PIRs addressed by intelligence products

Strategic Impact Metrics

Metric What It Measures
Proactive vs. reactive ratio Percentage of intelligence products delivered before an incident vs. in response
Decision support Number of security decisions (patching priorities, architecture changes, risk acceptance) informed by intelligence
Stakeholder satisfaction Regular feedback from intelligence consumers on relevance and quality
Threat anticipation Instances where CTI identified threats before they impacted the organization

Avoid vanity metrics. Processing 10 million IOCs per month means nothing if none of them resulted in a detection or informed a decision.

Common Pitfalls

  • Tool-first approach: Buying a TIP before defining requirements and processes. The tool will sit unused or be used as an expensive IOC database.
  • Feed overload: Subscribing to every available feed without the capacity to evaluate, curate, and operationalize the intelligence.
  • IOC tunnel vision: Focusing exclusively on atomic indicators (IPs, domains, hashes) while ignoring behavioral intelligence (TTPs) that has longer shelf life and greater defensive value.
  • Isolation: Building a CTI program that operates independently from SOC, IR, and hunt. Intelligence that does not reach operators is wasted.
  • No feedback loop: Producing intelligence without collecting feedback from consumers. You cannot improve products you do not evaluate.
  • Boiling the ocean: Trying to track every threat actor and cover every requirement simultaneously. Focus on what matters most to your organization.

Integrating CTI with Security Functions

CTI does not operate in a vacuum. Its value is realized through integration with adjacent functions:

  • SOC: CTI provides context for alerts, detection rules from behavioral intelligence, and prioritization guidance. SOC provides CTI with sighting data and observed attack patterns.
  • Incident Response: CTI provides threat actor playbooks, related IOCs, and historical context during incidents. IR provides CTI with forensic artifacts and real-world TTP observations.
  • Threat Hunting: CTI provides hunt hypotheses based on adversary behavior and intelligence gaps. Hunting provides CTI with validated detections and discovered threats.
  • Vulnerability Management: CTI provides exploitation intelligence to prioritize patching based on active threats. Vuln management provides CTI with exposure data for risk assessment.

These integrations should be formalized through defined handoff procedures, shared tools or platforms, and regular joint meetings.

Scaling the Program

As a CTI program matures from Level 2 to Level 3 and beyond, scaling involves:

  1. Expanding collection: Adding new sources, including human intelligence networks (trusted contacts, conference relationships), internal telemetry analysis, and commercial feeds
  2. Deepening analysis: Moving from tactical IOC analysis to operational campaign tracking and strategic forecasting
  3. Automating pipelines: Building automated collection, enrichment, and dissemination pipelines to handle increasing volume without proportional staffing increases
  4. Expanding integration: Embedding CTI into risk management, security architecture decisions, and executive strategy discussions
  5. Contributing to the community: Shifting from pure consumer to active contributor in sharing communities, ISACs, and partner networks

Key Takeaways

  • Start with requirements, not tools — define what intelligence your organization needs before selecting platforms or feeds
  • Use the CREST maturity model to assess your current state and plan realistic, incremental improvements
  • Staff for your maturity level: a one-person program needs a generalist; larger programs differentiate tactical, operational, strategic, and engineering roles
  • Open-source tools (MISP, OpenCTI) are capable platforms for Level 1-3 programs; commercial platforms add value at higher maturity
  • Establish consistent daily, weekly, and monthly processes — consistency creates reliability and trust
  • Measure operational output and strategic impact, not vanity metrics — the question is always whether intelligence informed a decision or prevented harm
  • Integrate with SOC, IR, Hunt, and Vulnerability Management through defined processes and shared platforms

Practical Exercise

Develop a CTI program plan for a fictional mid-size organization (2,000 employees, financial services sector, one CISO, a 6-person SOC, a 2-person IR team, no existing CTI function):

  1. Requirements: Write three SIRs, six PIRs (two per SIR), and three EEIs per PIR relevant to a financial services organization.
  2. Staffing plan: Define the first CTI hire (role, required skills, key responsibilities). Plan the first-year growth to a second hire and define that role.
  3. Tooling selection: Select a TIP, three open-source intelligence feeds, and one commercial feed. Justify each selection based on the organization's sector, size, and maturity level.
  4. Process design: Document the daily, weekly, and monthly CTI processes for a one-person program. Be specific about what happens at each cadence.
  5. Integration plan: Define how the CTI function will integrate with the existing SOC and IR team. Specify what data flows between functions and through what mechanisms.
  6. Metrics: Identify five metrics you will track in the first year to demonstrate program value to the CISO.

Further Reading