STIX: Indicator vs Observed Data

A STIX Indicator proposes a detection condition. Observed Data records observed facts. Confusing the two can turn an ordinary DNS lookup into evidence of a threat, or cause a rule to be imported as though it described an incident that has already happened in your environment.

The distinction matters when a SOC receives external intelligence and matches it against its logs. The feed describes what to look for; local telemetry helps establish what happened. Your data model needs to preserve both layers so an analyst can explain the verdict.

Three objects, three questions

In STIX 2.1, indicator includes a pattern and its validity period. observed-data associates observable objects with first_observed, last_observed, and number_observed. A sighting asserts that an intelligence object was observed and can reference the supporting data. These roles are defined in the Indicator, Observed Data, and Sighting sections of STIX 2.1.

Before deciding which object to produce, write down what you know in plain language:

This table helps with modeling; it is not a blocking policy. An organization can receive an Indicator that is useful for a retrospective search without choosing to deploy it to prevention controls.

A domain in the logs is not a verdict

Consider a fictional example: a source publishes a pattern for collecteur.example, and an internal resolver records a query for that name. The reserved .example domain is used only for illustration.

The STIX pattern could be:

[domain-name:value = 'collecteur.example']

This is only the pattern field, not a complete STIX object. Before using it, your importer also needs to preserve its identifier, known author, version, and the information required by local policy.

The analyst then discovers that the DNS client was a threat research platform. It queried the domain as part of an authorized investigation. The observation remains true. The pattern match remains true. However, the hypothesis that an employee workstation is compromised has not been established.

If the connector had immediately labeled the observation as an infection, the SIEM would have propagated an incorrect conclusion. Keep the asset's role and the reason for its activity in the investigation record. A blanket exclusion for the domain would also suppress future matches that might be relevant.

Keep the different timestamps separate during import

Your interface should distinguish when the intelligence was created, when its pattern is useful, and when the local event occurred. A single “date” column makes these values look interchangeable even though they answer different questions.

In this scenario, imagine a local event on Monday, an Indicator received on Wednesday, and a retrospective search performed on Thursday. Thursday is the detection date in your tool, not the date of contact with the domain. Without that distinction, a team might search the wrong time window or treat historical activity as current.

Also record when the intelligence was consulted. If the source revises its analysis, your team should be able to reconstruct the decision using the information available when the alert was handled. Retaining only the latest visible record does not support that review.

Correlating IP, DNS, and process evidence is the next step: after finding a match, connect the asset and process to specific events.

Preserve relationships without inventing their meaning

STIX represents intelligence as a graph of objects and relationships. The official OASIS introduction describes this structure, which preserves the context around an indicator.

Avoid flattening the entire graph into a row containing just “value, malicious.” An address shared by two reports is not enough to merge the campaigns those reports describe. An imported relationship should retain its origin, while a relationship inferred locally should be identifiable as an inference.

An import contract can define three outputs: the archived raw document, fields the correlation engine can use, and items requiring review. A pattern your engine does not understand belongs in the third output. Extracting only its first domain and ignoring the other conditions would change its meaning.

Test this separation with a fictional dataset containing a simple pattern, a compound pattern, and an observation that makes no threat claim. Specify which object should produce a search, which should add context, and which should await a human decision. This tests the connector's behavior, beyond its ability to parse JSON.

Control what triggers an action

For each match, have the decision engine retain four things: the Indicator used, its version, the local event, and the policy applied. This record helps explain why two alerts involving the same domain received different treatment.

A production server and an analysis environment can warrant different priorities. Missing context must remain visible, however. Automatically replacing it with high confidence hides exactly what still needs to be checked.

Sharing markings also deserve a dedicated step. Before redistributing an observation, establish whether endpoint names, accounts, or paths can leave your organization. A format's ability to hold a field does not mean every recipient should receive it. Keep detailed evidence in the internal case record when its distribution is not authorized.

The STIX/TAXII feed guide explains where this transformation sits between the provider, intelligence platform, and SIEM. Include an acceptance test where the import succeeds but no automated action should follow.

For your next alert, open an indicator report, record its dated context, and write the local observation and the analyst's conclusion separately. If those three statements cannot be distinguished in the ticket, fix the data model before adding another intelligence source.