Résumé
- La RFC 3067 demandait un objet commun qui garde séparés événement observable, éléments de preuve, qualification d’incident, dommage réel, impact possible et confiance.
- Le dossier devait évoluer de l’alerte à l’archive, en conservant restrictions par élément, chaîne de garde et actions des CSIRT précédents.
Avant le schéma, une théorie de la passation
Publiée en février 2001 comme document informatif, la RFC 3067 décrivait les exigences TERENA pour l’IODEF. Les attaques traversaient pays, langues, cultures et circonscriptions ; les CSIRT devaient partager alertes, enquêtes, statistiques et expérience postérieure.
L’objet prévu n’était pas une simple enveloppe machine. Il devait être créé et autorisé par des humains, rester lisible avec des outils ordinaires et aider les systèmes de traitement. Un message de détection pouvait ouvrir le récit, mais la description d’incident devait porter ce que plusieurs équipes apprenaient, décidaient et faisaient dans le temps.
Le vocabulaire séparait donc événement, preuve, incident, dommage, impact et confiance. Un événement observable pouvait déclencher une alerte. Une preuve soutenait une conclusion. Un incident impliquait une violation. Le dommage décrivait un effet réel sur un système ; l’impact, les conséquences pour une communauté. La confiance indiquait la force du rapport. Ces mots n’étaient pas des synonymes rangés dans plusieurs colonnes.
L’alerte ne possédait pas la conclusion
Trois échecs de connexion pouvaient produire une alerte sans prouver attaquant, compromission, dommage ni impact. Un détecteur statistique estimait une probabilité ; un CSIRT escaladait selon sa politique ; un autre corrélait avec une campagne. L’objet commun devait conserver chaque étape sans transformer le premier signal en verdict final.
La RFC exigeait donc un degré de confiance. Elle permettait un impact possible issu d’une liste normalisée ou, faute de référence, de l’expérience d’un membre responsable. Un type encore inconnu pouvait recevoir un nom temporaire propre à l’implémentation. La structure servait l’agrégation ; le texte libre gardait ce qui n’était pas stabilisé.
Le dossier devait croître pendant l’enquête. Les premiers détails étaient minces ; remédiation et analyse ajoutaient attaque, preuves, acteurs, cibles, effets et actions. Les décisions des CSIRT antérieurs restaient visibles pour que le suivant sache ce qui restait à faire. L’objet était un dossier vivant, non une alarme figée.
Chaque compartiment avait son public
Le partage promettait la coopération mais risquait la fuite. Mots de passe, identifiants et matériaux forensiques pouvaient cohabiter. La RFC demandait une restriction d’accès pour chaque élément, pas une seule bannière sur tout le rapport.
Une équipe pouvait voir le type d’attaque et le réseau sans voir l’identité de la victime ni une preuve scellée. Les statistiques pouvaient conserver un impact agrégé en retirant le détail opérationnel. Les preuves pouvaient rester dans un dépôt externe avec d’autres droits et une autre garde.
Le chiffrement ne suffisait pas : un système autorisé pouvait déchiffrer puis transmettre mal. La marque de restriction devait voyager avec l’information. L’échange était normalement initié et approuvé par un opérateur ou un responsable ; la lisibilité machine assistait l’autorité humaine, elle ne la remplaçait pas.
La preuve exigeait une histoire de garde
La RFC citait journaux, mémoire, caches, statistiques du noyau et fichiers temporaires comme preuves possibles. Elle exigeait intégrité, chiffrement si nécessaire, chaîne de garde documentée et conformité au droit local. Le destinataire avait besoin des octets, mais aussi du collecteur, du moment, des conditions et des transformations. La RFC 3227 détailla ensuite volatilité, modification minimale et documentation. Aucun format ne pouvait garantir une recevabilité juridique partout.
Le temps avait la même limite. Les étapes devaient être datées en heure locale avec décalage UTC pour permettre normalisation et corrélation. Cela n’effaçait ni horloge fausse, ni délai de collecte, ni causalité mal attribuée.
La RFC 5070 transforma ces exigences en modèle XML standard en 2007, tout en refusant une définition universelle de l’incident et en qualifiant le format de transport. La RFC 7970 la remplaça en 2016. Le schéma devint concret ; l’autorité resta distribuée entre créateur, collecteur, organisation émettrice, équipe réceptrice et droit applicable.
Sources
- https://www.rfc-editor.org/rfc/rfc3067.html
- https://www.rfc-editor.org/info/rfc3067/
- https://datatracker.ietf.org/doc/rfc3067/
- https://www.rfc-editor.org/rfc/rfc2350.html
- https://www.rfc-editor.org/rfc/rfc3227.html
- https://www.rfc-editor.org/rfc/rfc5070.html
- https://www.rfc-editor.org/rfc/rfc7970.html
- https://www.iana.org/assignments/xml-registry
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
