Monter un CSIRT interne, missions, services FIRST et rattachement

Monter un CSIRT interne, missions, services FIRST et rattachement

Un CSIRT (Computer Security Incident Response Team) interne est l’équipe mandatée pour répondre aux incidents de sécurité d’une organisation : analyser, confiner, coordonner, tirer les leçons. Le monter revient à trancher quatre questions dans l’ordre : quelle autorité, sur quel périmètre, avec quels services choisis dans le catalogue du FIRST (Forum of Incident Response and Security Teams), et rattaché à qui. Position défendue sur cette page : un mandat étroit doté d’une autorité réelle vaut mieux qu’un catalogue large sans pouvoir d’agir.

Explication de la marmotte

Dans un immeuble, quand l’alarme incendie sonne, quelqu’un sait déjà qui a les clés du local électrique et qui appelle les pompiers. Une équipe de réponse aux incidents informatiques joue ce rôle pour les ordinateurs d’une organisation : des personnes désignées à l’avance, à qui tout le monde a accepté d’obéir le jour où ça brûle, et qui connaissent les secours extérieurs par leur prénom.

→ Lire l’explication complète de la marmotte

Mandat du CSIRT interne : autorité, périmètre servi et fiche RFC 2350

Un point de vocabulaire d’abord. « CERT » (Computer Emergency Response Team) est une marque déposée de l’université Carnegie Mellon ; « CSIRT » est le terme générique, et c’est celui qu’une équipe interne emploie sans rien demander à personne.

Le mandat est le premier livrable, avant tout outil. C’est un document signé par la direction générale qui fixe trois choses : la mission, le périmètre servi (la « constituency » : entités, filiales, environnements cloud, systèmes industriels, prestataires infogérés) et le niveau d’autorité. La littérature CSIRT distingue trois niveaux : autorité pleine (l’équipe décide et exécute les mesures), autorité partagée (elle participe à la décision), autorité nulle (elle conseille). Un CSIRT à autorité nulle, c’est un club de lecture avec une astreinte.

Le compromis central du sujet est là. Une autorité pleine sur tout le périmètre n’est jamais accordée, parce que couper un service de production engage le chiffre d’affaires. Une autorité nulle partout rend l’équipe décorative. La sortie qui tient en production : une liste fermée d’actions pré-autorisées, exécutables sans validation à n’importe quelle heure, et tout le reste soumis à arbitrage. Typiquement :

• isoler un poste ou un serveur non critique du réseau ;
• désactiver un compte ou révoquer ses sessions ;
• bloquer un flux sortant vers une destination identifiée ;
• suspendre un accès distant de prestataire.

L’arrêt d’un service métier, lui, remonte à la cellule de crise. Ce qu’on gagne : des minutes au moment où l’attaquant se déplace. Ce qu’on paie : une négociation pénible en amont avec chaque responsable d’exploitation, à mener à froid, parce qu’à chaud elle est perdue d’avance.

Le périmètre servi mérite la même précision, surtout sur ce qu’il exclut. Une filiale autonome, un environnement cloud ouvert par un métier avec sa carte bancaire, un automate d’atelier : si le mandat ne dit pas qui répond, personne ne répond, et la découverte se fait en plein incident.

Le tout se consigne dans une fiche au format RFC 2350 (Request for Comments, « Expectations for Computer Security Incident Response », 1998). Ce gabarit couvre le périmètre servi, le mandat et l’autorité, les contacts et horaires, les clés de chiffrement, les services rendus et la politique de divulgation. Rédiger cette fiche oblige à répondre aux questions que l’organigramme laisse dans le flou, ce qui explique son âge canonique et sa longévité.

Prérequis à réunir avant de signer le mandat :

• un inventaire des actifs avec, pour chacun, un responsable joignable ;
• des journaux centralisés et conservés assez longtemps pour remonter une intrusion ancienne (voir la normalisation des logs et les pipelines) ;
• une source de détection, interne ou externalisée ;
• des sauvegardes dont la restauration a été testée ;
• un interlocuteur juridique identifié ;
• un contrat de renfort déjà signé avec un prestataire de réponse, car contractualiser pendant une crise prend plus de temps que la crise n’en laisse.

Frontière SOC et CSIRT : passages de main vers la cellule de crise et l’extérieur

Le SOC (Security Operations Center) surveille, trie et qualifie des événements. Le CSIRT prend la main quand un événement devient un incident : il enquête, confine, coordonne la remédiation et produit le retour d’expérience. Le SOC travaille en flux continu sur du volume, le CSIRT en mode dossier sur des cas. La page SOC détaille la détection, le tri et les modèles interne ou externalisé ; ici, seule la frontière compte.

Cette frontière s’écrit comme un contrat d’escalade à deux clauses :

• Le critère de bascule : compromission confirmée d’un compte à privilèges, exécution de code malveillant non bloquée, exfiltration suspectée, ou simple doute sérieux de l’analyste.
• Le contenu du dossier transmis : chronologie, actifs touchés, alertes sources, actions déjà effectuées.

Cette dernière ligne n’est pas une politesse. Un poste réinstallé par zèle avant l’escalade emporte avec lui la mémoire vive et les traces sur disque, et aucune procédure ne les fera revenir (voir la chaîne de conservation des preuves).

Le schéma ci-dessous se lit de haut en bas : chaque flèche est un passage de main, et les crochets indiquent la condition qui le déclenche.

Deux règles en découlent :

• Le CSIRT ne dirige pas la crise. La cellule de crise est décisionnelle et métier ; le CSIRT lui apporte des faits et des options, puis exécute les arbitrages. Un responsable d’incident qui anime la cellule de crise tout en pilotant l’investigation fait mal les deux (voir la communication de crise et le retour d’expérience).
• Le retour vers le SOC est obligatoire. Un incident clos sans nouvelle détection est un incident qui reviendra sous la même forme.

Catalogue de services : choisir dans le CSIRT Services Framework de FIRST

Le CSIRT Services Framework de FIRST (version 2.1) fournit un vocabulaire commun pour décrire ce qu’une équipe fait. Il est organisé en cinq domaines de services (service areas), déclinés en services, fonctions et sous-fonctions :

Domaine	Ce qu’il recouvre	Porteur habituel
Gestion des événements de sécurité (Information Security Event Management)	Surveillance, détection, analyse des événements	SOC
Gestion des incidents (Information Security Incident Management)	Réception des signalements, analyse, examen des artefacts et preuves, confinement et rétablissement, coordination, appui à la gestion de crise	CSIRT, toujours
Gestion des vulnérabilités (Vulnerability Management)	Réception, analyse et coordination des signalements de failles, divulgation	CSIRT pour la coordination, exploitation pour le correctif
Connaissance de la situation (Situational Awareness)	Acquisition de données, synthèse, diffusion vers ceux qui décident	CSIRT ou cellule de renseignement sur la menace
Transfert de connaissances (Knowledge Transfer)	Sensibilisation, formation, exercices, conseil	CSIRT en appui

Ce cadre est un catalogue où choisir, pas une liste à cocher en entier. Afficher les cinq domaines au lancement produit une fiche de services flatteuse et une équipe qui ne tient aucun engagement. La recommandation : ouvrir la gestion des incidents seule, la tenir avec un niveau de service écrit, puis étendre. Chaque service affiché dans la fiche RFC 2350 est une promesse faite au périmètre servi ; mieux vaut trois promesses tenues que quinze lignes de plaquette.

Trois précisions évitent des confusions courantes :

• Produits vendus : une organisation qui vend des logiciels ou des équipements a aussi besoin de traiter les failles de ses propres produits. C’est le métier d’un PSIRT (Product Security Incident Response Team), pour lequel FIRST publie un cadre distinct. Fusionner les deux dans une équipe de trois personnes revient à ne faire ni l’un ni l’autre.
• Processus de réponse : le cadre FIRST dit quoi offrir, pas comment dérouler une réponse. Pour le processus, les références sont le NIST SP 800-61 (National Institute of Standards and Technology, Special Publication), dont la révision 3 de 2025 s’aligne sur le CSF (Cybersecurity Framework) 2.0, et l’ISO/IEC 27035 (International Organization for Standardization, International Electrotechnical Commission).
• Maturité : elle se mesure avec SIM3 (Security Incident Management Maturity Model), maintenu par l’Open CSIRT Foundation, qui évalue quatre familles de paramètres : organisation, humain, outils, processus. Ce modèle sert de référence à l’ENISA (Agence de l’Union européenne pour la cybersécurité) pour le réseau des CSIRT, ainsi qu’à FIRST et à TF-CSIRT (Task Force CSIRT, via son service Trusted Introducer) pour l’adhésion. Une auto-évaluation SIM3 à la création donne une feuille de route plus honnête qu’un tableau de bord inventé pour l’occasion.

Rattachement hiérarchique du CSIRT : RSSI, DSI ou direction des risques

La question qui décide du rattachement tient en une ligne : qui arbitre quand le confinement coûte de la disponibilité ? Si la même personne porte les objectifs de disponibilité et encadre le CSIRT, l’arbitrage est rendu avant d’être posé.

Rattachement	Ce qu’on gagne	Ce qu’on paie
DSI (direction des systèmes d’information), côté exploitation	Proximité, accès aux systèmes, rapidité d’exécution	Conflit d’intérêts structurel : le retour d’expérience qui pointe un défaut d’administration est rédigé sous l’autorité de ceux qu’il met en cause
RSSI (responsable de la sécurité des systèmes d’information) placé hors DSI	Indépendance, voie d’accès à la direction générale	Distance avec l’exploitation, à compenser par des conventions d’intervention écrites et des accès techniques négociés à l’avance
Direction des risques ou sécurité groupe	Cohérence dans un groupe à plusieurs entités, avec un CSIRT coordinateur et des correspondants locaux	Aucune main sur les systèmes : tout repose sur les correspondants, donc sur leur disponibilité réelle

La recommandation : rattachement au RSSI quand celui-ci n’est pas lui-même subordonné à l’exploitation, avec une voie d’escalade directe vers la direction générale écrite dans le mandat. Quand l’organigramme impose la DSI, le mandat doit au minimum être signé au-dessus d’elle et garantir que le retour d’expérience est diffusé sans réécriture hiérarchique. Renommer l’équipe d’exploitation en CSIRT ne change que la signature des courriels.

Le rattachement ne règle pas tout. Un retour d’expérience honnête suppose que ceux qui ont commis l’erreur puissent la raconter sans y laisser leur évaluation annuelle (voir la culture juste après incident).

Effectifs, astreinte et outillage minimal du CSIRT

Effectifs. L’arithmétique vient avant l’ambition. Une présence continue représente 168 heures par semaine ; un temps plein en couvre de l’ordre de 35 à 40, avant congés, repos obligatoires, formation et absences. La division donne déjà plus de quatre personnes, et cinq à six par poste tenu en permanence une fois les absences comptées. C’est un calcul de planning, pas une statistique de secteur.

D’où une position nette : un CSIRT interne n’a presque jamais à tenir une présence 24/7. La veille continue relève de la détection, donc du SOC, interne ou externalisé. Le CSIRT tient une astreinte : joignable, mobilisable, avec un délai de prise en charge écrit.

Astreinte. Même en astreinte, le planning impose son plancher. À moins de quatre personnes dans la rotation, chacun est de garde plus d’une semaine sur quatre, et la première intervention de nuit suivie d’un repos obligatoire vide le planning de jour. La page astreinte cybersécurité traite de la durabilité. Pour le dimensionnement, retenir qu’une équipe de deux personnes est un point de défaillance unique avec un second point de défaillance unique en vacances.

Outillage. Le minimum tient en six éléments, et aucun ne s’achète sur un stand de salon :

• Un outil de gestion de dossiers dédié, à accès restreint, distinct de l’outil de tickets généraliste (un dossier d’incident décrit des faiblesses exploitables).
• Un stockage de preuves avec contrôle d’intégrité et journal des accès.
• Des accès de collecte déjà ouverts : console EDR (Endpoint Detection and Response), journaux centralisés, annuaire, traces réseau.
• Un canal de communication hors bande, qui ne dépend ni de la messagerie ni de l’annuaire de l’organisation.
• Un annuaire de contacts (responsables d’actifs, juridique, direction, partenaires extérieurs) disponible hors ligne, papier compris.
• Des fiches réflexes par type d’incident, testées en exercice.

Conditions d’exploitation. Ce sont elles qu’on oublie en premier :

• Clé de chiffrement d’équipe : la clé PGP (Pretty Good Privacy) publiée dans la fiche RFC 2350 a une date d’expiration, un nombre réduit de détenteurs et une procédure de renouvellement au départ d’un membre.
• Comptes de collecte : un compte privilégié qui ouvre une session interactive sur une machine compromise y laisse des secrets réutilisables. Ces comptes se renouvellent après chaque intervention.
• Comptes de secours : scellés, et testés à échéance fixe.
• Sauvegarde : la base de dossiers et les preuves résident hors du périmètre qu’un rançongiciel peut chiffrer.
• Supervision : les actions privilégiées du CSIRT sont journalisées et relues par quelqu’un d’extérieur à l’équipe.
• Exercices : au moins un par an. Un plan jamais joué est une hypothèse.

Coopération avec le CERT-FR, les CSIRT sectoriels et les prestataires PRIS

Le CERT-FR est le CSIRT gouvernemental et national français, opéré par l’ANSSI (Agence nationale de la sécurité des systèmes d’information). Un CSIRT interne en consomme les alertes et les avis, lui signale des incidents et peut recevoir de lui des signalements. Le CERT-FR n’est pas un prestataire de réponse à la demande pour toute entreprise : il intervient selon ses propres priorités.

Pour une intervention sur site ou un renfort d’investigation, le recours est un prestataire qualifié PRIS (Prestataires de Réponse aux Incidents de Sécurité, visa de sécurité ANSSI), choisi et contractualisé à froid.

Autour du CERT-FR, l’écosystème français comprend :

• InterCERT France, association de CERT et de CSIRT français ;
• des CSIRT régionaux, tournés vers les structures de taille intermédiaire de leur territoire ;
• des CSIRT sectoriels, par exemple le CERT Aviation France ou le M-CERT pour le maritime.

Le CSIRT sectoriel est souvent l’interlocuteur le plus rentable : il voit passer la même campagne chez plusieurs acteurs du secteur avant qu’elle ne devienne une alerte publique. À l’échelle internationale, l’adhésion à FIRST ou l’inscription auprès de TF-CSIRT ouvrent des canaux équivalents.

Tout échange suit le marquage TLP (Traffic Light Protocol), décrit sur la page FIRST et TLP, et porte sur des éléments exploitables (voir indicateurs de compromission et TTP, les tactiques, techniques et procédures de l’attaquant). Deux règles d’usage :

• La confiance se construit avant l’incident. Un courriel envoyé à une liste de diffusion par une équipe inconnue reçoit une réponse polie ; un message à un pair déjà croisé en reçoit une qui sert.
• Le partage fonctionne à la réciprocité. Une équipe qui consomme sans jamais contribuer voit ses sources se tarir sans préavis.

Côté réglementaire, la directive NIS2 (Network and Information Security, directive (UE) 2022/2555) encadre les CSIRT nationaux, leurs exigences et la divulgation coordonnée des vulnérabilités (articles 10 à 12), ainsi que le réseau des CSIRT (article 15). Son article 23 fixe la séquence de notification pour un incident atteignant le seuil prévu (« incident important » dans la version française de la directive) :

Échéance	Livrable	Contenu attendu
24 heures après la prise de connaissance	Alerte précoce	Caractère malveillant suspecté ou non, impact transfrontière possible
72 heures	Notification	Évaluation initiale, gravité, impact, indicateurs de compromission disponibles
Un mois après la notification	Rapport final	Bilan de l’incident

La transposition nationale en vigueur fait foi sur le périmètre, les seuils et le destinataire ; la page NIS2 détaille le texte.

La conséquence d’architecture est directe : le modèle de dossier du CSIRT comporte ces champs dès l’ouverture et horodate la prise de connaissance, puisque c’est elle qui lance l’horloge. Le CSIRT alimente la notification ; il ne la décide pas et ne la remplace pas. La décision de notifier appartient au responsable désigné par l’organisation, avec son conseil juridique.

Surface d’attaque d’un CSIRT interne et limites de ce qu’il garantit

Une équipe de réponse concentre des privilèges, des secrets et la carte des faiblesses de l’organisation. Elle est donc une cible, et un attaquant installé depuis des semaines le sait.

Vecteur	Ce que l’attaquant y gagne	Contre-mesure
Outillage adossé à l’annuaire compromis	Lecture des dossiers, voire verrouillage des répondants hors de leurs propres outils	Authentification de l’outil de dossiers indépendante de l’annuaire principal, comptes de secours locaux
Messagerie et visioconférence de l’organisation	Suivi en direct de l’investigation, adaptation avant chaque mesure de confinement	Bascule sur le canal hors bande dès qu’une compromission de la messagerie ou de l’annuaire est plausible, pas une fois qu’elle est prouvée
Console EDR et comptes de collecte	Exécution à distance sur tout le parc	Authentification multifacteur, postes d’administration dédiés, droits accordés à la demande et retirés ensuite
Usurpation du CSIRT ou d’un partenaire	Obtention d’identifiants ou exécution d’un « outil de diagnostic » par un utilisateur conciliant	Canaux publiés dans la fiche RFC 2350, signature des messages, rappel sur un numéro connu (voir ingénierie sociale et accès initial)
Base de dossiers	Inventaire commenté de ce qui a déjà cédé	Cloisonnement par dossier, journal des consultations, chiffrement au repos
Fuite d’informations reçues de pairs	Rupture de confiance et tarissement des sources	Discipline TLP, y compris dans les comptes rendus internes

Ce qu’un CSIRT interne ne garantit pas, et d’où doit venir le reste :

• La détection. Elle vient du SOC et de la qualité des journaux. Un CSIRT sans détection répond aux incidents que les utilisateurs remarquent, c’est-à-dire aux plus bruyants.
• La prévention. Durcissement, correctifs et segmentation restent à la charge de l’exploitation et de l’architecture ; le CSIRT fournit les priorités, pas les bras.
• La reprise d’activité. Elle dépend des sauvegardes et du plan de continuité. Confiner proprement un parc dont aucune sauvegarde n’est restaurable ne ramène rien.
• La conformité. Notification réglementaire, qualification juridique et dépôt de plainte relèvent de la direction et du juridique.
• L’attribution. Dire qui est derrière une attaque demande des moyens et des précautions qu’une équipe interne n’a généralement pas (voir l’attribution d’une cyberattaque).

Exemple : ordre d’ouverture des services du catalogue FIRST

L’exemple montre une logique de décision : quels domaines du cadre FIRST ouvrir, dans quel ordre, et sous quelle condition. Chaque flèche part de ce qui doit exister et pointe vers ce qu’on peut ouvrir ensuite ; la condition entre crochets est le fait observable qui justifie l’ouverture. Quand un SOC existe, la gestion des événements reste chez lui et n’entre pas dans le catalogue du CSIRT.

La lecture se fait en trois temps :

1. La gestion des incidents s’ouvre seule, dès que le mandat et la fiche existent. C’est le seul domaine sans lequel l’équipe ne mérite pas son nom.
2. La gestion des événements ne s’ajoute que par défaut. Si un SOC existe, elle reste chez lui. S’il n’existe pas, le CSIRT l’assume en l’écrivant noir sur blanc, avec la conséquence sur l’effectif : une équipe qui trie des alertes toute la journée n’enquête plus (voir la fatigue d’alerte).
3. Les trois autres domaines s’ouvrent sur preuve de besoin, jamais par symétrie avec le cadre. Les vulnérabilités, quand les dossiers d’incident montrent que les failles exploitées étaient connues. La connaissance de la situation, quand il existe quelqu’un avec qui échanger, sinon c’est une revue de presse. Le transfert de connaissances, quand il y a une matière à transmettre, donc des retours d’expérience réels.

Un domaine ouvert se referme rarement : chaque ouverture se décide avec l’effectif qui va avec, ou ne se décide pas.

FAQ

Un CSIRT interne dispense-t-il de notifier un incident aux autorités ?

Non. La notification prévue par l’article 23 de NIS2, comme toute autre obligation de déclaration applicable, pèse sur l’entité, pas sur son équipe de réponse. Le CSIRT produit la chronologie et les éléments techniques dans les délais ; la décision et l’envoi relèvent du responsable désigné. Le texte officiel et la transposition nationale en vigueur font foi.

CSIRT interne ou prestataire de réponse à incident ?

Les deux, et la question est celle de la répartition. La connaissance du système d’information, l’autorité d’agir et la coordination interne ne s’externalisent pas : un prestataire qui arrive sans interlocuteur mandaté passe ses premières heures à chercher qui peut lui ouvrir un accès. L’investigation lourde et le renfort en volume s’achètent, de préférence auprès d’un prestataire qualifié PRIS sous contrat avant l’incident.

🐝 Ce qui arrive si on s’en passe

Sans équipe mandatée, chaque incident se traite par la bonne volonté de celui qui décroche. Personne n’a le droit écrit d’isoler une machine, donc l’isolement attend une validation pendant que l’attaquant change de serveur. Les preuves disparaissent avec les réinstallations faites pour rendre service. Les mêmes failles reviennent, puisque personne n’est chargé de relier un incident au précédent. Les signalements venus de l’extérieur (un chercheur, un partenaire, une autorité) atterrissent sur une adresse générique que personne ne lit. Et le jour où un délai légal de notification démarre, il manque la chronologie, la liste des systèmes touchés et l’interlocuteur capable de les fournir.

🦫 Explication de la marmotte 🍫

Une équipe de réponse aux incidents de sécurité est un groupe de personnes chargé d’agir quand un système informatique est attaqué. Avant tout, la direction signe un document qui dit ce que l’équipe a le droit de faire sans demander la permission, par exemple couper un ordinateur du réseau ou bloquer un compte, et sur quelles parties de l’organisation. Sans ce document, l’équipe ne peut que donner des conseils, et l’attaquant avance pendant que les responsables discutent. Ensuite, le travail suit un ordre. Une autre équipe, chargée de la surveillance, repère une anomalie et la transmet avec ce qu’elle sait déjà. L’équipe de réponse cherche ce qui s’est passé, empêche l’attaque de s’étendre, puis aide à réparer. Si l’activité de l’organisation est menacée, les dirigeants décident, et l’équipe leur fournit les faits. La loi peut obliger à prévenir les autorités dans un délai court : cette démarche reste à faire, équipe ou pas. L’équipe choisit ses activités dans une liste internationale, en commençant par la réponse aux attaques, puis en ajoutant le reste quand elle en a les moyens. Elle garde ses propres moyens de communication, séparés du réseau habituel, car un attaquant installé peut lire les messages. Enfin, elle échange des informations avec les équipes d’autres organisations et sait à qui demander du renfort quand l’attaque la dépasse.

À lire aussi

• CERT-EU réponse aux incidents des institutions européennesCERT-EU est le service opérationnel de réponse aux incidents des institutions, organes et agences de l’Union européenne, distinct d’ENISA et d’Europol.
• CCN-CERT Espagne : rôle, guides CCN-STIC et ENSFiche du CCN-CERT espagnol et du Centro Criptológico Nacional, leur mandat sur la sécurité du secteur public espagnol, les guides CCN-STIC, le Schéma national de sécurité et la coopération avec les CERT européens.
• NCSC-NL et coordination cyber portuaire néerlandaiseFiche du NCSC-NL néerlandais, de sa coordination avec le privé et de ses implications pour les infrastructures portuaires et logistiques.
• NIS2 pour les petites structuresLa plupart des petites structures ne sont pas directement visées par NIS2, mais beaucoup la rencontreront par leurs clients, sous forme de clauses et de questionnaires. Ce qu'elle demande ressemble moins à un chantier de conformité qu'à une hygiène qu'on aurait dû avoir de toute façon.

Pages voisines

Monter un CSIRT interne, missions, services FIRST et rattachement

Elle cite

• ⇄Lien dans les deux sens :Réponse à incident NIST SP 800-61r3, cycle complet et architecture
• ⇄Lien dans les deux sens :Partager le renseignement sur la menace avec ISAC, MISP et STIX
• ⇄Lien dans les deux sens :PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA
• Communiquer pendant un incident et mener un retex
• Forensics numérique et chaîne de conservation après incident
• Comment attribuer techniquement une cyberattaque
• Comment contrer le spear phishing et la fraude au président
• IoC ou TTP pour détecter une compromission
• Normaliser les logs avec OCSF, ECS ou CIM
• Réduire la fatigue d’alerte dans un SOC
• SOC centre des opérations de sécurité : rôle, organisation, mesure
• ANSSI

⇄ : les deux pages se citent l’une l’autre.