STIX : distinguer Indicator et Observed Data

Un objet Indicator STIX propose une condition de détection. Un objet Observed Data rapporte des faits observés. Confondre les deux conduit à transformer une résolution DNS ordinaire en preuve de menace, ou à importer une règle comme si elle décrivait un incident déjà survenu chez vous.

Cette différence devient concrète lorsqu’un SOC reçoit du renseignement externe et le rapproche de ses journaux. Le flux décrit ce qu’il faut chercher ; la collecte locale permet de déterminer ce qui s’est passé. Le modèle doit conserver les deux niveaux pour que l’analyste puisse expliquer son verdict.

Trois objets, trois questions

Dans STIX 2.1, indicator porte notamment un pattern et sa période de validité. observed-data associe des objets observables à first_observed, last_observed et number_observed. sighting exprime l’observation d’un objet de renseignement et peut référencer les données qui l’étayent. Ces rôles sont définis dans les sections Indicator, Observed Data et Sighting de STIX 2.1.

Pour choisir quoi produire, formulez d’abord votre phrase en français :

Ce tableau est une aide de modélisation, pas une règle de blocage. Une organisation peut recevoir un Indicator utile à une recherche rétrospective sans décider de le déployer dans ses équipements de prévention.

Un domaine présent dans les journaux n’est pas un verdict

Prenons un exemple fictif : une source publie un motif visant collecteur.example, et un résolveur interne enregistre une demande vers ce nom. Le domaine réservé .example sert uniquement à l’illustration.

Le motif STIX pourrait être :

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

Il s’agit seulement du champ pattern, pas d’un objet STIX complet. Avant de l’exploiter, votre importeur doit aussi conserver son identifiant, son auteur connu, sa version et les informations nécessaires à la politique locale.

L’analyste découvre ensuite que le client DNS était une plateforme de recherche de menaces. La plateforme a interrogé le domaine dans le cadre d’une investigation autorisée. L’observation reste vraie. La correspondance avec le motif reste vraie. L’hypothèse « un poste métier est compromis » n’est toutefois pas établie.

Si le connecteur avait immédiatement étiqueté cette observation comme une infection, le SIEM aurait propagé une conclusion incorrecte. Conservez donc le rôle de l’actif et le motif de l’activité dans le dossier d’enquête. Une liste d’exclusion générale sur le domaine effacerait aussi de futures correspondances pertinentes.

Séparer les horloges pendant l’import

Votre interface devrait distinguer la création du renseignement, la période pendant laquelle le motif est utile et l’heure de l’événement local. Afficher une seule colonne « date » rend ces valeurs interchangeables alors qu’elles répondent à des questions différentes.

Dans notre scénario, imaginez un événement local du lundi, un Indicator reçu le mercredi et une recherche rétrospective exécutée le jeudi. Le jeudi est la date de détection dans votre outil, pas celle du contact avec le domaine. Sans cette distinction, une équipe peut chercher des traces sur le mauvais créneau ou traiter comme active une activité ancienne.

Notez aussi la date de consultation du renseignement. Si la source révise son analyse, l’équipe doit pouvoir reconstruire la décision prise avec les informations disponibles au moment du traitement. Garder uniquement la dernière fiche visible ne permet pas cette relecture.

La corrélation entre IP, DNS et processus fournit la suite logique : une fois la correspondance trouvée, relier l’actif et le processus à des événements précis.

Préserver les relations sans inventer leur sens

STIX représente le renseignement comme un graphe d’objets et de relations. L’introduction officielle d’OASIS présente cette organisation, qui permet de garder le contexte autour d’un indicateur.

Dans votre pipeline, évitez d’aplatir tout le graphe en une ligne « valeur, malveillant ». Une adresse partagée par deux rapports ne suffit pas à fusionner les campagnes de ces rapports. Une relation reçue doit garder son origine ; une relation déduite localement doit être reconnaissable comme telle.

Un contrat d’import peut définir trois sorties : le document brut archivé, les champs utilisables par le moteur de corrélation et les éléments soumis à examen. Un motif que votre moteur ne comprend pas va dans la troisième sortie. Extraire uniquement son premier domaine et ignorer ses autres conditions changerait sa signification.

Testez cette séparation avec un jeu fictif comprenant un motif simple, un motif composé et une observation sans qualificatif de menace. Le résultat attendu doit préciser quel objet produit une recherche, lequel enrichit le contexte et lequel attend une décision humaine. Ce test vérifie le comportement du connecteur, pas seulement sa capacité à lire du JSON.

Contrôler ce qui déclenche une action

Pour chaque correspondance, demandez au moteur de décision de conserver quatre éléments : l’Indicator utilisé, sa version, l’événement local et la politique appliquée. Cette trace aide à expliquer pourquoi deux alertes portant sur le même domaine ont reçu des traitements différents.

Le contexte d’un serveur de production et celui d’un environnement d’analyse peuvent justifier des priorités différentes. En revanche, l’absence de contexte doit rester visible. La remplacer automatiquement par une confiance élevée masque précisément ce qu’il reste à vérifier.

Les marques de partage méritent également une étape dédiée. Avant de redistribuer une observation, vérifiez si les noms de postes, comptes ou chemins peuvent sortir de votre organisation. Le fait qu’un format accepte un champ ne signifie pas que tout destinataire doit le recevoir. Gardez les preuves détaillées dans le dossier interne quand leur diffusion n’est pas autorisée.

Le guide des flux STIX/TAXII explique comment situer cette transformation entre le fournisseur, la plateforme de renseignement et le SIEM. Ajoutez à votre recette un cas où l’import réussit mais où aucune action automatique ne doit se produire.

Pour votre prochaine alerte, ouvrez un rapport d’indicateur, consignez son contexte daté, puis écrivez séparément l’observation locale et la conclusion de l’analyste. Si ces trois phrases sont impossibles à distinguer dans le ticket, corrigez le modèle avant d’ajouter une nouvelle source de renseignement.