CSIRTS.eu

An independent tool index
for incident response teams

A threat intelligence workflow for CSIRTs

A traceable intelligence record with a named recipient, confidence assessment, sharing boundary and next action.

CSIRTS.eu editorialSources reviewed

Before you start

A useful intelligence workflow ends with a decision someone can act on: investigate a host, test a detection, warn a constituent, or keep watching. Start with that decision before adding feeds or choosing a platform.

This guide follows one report from intake to a reviewed handoff. The suggested checks are an editorial workflow for a small response team. Product references establish what the named tools document; they do not establish that every integration or deployment has been tested.

Have these ready

  • The original report or observation and its source.
  • A question tied to your constituency, assets or detection coverage.
  • Your sharing rules and a place to record review decisions.

1. Define the question and the recipient

Write a narrow question such as: “Does this reported activity affect software used by our constituency, and what can our responders look for?” Record who needs the answer and when. A detection engineer needs observables and testable behavior; a service owner needs affected products and an action. One undifferentiated export rarely serves both.

Set an initial disposition: actionable now, needs validation, or retained for context. MISP’s guidance stresses audience, purpose and analysis state. Use that distinction to keep unfinished research from becoming an implicit instruction to block something.

2. Preserve the claim and its context

Keep the source URL, publisher, publication date, observation period and retrieval date alongside each claim. Separate what the author observed from their attribution or prediction. Record when a domain was reportedly used; its ownership or purpose may have changed since.

OpenCTI documents separate representations for reports, observables, indicators and their relationships, with external references and change history. When modelling the report, preserve those distinctions. Two objects being present in the same report is weaker evidence than the author explicitly linking them.

3. Assess confidence before promotion

Check the original evidence, alternative explanations and relevance to your environment. Keep source reliability separate from confidence in a particular claim: a generally reliable publisher can still make an uncertain attribution. OpenCTI’s documentation treats these as distinct concepts.

Review proposed indicators against ordinary business use and any available internal observations. A shared hosting IP or common filename needs more context than an exact sample hash. Have a reviewer record why an item is suitable for detection, only for enrichment, or unsuitable for use. Do not treat an enrichment service’s match as an independent confirmation when it repeats the same source.

4. Select the sharing boundary and delivery

Apply the source’s sharing restrictions before exporting. FIRST’s TLP 2.0 describes how recipients may share information; it does not implement access control for you. Check actual groups, recipient permissions and export contents as well as the label.

For a machine consumer, agree the required types, timestamps and fields first. Test a small export through that consumer and inspect what arrives. A format name such as STIX is not proof that markings, relationships or updates survive a particular connector. Preserve a human-readable summary for context that the receiving system cannot represent.

5. Close the feedback loop

Ask the recipient to return useful sightings, false positives and missing context. Give each operational indicator a review point and an owner who can withdraw or correct it. Record whether the handoff produced an investigation, a tested detection, a notification, or no action.

Keep the original assessment when revising a conclusion so a responder can understand why an earlier action was taken. MISP documents proposals for corrections and extensions for additional analysis. Choose the mechanism that preserves the relationship to the original record and the intended distribution.

Handoff checks

Before passing the work on, confirm that:

  • Every actionable claim leads back to an original source.
  • The record separates observed facts, interpretation and confidence.
  • The recipient can see what to do, what to avoid and when to review it.
  • A test export preserved the fields and sharing restrictions the recipient needs.

Tools to evaluate

These profiles document different parts of the workflow. Their inclusion is not a ranking or a claim that they form an integrated stack.

MISP

Evaluate for structured indicator sharing, contextual tags and collaborative corrections. Check the export and distribution settings for your particular community.

OpenCTI

Evaluate for modelling reports, entities and relationships with source references. Confirm the edition and connector behavior needed for your workflow.

All threat intelligence tools

Sources and review

Primary documentation checked on . The numbered sequence and handoff checks are editorial recommendations. Product behavior and availability may change; this guide does not report hands-on testing.

Suggest a correction
All guides