TLP 2.0 : partager la threat intelligence sans fuite de données

TLP 2.0 indique à qui une information peut être redistribuée. Pour une équipe de threat intelligence, ce marquage devient utile lorsqu’il accompagne réellement les rapports, les indicateurs et les copies envoyées aux destinataires. Une étiquette perdue pendant un export peut laisser un analyste interpréter comme public un renseignement reçu pour un cercle limité.

La discussion du 11 septembre 2026 sur les débuts d’un analyste CTI pose notamment la question des services rendus aux différentes équipes. Ce guide prolonge ce besoin par le volet diffusion. Le fil ne porte pas spécifiquement sur TLP : il ne constitue donc pas une preuve d’un regain d’intérêt pour ce standard.

L’objectif pratique est de préparer une copie utile pour le bon destinataire, d’en conserver les conditions de partage et de pouvoir la corriger. Le workflow proposé ci-dessous complète le standard par des choix d’organisation explicites.

Comprendre les limites de partage de TLP 2.0

Le standard FIRST définit ces périmètres :

• TLP:RED : destinataires individuels uniquement, sans redistribution.
• TLP:AMBER : organisation et clients, selon le besoin d’en connaître.
• TLP:AMBER+STRICT : même principe, sans clients extérieurs à l’organisation.
• TLP:GREEN : communauté concernée, sans diffusion publique.
• TLP:CLEAR : diffusion libre, sous réserve du droit d’auteur.

Les libellés ne se traduisent pas. TLP ne définit ni licence, ni chiffrement, ni classification légale. Élargir le partage exige la permission de la source. Les documents conservent marquages et restrictions sur chaque page.

Le guide du NCSC néerlandais explique aussi le placement des marquages dans les messages et documents. Dans votre workflow, contrôlez la copie exportée plutôt que de supposer que l’écran d’édition montre tout ce que verra le destinataire.

Cette distinction évite une erreur de conception : votre système documentaire doit gérer séparément le destinataire permis, la protection du fichier et les droits d’utilisation. Un rapport transmis par un canal sécurisé peut arriver chez une personne qui ne devait pas le recevoir. Une information publique peut, inversement, nécessiter une attribution ou des précautions avant de réutiliser ses illustrations.

Distinguer la source, le destinataire et son fournisseur

Un prestataire de sécurité n’appartient pas automatiquement à l’organisation de son client. Le sens de la relation compte. Un CSIRT qui sert une entreprise a cette entreprise pour cliente ; l’entreprise qui reçoit un rapport ne peut pas traiter chacun de ses fournisseurs comme son propre client.

Les cas d’usage FIRST précisent que transmettre de l’AMBER ou de l’AMBER+STRICT à un prestataire extérieur demande la permission de la source. Celle-ci peut figurer dans un accord permanent, une réponse à une demande ou des instructions jointes. Ils expliquent aussi comment séparer des portions partageables d’un document plus restreint : l’ensemble conserve le marquage le plus restrictif.

Pour éviter une découverte en pleine investigation, établissez une fiche des relations de partage. Elle décrit les équipes internes, les sociétés distinctes, les fournisseurs intervenant en réponse à incident et les accords déjà disponibles. Faites vérifier les cas ambigus par les responsables de ces accords avant de les automatiser.

Une équipe multinationale peut utiliser les mêmes adresses de messagerie sans avoir un périmètre organisationnel évident. Un espace de collaboration peut accueillir des invités, des consultants et des filiales. Vérifiez qui peut lire le canal au moment de l’envoi, plutôt que de déduire le droit de partage de son nom.

Préparer trois objets distincts dans le dossier

Le workflow proposé conserve une copie reçue, une fiche d’analyse et une copie destinée au partage. Ces objets ont des usages différents et doivent rester reliés par un identifiant de dossier.

La copie reçue conserve le texte, les pièces jointes, la date et les instructions de la source. Elle permet de revenir à la formulation exacte si un analyste conteste une restriction ou si la source corrige son renseignement. L’accès à cette copie doit suivre votre politique interne.

La fiche d’analyse relie le renseignement aux observations locales. Elle peut devenir plus sensible que le document initial : vous y ajoutez des noms de systèmes, des utilisateurs, des extraits de journaux et les résultats d’une investigation. Ne présumez pas que le statut de la source publique s’étend à ces ajouts.

La copie destinée au partage répond au besoin du destinataire. Elle peut contenir uniquement un indicateur contextualisé et une action de vérification. Sa préparation évite de transférer tout un fil d’enquête pour obtenir une réponse sur un domaine. Le guide du partage CTI entre organisations présente les communautés possibles ; cette séparation traite le contenu effectivement envoyé.

Réduire les données sans détruire la valeur analytique

La minimisation consiste à retirer ce qui n’est pas nécessaire à l’action prévue. Elle demande toutefois de conserver le contexte qui empêche une mauvaise interprétation. Un domaine seul peut être insuffisant si la détection ne concerne qu’un chemin particulier ou une période passée.

Commencez par définir l’action du destinataire : rechercher une connexion, vérifier une configuration, examiner une pièce jointe ou confirmer une observation. Pour chaque champ, demandez s’il contribue à cette action et si une version moins précise suffirait.

Un identifiant de compte interne peut devenir un rôle générique. Un extrait de journal peut être réduit aux champs requis. Un horodatage peut parfois perdre une précision inutile, mais cette transformation doit être signalée si elle change la capacité de corrélation. Le fichier original demeure accessible aux personnes habilitées.

Examinez les révélations indirectes : domaine interne dans une URL, numéro de dossier dans une capture, adresse personnelle dans le nom d’un fichier, commentaire caché dans un document. La copie destinée au partage doit être contrôlée après sa génération, car les données ajoutées par l’outil d’export peuvent différer du texte affiché.

Ces gestes ne garantissent pas l’anonymat et ne remplacent pas une autorisation de diffusion. Le guide NIST SP 800-150 situe le partage dans un dispositif plus large comprenant objectifs, périmètres, règles de publication et relations entre participants. Le marquage fonctionne mieux lorsque ces décisions existent déjà.

Exemple : demander de l’aide sans transférer tout le dossier

Le scénario suivant est fictif. Une équipe reçoit un rapport AMBER+STRICT sur un service externe suspect. Elle dispose d’un contrat avec un prestataire de réponse à incident, mais l’accord de partage avec la source ne mentionne pas ce prestataire.

L’analyste prépare d’abord la question précise : il souhaite savoir si des événements internes correspondent à la période et au comportement décrits. Il identifie la portion du rapport qui serait nécessaire au prestataire et sépare les éléments propres à l’entreprise.

La demande adressée à la source peut prendre cette forme :

Référence du renseignement : dossier SOURCE-42, version 2
Usage demandé : assistance à l’examen de journaux internes
Destinataire proposé : société et équipe nommément désignées
Contenu nécessaire : indicateurs et période d’observation
Contenu exclu : identité de votre source et annexes contextuelles
Conditions proposées : accès limité à l’équipe mandatée
Question : autorisez-vous cette transmission et sous quelles conditions ?

Ce modèle est une proposition de demande, pas un texte normatif. Une autorisation reçue doit être conservée avec la version à laquelle elle s’applique. Si elle limite les informations transmises, le rédacteur prépare une copie conforme à cette portée ; il ne remplace pas simplement le libellé du document complet.

Pendant l’attente, les travaux internes autorisés peuvent continuer. Le demandeur peut aussi décrire au prestataire un besoin générique ne révélant pas le renseignement restreint, à condition de vérifier qu’aucun détail ne le reconstitue. L’existence d’une urgence doit déclencher l’escalade prévue dans les accords, sans inventer une dérogation automatique.

Conserver les instructions dans les outils et les exports

Le risque de perte apparaît à chaque transformation : rapport vers ticket, ticket vers messagerie, objet d’une plateforme vers fichier CSV, puis fichier vers outil de détection. Faites de ces passages une liste explicite avant de construire des règles automatiques.

Un modèle local peut associer à chaque observation les champs suivants :

reference_source
version_source
marquage_recu
restrictions_complementaires
reference_autorisation
destinataires_valides
date_de_verification
copie_partagee_et_version
responsable_du_partage

Ces noms sont indicatifs : ils ne prétendent pas décrire un schéma TLP officiel. L’objectif est de garder les informations nécessaires lorsque le contenu change de format. Une intégration qui ne transporte pas les restrictions doit signaler cette perte avant de poursuivre la redistribution.

Pour les pipelines STIX et TAXII, testez l’importation et l’exportation avec des objets synthétiques portant plusieurs restrictions. Vérifiez la copie reçue par le système final, y compris les commentaires et les pièces jointes. La présence d’un champ de marquage dans l’outil d’origine ne prouve pas qu’un connecteur le préserve.

Évitez une règle qui transforme toute valeur inconnue en information publique. Une mise à jour de connecteur, un champ vide ou une variante mal saisie doit produire un cas à vérifier. Le système peut conserver l’objet pour l’analyse interne tout en suspendant sa redistribution.

Organiser la revue avant l’envoi

Une revue légère fonctionne si elle examine la copie réelle et son destinataire. Pour une diffusion répétitive, documentez un parcours approuvé avec les responsables appropriés, puis faites remonter les exceptions. Pour un nouveau partenaire ou un contenu plus sensible, ajoutez une seconde lecture ciblée.

Le réviseur répond à quelques questions concrètes : l’objet respecte-t-il les instructions reçues ? Les pièces jointes ont-elles été examinées ? Le canal contient-il des invités ? La copie inclut-elle des données locales ajoutées depuis la dernière validation ? Peut-on retrouver la source et l’autorisation sans fouiller dans plusieurs conversations ?

Attribuez les rôles. Le propriétaire du dossier décide du contenu nécessaire, le responsable du canal connaît ses membres et la personne chargée de l’accord confirme la portée du partage. Une case « approuvé » anonyme ne permet pas de résoudre une contradiction.

Le guide OPSEC des scans d’URL confidentiels examine cette frontière pour les outils d’investigation en ligne.

Le cadre éthique de la collecte OSINT complète cette préparation pour les données provenant de sources ouvertes. Une collecte publique et une diffusion pertinente sont deux décisions qu’il faut documenter séparément.

Réagir lorsqu’une mauvaise copie a circulé

Préparez cette procédure avant le premier incident. Commencez par identifier la version envoyée, le canal, les destinataires effectifs et les automatismes susceptibles d’avoir produit d’autres copies. Suspendez les envois concernés pendant la vérification.

Informez les responsables appropriés et la source selon les accords applicables. Décrivez ce qui a effectivement été transmis, sans supposer qu’un message supprimé n’a jamais été consulté. Demandez aux destinataires de remplacer ou supprimer les copies concernées et de vérifier leurs propres relais.

Conservez les confirmations et les limites connues : copie locale impossible à rappeler, export vers un autre outil, accès d’un invité pendant une période donnée. Une suppression dans votre interface ne prouve pas la suppression partout. Cette précision permet de décider des suites proportionnées.

Après correction, rejouez le parcours avec un document de test. L’erreur venait-elle d’un droit de canal, d’une pièce jointe oubliée, d’un connecteur ou d’une instruction ambiguë ? Corrigez le point qui a permis la diffusion, puis vérifiez le résultat. Évitez d’ajouter une validation générale qui ralentit tous les échanges sans traiter la cause.

Vérifier le dispositif sur un échange réel

Choisissez un parcours fréquent, par exemple un rapport reçu qui devient une demande au prestataire SOC. Suivez la copie de bout en bout et notez où ses instructions disparaissent. Testez également une correction de source : le destinataire final retrouve-t-il la nouvelle version ?

Lorsqu’un indicateur partageable nécessite un contexte de réputation, le guide d’enrichissement IOC pour le triage SOC montre comment l’ajouter au travail d’analyse. Vérifiez d’abord ce que la requête transmet au service externe. Un workflow de partage maîtrisé conserve à la fois le contexte utile, les conditions de diffusion et la possibilité de corriger les copies.