Assess a threat-intelligence source

Assess the claim as well as its publisher. A familiar organisation can publish an early assessment with important gaps; an unfamiliar researcher can provide inspectable evidence. Your record should explain what supports this particular conclusion, how well it matches your question and what would change your judgement.

The NCSC's guidance warns about low-confidence or outdated indicators and recommends checking whether intelligence sources deliver value. The practical consequence is to preserve dates, context and limitations when information enters your workflow.

Separate four questions

Keep a source copy or stable reference where your organisation's permissions and retention rules allow it. A link alone can become difficult to interpret if the publisher later updates the page. Record which version you actually used.

Compare fictional claims

The following reports and product names are invented to demonstrate assessment. No named organisation or software is being accused of a vulnerability.

The supplier bulletin and anonymous post may refer to the same underlying event. Their agreement does not establish two independent observations. Trace the chain back before describing a claim as corroborated.

Write a confidence statement with reasons

Use a sentence rather than a bare label. For example:

We have high confidence that the supplier describes an issue affecting the stated versions because its bulletin identifies the conditions and corrective action. We have not yet established whether our configuration meets those conditions. We have no evidence from this bulletin alone that our organisation has been compromised.

This is three judgements with different evidence, not one global confidence score. Keep likelihood, impact and confidence separate: a serious possible outcome can still be supported by limited evidence. If you use terms such as low, moderate or high, define them within your team and attach the reasoning.

Useful challenge questions include: what alternative explanation fits the observations; what information would disprove the claim; and what is missing because the source could not see it? Record disagreement instead of silently averaging incompatible accounts.

Handle indicators as contextual observations

A listed address, domain or file hash needs a reason for inclusion, an observation period and a planned use. Decide whether the information supports a search, an alert, an investigation or a blocking change. Those actions have different consequences.

For a proposed automated action, ask the service owner to consider legitimate use, reversal and monitoring. In a fictional review, a reported address might belong to shared infrastructure used by both suspicious and legitimate traffic. That possibility warrants a more specific check; it does not justify dismissing the report entirely.

Respect the source's sharing rules

FIRST's Traffic Light Protocol communicates disclosure boundaries. It is not a confidence scale. For example, TLP:AMBER+STRICT limits sharing to the recipient organisation; it does not mean the evidence is more reliable than a public report. Check the full current definitions and any additional restrictions before forwarding information.

Avoid copying restricted incident details into a public ticket, portfolio or conference note. If a decision requires wider disclosure, ask the source what may be shared and through which channel.

A compact assessment record

Record the claim, source and version; relevant dates; underlying evidence; applicability; alternative explanation; confidence with reasons; handling restrictions; and next verification step. Attach the intelligence requirement it answers.

The next step might be to inspect an authorised configuration, ask the supplier for clarification or take no action pending better evidence. Preserve that decision so the same unverified claim does not repeatedly consume the team's time. When the assessment supports a concrete change, use intelligence to action to assign and validate it.