Publiée en juin 1998, la RFC (1) 2350 n’a jamais été remplacée. Le gabarit de sept parties qu’elle propose est devenu le document qui dit à l’extérieur qui est une équipe de sécurité, ce qu’elle traite et comment la joindre.
L’essentiel
La RFC 2350 porte le numéro BCP (2) 21 dans la série des bonnes pratiques de l’IETF (3). Elle a été écrite par Nevil Brownlee et Erik Guttman, au sein du groupe de travail GRIP, et publiée en juin 1998. Vingt-huit ans plus tard, elle reste la version de référence : aucune RFC ne l’a remplacée, et la page de la série en recense trois errata.
Son objet est simple. Elle exprime ce que la communauté Internet attend d’un CSIRT (4), dénomination équivalente au terme plus ancien de CERT (5), et elle fournit un gabarit que l’équipe remplit et publie. Ce document est aujourd’hui exigé par l’accréditation du Trusted Introducer, attendu au dossier d’adhésion au FIRST (6), et repris comme exigence minimale par le modèle de maturité SIM3 (7).
- Sept parties, une trentaine de rubriques, un exemple entièrement rempli fourni en annexe.
- Aucune réponse imposée : le texte décrit ce que chaque sujet signifie, pas ce qu’il faut y répondre.
- Une seule obligation de fond : publier. Le texte qualifie de mandatory le fait que les équipes publient ces informations vers leur constituency, c’est à dire le périmètre qu’elles servent.
- Remplir et publier ce document est un impératif pour les équipes accréditées par le Trusted Introducer depuis mai 2009.
- Le paramètre O-5 de SIM3 reprend son contenu minimal, coordonnées, plages de service, description des services et politique de divulgation, avec une version anglaise publique.
- Le texte a vieilli sur la cryptographie et sur les liens cités, pas sur les questions qu’il pose.
Le travail que demande une RFC 2350 n’est pas un travail de rédaction, c’est un travail de décision. Une fois le périmètre servi, l’autorité, le niveau de support et la politique de divulgation arrêtés, le document s’écrit en une journée. C’est aussi pour cela qu’il constitue un bon point de départ pour une équipe qui structure son activité.
Ce que la RFC 2350 est, et ce qu’elle n’est pas
Le texte pose lui-même sa limite dès le résumé : il n’est pas possible de définir un jeu d’exigences qui conviendrait à toutes les équipes, mais il est possible et utile de lister les sujets qui intéressent les communautés servies. Aucun sujet n’est donc assorti d’une bonne réponse. Chacun est discuté pour ce qu’il signifie, à charge pour l’équipe de trancher.
Ce qui n’est pas laissé au choix, c’est la publication. Le texte est explicite : quel que soit le type d’équipe, la constituency doit connaître ses politiques et ses procédures, et il est donc obligatoire que l’équipe les publie. Le même passage précise que tout n’a pas vocation à être public : il n’est pas nécessaire de comprendre le fonctionnement interne d’une équipe pour lui signaler un incident.
Le document contient deux annexes qui font l’essentiel de son usage pratique. L’annexe D donne le gabarit en sept parties. L’annexe E donne un exemple entièrement rempli, celui d’un CERT universitaire fictif. Cet exemple est assorti d’une réserve explicite : il ne vaut pas approbation par le groupe de travail ni par l’IETF d’un jeu particulier de procédures ou de politiques, et le texte précise que son usage tel quel n’est ni obligatoire, ni même approprié dans la plupart des cas.
Les remerciements de la RFC citent Don Stikvoort pour son aide dans la refonte de la description des services d’une équipe de réponse à incident. C’est le même auteur qui écrira dix ans plus tard le modèle de maturité SIM3, dont le paramètre O-5 reprend aujourd’hui le contenu minimal d’une RFC 2350.
Le gabarit en sept parties
La structure de l’annexe D est conçue pour communiquer les politiques et les procédures d’une équipe à sa constituency comme aux organisations extérieures, en particulier aux autres équipes.
| Partie | Rubriques |
|---|---|
| 1. Informations sur le document | Date de dernière mise à jour, liste de diffusion des notifications, emplacements où le document est accessible |
| 2. Informations de contact | Nom de l’équipe, adresse, fuseau horaire, téléphone, télécopie, autres moyens de télécommunication, adresse électronique, clés publiques et informations de chiffrement, membres de l’équipe, autres informations, points de contact |
| 3. Charte | Énoncé de mission, constituency, parrainage et rattachement, autorité |
| 4. Politiques | Types d’incidents et niveau de support, coopération et divulgation de l’information, communication et authentification |
| 5. Services | Réponse à incident, déclinée en triage, coordination et résolution, puis activités proactives |
| 6. Formulaires de signalement | Les formulaires proposés à ceux qui signalent un incident, et la façon de les utiliser |
| 7. Clauses de non-responsabilité | L’avertissement sur les limites du document et de l’information diffusée |
Une différence mérite d’être relevée entre les deux annexes. Le gabarit de l’annexe D s’arrête, pour la première partie, à trois rubriques. L’exemple rempli de l’annexe E en ajoute une quatrième, l’authentification du document, qui indique où trouver les signatures des versions publiées. C’est cette version à quatre rubriques que reprennent la plupart des documents publiés aujourd’hui.
Le fuseau horaire, demandé en partie 2, sert à coordonner les incidents qui traversent plusieurs fuseaux. Les plages de service, demandées dans la même partie avec le calendrier des jours fériés, disent si une astreinte existe. Ce sont deux informations qu’une équipe pair cherche en premier, et leur absence se remarque immédiatement.
Les décisions que le document oblige à prendre
La difficulté d’une RFC 2350 ne tient pas à sa rédaction. Elle tient à quatre décisions que le texte oblige à formuler, et qui sont rarement écrites ailleurs.
La constituency
Le texte demande de tracer un périmètre autour du groupe servi, puis d’expliquer dans la partie Politiques comment sont traitées les demandes venues de l’extérieur de ce périmètre. Une équipe qui choisit de ne pas publier sa constituency doit exposer le raisonnement qui la conduit à ce choix, le cas typique étant celui d’une équipe commerciale liée par des contrats clients. Le texte prévoit aussi le recouvrement de périmètres, lorsqu’un opérateur sert des clients qui disposent eux-mêmes d’une équipe.
L’autorité
Le texte distingue le périmètre de la constituency et le périmètre de contrôle, et demande d’identifier le second. Une équipe peut servir un ensemble sans avoir le pouvoir d’intervenir sur tous ses systèmes. Si des équipes opèrent hiérarchiquement à l’intérieur du périmètre, elles doivent être nommées. Le texte ajoute un avertissement sans détour : publier son autorité peut exposer à des mises en cause, et il conseille à toute équipe de prendre un avis juridique sur ce point.
Le niveau de support
La partie 4.1 demande la liste des types d’incidents traités et le niveau de support associé, ainsi que les facteurs qui le font varier, charge de travail et complétude de l’information signalée. Comme aucune liste de types d’incidents ne peut être exhaustive, le texte demande également d’indiquer le support par défaut pour les cas non listés. Il précise enfin qu’agir sur une information de vulnérabilité relève d’une politique de service proactive optionnelle, et non d’une exigence de base pour un CSIRT.
La politique de divulgation
C’est la partie la plus exigeante, et le texte y prend position. Il relève que le statut par défaut de toute information reçue est généralement confidentiel, mais qu’une application rigide de ce principe fait de l’équipe un trou noir informationnel, ce qui réduit la coopération qu’elle obtient de ses clients comme des autres organisations. Le document doit donc dire quelle information est rapportée ou divulguée, à qui, et quand.
L’exemple de l’annexe E montre à quoi ressemble une réponse complète : sept catégories d’information, de l’information sur un utilisateur à l’information statistique en passant par l’information dite embarrassante, croisées avec onze familles de destinataires, du management aux forces de l’ordre, en passant par la presse, les éditeurs et les autres équipes. Cet exemple n’a pas valeur normative, mais il donne la mesure du travail.
Sur ce point précis, une équipe qui écrit sa RFC 2350 en 2026 n’a plus à inventer sa grammaire de rediffusion : le TLP (8) 2.0 la fournit, et il suffit de dire qu’on l’applique.
La partie 4.3 est la seule que le texte formule à l’impératif : il faut une politique qui décrive les méthodes de communication sûres et vérifiables employées. Elle comprend les clés publiques ou les pointeurs vers elles, empreintes comprises, la façon de vérifier l’authenticité, et la conduite à tenir lorsqu’une information reçue se révèle corrompue.
Pourquoi ce document est devenu un prérequis
Une RFC de 1998 aurait pu rester une curiosité. Trois mécanismes en ont fait un passage obligé.
- L’accréditation. Remplir et publier une RFC 2350 est un impératif pour les équipes accréditées par le Trusted Introducer depuis mai 2009. Le document y est présenté comme la bonne pratique qui pousse toute équipe de sécurité à énoncer clairement son mandat et ses services.
- L’adhésion. Le modèle de rapport de visite utilisé par le FIRST pour les candidatures prévoit que les informations de l’équipe soient disponibles au format RFC 2350 dans le dossier de candidature.
- La maturité. Le paramètre O-5 de SIM3 exige les coordonnées, les plages de service, une description concise des services et la politique de traitement et de divulgation de l’information, publiquement disponibles en anglais. La RFC 2350 est la forme normalisée conseillée pour publier cet ensemble. Le détail des quarante-cinq paramètres du modèle est dans l’article consacré à SIM3 v2 interim.
L’exercice ne concerne d’ailleurs pas que les CSIRT. Le document de typologie publié par le FIRST définit quatre types d’équipes de gestion des incidents, alignés chacun sur les services qu’ils rendent : les CSIRT, les PSIRT (9), les SOC (10) et les ISAC (11). Le raisonnement de la RFC 2350 vaut pour les quatre : dire qui l’on sert, ce que l’on traite, comment on est joignable et ce que l’on divulgue.
Le Trusted Introducer signale un usage utile du CSIRT Services Framework du FIRST : choisir ses services dans une liste commune et les désigner par leur nom normalisé rend la RFC 2350 publiée réellement exploitable par les autres équipes, au lieu d’une description propre à chaque organisation.
Ce qui a vieilli, et par quoi le remplacer
Lire la RFC 2350 aujourd’hui demande de faire la part entre le raisonnement, qui n’a pas bougé, et les exemples techniques, qui datent de 1998. Le tableau ci-dessous fait le tri.
| Élément cité en 1998 | État en 2026 | Ce qui le remplace |
|---|---|---|
| PGP (12) recommandé comme minimum | Toujours pertinent | OpenPGP, avec une empreinte publiée et une clé valide |
| PEM (13) et MOSS (14) proposés en alternative | Sortis des usages | S/MIME (15), cité par le même passage, ou OpenPGP |
| DES (16) cité pour les clés secrètes | Retiré des usages | Les algorithmes symétriques actuels |
| Téléphonie sécurisée de type STU III | Hors du paysage courant | Les messageries chiffrées de bout en bout employées par la communauté |
| Liste de notification gérée par un gestionnaire de listes d’époque | Remplacé | Une liste de diffusion ou un flux, dont l’adresse figure en partie 1 |
| Liens de référence en ftp | Morts | Les sites actuels des mêmes organisations |
| Plus de cinquante-cinq équipes membres du FIRST | Chiffre d’époque | L’annuaire en ligne du FIRST |
| Absence d’un dépôt central des documents publiés | Comblée | L’annuaire du Trusted Introducer et la liste des membres du FIRST |
| Politique de divulgation à construire de zéro | Outillée | Le TLP 2.0 pour la rediffusion, la RSIT (17) pour la classification des incidents |
Une remarque du texte mérite d’être relue à la lumière de ce qui a suivi. Les auteurs écrivaient qu’un dépôt central de tous les documents publiés serait très utile, qu’il n’en existait aucun au moment de la rédaction, et que cela changerait peut-être. Les annuaires du Trusted Introducer et du FIRST remplissent aujourd’hui cette fonction, et les moteurs de recherche font le reste, comme le texte l’anticipait également.
Écrire ou rafraîchir le sien
Ce que le texte signale lui-même comme critique
Les points ci-dessous ne sont pas des recommandations extérieures. Ils figurent dans la RFC, et ils décrivent ce qui rend un document publié utile ou nuisible.
- Le gabarit rempli doit indiquer quand il a été modifié pour la dernière fois, et comment être informé des mises à jour. Sans cela, les malentendus s’installent avec le temps, et le texte avertit qu’un document périmé peut faire plus de mal que de bien.
- Le document doit être protégé par une signature numérique, ce que le texte recommande fortement pour la version en ligne comme pour les messages de mise à jour.
- Celui qui lit le document doit pouvoir en vérifier l’authenticité, donc la signature doit être publiée à côté.
- Le document doit être accessible sur le serveur d’information de l’équipe. Le texte signale le problème qui subsiste : encore faut-il que la constituency sache que l’équipe existe.
- En cas de traduction, la version traduite porte un avertissement et un renvoi vers l’original, et le texte fournit un exemple de clause qui fait prévaloir la version d’origine en cas d’écart.
- La constituency est en droit d’attendre les services décrits dans le document publié. Ce qui y figure engage l’équipe.
La méthode
- Partir de l’annexe D pour la structure et de l’annexe E pour le niveau de détail, sans reprendre les politiques de l’exemple, qui n’engagent personne.
- Trancher les quatre décisions de la section précédente avant d’ouvrir l’éditeur. C’est là que se trouve le travail réel.
- Nommer les services avec le CSIRT Services Framework, plutôt qu’avec le vocabulaire interne de l’organisation.
- Adosser la politique de divulgation au TLP 2.0 et la classification des incidents à la RSIT.
- Publier à une adresse stable, en texte brut et en PDF, avec la signature détachée à côté, et un numéro de version accompagné de sa date.
- Publier une version anglaise, qui est l’exigence du paramètre O-5 de SIM3 et la condition pour être lisible par les équipes étrangères.
- Relire les documents déjà publiés par d’autres équipes avant d’écrire le sien. Team Cymru, KIT-CERT et REN-ISAC publient les leurs, avec pour la deuxième une version signée en PDF et en texte, et pour la troisième un numéro de version et une liste de notification.
La RFC ne fixe aucune fréquence. Elle demande seulement que la date figure et que le document reste juste. En pratique, les événements qui imposent une révision sont connus : changement de coordonnées ou de plages de service, renouvellement de clé, évolution du périmètre servi, ajout ou retrait d’un service. Rattacher la revue du document à ces événements évite de s’en remettre à une échéance annuelle qui passe inaperçue.
Qualification des sources
Le contenu de la RFC a été relevé sur la page rendue par l’éditeur de la série, et non sur une reprise. Les exigences des communautés proviennent des organisations qui les posent.
| Élément | Statut | Commentaire |
|---|---|---|
| Contenu, structure et statut de la RFC 2350 | corroboré | Page de la RFC chez l’éditeur de la série et texte intégral publié, valeurs relevées sur la page rendue |
| Statut BCP 21 et absence de version de remplacement | corroboré | Aucune mention de remplacement sur la fiche de la RFC, consultée le 15 septembre 2026 |
| Exigence du Trusted Introducer depuis mai 2009 | source unique | Page des standards de fait du Trusted Introducer, non recoupée |
| Présence du format RFC 2350 au dossier d’adhésion au FIRST | source unique | Modèle de rapport de visite publié par le FIRST |
| Reprise du contenu minimal par le paramètre O-5 de SIM3 | corroboré | Standard SIM3 v2 interim, exigence minimale du paramètre O-5 |
| Sept catégories d’information et onze familles de destinataires | source unique | Relevées dans l’exemple de l’annexe E, qui n’a pas valeur normative |
| Contenu des trois errata recensés | écarté | Base des errata inaccessible à la date de rédaction, contenu non vérifié |
| État des documents publiés par des équipes tierces | écarté | Cités comme exemples de mise en forme, leur contenu n’a pas été audité |
Évaluation
Analyse construite sur le texte de la RFC 2350 relevé sur la page rendue par l’éditeur de la série, sur les pages publiées par le Trusted Introducer et par le FIRST et consultées le 15 septembre 2026, et sur le standard SIM3 v2 interim. Le décompte des sept parties et de leurs rubriques est fait sur l’annexe D. Les sept catégories d’information et les onze familles de destinataires sont relevées dans l’exemple de l’annexe E, dont le texte rappelle qu’il n’engage ni le groupe de travail ni l’IETF. Les appréciations portées dans la grille ci-dessus relèvent du jugement, pas de la mesure.
Lexique
- RFC (1) : Request for Comments, série de documents de référence publiés par la communauté Internet.
- BCP (2) : Best Current Practice, catégorie de RFC qui énonce une bonne pratique en vigueur, identifiée par son propre numéro de série.
- IETF (3) : Internet Engineering Task Force, organisation qui produit les standards de l’Internet.
- CSIRT (4) : Computer Security Incident Response Team, équipe de réponse aux incidents de sécurité informatique.
- CERT (5) : Computer Emergency Response Team, dénomination plus ancienne, équivalente à CSIRT.
- FIRST (6) : Forum of Incident Response and Security Teams, organisation mondiale des équipes de réponse aux incidents.
- SIM3 (7) : Security Incident Management Maturity Model, modèle de mesure de la maturité de la gestion des incidents de sécurité.
- TLP (8) : Traffic Light Protocol, protocole de marquage qui encadre la rediffusion d’une information partagée.
- PSIRT (9) : Product Security Incident Response Team, équipe de réponse aux incidents de sécurité d’un produit, chez son éditeur ou son constructeur.
- SOC (10) : Security Operations Center, équipe de supervision et de détection.
- ISAC (11) : Information Sharing and Analysis Center, structure de partage d’information sectorielle.
- PGP (12) : Pretty Good Privacy, mécanisme de chiffrement et de signature des messages, dont la déclinaison normalisée est OpenPGP.
- PEM (13) : Privacy Enhanced Mail, mécanisme de messagerie sécurisée des années 1990, fondé sur une hiérarchie d’autorités de certification.
- MOSS (14) : MIME Object Security Services, autre mécanisme de sécurisation des messages de la même époque.
- S/MIME (15) : Secure MIME, standard de signature et de chiffrement des messages électroniques reposant sur des certificats.
- DES (16) : Data Encryption Standard, algorithme de chiffrement symétrique retiré des usages.
- RSIT (17) : Reference Security Incident Taxonomy, taxonomie de référence des incidents de sécurité, issue des travaux soutenus par l’ENISA.
Sources
- IETF, RFC 2350, BCP 21, Expectations for Computer Security Incident Response, juin 1998, fiche consultée le 15 septembre 2026. rfc-editor.org
- IETF, RFC 2350, texte intégral, consulté le 15 septembre 2026. rfc-editor.org
- Trusted Introducer, De-Facto Standards for CSIRTs and other security teams, consultée le 15 septembre 2026. trusted-introducer.org
- FIRST, modèle de rapport de visite pour les candidatures à l’adhésion, consulté le 15 septembre 2026. first.org
- FIRST, CSIRT Services Framework v2.1.0, consulté le 15 septembre 2026. first.org
- FIRST, Team Types within the Context of Security Incident Management, version 1.2, consulté le 15 septembre 2026. first.org
- FIRST, Traffic Light Protocol, consulté le 15 septembre 2026. first.org
- Open CSIRT Foundation, SIM3 v2 interim, Full Standard, 1er janvier 2023. opencsirt.org
- ENISA, Reference Security Incident Taxonomy, consultée le 15 septembre 2026. github.com
- Team Cymru, document RFC 2350, consulté le 15 septembre 2026. team-cymru.com
- KIT-CERT, CERT Description as per RFC 2350, consultée le 15 septembre 2026. cert.kit.edu
- REN-ISAC, CSIRT RFC 2350, consultée le 15 septembre 2026. ren-isac.net
Marquage TLP:CLEAR, PAP:CLEAR. Diffusion libre, exploitation sans restriction.
Les analyses présentées ici n’engagent que leur auteur et reposent sur les sources publiques listées ci-dessus.
