Résumé

  • Une restriction IODEF s’applique à une classe et à ses descendants, mais un enfant peut explicitement la durcir ou l’assouplir. L’étiquette du dossier ne suffit donc pas à décrire chaque extrait.
  • Retirer un élément de sa hiérarchie peut lui faire perdre une condition héritée, même lorsque toutes les données factuelles sont conservées.
  • La conversion de l’ancien amber IODEF en TLP:AMBER actuel peut élargir le public destinataire. La ressemblance des noms ne constitue pas une équivalence de politique.

Le changement pourrait arriver dans une simple table de correspondance. Un outil reçoit la valeur amber, reconnaît une couleur familière et affiche TLP:AMBER. Aucun nom n’a été ajouté au rapport, aucune adresse n’a été modifiée. Pourtant, selon le vocabulaire de départ et celui d’arrivée, des clients peuvent désormais entrer dans le cercle des destinataires autorisés par l’étiquette affichée.

Il s’agit d’un scénario déduit de définitions publiques, pas d’une défaillance constatée dans un produit. Son intérêt tient précisément à sa banalité apparente : une opération présentée comme de la mise en forme peut prendre une décision sur la diffusion. Le rapport d’incident devient plus facile à lire, mais sa règle n’est plus nécessairement la même.

Deux vocabulaires, une différence concrète

Le registre IANA associé à IODEF conserve les alias de couleur de la spécification. amber y correspond à need-to-know, dont la portée est interne à l’organisation, pour les personnes ayant besoin de l’information. Les autres correspondances sont white avec public, green avec partner et red avec private. Ce sont les définitions du registre consulté pour cette analyse, et non des équivalences que l’on pourrait réinterpréter à volonté. Registre IANA.

Le TLP 2.0 de FIRST, version actuelle faisant autorité depuis août 2022, définit autrement le point qui nous intéresse. TLP:AMBER permet un partage nécessaire à la protection de l’organisation destinataire et de ses clients, au sein de ces deux populations. TLP:AMBER+STRICT limite la diffusion à l’organisation. La source peut ajouter des restrictions ; un élargissement au-delà de celles reçues demande son autorisation explicite. Les étiquettes gardent leur forme d’origine, même dans un texte français. FIRST, TLP 2.0.

Une conversion automatique vers le seul TLP:AMBER peut donc faire plus que moderniser un mot : elle peut ajouter les clients à une audience jusque-là interne. Cela ne prouve pas qu’un échange a effectivement divulgué des informations. Cela ne fournit pas non plus une table de conversion universellement approuvée. Les limites de l’organisation et les instructions supplémentaires restent à examiner. La conclusion est plus étroite : on ne peut pas déduire l’équivalence du seul rapprochement des couleurs.

Le dossier donne un sens à ses éléments

Le problème de version se superpose à une autre dépendance, celle de la structure. Le RFC 7970, publié en novembre 2016 et toujours indiqué comme Proposed Standard dans sa fiche officielle, définit IODEF version 2 : un modèle d’information et sa représentation XML pour les incidents et indicateurs de sécurité. Son rôle est de faciliter la coopération opérationnelle, pas de rendre chaque fragment indépendant du document qui l’entoure. RFC 7970, fiche officielle.

La section 3.3.1 décrit l’attribut restriction comme une consigne de divulgation émise par l’expéditeur. Elle vaut pour la classe concernée et ses enfants. Un enfant peut la remplacer par une consigne plus restrictive, mais aussi moins restrictive. En l’absence d’attribut, la valeur spécifiée par l’ancêtre le plus proche est héritée. La règle générale donne à la classe Incident une valeur par défaut de private.

Prenons un exemple fictif utilisant la classe Contact. Un incident explicitement private peut contenir un contact explicitement public. L’expéditeur peut ainsi indiquer que ce contact est diffusable sans rendre public le dossier entier. Inversement, un incident destiné à des partenaires peut contenir un contact private. La possibilité d’exprimer cet assouplissement local ne démontre pas que l’expéditeur possède tous les droits nécessaires à la divulgation : elle décrit ce que le format permet de communiquer. RFC 7970, section 3.3.1.

Cette souplesse évite un faux choix entre tout transmettre et tout retenir. Pour aider un autre opérateur, il peut suffire de lui communiquer le bon contact, sans lui fournir les détails sensibles qui l’accompagnent. Une interface qui réduit l’ensemble à la restriction la plus forte peut empêcher ce partage utile. Ce choix conservateur peut être une politique locale assumée ; il n’est pas la restitution exacte de toutes les règles propres aux éléments du dossier.

À l’autre extrême, afficher uniquement la règle du parent peut masquer un enfant plus protégé. Une seule pastille peut donc être trop permissive pour une partie du contenu et trop restrictive pour une autre, selon la méthode utilisée pour la choisir. La question pertinente n’est pas seulement de savoir si une étiquette existe, mais de préciser ce qu’elle résume.

L’absence n’est pas une convention

Un contact sans instruction locale offre un cas particulièrement éclairant. Dans un incident marqué partner, il hérite de la consigne applicable. Si un export conserve le nom, l’adresse et le rôle, mais abandonne la hiérarchie, le destinataire possède les faits sans disposer nécessairement de leur condition de diffusion. Aucune altération de ces faits n’est indispensable à cette perte de sens. Nous n’avons testé ici aucun logiciel d’export ; l’exemple explique une dépendance de la spécification.

Le mot default ajoute une difficulté. Lorsqu’il est explicitement utilisé comme valeur de restriction, il désigne une politique de divulgation préalablement convenue entre les parties. Ce n’est pas l’équivalent d’un attribut absent. Dans un cas, il faut retrouver un ancêtre ; dans l’autre, une convention. Les rabattre tous deux sur le réglage par défaut d’une application revient à remplacer deux références distinctes par une troisième, locale, qui n’était peut-être pas celle de l’expéditeur. IANA, Restriction.

Il convient aussi de reconnaître les limites du texte. Certaines descriptions de valeurs par défaut propres à des classes demandent une lecture attentive avec la règle générale et le schéma. Cette analyse s’appuie sur Contact et sur des attributs explicites ; elle ne fait pas de l’absence de restriction dans EventData ou Expectation un cas prétendument réglé sans ambiguïté. Un profil d’échange peut définir des valeurs explicites et documenter une interprétation commune sans se présenter comme l’arbitre de toutes les difficultés du RFC.

Valider une forme ne clôt pas l’interprétation

Le RFC 7970 distingue lui-même plusieurs niveaux de vérification. La section 4.3 exige un XML bien formé, recommande la conformité au schéma et rappelle que les contraintes supplémentaires du modèle d’information doivent également être prises en compte. Le passage d’un contrôle de schéma ne suffit pas à établir toute la validité sémantique du document.

L’erratum technique 5543, vérifié en novembre 2018, illustre cette distinction dans un domaine voisin. Il corrige la définition XML de Confidence afin d’autoriser le contenu numérique décrit par le texte. Cette correction rend la représentation cohérente avec cette possibilité ; elle ne crée pas une signification partagée des nombres. L’interprétation numérique demeure hors du périmètre défini par le RFC. Un nombre correctement reçu peut encore demander un accord avant de servir à une décision. Erratum 5543, RFC 7970.

Il serait donc abusif de transformer cette correction en garantie générale sur les restrictions de diffusion. Elle ne résout pas leurs valeurs par défaut. Plus largement, les erreurs de syntaxe, les ambiguïtés du modèle et les conventions manquantes ne réclament pas nécessairement le même responsable ni la même réponse.

La coopération continue après le transport

L’échange sous-jacent doit assurer confidentialité, intégrité et authenticité, selon le RFC 7970. Le format reconnaît néanmoins qu’une consigne de divulgation ne fournit aucun mécanisme technique garantissant son respect par le destinataire. Sa discussion de la vie privée concerne également les rapports conservés et les analyses dérivées. Des identifiants peuvent devenir plus révélateurs lorsqu’ils sont rapprochés ; des tiers peuvent être décrits sans avoir participé à l’échange. RFC 7970, section 9.

Le RFC 6545 consacré à RID développe, dans ses sections sur la vie privée et les profils de partage, l’importance des accords sur les catégories de données, leur protection et leur circulation ultérieure. Il envisage aussi qu’un résultat confirme une action de limitation de l’incident sans révéler l’identité de sa source. Une coopération utile ne demande donc pas toujours de communiquer le maximum d’information disponible. De même, protéger chaque liaison successive ne règle pas à lui seul la visibilité de bout en bout. Ces considérations de conception ne valent pas autorisation juridique contemporaine. RFC 6545, sections 9.5–9.6.

L’enjeu pratique est de traiter l’extrait comme une nouvelle sortie à examiner. Son audience correspond-elle à celle voulue ? La restriction effective reste-t-elle explicable ? La convention invoquée par default concerne-t-elle encore les destinataires ? Une exception locale a-t-elle été conservée sans être étendue aux éléments voisins ? Ce sont des questions d’exploitation proposées ici, pas des exigences supplémentaires attribuées au RFC.

La distinction de Lu Heng entre représentation symbolique et pouvoir effectif aide à situer le problème. L’étiquette indique une frontière. Le programme qui extrait, la personne qui approuve les destinataires et les pratiques de l’organisation réceptrice participent à son application réelle. Cette lecture n’attribue pas à Lu Heng une analyse d’IODEF ; elle utilise son cadre pour repérer où se prend une décision que le vocabulaire peut rendre invisible. Lu Heng, sur les couches de réalité.

Partager moins de données n’est pas automatiquement partager avec plus de discernement. Un petit extrait privé de sa règle peut être moins maîtrisé qu’un dossier dont les limites sont explicites. L’objectif n’est pas d’interdire l’extraction, mais de faire voyager les conditions nécessaires avec ce que l’on choisit de transmettre.