Diamond Model : mener une enquête CTI fondée sur les preuves

Le Diamond Model aide à répondre à une question précise : quelles relations peut-on établir entre une activité hostile, les moyens employés, l'infrastructure et la cible ? Son intérêt apparaît lorsque chaque lien repose sur une preuve consultable. Un diagramme rempli d'icônes sans justification n'améliore pas une enquête.

Le modèle décrit dans le travail original de Caltagirone, Pendergast et Betz représente un événement par quatre éléments : adversaire, capacité, infrastructure et victime. Nous allons appliquer cette structure à un dossier pédagogique, puis décider quels pivots justifient une investigation supplémentaire.

Tout le cas suivant est fictif. Les domaines en .example, les adresses de documentation et les journaux décrits sont inventés. Ils servent à travailler le raisonnement sans contacter une infrastructure réelle ni attribuer une activité à une organisation existante.

Commencer par la décision attendue

Une entreprise fictive, Atelier Boréal, reçoit un signalement de message suspect. La personne qui enquête pourrait chercher des centaines de domaines similaires. Ce volume ne répondrait pas nécessairement au besoin du responsable sécurité.

Le mandat retenu est plus étroit : déterminer avant midi si d'autres collaborateurs ont consulté la page signalée et si une investigation des comptes doit commencer. Le périmètre inclut les journaux de messagerie, de navigation et d'authentification disponibles depuis sept jours. Il exclut l'identification civile de l'opérateur.

Cette formulation fixe les limites du travail. Un domaine apparenté ne mérite une collecte supplémentaire que s'il peut révéler une autre exposition ou modifier les actions sur les comptes. Un rapprochement séduisant avec un groupe connu reste secondaire.

Une présentation SANS consacrée aux exigences de renseignement et au Diamond Model, publiée en janvier 2026, explore ce rapprochement entre question initiale et structure d'analyse. Le modèle prend ainsi place dans une enquête orientée vers une décision.

Constituer le premier événement sans combler les blancs

À 08:42 UTC, une salariée transmet un message proposant de consulter un document RH. Les en-têtes indiquent une réception à 08:37. Le lien affiché mène vers documents-boreal.example. Le journal du proxy enregistre une requête du poste POSTE-17 à 08:39 vers ce même nom.

Un export déjà collecté par l'équipe de réponse montre une page imitant le portail de connexion interne. Son formulaire possède une destination distincte, collecte-session.example. À ce stade, aucune télémétrie ne confirme qu'une personne a envoyé le formulaire.

Nous créons l'événement E01 pour la livraison du message :

• Victime ciblée : la destinataire du message.
• Infrastructure : le domaine présent dans le lien.
• Capacité observée : un message proposant un document RH pour inciter à suivre ce lien.
• Adversaire : opérateur inconnu, sans attribution nominative.

Nous créons séparément E02 pour la requête de POSTE-17. Le proxy établit cette requête; l'interaction humaine reste à vérifier. La copie de page documente une capacité de collecte apparente et sa destination à l'heure de la capture. Elle ne prouve pas ce qui a été présenté au poste ni qu'un formulaire a été envoyé. Livraison, requête et vol d'identifiants restent des propositions distinctes.

Décrire ce que chaque preuve permet réellement d'affirmer

Chaque pièce reçoit un identifiant stable et une description courte. P01 désigne le message exporté, P02 la ligne du proxy et P03 la copie de page. Nous conservons leur heure de collecte, leur système d'origine et le périmètre dont elles rendent compte.

Les pièces soutiennent des propositions précises : P01 justifie « le message contient ce lien » dans E01; P02 justifie « ce poste a demandé cette URL » dans E02; P03 justifie « cette copie contient ce formulaire ». Rien n'autorise encore « le poste a envoyé son mot de passe ».

Un en-tête de message peut être falsifié. Un journal peut provenir d'un scanner automatique. Une copie de page peut correspondre à une réponse différente de celle reçue par le collaborateur. L'analyste examine donc comment chaque pièce a été produite avant d'en déduire une action humaine.

Pour approfondir cette distinction entre information et preuve, le guide sur les sources de threat intelligence aide à examiner origine, fraîcheur et indépendance des observations.

Choisir un pivot qui pourrait changer la réponse

Le premier pivot utile porte sur le domaine du lien dans les journaux internes. Il répond directement au mandat : qui d'autre a été exposé ? La recherche retrouve une requête de POSTE-24, une minute après la réception d'un message au même objet.

Nous créons E03 pour ce deuxième message et E04 pour la requête de POSTE-24, avec leurs propres pièces et inconnues. Cette requête pourrait provenir d'une prévisualisation automatique, sans que la première requête suffise davantage à prouver une navigation humaine.

Le deuxième pivot porte sur la destination du formulaire dans les copies déjà disponibles. Deux pages possèdent cette même destination et un identifiant de campagne fictif identique. Cela renforce l'hypothèse d'une infrastructure commune. Cela ne démontre toujours pas que les deux sites appartiennent à une personne précise.

Avant chaque nouvelle recherche, notez ce qu'un résultat positif et un résultat négatif changeraient. Si aucun des deux ne peut modifier l'enquête, le pivot mérite probablement d'attendre.

Refuser une association fondée sur le seul hébergement

Une donnée DNS pédagogique associe documents-boreal.example à 192.0.2.44. Une autre liste présente cent noms sur cette adresse. Faut-il les rattacher à la campagne ? Non, pas sur cette seule base.

L'adresse peut représenter un hébergement mutualisé, un proxy ou une infrastructure réaffectée. La présence sur le même serveur devient un point de départ pour vérifier une relation, jamais un certificat d'appartenance. Nous inscrivons ces noms dans une liste de candidats, sans les inclure dans le regroupement provisoire étudié.

Un rapprochement devient plus intéressant si plusieurs éléments convergent : même destination spécifique de formulaire, même identifiant propre à la campagne et observation pendant une période compatible. Il faut encore se demander si ces éléments viennent réellement de collectes indépendantes.

Le guide consacré à l'anatomie des infrastructures de phishing détaille les objets souvent rencontrés dans ces enquêtes. Le Diamond Model apporte ici une discipline supplémentaire : enregistrer la nature exacte de la relation entre eux.

Construire une chronologie avec plusieurs horloges

La date de publication d'un rapport ne correspond pas nécessairement à la date d'utilisation d'un domaine. La date de collecte d'un journal ne correspond pas non plus à l'heure de l'événement qu'il contient.

Dans le dossier fictif, le proxy a observé E02 à 08:39. L'export a été réalisé à 09:06. La copie de page disponible a été obtenue la veille à 17:20. Ces heures doivent rester distinctes : la page a pu changer entre la collecte et la visite.

Notre chronologie comporte donc, pour chaque observation, une heure d'événement, une heure d'acquisition et une indication de précision. Une heure au format UTC n'est pas forcément exacte à la seconde; le système peut avoir une dérive connue ou un décalage non vérifié.

La spécification STIX 2.1 distingue notamment les objets d'observation, les indicateurs et leurs propriétés temporelles. Lors d'un export, préservez ces différences au lieu de recopier partout l'heure d'importation du dossier.

Distinguer les fils causaux des groupes d'activité

Un fil d'activité ordonne par phase des événements liés causalement, avec des liens éventuellement hypothétiques. Un groupe d'activité rassemble des événements ou des fils par leurs caractéristiques communes. Les sections 8 et 9 du document original distinguent ces relations.

Pour la première salariée, le fil provisoire relie la livraison E01 à la requête E02. Ce lien reste une hypothèse à vérifier avec la télémétrie : l'ordre des heures ne démontre pas que le message a provoqué une navigation humaine. Le deuxième salarié possède son propre fil provisoire, de E03 à E04. Une URL commune ne crée pas de causalité entre les actions des deux personnes.

La destination de formulaire, l'identifiant spécifique et la période compatible permettent de proposer un groupe d'activité réunissant ces deux fils. Le groupe porte un nom neutre, ACTIVITE-BOREAL-01, et des critères d'inclusion explicites. Il sert à rechercher les expositions apparentées sans identifier leur opérateur. Si une pièce invalide les critères, le groupe peut être scindé en conservant l'évaluation précédente.

À 10:15, un événement E05 arrive. Un message reçu trois semaines plus tôt réutilise le même modèle visuel, mais mène vers une autre destination. Le dessin ressemble; les critères spécifiques de regroupement ne sont pas satisfaits. L'événement reste un candidat hors du groupe.

Cette décision évite de transformer un kit réutilisé en preuve d'opérateur commun. Deux acteurs peuvent acheter le même outil. Un seul acteur peut changer d'outil. Un prestataire criminel peut fournir une infrastructure à plusieurs clients.

Si l'identité de l'acteur devient une question décisionnelle, ouvrez une analyse d'attribution avec hypothèses concurrentes. Sa confiance reste distincte des liens causaux hypothétiques dans chaque fil et des similitudes qui justifient le groupe.

Mettre les explications concurrentes à l'épreuve

Deux explications restent plausibles pour la visite de POSTE-24 : un utilisateur a ouvert le message, ou un mécanisme automatique a suivi le lien. Le journal du proxy montre une requête, mais n'arbitre pas seul entre ces hypothèses.

Nous demandons alors une pièce ciblée : la documentation du dispositif de prévisualisation et les traces disponibles sur le poste au même moment. Si le produit visite systématiquement les liens à la réception, l'hypothèse automatique gagne du poids. Une session de navigateur interactive pourrait soutenir l'autre explication.

L'absence de trace interactive ne prouve pas une absence de clic si cette télémétrie n'est pas collectée. Le dossier doit porter « impossible à départager avec les données disponibles ». Cette formulation indique une limite précise au destinataire.

Pour chaque explication, inscrivez une observation qui la renforcerait et une observation qui la fragiliserait. Le but n'est pas de distribuer artificiellement des probabilités égales, mais d'empêcher l'enquête de rechercher uniquement ce qui confirme son premier récit.

Ajouter ATT&CK au bon niveau

Un comportement observé peut recevoir un identifiant ATT&CK après vérification de sa description. Le code ne remplace ni l'événement ni la preuve. Il facilite la comparaison avec des capacités de détection et des scénarios de test.

Dans notre cas, la présence du message et du site de collecte soutient un scénario de phishing. Elle ne permet pas d'ajouter automatiquement toutes les techniques d'un groupe habituellement associé à ce scénario. Aucune persistance, exécution locale ou exfiltration supplémentaire n'a été observée.

Le guide de cartographie des défenses avec MITRE ATT&CK complète cette étape. Gardez dans le dossier le lien entre technique proposée, élément observé et télémétrie nécessaire. Une case colorée sur une matrice ne démontre pas qu'une détection fonctionne.

Cette séparation permet aussi de réutiliser une enquête lorsque le vocabulaire change. Les événements et leurs preuves subsistent; les annotations de technique peuvent être révisées sans détruire les faits.

Transformer le dossier en actions limitées

À 11:30, les éléments recueillis permettent de confirmer deux expositions réseau dans le périmètre des journaux disponibles. Le dossier ne confirme aucun envoi d'identifiants. Il justifie une vérification ciblée des comptes associés et un contrôle des autres messages contenant les deux destinations retenues.

Le responsable messagerie reçoit les éléments nécessaires à sa recherche. L'équipe identité reçoit les comptes concernés, la période et l'incertitude sur l'interaction humaine. Les cent domaines cohébergés ne sont pas transmis comme liste de blocage validée.

Chaque action possède un propriétaire, une échéance et un critère de clôture. « Vérifier les comptes » devient « examiner les événements d'authentification disponibles pendant la période retenue et documenter les anomalies ou les angles morts ». La consigne peut alors être exécutée et revue.

Une corrélation entre IP, DNS et processus peut apporter les éléments locaux manquants. Elle enrichit le dossier uniquement pour ce qu'elle observe réellement.

Un dossier réutilisable par un autre analyste

La livraison contient une page de conclusion et un petit dossier de preuves. Une autre personne doit pouvoir comprendre le raisonnement sans participer aux échanges initiaux. Voici un format de travail proposé pour cet exemple :

1. Question et périmètre : décision attendue, période, systèmes couverts et exclusions.
2. Événements : quatre éléments, inconnues explicites et relations justifiées.
3. Registre des pièces : origine, heures, intégrité, méthode de collecte et restrictions de partage.
4. Journal des pivots : question posée, résultat, décision et candidats écartés.
5. Évaluation : conclusions, explications concurrentes et preuves qui changeraient l'analyse.
6. Actions : destinataire, propriétaire, échéance et résultat de la vérification.

La revue cherche surtout les sauts logiques. Une observation locale est-elle devenue une affirmation globale ? Une visite est-elle devenue un vol ? Un domaine partagé est-il devenu une attribution ? Un résultat absent vient-il d'une recherche complète ou d'un manque de visibilité ?

Savoir clôturer sans prétendre tout connaître

L'enquête peut être clôturée lorsque la décision prévue a été prise, que ses limites sont documentées et que les actions restantes ont un propriétaire. Identifier l'opérateur n'est pas un préalable si cette identité ne change pas la protection des personnes exposées.

Définissez cependant des critères de réouverture : nouvelle exposition interne, preuve de soumission d'identifiants, infrastructure commune plus spécifique ou correction d'une source initiale. Ces critères transforment les inconnues en tâches suivables.

Pour une enquête autorisée sur des indicateurs réels, un rapport isMalicious peut compléter le contexte de réputation. Conservez la source et l'heure du résultat dans votre dossier, puis examinez ce que cette information permet d'affirmer. Les identifiants fictifs de cet exercice restent hors ligne.

La qualité du travail se voit dans les relations démontrées et les décisions rendues possibles. Le sommet adversaire peut rester vide. Une relation incertaine peut rester en pointillés. Le dossier reste utile tant qu'il dit exactement ce qui est connu, ce qui manque et ce qu'il faut faire ensuite.