Threat Intelligence : STIX (Structured Threat Information eXpression)

Note

Résumé exécutif : historiquement, la Cyber Threat Intelligence (CTI) était partagée via des rapports PDF non structurés, des fichiers CSV et des e-mails disparates, nécessitant un effort manuel intense pour extraire des indicateurs exploitables. STIX (Structured Threat Information eXpression), maintenu par le consortium OASIS, résout ce problème en fournissant un langage standardisé basé sur JSON pour décrire les cybermenaces. Il permet aux outils de sécurité de consommer, d’analyser et de réagir automatiquement à des données de menace complexes. STIX transforme la CTI : de récits lisibles par des humains, elle devient une base de données orientée graphe exploitable par des machines.

1. La philosophie : un langage basé sur des graphes

La véritable puissance de STIX (en particulier STIX 2.x) réside dans son architecture. Il modélise le paysage des menaces comme un graphe mathématique, où les entités sont des nœuds et les interactions entre elles sont des arêtes.

Ceci est accompli grâce à trois blocs de construction fondamentaux :

1. SDO (STIX Domain Objects) : les “noms”. Ils représentent des concepts de renseignement de haut niveau (ex: acteurs de la menace, familles de malwares, campagnes).
2. SCO (STIX Cyber-observable Objects) : les “adjectifs/faits”. Ils représentent des artefacts techniques bruts au niveau du réseau ou de l’hôte (ex: adresses IP, hashs de fichiers, clés de registre).
3. SRO (STIX Relationship Objects) : les “verbes”. Ils lient les SDO et les SCO entre eux pour fournir un contexte crucial.

Analogie : si la CTI est le commerce mondial, STIX est le conteneur maritime standardisé. Parce que chaque flux de renseignement utilise exactement le même conteneur JSON, les grues d’orchestration de sécurité (SOAR) peuvent automatiquement soulever, déballer et acheminer les données sans intervention humaine.

2. Le lexique STIX fondamental

Pour naviguer dans les flux STIX, les analystes DFIR et les Threat Hunters doivent être familiers avec les objets les plus critiques.

A. Objets de domaine (SDO)

Ces objets décrivent le qui, le quoi et le pourquoi d’une intrusion.

• threat-actor : l’adversaire derrière l’attaque (ex: les courtiers d’accès initial - IAB, APT28).
• campaign : un regroupement d’activités malveillantes ciblant un objectif spécifique.
• malware : le logiciel malveillant utilisé (ex: le Ransomware Akira).
• attack-pattern : une TTP spécifique, nativement mappée au framework MITRE ATT&CK (ex: T1059.001 - PowerShell).
• indicator : un objet hautement critique. Il contient un modèle (pattern) qui peut être utilisé pour détecter une activité suspecte. Il sert de pont entre les observables techniques et l’intention malveillante.

B. Cyber-observables (SCO)

Ces objets décrivent le où et le comment (les IOCs traditionnels).

• ipv4-addr / domain-name / url : infrastructure réseau.
• file : artefacts d’hôte, contenant des propriétés telles que les noms et les hashs SHA256.
• process / windows-registry-key : traces d’exécution.

3. Créer du contexte via les relations (SRO)

Une seule adresse IP dans le vide est inutile. Les objets de relation STIX (SRO) génèrent des renseignements exploitables en reliant les points.

La chaîne sémantique :

• le SDO Threat Actor: APT28 → uses (utilise) → le SDO Malware: DropperX.
• le SDO Malware: DropperX → communicates-with (communique avec) → le SCO Domain-Name: evil-c2.com.
• le SDO Indicator → indicates (indique) → le SDO Malware: DropperX (et contient un pattern correspondant au domaine evil-c2.com).

JSON (Exemple de relation STIX 2.1)

stix_relationship.json

{
  "type": "relationship",
  "spec_version": "2.1",
  "id": "relationship--8e461b0a-313d-4c31-901c-6dcb9a567c9c",
  "created": "2026-11-17T10:00:00.000Z",
  "modified": "2026-11-17T10:00:00.000Z",
  "relationship_type": "indicates",
  "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
  "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b"
}

4. Opérationnalisation pour le DFIR et le SOC

STIX n’est pas réservé aux seuls analystes en renseignement ; il est profondément intégré dans les opérations modernes de la Blue Team.

1. Ingestion automatisée : les plateformes de Threat Intelligence (TIP) agrègent les données STIX et poussent automatiquement les SCO pertinents (hashs, IPs) directement vers les agents EDR et les pare-feux.
2. Création de patterns STIX : STIX inclut un puissant langage de mise en correspondance de motifs (pattern-matching). Un objet Indicator STIX contient une chaîne pattern qui définit exactement comment trouver la menace (ex: [file:hashes.'SHA-256' = '4bac...']). Les SIEM modernes traduisent automatiquement ces modèles STIX en requêtes natives (comme KQL ou Splunk SPL) pour une chasse aux menaces immédiate.
3. La couche de transport : définir le langage n’est que la moitié de la bataille. Pour distribuer ces immenses graphes JSON en temps réel entre les organisations et les agences gouvernementales, l’industrie s’appuie sur un protocole de couche application dédié. Cette distribution automatisée est entièrement gérée par TAXII (Trusted Automated eXchange of Intelligence Information).

En comprenant STIX, les intervenants sur incident passent de la simple réaction à des alertes isolées à la compréhension d’une campagne plus vaste, cartographiant instantanément des artefacts d’hôtes isolés vers des acteurs de la menace mondiaux connus.

---

Sources et références

• OASIS Open : Spécification STIX 2.1
• MITRE : Introduction à STIX
• Écosystème lié : Protocole TAXII et échange automatisé
• Profil lié : Ransomware Qilin et Threat Intelligence