Threat Intelligence Platforms
Learn threat intelligence platforms through STIX/TAXII, indicator triage, confidence decay, TLP sharing, integrations, and feedback loops.
What are threat intelligence platforms?
Threat intelligence platforms (TIPs) are systems for turning threat evidence from many sources into governed, connected, and usable intelligence. A TIP ingests reports and machine-readable records, preserves where claims came from, links observables to campaigns or behavior, supports analyst review, and distributes approved results to people and security tools.
In plain language: a TIP is the workbench and control plane between "someone reported this" and "our organization should do something about it." It can help a team search, enrich, deduplicate, share, and retire intelligence, but it cannot decide truth from feed volume alone.
The core invariant is an indicator is a time-bounded claim with context, not an instruction by itself. A domain, address, or hash may justify a historical hunt while still being too stale, ambiguous, or risky for automated blocking. Provenance, confidence, validity, sharing rules, intended action, and consumer feedback must stay attached to the decision.
Collect
Preserve provenance
Keep source identity, observation time, markings, and the original claim.
Connect
Build context
Relate observables to sightings, behavior, campaigns, vulnerabilities, and analysis.
Decide
Gate each use
Apply action-specific confidence, freshness, false-positive, and approval policy.
Learn
Close the loop
Return dispositions, sightings, false positives, and disablement outcomes.
Begin with an intelligence requirement
An intelligence requirement is a specific question whose answer will change a defensive decision. "Ingest more feeds" is an implementation activity. "Which externally exposed identity systems are being targeted by current credential-phishing infrastructure, and what evidence is safe enough to alert on?" identifies an audience, scope, decision, and time horizon.
A recorded fact
Observable
A domain, address, file hash, process, URL, certificate, or other property seen in telemetry. An observable says what was seen; it does not by itself say why it matters.
A detection claim
Indicator
A pattern or condition judged to indicate malicious or suspicious activity during a stated validity window. Confidence and context describe uncertainty; they do not eliminate it.
Evidence of use
Sighting
A record that an indicator or related object was observed by a consumer at a time and place. A sighting can strengthen relevance, while a false-positive disposition can weaken or retire the claim.
Decision to support
Intelligence requirement
The question, audience, deadline, and action that determine which sources, relationships, enrichment, review, and output are useful. Requirements keep feed volume from becoming the program goal.
Before choosing a platform, write down:
- the defensive decision and its owner;
- the systems, identities, regions, or business processes in scope;
- the evidence and uncertainty the owner needs;
- how quickly the answer loses value;
- the widest audience allowed to receive it;
- the feedback that will show whether the intelligence helped or caused noise.
Turn source claims into governed intelligence
The intelligence lifecycle is a feedback loop, not a one-way feed pipeline. Ingestion creates candidate evidence. Analysis and policy decide which uses are justified. Consumer outcomes must return so the platform can revise confidence, validity, and distribution.
1 Source boundary
Collect and preserve
Authenticate the source, checkpoint ingestion, retain provenance and markings, reject malformed payloads, and record when each claim was produced and received.
2 Knowledge model
Normalize and connect
Map records into stable objects and relationships, deduplicate identities carefully, preserve conflicting claims, and attach internal sightings and enrichment with their own sources.
3 Decision boundary
Analyze and release
Evaluate relevance, confidence, freshness, false-positive risk, sharing limits, and the blast radius of the requested action before publishing to each consumer.
4 Feedback boundary
Measure and revise
Return analyst dispositions, control outcomes, sightings, false positives, and disablement events; then update, revoke, or expire the intelligence deliberately.
Deduplication must not erase disagreement. Two sources can refer to the same domain while making different claims with different confidence, markings, and validity. Merge identity where justified, but keep claim-level provenance and time.
Match evidence strength to action blast radius
An action policy defines the evidence gates required before intelligence can affect a particular consumer. A historical hunt is reversible and low impact. An alert consumes analyst attention. Automated prevention can interrupt legitimate work, so it needs stronger and fresher evidence.
Use the lab to compare a fresh phishing domain, a malware hash, a shared-hosting address, and a known public resolver. Change the intended action, then add delay. Confidence, freshness, false-positive risk, and the release decision update together.
Read the model as a policy, not a truth machine
- Confidence decay is explicit. The lesson model lowers confidence by a visible amount at fixed age intervals so readers can inspect the arithmetic. A real program must calibrate decay by indicator type and observed lifetime.
- Sightings do not cancel collateral risk. A busy shared-hosting address can have many malicious sightings and still be unsafe to block broadly.
- Freshness depends on use. Old evidence may remain valuable for retrospective hunting after it is no longer safe for a current alert or deny rule.
- Higher blast radius needs stronger gates. The model intentionally makes investigation easier to approve than automated prevention.
Never treat a source's confidence value as globally calibrated. Record what the source means, add your own assessment separately, and test downstream policy against known true positives and false positives.
Separate representation, transport, and sharing policy
Interoperability works only when the data model, exchange protocol, and handling rules keep separate responsibilities. STIX represents CTI, TAXII exchanges CTI objects, and TLP communicates sharing boundaries. None of them proves that a claim is analytically correct.
Representation
STIX 2.1
STIX is a JSON-based language for cyber threat intelligence. Domain objects such as indicators, malware, reports, and threat actors connect to cyber-observable objects and relationships as a graph. Use stable IDs, timestamps, confidence, validity, markings, and relationships to preserve meaning.
Exchange
TAXII 2.1
TAXII defines discovery, API roots, collections, manifests, object endpoints, and status resources over HTTPS. A collection is a permissioned logical repository; clients may have read, write, both, or neither capability.
Sharing boundary
TLP 2.0
FIRST defines TLP:RED, TLP:AMBER, TLP:GREEN, and TLP:CLEAR. TLP:AMBER+STRICT narrows TLP:AMBER to the recipient's organization. TLP is not a formal classification scheme and does not define automated access-control mapping for you.
Behavior vocabulary
ATT&CK
ATT&CK technique and software references can help analysts describe adversary behavior consistently. A mapping is context for analysis and detection engineering, not proof that an indicator is current or that a local control works.
The current OASIS STIX 2.1 specification defines the object model and patterning language. The OASIS TAXII 2.1 specification defines collection endpoints, media types, filtering, pagination, and error behavior. The FIRST TLP 2.0 standard is authoritative for current TLP labels and their sharing boundaries.
For incremental collection reads, persist the server's checkpoint and follow pagination until the response says no more data remains. Send the TAXII 2.1 media type, handle 401, 403, 404, 406, and rate limits explicitly, and make object processing idempotent. A successful HTTP response means exchange succeeded; it does not mean the intelligence passed local policy.
Trace the operating loop and its control points
A TIP operating loop connects source evidence to a bounded consumer decision and then returns outcomes. The critical controls sit at ingestion, identity resolution, analyst review, sharing and action policy, and feedback.
Switch among a curated alert, a raw auto-block, a restricted-sharing case, and a missing-feedback failure. The selected route, failed or degraded component, component responsibility, and operational result update together.
Keep transport success separate from decision quality
- If ingestion fails, preserve the last confirmed checkpoint and retry without duplicating objects or losing provenance.
- If normalization is uncertain, quarantine the record or preserve competing identities rather than forcing an irreversible merge.
- If evidence does not satisfy an action policy, retain it for an allowed lower-impact use or hold it for review.
- If sharing policy rejects a destination, do not widen the audience merely because a connector can reach it.
- If consumer feedback is absent, treat intelligence quality as unmeasured and shorten review intervals until the loop is restored.
Choose a platform shape from the operating model
A platform choice is a fit decision about workflows, data model, communities, controls, integrations, and ownership. Feature counts do not reveal whether the team can maintain source contracts, resolve identity, review evidence, enforce markings, and collect feedback.
Events and communities
MISP-centered sharing
Fit: teams that need event and attribute workflows, sharing groups, taxonomies, galaxies, warning lists, feeds, and community exchange. Verify the exact MISP version, enabled modules, distribution settings, synchronization model, and API contract.
Entities and relationships
OpenCTI-centered knowledge graph
Fit: teams that need STIX 2.1-oriented entity and relationship analysis, confidence and marking controls, deduplication, inference, and import, enrichment, stream, or file connectors. Plan connector isolation and queue operations as part of the system.
Operations and support
Managed or commercial TIP
Fit: organizations that need vendor-operated content, support, access controls, workflow, and maintained integrations. Evaluate export fidelity, policy granularity, audit evidence, data residency, connector ownership, failure behavior, and exit strategy with real use cases.
Narrow requirement
Focused integration layer
Fit: a bounded workflow with few sources and consumers that does not yet need a full collaborative knowledge base. Keep the same provenance, idempotency, policy, expiry, audit, and feedback contracts so the pipeline does not become an ungoverned feed forwarder.
MISP's official warning-list documentation shows how known infrastructure can flag likely false positives at event, attribute, and API boundaries. OpenCTI's current documentation describes its STIX-based graph model, data processing controls, and connector roles.
Product capabilities change, so verify release-specific documentation and test with representative data before committing to an operating model.
Encode an indicator and test policy offline
A portable example should expose the decision contract without requiring credentials, a live feed, or a vendor SDK. The STIX bundle demonstrates a bounded indicator. The evaluator applies the same transparent aging and action gates used by the learning lab.
The indicator has a stable STIX ID, a STIX pattern, valid_from, valid_until, and confidence. Validate its JSON syntax with node -e "JSON.parse(require('fs').readFileSync(process.argv[1]))" followed by the file path. In production, validate against the STIX specification and your profile before exchange.
Run the dependency-free evaluator from the repository root with the model path and an optional delay in days: node content/entries/technology/threat-intelligence-platforms/code/evaluate-indicators.mjs content/entries/technology/threat-intelligence-platforms/data/indicator-triage-model.json 17.
The script prints eligible or the exact failed gates for each candidate and action. It performs no network requests and takes no enforcement action.
Operate for useful outcomes, not feed volume
An intelligence metric should connect platform work to a reproducible consumer outcome. Raw object count measures ingestion pressure, not analytical value.
Yield
Actionable output
Released items divided by accepted candidates, with both counts visible.
Time
Decision latency
Time from source availability to reviewed, consumer-ready intelligence.
Noise
False-positive outcome
Released items later disabled, suppressed, or reversed by consumers.
Age
Stale exposure
Active consumer rules beyond their review or validity boundary.
Run the platform with explicit contracts:
- Source contract: owner, authentication, allowed use, marking semantics, schema/profile, rate limits, checkpoints, quality expectations, and revocation path.
- Identity contract: matching keys, merge authority, conflict handling, version behavior, and provenance retained after deduplication.
- Action contract: consumer, permitted object types, confidence and freshness gates, approval mode, expiry, rollback, and audit evidence.
- Feedback contract: sightings, dispositions, false positives, missed detections, disablement, delivery failures, and how each outcome changes platform state.
- Recovery contract: backups, queue replay, connector restart, reindexing, duplicate handling, secret rotation, degraded mode, and tested restore objectives.
Alert on stale connectors, checkpoint lag, rejected payloads, unresolved merge spikes, policy-denied releases, missing feedback, expired active rules, and consumers that stop acknowledging updates. Rehearse source compromise and mass revocation: the platform must identify every derived object and downstream release affected by a bad source.
Recognize the common failure modes
A TIP fails when it accelerates unsupported claims or loses the controls needed to revise them. Availability matters, but a fully available platform can still distribute harmful intelligence quickly.
Requirement failure
Feed accumulation
Symptom: rising object counts, duplicate records, and analyst backlog without named consumer decisions. Fix: remove unused sources, define requirements, and measure yield by source and use case.
Model failure
Irreversible entity merges
Symptom: conflicting actors, infrastructure, or observables collapse into one identity and provenance becomes unclear. Fix: preserve claim-level sources, require review for ambiguous merges, and support split or correction workflows.
Sharing failure
Marking without enforcement
Symptom: labels appear in the UI but connectors export to audiences that the source did not authorize. Fix: map markings to tested destination policy and deny release when the mapping is absent or ambiguous.
Learning failure
One-way distribution
Symptom: consumers receive indicators but never return sightings, false positives, or disablement. Fix: make feedback part of the integration acceptance criteria and report missing outcomes as a quality gap.
The safest default is to fail closed on external sharing and high-impact automation while preserving evidence for internal review. Fail-open behavior must be an explicit, bounded decision for a consumer whose risk is understood.