PSIRT vs CSIRT : vulnérabilités produit et incidents dans votre propre SI

Qu'est-ce qu'un CSIRT ?

Un CSIRT (Computer Security Incident Response Team) est l'équipe qui traite les incidents de sécurité pour un groupe défini de personnes ou d'organisations, appelé sa communauté desservie. Le CSIRT Services Framework de FIRST le définit comme une unité organisationnelle, éventuellement virtuelle, ou une capacité qui fournit des services à cette communauté pour prévenir, détecter, traiter les incidents de sécurité informatique et y répondre.

C'est la communauté desservie qui détermine le type de CSIRT :

• CSIRT d'entreprise : les réseaux, systèmes, comptes et données d'une seule entreprise.
• CSIRT sectoriel : un groupe d'organisations d'un même secteur, comme la finance ou l'énergie.
• CSIRT national : un pays entier, souvent avec un rôle de coordination transfrontalière.
• Équipe d'éditeur : les clients d'une entreprise, pour les problèmes touchant ses produits. C'est le PSIRT.

Le CSIRT Services Framework (version 2.1) regroupe les services d'un CSIRT en cinq domaines : gestion des événements de sécurité de l'information, gestion des incidents de sécurité de l'information, gestion des vulnérabilités, connaissance de la situation et transfert de connaissances.

Qu'est-ce qu'un PSIRT ?

Un PSIRT (Product Security Incident Response Team) est, selon FIRST, l'entité d'une organisation axée sur l'identification, l'évaluation et le traitement des risques liés aux vulnérabilités de sécurité des produits que l'organisation fabrique ou vend. Il reçoit les signalements de vulnérabilités, détermine quels produits et versions sont touchés, fait développer et livrer une correction, et informe les clients par des avis de sécurité.

Son cadre, le PSIRT Services Framework (version 1.1), compte six domaines de services : gestion de l'écosystème des parties prenantes, découverte des vulnérabilités, tri et analyse des vulnérabilités, remédiation, divulgation des vulnérabilités, ainsi que formation et sensibilisation.

La différence essentielle

La différence tient aux systèmes exposés. Un CSIRT protège l'organisation : l'incident se trouve dans votre environnement, et vous le contenez. Un PSIRT protège vos clients : la vulnérabilité se trouve dans votre produit, exécuté dans leurs environnements, et vous ne pouvez pas le corriger à leur place. Vous livrez une correction et vous leur demandez de l'installer.

FIRST le dit clairement : c'est l'accent mis sur les produits qui distingue avant tout un PSIRT des autres équipes de réponse aux incidents de la même organisation, et un CSIRT d'entreprise se concentre généralement sur les systèmes et réseaux qui composent l'infrastructure de l'organisation.

PSIRT et CSIRT comparés

	CSIRT d'entreprise	PSIRT
Périmètre	Incidents dans les réseaux, systèmes et données de l'organisation	Vulnérabilités dans les produits que l'organisation livre
Communauté desservie	Employés et systèmes internes	Clients et utilisateurs des produits
Entrées habituelles	Alertes, journaux, signalements d'utilisateurs, renseignement sur les menaces	Signalements de chercheurs, avis sur des composants tiers, tests internes, coordinateurs
Sorties habituelles	Incidents contenus, systèmes rétablis, revues post-incident	Releases corrigées, avis de sécurité, enregistrements CVE, notifications aux clients
Début du compte à rebours	Lorsqu'un incident est détecté	Lorsqu'une vulnérabilité est signalée ou publiée
Responsable habituel	Le RSSI ou la sécurité informatique	La sécurité produit ou l'ingénierie
Cadre FIRST	CSIRT Services Framework 2.1	PSIRT Services Framework 1.1
Normes	ISO/IEC 27035 (gestion des incidents)	ISO/IEC 29147 (divulgation des vulnérabilités), ISO/IEC 30111 (traitement des vulnérabilités)

Les deux cadres soulignent que ces équipes ne travaillent pas isolément. Le cadre PSIRT présente les CSIRT, y compris nationaux, comme des parties prenantes avec lesquelles un PSIRT doit nouer des relations, car c'est souvent par eux qu'un éditeur apprend tôt l'existence d'une vulnérabilité.

CERT vs CSIRT

La première équipe de ce type a été le CERT Coordination Center, qui, selon le SEI, est né de la réponse au ver Morris en 1988, avec un financement de la DARPA, au Software Engineering Institute de Carnegie Mellon. CERT est une marque déposée aux États-Unis par l'université Carnegie Mellon, et le SEI autorise des équipes américaines à l'utiliser dans leur nom. Il n'accorde plus de licence pour cette marque hors des États-Unis.

« CERT » et « CSIRT » désignent donc le même type d'équipe. CSIRT est le terme neutre, utilisé par FIRST et dans le droit de l'UE ; de nombreuses équipes, nationales en particulier, gardent le mot CERT dans leur nom.

CSIRT nationaux et coordinateurs

Quelques organisations comptent pour une équipe produit, car elles se situent entre découvreurs, éditeurs et utilisateurs :

• Le CERT/CC coordonne la divulgation des vulnérabilités logicielles depuis 1988 et publie un guide de la divulgation coordonnée des vulnérabilités pour les organisations qui bâtissent leur propre processus.
• La CISA coordonne la divulgation entre auteurs de signalements, fabricants et utilisateurs aux États-Unis, et peut publier dès 45 jours après une première tentative de contact d'un éditeur qui ne répond pas, qu'une correction existe ou non.
• Les CSIRT nationaux de l'UE. NIS2 impose à chaque État membre de désigner ou de créer un ou plusieurs CSIRT, qui coopèrent au sein du CSIRTs Network avec le CERT-EU. L'ENISA, l'agence de l'UE pour la cybersécurité, en assure le secrétariat.

Les CSIRT nationaux ont aussi un rôle formel dans le signalement des vulnérabilités. En vertu de l'article 12 de NIS2, chaque État membre désigne un CSIRT comme coordinateur de la divulgation coordonnée des vulnérabilités : un intermédiaire de confiance entre la personne qui signale une vulnérabilité et le fabricant, qui peut identifier les éditeurs concernés, aider l'auteur du signalement et négocier les délais de divulgation. Le Cyber Resilience Act s'appuie sur ce même rôle : les fabricants notifient les vulnérabilités activement exploitées dans leurs produits au CSIRT coordinateur et à l'ENISA en même temps.

Comment un PSIRT et un CSIRT travaillent ensemble

Prenons un composant open source vulnérable en cours d'exploitation, utilisé à la fois dans votre produit et dans vos systèmes internes. Les deux équipes reçoivent le même avis, et chacune a sa propre mission :

1. CSIRT : repère le composant sur les serveurs et ordinateurs portables internes, recherche des traces d'exploitation dans les journaux, corrige ou isole, et gère un incident si quelque chose a été compromis.
2. PSIRT : détermine quels produits, versions et builds incluent le composant, évalue si le produit est touché, livre une release corrigée et publie un avis de sécurité, avec une déclaration VEX pour les versions non touchées.
3. Les deux : partagent indicateurs et chronologies. Si le CSIRT constate que l'attaque a atteint le système de build, le PSIRT doit vérifier si une release livrée a été altérée, ce qui transforme un incident interne en incident produit. Une attaque de la chaîne d'approvisionnement franchit généralement cette limite.

C'est la deuxième étape qui ralentit le PSIRT. Un CSIRT peut analyser son propre parc. Un PSIRT doit répondre de logiciels déjà entre les mains des clients, ce qui suppose de savoir ce qui est entré dans chaque release livrée. Les pages sur le cycle de vie de la gestion des vulnérabilités et la divulgation coordonnée des vulnérabilités couvrent le reste du parcours du PSIRT jusqu'à la correction.

CSIRT vs SOC

Un Security Operations Center (SOC) surveille : il suit les alertes et les journaux 24 heures sur 24, filtre le bruit et escalade ce qui semble réel. Un CSIRT répond : il prend en charge l'incident confirmé, le contient, enquête, se coordonne avec les équipes juridiques et de communication, et pilote le rétablissement. Dans les petites organisations, le SOC et le CSIRT sont souvent les mêmes personnes, et le SEI souligne que le nom d'une équipe, CSIRT, SOC ou autre, compte moins que les fonctions qu'elle assure.

Ni l'un ni l'autre ne remplace un PSIRT. Un SOC surveille votre environnement ; il ne peut pas voir une vulnérabilité dans un appareil utilisé par un client.

Avez-vous besoin des deux ?

Si vous fabriquez des logiciels ou des appareils et gérez aussi votre propre informatique, vous avez besoin des deux fonctions. Il ne vous faut pas deux services pour autant. Les petits éditeurs commencent souvent avec un responsable sécurité qui pilote la réponse aux incidents de l'entreprise et un processus PSIRT écrit pour les produits, avec l'ingénierie d'astreinte pour les corrections. C'est le processus qui doit être séparé : un incident interne et une vulnérabilité produit ont des responsables différents, des délais différents et des interlocuteurs à prévenir différents.

La place de CRACI

CRACI soutient le volet PSIRT : savoir ce que contient le logiciel que vous livrez. Il exécute vos builds GitHub Actions sur ses propres runners et enregistre les paquets réellement récupérés par chaque job, y compris les dépendances transitives et les paquets restaurés depuis les caches, et exporte les SBOM en CycloneDX ou SPDX.

Les SBOM surveillées sont réévaluées en continu, et l'historique des builds indique quels builds passés contenaient une dépendance vulnérable. La vue d'inventaire montre quelles versions sont déployées sur quels produits, et les équipes de sécurité trient les résultats et les transmettent aux équipes responsables de la correction. Consultez le suivi des vulnérabilités et CRACI pour les PSIRT.

PSIRT vs CSIRT : questions fréquentes

Qu'est-ce qu'un CSIRT ?

Un Computer Security Incident Response Team. FIRST le définit comme une unité organisationnelle, éventuellement virtuelle, ou une capacité qui fournit des services et un soutien à une communauté définie pour prévenir, détecter, traiter les incidents de sécurité informatique et y répondre. Cette communauté peut être une entreprise, un secteur ou un pays entier.

Quelle est la différence entre un PSIRT et un CSIRT ?

Un PSIRT traite les vulnérabilités des produits vendus par une entreprise, auxquelles ses clients sont exposés. Un CSIRT d'entreprise traite les incidents de sécurité dans les systèmes et réseaux de l'entreprise elle-même. Pour FIRST, l'accent mis sur les produits est ce qui distingue avant tout les deux équipes.

Un CERT est-il la même chose qu'un CSIRT ?

Sur le plan fonctionnel, oui. CERT est une marque déposée aux États-Unis par l'université Carnegie Mellon, dont le CERT Coordination Center a été la première équipe de ce type, créée en 1988 après le ver Morris. CSIRT est le terme générique. De nombreuses équipes nationales utilisent CERT dans leur nom, et l'UE emploie CSIRT dans sa législation.

Quelle est la différence entre un SOC et un CSIRT ?

Un SOC surveille et détecte 24 heures sur 24 : il suit les alertes et les journaux, et escalade ce qui semble réel. Un CSIRT assume la réponse aux incidents confirmés : confinement, enquête, coordination et rétablissement. Dans de nombreuses organisations, les deux se recoupent ou partagent des personnes, et le SEI note que ce qui compte, ce sont les fonctions assurées par une équipe, pas son nom.

Avons-nous besoin à la fois d'un PSIRT et d'un CSIRT ?

Si vous vendez des logiciels ou des appareils et gérez aussi votre propre informatique, vous avez besoin des deux fonctions, mais pas forcément de deux services. Dans une petite entreprise, les mêmes quelques personnes couvrent souvent les deux, avec des processus distincts : l'un pour les incidents dans votre environnement, l'autre pour les vulnérabilités de ce que vous livrez.

Que fait un CSIRT national ?

Il traite les incidents pour une communauté nationale, diffuse des alertes et assure une coordination transfrontalière. En vertu de NIS2, chaque État membre de l'UE désigne au moins un CSIRT, et l'un d'eux joue le rôle de coordinateur de la divulgation coordonnée des vulnérabilités : un intermédiaire de confiance entre la personne qui signale une vulnérabilité et le fabricant.