Threat Intelligence Sharing: What to Share, With Whom, and How

Threat intelligence sharing creates value when the right recipient receives enough trustworthy context to act—without exposing victims, sources, personal data, operations, or legal interests unnecessarily. Sharing too little produces context-free indicators. Sharing too much can create harm that no detection benefit justifies.

The practical decision has four parts: why are we sharing, with whom, what do they need, and which boundaries must remain attached? Format comes afterward. STIX, TAXII, TLP, portals, email, briefings, and trusted communities can support the decision, but none determines whether the content is relevant, accurate, authorized, or safe.

This guide explains how producers and recipients should make sharing decisions, use current handling and exchange standards, minimize sensitive data, preserve provenance, correct mistakes, and evaluate value. It applies to sharing inside an organization as well as with peers, providers, customers, government partners, and communities.

Start With the Purpose and Recipient Decision

“Share more” is not a requirement. Define the result the exchange should support:

• block or monitor a current artifact;
• hunt for an adversary procedure;
• scope an incident across organizations;
• warn peers about targeting;
• compare campaign or actor evidence;
• prioritize a vulnerability or control;
• coordinate disruption or response;
• inform a supplier, customer, regulator, or leadership decision.

Name the recipient group and what it can do. A SOC needs precise observable context and triage guidance. A peer CTI team may need evidence, cluster boundaries, and confidence. An executive needs implications and choices. A public audience requires stronger minimization and review than a restricted incident-response circle.

Then ask whether sharing is necessary and proportionate. Could a sanitized behavior description support detection without naming the victim? Could an aggregated sector warning replace individual cases? Does the recipient need raw evidence or only the resulting judgment?

Record the authority for sharing, not only the benefit. Contracts, privacy, regulation, copyright, employment obligations, source agreements, classification, law-enforcement sensitivity, and incident strategy can limit disclosure.

Share Enough Context for Independent Evaluation

A useful package should answer:

• What happened? Separate observed facts, source claims, and analytic judgments.
• When? Include observation, collection, publication, and validity times.
• Where did the information come from? Preserve direct and upstream provenance.
• Why does it matter? State role, behavior, campaign, target, or decision relevance.
• How certain is it? Explain confidence, assumptions, gaps, and alternatives.
• How may it be used and shared? Attach markings and restrictions.
• What should the recipient do? Recommend block, alert, enrich, hunt, investigate, prepare, or assess.
• When should it be reviewed? Define expiry, status, and change triggers.

For an indicator, include exact pattern semantics, malicious role, infrastructure context, first and last seen, confidence, expected lifetime, false positives, and related procedure. The complete indicator workflow appears in Indicators of Compromise and TTPs.

For an actor or campaign, define the activity set and naming relationships. Do not let a familiar alias imply evidence you are not sharing. The standards in Cyber Threat Attribution still apply.

Minimize Victim, Personal, and Operationally Sensitive Data

Include sensitive detail only when it is necessary for the purpose and the recipient is authorized to receive it.

Review:

• victim and employee identity;
• usernames, email addresses, credentials, tokens, and personal data;
• internal hostnames, architecture, vulnerabilities, and security controls;
• incident scope, business impact, negotiations, and legal advice;
• source identity, access, methods, and collection capabilities;
• investigative leads, law-enforcement actions, and planned disruption;
• proprietary data, customer information, and contractual material.

Use de-identification, aggregation, generalized roles, redaction, time-bounding, and separate annexes. Confirm that remaining details cannot easily be recombined to identify a victim or source.

Sanitization must not change meaning. Removing time from an infrastructure relationship can make a historical observation look current. Removing the source can make repeated reporting appear independent. Retain a controlled full record and document what was removed from the shared version.

Use TLP for Sharing Boundaries—and Know What It Does Not Do

The FIRST Traffic Light Protocol 2.0 defines four labels:

• TLP:RED: not for disclosure beyond the individual recipients.
• TLP:AMBER: limited disclosure; recipients may share within their organization and with clients who need the information to protect themselves, subject to the source’s conditions.
• TLP:GREEN: limited disclosure within the recipient’s community, but not through publicly accessible channels.
• TLP:CLEAR: disclosure is not limited, subject to applicable rules and procedures for public release.

FIRST also defines TLP:AMBER+STRICT to restrict sharing to the recipient’s organization. Use the official definitions and exact labels; do not invent extra colors or silently redefine a label.

The source assigns TLP and should choose the least restrictive label that still protects the information. Recipients preserve the label and ask the source when boundaries are unclear.

TLP does not replace classification, legal restrictions, contracts, privacy controls, copyright, source agreements, or security requirements. It does not say whether information is accurate. A record may need TLP plus additional markings, permitted-purpose language, retention, encryption, named recipients, or regulatory controls.

Choose STIX and TAXII When Structured Exchange Solves a Real Need

STIX 2.1 is an OASIS language and serialization format for representing CTI. It can model indicators, malware, campaigns, threat actors, infrastructure, identities, vulnerabilities, sightings, notes, opinions, data markings, and relationships.

TAXII 2.1 is an OASIS application-layer protocol for communicating CTI. Services expose API roots and collections through which authorized clients can discover, retrieve, and add content according to permissions.

Use structured exchange when recipients need automation, machine-readable relationships, consistent updates, collections, or integration at scale. Use a human-readable assessment when meaning depends on narrative, alternatives, business implications, or complex reasoning. Often the right answer is both: a concise assessment plus structured objects for operational use.

Valid syntax does not guarantee interoperability. Agree on:

• which objects, properties, extensions, and relationships to use;
• identity and naming rules;
• confidence and status vocabulary;
• indicator patterns and validity;
• sightings, corrections, revocations, and deletions;
• markings and access;
• collection purpose and filtering;
• version support and conformance testing.

Exchange the smallest meaningful representation. A graph containing hundreds of weak inferred relationships can be less useful than ten well-sourced objects.

Match the Channel to Sensitivity, Urgency, and Use

Sharing channels include:

• direct analyst-to-analyst contact;
• incident bridges and secure case collaboration;
• ISACs, ISAOs, CSIRTs, and trusted communities;
• provider or customer portals;
• STIX/TAXII collections and APIs;
• secure email, messaging, and file transfer;
• published reports and public advisories;
• security-tool integrations.

Evaluate membership, identity assurance, access control, encryption, audit, moderation, retention, search, correction, availability, export, jurisdiction, and incident response. A fast chat channel may be appropriate for urgent coordination but poor as the only long-term record.

Define who monitors each channel and when. A 24/7 warning collection creates little value if nobody reads it outside office hours. Agree on urgent escalation, acknowledgement, and fallback when the platform is unavailable.

Communities work through reciprocity and trust. Share useful, accurate material; correct mistakes; respect restrictions; avoid flooding; and explain gaps. Consumption without contribution may be appropriate temporarily, but should be an explicit participation model.

The Producer Workflow

Before release:

1. define purpose, recipients, urgency, and expected action;
2. confirm authority, restrictions, and source consent;
3. validate evidence and trace provenance;
4. separate facts, claims, and judgments;
5. minimize sensitive and unnecessary detail;
6. choose format and channel for the recipient;
7. apply TLP and any additional handling;
8. assign confidence, status, validity, and review time;
9. conduct technical, analytic, privacy, legal, or communications review proportionate to consequence;
10. retain the released version and recipient record.

After release, monitor questions, sightings, false positives, and new evidence. Maintain a way to send corrections and revocations to every recipient and automated destination. If an indicator entered blocklists, correcting the report alone is insufficient.

Measure whether recipients understood and used the content, not only how many objects were distributed.

The Recipient Workflow

Receipt is the beginning of analysis, not automatic approval.

1. authenticate the source and preserve the original content and markings;
2. confirm permitted use and redistribution;
3. evaluate source access, claim credibility, time, and confidence;
4. determine relevance to assets, identities, suppliers, geography, and current incidents;
5. choose block, alert, enrich, hunt, investigate, brief, or retain as a lead;
6. assess false-positive and operational consequences;
7. record implementation, owner, expiry, and rollback;
8. report sightings, disagreement, and outcomes within permitted boundaries;
9. process producer corrections and propagate them downstream.

Do not remove provenance to make data easier to ingest. If a tool cannot preserve essential context, retain a reference to the full record and restrict the action to what the reduced representation supports.

The source-evaluation method in Cyber Threat Intelligence Sources helps distinguish independent evidence from repeated reporting.

Put Agreements and Decision Rights Around Sharing

A sharing agreement or policy should define:

• participants, identity assurance, and authorized roles;
• purposes and prohibited uses;
• content scope and minimum quality;
• TLP and additional markings;
• personal, victim, source, and classified information;
• intellectual property, licensing, and attribution;
• retention, deletion, audit, and security;
• onward sharing and cross-border transfer;
• corrections, disputes, incidents, and breach notification;
• service levels, availability, and termination;
• legal jurisdiction and points of contact.

Assign decision rights. Analysts may recommend sharing; source owners approve disclosure; privacy and legal functions advise on regulated or sensitive content; incident command coordinates live cases; communications owns public release; executives authorize high-consequence positions.

Review agreements and communities based on outcomes, not activity alone. Useful measures include warnings received in time, validated sightings returned, incidents connected, detections improved, false positives prevented, correction speed, participation health, and decisions supported.

The Sharing Decision Checklist

Before sending, answer:

• What decision or defensive action should this support?
• Who needs it, and who does not?
• Is sharing authorized and proportionate?
• What is observed, claimed, and assessed?
• Can recipients trace the source and time?
• What confidence, gaps, and alternatives matter?
• Which sensitive details can be removed?
• Which TLP and additional restrictions apply?
• Is the format usable by this recipient?
• What is the intended use, expiry, and review trigger?
• How will corrections reach every destination?
• How can the recipient return sightings and outcomes?

Share for a reason, not because a platform makes distribution easy. The best exchange gives recipients enough evidence to make a better decision while protecting every person, source, and operation that does not need to be exposed.