Threat Intelligence Standards

Threat Intelligence (CTI) standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies to producing, evaluating, distributing and expiring knowledge about the adversary: intelligence requirements, collection, processing, analysis, dissemination and feedback; modelling and exchange (STIX/TAXII, MISP, OpenCTI); source quality; indicator lifecycle; mapping to ATT&CK; marking and sharing; and attribution assessment.

Guiding principle: intelligence is judged by the decision it changes, not by the volume it produces. A report nobody uses to decide where to look, what to patch first or what detection to write is a subscription, not intelligence. Corollaries that order the whole document:

1. Without PIRs there is no CTI, only expensive curiosity. The requirement precedes collection.
2. An IoC without an expiry date is debt, not a control. It poisons detection for years and generates false positives that get paid for in analyst hours (§3).
3. Attribution almost never decides anything operational (§5). It is interesting; it is rarely actionable.

Triggers: those in the frontmatter. Arbitration rule in one line: if the deliverable is knowledge with confidence, source and expiry, it is ours; if it is a rule, a shift, a case or a patch, it belongs to the neighbouring skill.

Not applicable: see

• detection-engineering-standards: the rule is written there. Here we produce the hypothesis, the indicator and the ATT&CK mapping that feed it; the rule's lifecycle, its tests, its tuning and its coverage are theirs. Bidirectional boundary: detection returns sightings that here score and expire indicators. A CTI flow that receives no detection feedback is blind.
• soc-operations-standards: the shift, the queue and triage. Alert enrichment consumes what is produced here; handling, fixing or retiring an alert is their decision.
• incident-response-forensics-standards: the live case. The investigation consumes CTI and produces new indicators that come back here to be normalised, marked and expired — they do not stay in the ticket.
• vulnerability-management-standards: EPSS, KEV, CVSS and the patching SLA are theirs, without exception. Here only our own contribution — this actor exploits this against this sector — which is handed to them as a prioritisation input. Their risk model is not duplicated.
• incident-management-standards (incident governance), offensive-security-standards (adversary emulation with written scope and authorisation; this skill is defensive and produces the TTP profile the exercise emulates), observability-standards (telemetry pipeline and retention), grc-compliance-standards (notification duty, audit evidence and the NIS2/DORA framework), privacy-engineering-standards (personal data inside the intelligence: an indicator can be a person's IP, and sharing it either has a legal basis or it does not), identity-access-management-standards, email-security-standards (phishing as a channel with its own controls), finops-standards (subscription cost as an economic unit), ai-governance-standards and llm-app-engineering-standards (if an LLM is used to summarise or classify reports: an invented summary is an intelligence failure, not a product one).

2. Default decisions

Verify the latest version on the web before pinning it in a real project (§8).

3. The cycle, the levels and the indicator lifecycle

Intelligence cycle — you run it all the way through or it is not intelligence: requirements → collection → processing → analysis → dissemination → feedback. The step that always gets skipped is the last one, and it is the only one that tells you whether it was any use.

• PIRs (Priority Intelligence Requirements): between 3 and 10, written down, with a business owner and reviewed at least annually. A PIR is a question someone will use to decide ("which actors attack our sector with ransomware and through which initial vector?"), not a topic ("ransomware"). Without PIRs, collection is defined by the vendor.
• Collection plan: each PIR is mapped to the sources that answer it and to the gaps nobody covers. A declared gap is a deliverable; papering over it with a generic feed is self-deception.
• Three levels, three products, three audiences — mixing them is the most common formatting mistake: strategic (trends, sector risk, intent; audience is leadership, no IoCs and no jargon, with an investment implication); operational (campaigns, TTPs, infrastructure; audience is SOC, detection and IR — the highest-value level and the most neglected, because it is the most expensive to produce); and tactical (atomic indicators; audience is machines — it is consumed automatically or it is not consumed: an IoC hand-copied into a SIEM already arrived late).

Indicator lifecycle (hard rule):

• Every indicator is born with: source, observation date, confidence, valid_until and the context that makes it actionable. Without all five, it does not enter the platform. The field people omit is always valid_until, and it is the one that decides whether the system ages well.
• Expiry by type, not uniform: a file hash can live for years; a C2 IP on shared hosting lives for days and after that is a guaranteed false positive; a domain, in between. A configured automatic decay (MISP has decay models) is mandatory, not optional.
• Warninglists / allowlists before publishing: cloud ranges, public resolvers, CDNs, domains of legitimate services. A CDN's IP published as an IoC is a service outage with a known cause.
• The sightings are the quality mechanism: an indicator nobody ever sees for months is downgraded; one that only fires false positives is retired and the sender is told. Without the loop back to detection-engineering, the scoring is theory.
• Precision over volume, always. The number of indicators on the platform is not a programme metric: it is an accumulation metric.

Mapping to ATT&CK:

• Every operational product carries technique, sub-technique, tactic and the ATT&CK version used. Without the version, the product is not comparable two releases later (§2).
• Map what you have observed, not what the vendor report says. Copied mapping inflates apparent coverage and does not survive a review.
• TA0005 changed meaning in v19. Every mapping predating Apr 2026 is reviewed with the crosswalk before being reused in a coverage metric.

4. Source and product quality

Evaluate a feed before ingesting it — five axes, measured, not promised:

1. Volume and its distribution over time (a spike is an event, not a trend).
2. Uniqueness: how much it adds that you do not already have. With the low overlap measured in the literature (§2), it has to be measured against your current sources, not assumed.
3. Latency between observation and publication: a feed 30 days behind is history.
4. Precision / false-positive rate, measured against your own traffic in observation mode.
5. Context: does it bring actor, campaign, TTP and confidence, or is it a list of strings? A list without context cannot be triaged or expired with any judgement.

Mandatory trial before buying or blocking: ingest in no-block mode for an agreed period, measuring the five axes. No feed goes straight to blocking.

When a commercial feed adds nothing — rejection criteria: it repeats what you already have from open sources; its uniqueness is high but irrelevant to your PIRs; it does not cover your sector, geography or stack; it delivers volume with no context and no expiry (it transfers the analysis to you and charges you for it); it only gives atomic indicators and no TTP analysis; you cannot evaluate it — with no trial on your data and no published methodology, a vendor who does not allow the trial is telling you the result —; or the team has no capacity to consume it, which is the most expensive way of not doing CTI.

Programme metrics (few, and ones that change decisions): PIRs covered versus declared gaps; products that triggered a traceable action (a new rule, a prioritised patch, a changed control, a hunt started) — the only one that justifies the team —; false-positive rate per source; and average age of the active indicator (if it goes up, decay is not working). ❌ These are not metrics: number of indicators, of reports read or of feeds.

5. Security, marking and attribution

• TLP is applied verbatim and propagates to every derivative. Downgrading the label on someone else's product is a breach of trust that gets you thrown out of the sharing community, and that expulsion is permanent. When in doubt about the level, you ask the sender.
• PAP (Permissible Actions Protocol) is different from TLP and has to be honoured separately: it governs what actions you may take with the data (resolving a domain, scanning an IP, detonating a sample) without tipping off the adversary. Querying the attacker's infrastructure from your corporate IP is free counterintelligence for them.
• OPSEC of the CTI team itself: research infrastructure separated from the corporate one, managed research identities, no corporate credentials on hostile sources, and an isolated detonation sandbox (ctf-lab-standards for the lab).
• The CTI platform is a high-value target: it contains what you know about the adversary and, therefore, what you do not know. MISP/OpenCTI never exposed to the Internet without strong authentication and segmentation; and watch out for CVEs in the platform itself (verified: MISP published in 2026 fixes for SQL injection, privilege escalation and RCE — it is security software, not secure software).
• Personal data: an indicator can be an identifiable person's IP or email address. Sharing it needs a legal basis and minimisation (privacy-engineering-standards). "It is an IoC" is not a legal basis.
• Attribution — the section that has to be said without ornament:
  • It almost never changes a defensive decision. Knowing the actor is "APT-whatever" does not alter what you patch, what you detect or how you contain. What does alter it is their TTPs, and those are obtained without attributing.
  • It is written with explicit analytic confidence language ("we assess with moderate confidence…"), separating observation, inference and assumption. Never a flat assertion.
  • Attribution indicators are falsifiable by design: reused infrastructure, language fingerprints, compilation timestamps, leaked and public tooling. False flags are a documented technique, not an exotic hypothesis.
  • Attribution with legal, diplomatic or insurance consequences is not made by a corporate CTI team. It is escalated; it is not published.

6. Operation

• Automate ingestion and expiry; do not automate analysis. Volume versus judgement.
• MISP synchronisation between organisations: define and review which direction each distribution flows in — a misconfigured sync rule publishes outward what was internal, and it is this tool's classic incident.
• Ingestion budget: every indicator sent to the SIEM costs storage and correlation (finops-standards, soc-operations-standards). Sending the whole platform to the SIEM breaks the budget without improving a single detection.
• Retention: an expired indicator is not deleted, it is archived — it is useful for retrospective hunting and for forensics. Expiring ≠ forgetting.
• Continuity: the platform is backed up and its restore is tested (backup-recovery); the accumulated knowledge graph cannot be rebuilt.

7. Long-term sustainability and prohibitions

• Cadence: the ATT&CK version is reviewed every release and the migration is planned (§2); the platforms are patched with the SLA of exposed software, not of an internal tool.

• Every product has a review date and an owner. A three-year-old actor profile with no review is disinformation with your logo on it.

• ❌ FORBIDDEN to publish or ingest an indicator without an expiry date. Rule number one.

• ❌ Blocking with a feed that has not passed a trial in observation mode (§4).

• ❌ Sending the entire CTI platform to the SIEM "just in case".

• ❌ Downgrading a TLP label, or using TLP:WHITE (retired in TLP 2.0) and local dialects.

• ❌ Ignoring the PAP: querying, scanning or detonating adversary infrastructure from attributable corporate infrastructure.

• ❌ Publishing an attribution as fact, or letting it influence the technical response (§5).

• ❌ Copying the ATT&CK mapping from a vendor report and presenting it as your own coverage.

• ❌ Using volume metrics (number of IoCs, feeds or reports) as programme health.

• ❌ Buying a feed with no PIR to justify it, or that the team cannot consume.

• ❌ Writing detections here (detection-engineering-standards) or duplicating the vulnerability prioritisation model: EPSS and KEV belong to vulnerability-management-standards.

• ❌ Exposing MISP/OpenCTI to the Internet without segmentation, MFA and up-to-date patching.

• ❌ Sharing indicators containing personal data without a legal basis or minimisation.

• ❌ Taking a CTI platform's licence on faith from what its website says: you read the raw LICENSE (§2 — OpenCTI is not AGPL).

• ❌ Treating an LLM-generated summary of a threat report as an intelligence product without human verification against the source.

8. Mandatory web verification

Before pinning anything in a real project, check on the web:

1. Current MITRE ATT&CK version at attack.mitre.org/resources/updates/ (as of Aug 2026: v19, published on 28-Apr-2026, with v19.0 and v19.1 data in MITRE/CTI) and what changed relative to the one your mappings use. The two changes that break things silently: v18 (Data Sources and Detections → Detection Strategies DET… + Analytics AN…) and v19 (TA0005 = Stealth, TA0112 = Defense Impairment, T1562→T1685, Enterprise only). Use the official crosswalk for the split, not a conversion of your own.
2. STIX/TAXII: that 2.1 is still the current OASIS Standard version and whether there is work towards 2.2 (oasis-tcs/cti-stix2). As of Aug 2026 no 2.2 is on record as published.
3. TLP: current version at first.org/tlp and the exact text of each label (verified: TLP 2.0, authoritative since Aug 2022). If your documentation cites TLP 1.0, it is out of date.
4. MISP: current release at misp-project.org (the project website, not the GitHub feed) and the platform's security advisories, which in 2026 included SQLi, privilege escalation and RCE. Licence verified raw: AGPLv3.
5. OpenCTI: current version and, above all, which features stay in Enterprise Edition — it changes between releases and it decides whether the project is viable on Community. Licence verified raw: Community = Apache-2.0; Enterprise = Filigran proprietary licence. Consult opensource-licensing-standards before committing architecture.
   • Declared gap: OpenCTI uses a date-based version scheme (the 7.26xxxx series in 2026) and I could not pin down on the web with any confidence the exact number of the current release or the terms of the LTS licence; verify at docs.opencti.io before planning an upgrade.
6. Feeds you use: status, cadence and terms of use — many open feeds change licence or disappear without notice, and their URL survives returning stale data.
7. Applicable sharing regulatory framework (NIS2, DORA, sector obligations of the ISAC you take part in): it is set by grc-compliance-standards, but verify that the marking level you use is compatible with your notification duty.
8. Feed quality studies: the reference used here is Reading the Tea Leaves (USENIX Security '19). It is from 2019: look for a more recent measurement before citing it as the state of the art — the mechanism (low overlap, high IP churn) still holds; the specific figures may not.

If the web contradicts this document, the web wins — flag the discrepancy.