Construire un pipeline d'IOC avec MISP et STIX : guide complet

Une équipe SOC reçoit un accès à trois flux de threat intelligence, deux listes CSV partagées par un partenaire et un export JSON d'un fournisseur EDR. Chaque source a son format, ses doublons, ses indicateurs vieux de deux ans encore actifs dans la liste. La question n'est plus « où trouver des IOC » (ils sont partout), mais « comment les faire tenir dans un pipeline qui alimente la détection sans la noyer ». MISP et STIX 2.1 sont les briques de référence pour répondre à cette question. Ce guide couvre l'architecture bout en bout, de la source à la règle qui déclenche.

Architecture d'ensemble : sources vers MISP, MISP vers la détection

Un pipeline d'IOC robuste s'articule en trois étages.

Sources vers MISP. Les flux entrants (feeds commerciaux, CERT nationaux, partages sectoriels ISAC, remontées internes d'incidents) arrivent dans MISP via des connecteurs de feed, l'API REST ou l'import manuel. MISP joue le rôle de plateforme de normalisation : chaque indicateur devient un attribut typé (ip-dst, domain, sha256, url...), rattaché à un événement, taggé selon une taxonomie commune.

Normalisation et dédoublonnage. C'est le rôle central de MISP : deux sources qui remontent le même hash sous des formats différents doivent converger vers un seul attribut, avec corrélation automatique entre événements qui partagent des indicateurs.

Export STIX 2.1 vers les moteurs de détection. Une fois les attributs qualifiés, MISP exporte au format STIX 2.1 (bundles d'objets indicator, malware, attack-pattern liés par des relationship), consommable par un SIEM, un NIDS comme Suricata, ou un EDR qui sait ingérer du threat intel structuré.

# Export STIX 2.1 d'un événement MISP via l'API REST
curl -s -H "Authorization: <API_KEY>" \
  -H "Accept: application/json" \
  "https://misp.example.org/events/stix/download/1234/2.1" \
  -o event-1234-stix21.json

Ce découpage en trois étages a une vertu simple : chaque maillon peut évoluer sans casser les autres. Changer de fournisseur de feed ne touche pas l'export vers Suricata, tant que la normalisation MISP reste stable.

Ingérer un feed : attributs, tags, taxonomies, corrélation

L'ingestion brute est le point où la plupart des pipelines déraillent. Un attribut mal typé (une IP taguée comme un hash) casse la corrélation en aval. Trois disciplines à respecter.

Typer correctement chaque attribut. MISP distingue par exemple ip-src (source d'une connexion observée) de ip-dst (destination), ce qui change le sens de la détection qu'on en tire : bloquer une IP source qu'on a vue attaquer n'est pas la même décision que bloquer une IP destination vers laquelle une machine interne a communiqué.

Taguer selon une taxonomie stable. MISP embarque des taxonomies standard (tlp, admiralty-scale, estimative-language) qui portent la fiabilité de la source et le niveau de diffusion autorisé. Un attribut sans TLP ne devrait jamais être exporté vers un tiers.

Activer la corrélation. MISP corrèle automatiquement les attributs identiques entre événements, ce qui fait remonter les indicateurs vus par plusieurs sources indépendantes, un signal de confiance bien plus fort qu'une mention isolée.

Le vrai filtre anti-bruit, cependant, ce sont les warninglists. Ce sont des listes de valeurs qui ne doivent jamais devenir des IOC bloquants, même si une source les a remontées par erreur ou par imprécision :

• les plages RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), des adresses privées qu'aucun flux externe légitime ne devrait qualifier de malveillantes ;
• le top 1 million de domaines les plus visités au monde, dont la présence dans un IOC signale presque toujours une extraction automatisée trop large plutôt qu'une compromission réelle ;
• les IP des grands fournisseurs cloud et CDN, souvent partagées par des milliers de services légitimes.

# Exemple de configuration warninglist activée dans MISP
warninglists:
  - name: "List of RFC 1918 private IP addresses"
    enabled: true
  - name: "Top 1000000 domains"
    enabled: true
  - name: "Cloud service providers IP ranges"
    enabled: true

Sans ces garde-fous, un pipeline finit tôt ou tard par proposer le blocage d'une IP interne ou d'un CDN public. C'est l'incident qui casse la confiance de l'équipe réseau dans tout le reste du flux d'IOC.

Cycle de vie d'un IOC : scoring, expiration, éviter le blocage abusif

Un IOC n'est pas une vérité permanente. Une IP malveillante aujourd'hui peut être réattribuée à un hébergeur légitime dans six mois. Un domaine de commande et contrôle saisi par les forces de l'ordre redevient disponible à l'achat pour n'importe qui.

Le scoring doit combiner plusieurs signaux : le nombre de sources indépendantes qui corroborent l'indicateur, la fraîcheur de la première observation, le type d'attribut (un hash de malware vieillit mieux qu'une IP), et le contexte de la campagne associée. MISP permet d'exposer ce score sous forme d'attribut Threat Level ou via des champs Galaxy personnalisés.

L'expiration (decay) doit être différenciée par type d'indicateur : un hash SHA-256 de malware reste valide des années, une IP d'infrastructure d'attaque a une durée de vie utile de quelques semaines à quelques mois, un domaine jetable encore moins. Un pipeline qui traite tous les IOC avec la même durée de rétention accumule mécaniquement du bruit obsolète.

L'exemple concret avant/après :

Avant (flux brut non géré) : une IP remontée il y a huit mois par un feed, jamais revue depuis, toujours présente dans la liste de blocage active du pare-feu. L'hébergeur a depuis réattribué cette IP à un client légitime, qui se retrouve bloqué sans explication, générant un ticket support et une perte de confiance dans le dispositif.

Après (pipeline avec cycle de vie) : la même IP est automatiquement dégradée en statut « expiré » après 90 jours sans nouvelle corroboration, retirée de la liste de blocage actif, mais conservée en base pour la corrélation historique en cas d'investigation ultérieure. Le blocage reste réservé aux indicateurs récents et corroborés.

Diffuser vers la détection : export et boucle de sightings

L'export STIX ne s'arrête pas à un fichier JSON déposé quelque part. Chaque moteur cible a son format de consommation.

Vers Suricata, les IOC réseau (IP, domaines, URL) se transforment en règles ou en listes d'interdiction (iprep, dataset) consommées au chargement.

# Exemple de règle Suricata générée à partir d'un indicateur IOC (IP de C2)
alert ip $HOME_NET any -> 198.51.100.23 any (msg:"IOC MATCH C2 infrastructure"; \
  reference:url,misp.example.org/events/view/1234; \
  classtype:trojan-activity; sid:9000123; rev:1;)

Vers Sigma, les IOC hôtes (hash, chemins de fichiers, clés de registre) alimentent des règles de détection endpoint plutôt que des signatures réseau.

Vers un EDR, les hashs et indicateurs de fichier s'intègrent en général via une API d'indicateurs personnalisés, à ne pas confondre avec les signatures propres au moteur EDR.

La boucle qui referme le pipeline, et que beaucoup d'équipes oublient, ce sont les sightings : à chaque fois qu'un indicateur déclenche réellement une alerte sur le terrain, ce « sighting » doit remonter vers MISP. Cette remontée renforce le score de confiance de l'IOC (un indicateur vu plusieurs fois en conditions réelles mérite plus de poids qu'un indicateur jamais revu depuis son import), et alimente en retour la décision d'expiration.

Mesurer la valeur d'un pipeline d'IOC

Un pipeline qui tourne sans mesure ne prouve rien. Trois indicateurs suffisent pour piloter la qualité dans la durée :

• Taux de match : proportion d'IOC qui déclenchent au moins un sighting sur une fenêtre donnée. Un taux durablement proche de zéro signale un flux qui n'apporte rien à votre contexte de menace.
• Taux de faux positifs : proportion d'IOC bloquants qui ont dû être retirés après investigation, faute de correspondre à une réelle activité malveillante. C'est le chiffre qui doit rester bas si les warninglists et le cycle de vie fonctionnent.
• Fraîcheur moyenne : âge médian des indicateurs actifs en base. Une base qui vieillit sans renouvellement perd de la valeur silencieusement, même si le volume total reste stable.

Un feed déjà curé plutôt qu'un flux brut à trier

Tout ce qui précède, la normalisation, les warninglists, le scoring, le cycle de vie, la boucle de sightings, représente un travail d'ingénierie récurrent, pas un projet qu'on termine une fois pour toutes. Chaque nouvelle source ajoute son lot d'exceptions à gérer et de faux positifs à filtrer.

C'est exactement ce que fournit le feed IOC de ThreatClaw : des indicateurs déjà normalisés et corroborés par plusieurs sources indépendantes, avec l'hygiène « ne jamais bloquer » intégrée en amont (RFC1918, top 1 million de domaines, infrastructures cloud légitimes) et des planchers de qualité qui écartent les indicateurs trop anciens ou trop peu corroborés. Vous branchez le flux sur votre détection ; le travail de tri, lui, est déjà fait.