Threat intelligence processing & summarisation

Security teams drown in advisories, vendor blogs, feeds and dark-web chatter, most of it irrelevant to their own estate. LLMs read these sources, translate them, extract indicators and attacker techniques into machine-readable STIX, link them to ATT&CK and the organisation's own assets, and write short, tailored briefings. Result: analysts spend time deciding and acting instead of reading and copy-pasting.

Problem & value

• Today: a threat-intelligence (CTI) analyst or an overstretched IT lead reads dozens of sources daily, manually extracts IOCs into a TIP/MISP, maps TTPs to ATT&CK by hand and writes briefings. Reports come in many languages and formats (PDF, HTML, tweets, forum posts). Most SMBs have no CTI role at all and only see raw feeds inside their security tools.
• AI value: (1) summarise and deduplicate the daily flood; (2) turn unstructured reports into structured STIX 2.1 objects; (3) filter by relevance to the organisation's sector, software stack and exposed assets; (4) answer analyst questions in natural language ("which actors use this loader against logistics firms?"); (5) draft detection ideas from described TTPs; (6) write audience-specific outputs (SOC technical, CISO, board).
• Evidence: vendor claims on time saved exist (e.g. Google, Microsoft, Recorded Future publish assistant features), but independent quantified studies are limited; academic work shows LLMs can extract CTI entities and map to ATT&CK with useful but imperfect accuracy, which is why human validation stays [5][6]. Measure your own baseline instead of trusting generic figures.
• Regulatory pull: NIS2 (Directive (EU) 2022/2555) and DORA require risk management, incident handling and information sharing; TI feeds the risk analysis and monitoring those duties assume [7].

Variants

• SMB / MSP: curated daily digest of advisories relevant to the software and cloud services actually in use, plus KEV/CVE alerts.
• Enterprise CTI team: TIP-centred pipeline with report-to-STIX extraction, actor profiles, RFI (request for information) answering.
• Sector ISAC / CERT / public sector: multilingual intake, sharing via TAXII/MISP communities, TLP-aware redistribution (see Risks).
• Financial sector (DORA/TIBER-EU): threat landscape summaries feeding threat-led penetration test scoping (SEC-007).
• Vulnerability-centric: exploit-in-the-wild summarisation for patch prioritisation (SEC-004).
• Brand/dark-web monitoring: see SEC-021; OSINT link analysis generally see KNOW-026.
• Private use: not applicable beyond consumer-oriented CERT newsletters.

How it works

1. sources (advisories, blogs, PDFs, feeds, forums, vendor TI)
2. collection & normalisation (RSS/API/TAXII, scraping, document parsing, language detection)
3. deduplication & clustering (embeddings; same campaign reported by many vendors)
4. LLM extraction (entities: actor, malware, CVE, IOC, TTP; schema-constrained JSON
5. STIX 2.1)
6. validation (regex/defang checks for IOCs, ATT&CK ID lookup, source citation per claim)
7. relevance scoring against asset inventory, sector and tech stack
8. summarisation & briefing generation (per audience, with source links, TLP label)
9. analyst review
10. publish to TIP/MISP/OpenCTI, SIEM watchlists, ticket, chat

• Extraction: LLM with structured outputs reads the report and emits STIX objects; IOCs are validated deterministically (never trust an LLM-typed hash or IP) and every claim keeps a pointer to the source passage.
• ATT&CK mapping: retrieval over the official ATT&CK knowledge base plus LLM or fine-tuned classifier; output a technique ID only if it exists in the matrix.
• Retrieval/Q&A: vector + keyword index and optionally a knowledge graph over STIX objects (GraphRAG, see KNOW-013).
• Human-in-the-loop: an analyst approves objects before they enter the shared TIP or feed blocklists; briefings for management are reviewed; automated blocking from LLM-extracted IOCs is not recommended without validation.

Data preparation

Inputs are mostly public or semi-public texts: vendor advisories, CERT bulletins, vulnerability feeds (CVE, KEV), blogs, PDF reports and mailing lists, plus your own asset and software inventory to judge relevance. In an SMB the inventory is the weak spot; it lives in ERP/CMDB, an Excel list or nowhere.

Typical gaps: no up-to-date asset and software list, reports as scanned or messy PDFs, duplicates across feeds, inconsistent naming of actors and malware families, unclear trust levels of sources, and no tagging by sector.

Preparation steps: 1. Build a minimal asset and software inventory so relevance can be matched (PREP-001, PREP-011). 2. Select a small set of trusted sources (BSI/CERT-Bund, vendor PSIRTs, ISAC) and set up feed ingestion. 3. Convert PDFs and web pages to clean text (DOC-014, PREP-007) and deduplicate. 4. Define tags and a simple schema such as STIX or MISP taxonomies (PREP-019). 5. Keep a few reviewed example briefings as gold standard (PREP-016).

Effort share is low, about 10 to 20 percent. Never mix confidential incident data into public tools without classification rules (PREP-024).

Implementation paths

Which path for whom

• SMB: Path A. Threat-intel feeds with built-in summaries from your security vendor, national CERT services (CERT-Bund, BSI) or an MDR provider need no own platform.
• Enterprise: Path B. A SOC with an existing TIP/SIEM adds LLM extraction and summarisation via EU-hosted APIs, which integrates well with its own data.
• Developer: Path C. MISP, OpenCTI and a local model on HW3 make a complete, cost-free lab stack.
• Public: Path C. Sensitive incident context and sovereignty requirements suggest self-hosted processing, with exchange via CERT networks.

Path A — Buy (recommended for most)

• Vendor TI platforms with generative assistants: Google Threat Intelligence (Mandiant/VirusTotal with Gemini summaries), Microsoft Defender Threat Intelligence / Security Copilot, Recorded Future (Intelligence Cloud with AI), CrowdStrike Falcon Intelligence / Charlotte AI, Palo Alto Unit 42, Anomali, ThreatConnect, Flashpoint, Intel 471, Silobreaker.
• EU / European vendors: EclecticIQ (NL, TIP), Sekoia.io (FR, XDR with CTI), Filigran (FR, commercial OpenCTI platform), HarfangLab (FR), Bitdefender (RO) GravityZone intelligence, WithSecure (FI), Orange Cyberdefense (FR) CTI services, Hornetsecurity/G DATA-type regional offerings. CERT-Bund/BSI and national CSIRTs provide free advisories.
• Choose A when: no dedicated CTI analyst, the SIEM/XDR vendor already ships the assistant, or you need curated finished intelligence. Check EU data residency, whether your queries/internal asset data train vendor models, and TLP handling.

Path B — Build on cloud APIs

• Models: Claude, GPT, Gemini (EU regions via Vertex AI / Azure OpenAI / AWS Bedrock) or Mistral (EU provider) with structured outputs / tool calling; long-context models handle 50–100 page reports in one pass.
• Platform: MISP or OpenCTI as the store, pycti/PyMISP connectors, n8n or Tines/Torq for orchestration; STIX validation with the OASIS stix2-validator.
• Choose B when: you already run MISP/OpenCTI and want custom extraction, summarisation and routing. Send only public reports to external APIs; keep internal asset inventory and incident data out of prompts or use EU-hosted/self-hosted models.

Path C — Self-host (open source)

• Platform: OpenCTI and MISP (both open source, STIX/TAXII capable); Cortex/TheHive for analysis; ATT&CK data via the mitreattack-python library or ATT&CK STIX repository.
• Models: open-weight LLMs such as Qwen3, Llama 3.x/4, Mistral Small/Medium open releases, gpt-oss, served with vLLM or Ollama; embeddings such as BGE-M3 or multilingual-e5; for classification, fine-tuned encoder models (e.g. SecureBERT-type, CTI-BERT-type) from research.
• Hardware: HW3 (one 48–96 GB GPU) for a ~30–70B model with long context; HW2 suffices for ~8–14B models on shorter documents. Ops effort: low-medium, mainly connector maintenance.
• Choose C when: reports are TLP:AMBER/RED, you are a CERT/ISAC/public body, or sovereignty requirements forbid external APIs.

Path D — Custom training

Fine-tune a small model for ATT&CK technique classification or domain NER when volume is high and API cost or latency matters. Needs a few thousand expert-labelled sentences/reports; the analyst corrections from the review step are the natural dataset. Public datasets from the research community (e.g. TRAM/ATT&CK-labelled corpora) help bootstrapping [6].

State of the art (2026)

• Report-to-STIX extraction with structured outputs is practical; entity extraction for CVEs, malware names and IOCs is reliable, while relationship extraction, attribution and ATT&CK sub-technique mapping remain the weak points.
• Agentic CTI assistants: vendor assistants answer questions over their own intelligence graph and summarise campaigns; open tooling adds MCP servers for MISP/OpenCTI so general agents can query them [2][3].
• Standards: STIX 2.1/TAXII 2.1 (OASIS) and MITRE ATT&CK are the interchange base; FIRST's TLP 2.0 governs sharing [1][4].
• Limits and failure modes: hallucinated IOCs, invented actor attribution, outdated or conflated aliases, confident but wrong summaries of low-quality sources, prompt injection through scraped content (adversaries can plant instructions in pages the pipeline ingests), and poisoning of feeds. Mitigate with deterministic validation, source citations, quarantine of untrusted content, no tool access during extraction, and confidence labels (Admiralty scale) that distinguish source reliability from information credibility.

Shared resources & combinations

• Same stack (llm-general + embedding-text + vector-db + knowledge-graph): KNOW-013 (GraphRAG), KNOW-026 (OSINT analysis), DOC-014 (document parsing), LANG-009 (translation of foreign-language reports).
• Downstream consumers: SEC-001 (SOC triage uses enriched TI), SEC-003 (malware analysis reports feed extraction), SEC-004 (exploit-aware patch priority), SEC-007 (scenarios for authorised testing), SEC-009 (risk and compliance evidence), SEC-021 (brand and dark-web monitoring).
• One self-hosted LLM server plus MISP/OpenCTI can serve SEC-001, SEC-003, SEC-008 and SEC-009.

Effort, cost & KPIs

• Path A: days to weeks; subscription per seat or per data volume, premium finished intelligence is a major cost driver; many vendors bundle the assistant into existing XDR/SIEM licences.
• Path B: 1–2 months for a digest and extraction pipeline on an existing MISP/OpenCTI; token cost small relative to analyst time (public documents only).
• Path C: 2–4 months incl. connector hardening and evaluation; GPU server plus maintenance.
• KPIs: analyst hours spent on reading/triage per week, share of extracted IOCs/TTPs accepted without edits, precision of relevance filter (reported items judged useful), time from advisory publication to internal action, false IOC rate entering blocklists, briefing consumption by management.

People & change

Threat-intelligence summarisation processes external information, not staff behaviour, so the organisational effort is light but not zero.

• Works council: no in the normal case; the system does not monitor employee behaviour or performance, so §87(1) no. 6 BetrVG is typically not triggered. Still inform it in good time if work processes in the SOC change substantially (§90(1) no. 3). Check again if employee-related incident data is analysed.
• Management sets scope and accepts that summaries are decision support; IT security is the process owner and defines trusted sources; IT handles integration; legal/compliance checks licences of feeds and reporting duties (NIS2, incident notification).
• DPO: needed only if personal data (e.g. leaked credentials, names in reports) is processed; check the AVV with the API provider (Art. 28 GDPR).
• AI literacy: support analysts in recognising hallucinated IOCs and wrong attribution (Art. 4 AI Act).
• Pilot: start with one analyst or the IT lead producing the weekly briefing, compare with the manual version.
• Typical concerns: trust in summaries and fear of leaking sensitive context into a cloud model. Address them with source citations in every summary, human approval before anything feeds blocklists, and an acceptable-use rule (GUIDE-007).

See GUIDE-007, GUIDE-013 and GUIDE-006.

Risks, regulation & compliance

• EU AI Act: minimal risk — defensive analysis support, no Annex III category; Art. 4 AI literacy applies. If the pipeline profiles named individuals in a way that affects their rights (e.g. for law-enforcement purposes), classification changes; that is outside this use case.
• GDPR: reports, leaked-data dumps and forum content contain personal data (names, emails, credentials). Define the legal basis (legitimate interest, Art. 6(1)(f), plus NIS2/security obligations), minimise storage, avoid long-term retention of breach-dump personal data, run a DPIA when processing leaked data at scale, and keep personal data out of third-party model APIs without a DPA and EU processing.
• NIS2/DORA: TI sharing is encouraged (NIS2 Art. 29 voluntary information sharing); the AI pipeline is part of your ICT supply chain, so include it in supplier risk management [7].
• Confidentiality: respect TLP labels; do not paste TLP:AMBER/RED material into external services; enforce label propagation in outputs.
• Security of the pipeline itself: prompt injection from scraped pages, poisoned feeds, accidental active contact with malicious infrastructure (fetch in sandbox, defang URLs). Dark-web collection must follow national law and the provider's lawful-collection practice; do not buy or interact with criminal services.
• Mitigations: human approval before IOC publication or blocking, provenance for every claim, evaluation set of past reports, audit log.

Getting started

1. Define intelligence requirements: sector, key technologies, crown jewels, audiences (SOC, CISO, board).
2. Pick 10–20 trusted sources (CERT-Bund/BSI, CERT-EU, CISA KEV, vendor advisories for your stack) and ingest them into MISP or OpenCTI.
3. Build an LLM digest: dedupe, summarise, rate relevance against your asset list, and cite sources; compare with what an analyst would pick for two weeks.
4. Add report-to-STIX extraction with deterministic IOC validation and analyst approval.
5. Connect approved output to SIEM watchlists and review KPIs and false IOCs monthly.

Sources

1. OASIS — STIX 2.1 and TAXII 2.1 specifications — https://oasis-open.github.io/cti-documentation/
2. OpenCTI (Filigran) documentation — https://docs.opencti.io/
3. MISP project — https://www.misp-project.org/documentation/
4. MITRE ATT&CK — https://attack.mitre.org/
5. FIRST — Traffic Light Protocol (TLP) 2.0 — https://www.first.org/tlp/
6. CTI-focused LLM research (e.g. "AnnoCTR", CTIBench) — https://arxiv.org/abs/2406.07599
7. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
8. ENISA — Threat Landscape — https://www.enisa.europa.eu/topics/cyber-threats/threats-and-trends
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj