Flux STIX/TAXII : guide opérationnel pour OpenCTI, MISP et pipelines SIEM

Votre SIEM ingère déjà les logs. Votre pare-feu bloque déjà les IP connues comme malveillantes. Le gap est souvent le contexte de menace structuré — qui se cache derrière l'indicateur, à quelle campagne il appartient, s'il est encore actif. STIX 2.1 et TAXII 2.1 existent pour déplacer ce contexte entre systèmes sans exports CSV ni pièces jointes par email.

isMalicious publie des données de menace sous forme d'objets STIX 2.1 via un serveur TAXII 2.1. Les indicateurs arrivent avec des relations vers familles de malware, acteurs de menace, campagnes et patterns MITRE ATT&CK. Vous vous authentifiez avec votre clé API sur l'URL de discovery et interrogez les collections selon le planning que votre plateforme supporte.

Ce guide couvre l'opérationnel : connexion OpenCTI et MISP, choix entre polling de flux et appels API d'enrichissement, gestion des scores de confiance, vieillissement des indicateurs obsolètes, et pourquoi l'ingestion automatisée ne remplace pas la revue analyste.

Ce que le flux apporte

Le flux STIX/TAXII livre des objets lisibles par machine, pas seulement des listes d'IOC plates.

Types d'objets inclus :

| Type STIX | Contenu | Usage typique | |-----------|---------|---------------| | indicator | IP, domaine, URL, hash avec pattern | Règles de bloc, corrélation SIEM | | malware | Nom de famille, labels | Contexte d'alerte, requêtes de chasse | | threat-actor | Attribution de groupe | Documentation de cas, reporting | | campaign | Opération nommée liant des indicateurs | Périmètre d'incident, timeline | | attack-pattern | Référence technique MITRE ATT&CK | Ingénierie de détection | | relationship | Liens entre les éléments ci-dessus | Traversée de graphe dans le TIP |

Les collections regroupent les objets par catégorie — indicateurs phishing, IP C2, hashes malware — pour s'abonner à ce qui correspond à votre cas d'usage.

Transport : document de discovery TAXII 2.1 → API roots → collections → objets/manifest. Votre client interroge les objets nouveaux ou mis à jour depuis le dernier checkpoint.

Authentification : clé API passée à l'URL de discovery. Les mêmes identifiants fonctionnent pour l'API REST si vous voulez aussi de l'enrichissement à la demande.

Consommateurs compatibles : MISP, OpenCTI, Anomali ThreatStream, ThreatConnect, et tout client custom sur taxii2client ou bibliothèques équivalentes.

Polling de collections vs API d'enrichissement

Les équipes confondent souvent ces deux patterns. Ils résolvent des problèmes différents.

Polling de collections (ingestion de flux)

Quand l'utiliser : Vous voulez un flux régulier d'indicateurs vers votre TIP, SIEM ou SOAR sans uploads manuels.

Comment ça marche :

1. Configurer votre TIP pour se connecter à l'URL de discovery TAXII avec votre clé API.
2. Sélectionner les collections pertinentes (domaines phishing, IP C2, etc.).
3. Définir un intervalle de polling — horaire pour les collections prioritaires, quotidien pour les ensembles plus larges.
4. Mapper les indicateurs ingérés vers vos objets internes (événements MISP, indicateurs OpenCTI, lookups Splunk).
5. Appliquer vos règles de confiance et de vieillissement avant de promouvoir les indicateurs vers les blocklists.

Forces : Mains libres une fois configuré. Les objets incluent relations et contexte. Scale à des milliers d'indicateurs par jour.

Limites : Vous obtenez ce que la collection contient au moment du poll. Un domaine devenu bénin hier peut rester dans votre TIP jusqu'au prochain rafraîchissement. La latence dépend de votre intervalle.

API d'enrichissement (lookup à la demande)

Quand l'utiliser : Une alerte cite une IP ou un domaine jamais vu. Vous avez besoin d'un verdict, WHOIS, historique DNS et contexte d'hébergement maintenant — pas au prochain cycle de poll.

Comment ça marche :

1. Votre playbook SOAR ou réponse adaptive SIEM appelle GET /check?query=<indicateur> avec les identifiants API.
2. La réponse inclut verdict de réputation, catégories, WHOIS et métadonnées associées.
3. Le playbook bifurque sur le verdict : escalade, bloc ou clôture.

Forces : Données fraîches pour l'indicateur sous investigation. Réponse en moins d'une seconde pour le triage inline.

Limites : Un indicateur par appel (ou endpoints bulk pour les lots). Ne peuple pas le graphe TIP avec les relations de campagne sauf si vous ingérez aussi les flux.

Utiliser les deux ensemble

La plupart des setups matures font exactement cela :

• Flux peuplent le TIP avec une couverture d'indicateurs de base et des graphes de relations.
• Enrichissement API gère les lookups au moment de l'alerte pour les indicateurs absents de toute collection.
• Revue analyste promeut les indicateurs confirmés du TIP vers blocklists pare-feu et règles de corrélation SIEM.

Ni l'un ni l'autre ne remplace l'autre. Flux sans enrichissement = indicateurs nouveaux manqués à l'alerte. Enrichissement sans flux = l'analyste repart de zéro à chaque ticket.

Connexion OpenCTI

OpenCTI supporte nativement les flux TAXII 2.1. La page d'intégration OpenCTI documente la configuration du connecteur.

Étapes de setup :

1. Dans OpenCTI, aller à Data → Ingestion → TAXII Feeds et créer un flux.
2. Saisir l'URL de discovery TAXII isMalicious et votre clé API.
3. Sélectionner les collections à souscrire. Commencer par une (ex. indicateurs phishing) avant d'en ajouter.
4. Définir l'intervalle de polling. Horaire est un défaut raisonnable pour les collections opérationnelles.
5. Mapper les types d'objets STIX vers les entités OpenCTI. Les indicateurs deviennent des objets Indicator ; les relations peuplent le graphe de connaissances.
6. Configurer les définitions de marquage TLP si votre organisation l'exige.

Notes opérationnelles :

• OpenCTI déduplique les indicateurs par pattern. Ré-ingérer la même IP met à jour l'objet existant.
• Utiliser les tableaux de bord OpenCTI pour visualiser les graphes de relations — une IP C2 liée à une famille malware et une campagne vaut mieux que l'IP seule.
• Pour comparer OpenCTI comme plateforme vs isMalicious comme source de données, voir /vs/opencti.

Ce qu'OpenCTI ne fait pas pour vous : décider quels indicateurs ingérés deviennent des règles pare-feu. Cette promotion exige encore une approbation analyste ou un seuil de confiance que vous définissez.

Connexion MISP

MISP consomme les flux TAXII via son mécanisme de sync intégré ou le bridge TAXII MISP.

Étapes de setup :

1. Dans MISP, naviguer vers Sync Actions → List TAXII Servers (ou plugin TAXII selon votre version).
2. Ajouter l'URL de discovery isMalicious avec authentification par clé API.
3. Mapper les collections vers les feeds MISP. Chaque collection devient un feed que MISP interroge.
4. Configurer tags par défaut et niveaux de distribution pour les événements ingérés.
5. Activer la sync pull sur un planning (cron ou scheduler MISP).

Notes opérationnelles :

• MISP stocke les indicateurs ingérés comme événements avec attributs. Les relations STIX peuvent s'aplatir en liens d'attributs selon version et plugin.
• Utiliser galaxies et taxonomies MISP pour classifier les données ingérées.
• MISP excelle au partage d'indicateurs vers les partenaires. Si vous ingérez depuis isMalicious et voulez partager des sous-ensembles curatés avec un ISAC, MISP est le hub.
• Pour le contexte de comparaison plateforme, voir /vs/misp.

Astuce corrélation : Activer la corrélation MISP pour voir quand un indicateur nouvellement ingéré correspond à un attribut d'un événement créé manuellement — c'est souvent ainsi que les données de flux se connectent à une investigation active.

Patterns d'intégration SIEM

Toutes les équipes ne font pas tourner un TIP complet. Si le SIEM est la cible principale :

Pattern A : TAXII → TIP → table de lookup SIEM

Ingérer les flux dans OpenCTI ou MISP, puis exporter les indicateurs confirmés vers une table de lookup SIEM (KV store Splunk, transform Elastic, liste d'indicateurs Microsoft Sentinel). Couche de curation entre flux brut et règles de bloc production.

Pattern B : TAXII → SIEM direct (limité)

Certaines plateformes SIEM supportent l'ingestion TAXII nativement. Utile pour petites équipes sans TIP, mais perte des graphes de relations et workflows de revue analyste.

Pattern C : Enrichissement API en réponse adaptive

Ignorer l'ingestion de flux pour les cas d'alerte. Configurer votre SIEM pour appeler l'API isMalicious quand une alerte contient une IP ou un domaine externe. Chemin le plus rapide vers la valeur, mais pas de graphe historique.

Recommandation : Commencer par le Pattern C pour l'enrichissement immédiat des alertes. Ajouter le Pattern A quand l'équipe veut des blocklists curatées et du contexte relationnel.

Confiance, scoring et faux positifs

Les indicateurs STIX portent un champ confidence (0–100). Traitez-le comme un indice, pas un verdict.

Seuils pratiques :

| Confiance | Action suggérée | |-----------|-----------------| | 80–100 | Auto-ingestion TIP ; éligible blocklist après revue | | 50–79 | Ingestion TIP ; approbation analyste avant bloc | | Sous 50 | Journalisation seule ; pas de bloc sans preuve additionnelle |

Ajustez selon votre tolérance aux faux positifs. Une SOC finance peut exiger 90+ pour l'auto-bloc ; un environnement de recherche peut tout ingérer pour la chasse.

Croiser avant de bloquer. Même les indicateurs haute confiance méritent une vérification rapide :

• L'IP est-elle sur un CDN ou hébergement partagé ? (Bulk Check aide pour les lots.)
• WHOIS ou historique DNS suggèrent-ils un propriétaire légitime ?
• L'indicateur est-il déjà apparu dans votre environnement sans incident ?

Les flux accélèrent la question « avons-nous déjà vu ça ? ». Ils n'éliminent pas « devons-nous bloquer ? »

Vieillissement et expiration des indicateurs

Les indicateurs vieillissent. Un attaquant abandonne une IP C2, un domaine phishing est retiré, un hôte compromis est remédié. Si votre TIP n'expire jamais les anciennes entrées, les blocklists grossissent indéfiniment et les faux positifs s'accumulent.

Modèle de politique de vieillissement :

Indicateurs IP :
  - Fenêtre de refresh : revu dans les 30 jours → garder actif
  - Non rafraîchi en 30 jours → marquer inactif, retirer des blocklists
  - Non rafraîchi en 90 jours → supprimer du TIP

Indicateurs domaine :
  - Fenêtre de refresh : 60 jours (les domaines persistent plus que les IP)
  - Non rafraîchi en 60 jours → marquer inactif
  - Non rafraîchi en 180 jours → supprimer

Indicateurs hash :
  - Conserver indéfiniment si lié à une famille malware nommée
  - Expirer les hashes non attribués après 90 jours

Implémentez cela dans les règles de decay du TIP (OpenCTI a des configurations de decay ; MISP utilise des modèles de decay) ou dans le script d'export vers le pare-feu.

Rôle du flux dans le vieillissement : Chaque poll peut mettre à jour les timestamps modified. Si un indicateur disparaît de la collection, c'est un signal qu'il n'est peut-être plus actif — mais une absence sur un poll n'est pas une preuve. Attendre deux absences consécutives avant expiration.

Ce que les flux ne remplacent pas

L'ingestion STIX/TAXII automatisée ne remplace pas :

• La curation analyste. Quelqu'un doit décider quels indicateurs deviennent des règles de bloc production vs entrées chasse uniquement.
• La télémétrie interne. Les données de flux disent qu'une IP est mauvaise globalement ; vos logs disent qu'elle a parlé à votre contrôleur de domaine.
• La sandbox. Les objets malware STIX décrivent des familles connues ; ils n'analysent pas la pièce jointe spécifique du ticket du jour.
• La réponse à incident. Les flux apportent du contexte à l'investigation ; ils ne la contiennent pas.

L'objectif est de réduire le copier-coller manuel d'IOC et standardiser le contexte entre outils — pas de retirer les humains de la boucle.

Checklist de démarrage

1. Obtenir les identifiants API depuis votre compte isMalicious (docs API).
2. Pointer un client TAXII vers l'URL de discovery et lister les collections disponibles.
3. Souscrire à une collection dans votre TIP (OpenCTI ou MISP) avec polling horaire.
4. Ingérer une semaine en mode surveillance — pas de changement blocklist.
5. Mesurer : combien d'indicateurs ingérés correspondaient à des alertes existantes ? Combien étaient nouveaux ?
6. Définir seuils de confiance et règles de vieillissement.
7. Ajouter l'enrichissement API à un playbook SOAR pour les lookups au moment de l'alerte.
8. Promouvoir les indicateurs approuvés vers la table de lookup SIEM ou EDL pare-feu.

Les flux STIX/TAXII transforment les données de menace en pipeline plutôt qu'en pièce jointe. Le setup prend un après-midi ; la discipline opérationnelle — seuils de confiance, vieillissement, revue analyste — est ce qui maintient le pipeline fiable mois après mois.