PSIRT : le rôle d'une équipe de réponse aux incidents de sécurité produit

Qu'est-ce qu'un PSIRT ?

Un Product Security Incident Response Team (PSIRT) est la fonction qui traite les vulnérabilités de sécurité des produits qu'une entreprise fabrique et vend. FIRST le définit comme une entité axée sur l'identification, l'évaluation et le traitement des risques liés aux vulnérabilités de sécurité des produits, y compris les offres, solutions, composants et services.

En pratique, un PSIRT :

• gère le canal par lequel chercheurs, clients et partenaires signalent des vulnérabilités ;
• surveille les vulnérabilités des composants tiers et open source présents dans ses produits ;
• trie chaque signalement : est-il fondé, quels produits et versions touche-t-il, quelle est sa gravité ;
• fait corriger le problème par l'équipe d'ingénierie responsable, selon un calendrier adapté au risque ;
• publie des avis de sécurité et coordonne la divulgation avec les découvreurs et les éditeurs en aval ;
• présente des métriques à la direction et forme les personnes qui construisent les produits.

L'essentiel du travail a lieu après la release. FIRST note que la plupart des vulnérabilités de produits sont signalées, une fois le produit sur le marché, comme des défauts de qualité passés au travers des contrôles, même si un PSIRT apporte aussi de la valeur plus tôt, lors des revues de conception et de la modélisation des menaces.

La place d'un PSIRT dans l'organisation

Ce qui le distingue des autres équipes de sécurité, c'est sa focalisation sur les produits. Un CSIRT d'entreprise protège les systèmes et réseaux de l'entreprise ; un PSIRT protège les clients qui utilisent ses produits. Les deux partagent des compétences et souvent une ligne hiérarchique, et ils se rencontrent lorsqu'un incident dans l'infrastructure de l'entreprise, comme un système de build compromis, atteint un produit. La comparaison complète figure dans PSIRT vs CSIRT.

FIRST décrit trois modèles opérationnels :

• Distribué : un petit PSIRT central définit la politique et coordonne, et des représentants sécurité dans chaque équipe produit assurent le tri et les corrections. Ce modèle s'adapte à un portefeuille vaste et varié, mais les personnes qui font le travail ne dépendent pas du PSIRT.
• Centralisé : un PSIRT plus important, avec ses propres équipes de gestion de programme, de tri et de remédiation, rattaché à un cadre dirigeant chargé de la sécurité produit. Il convient aux petites entreprises ou à un portefeuille homogène et coûte plus cher à mesure que le portefeuille grandit.
• Hybride : un mélange des deux, choisi selon la taille de l'entreprise, le portefeuille et la stratégie de développement.

Quel que soit le modèle, FIRST insiste sur l'indépendance : le PSIRT doit rendre compte à un dirigeant qui confirme son autorité, afin de pouvoir adopter une position objective sur les vulnérabilités des produits de l'entreprise.

Le FIRST PSIRT Services Framework

Le PSIRT Services Framework, publié gratuitement par FIRST et désormais en version 1.1, est la référence sur laquelle la plupart des PSIRT construisent leur catalogue de services. Il pose des fondations opérationnelles (mandat, parties prenantes, budget, politiques), puis six domaines de services :

Domaine de services	Ce qu'il couvre
1. Gestion de l'écosystème des parties prenantes	Parties prenantes internes, communauté des découvreurs, éditeurs en aval et clients, communication sur les incidents, reconnaissance des découvreurs, métriques sur les parties prenantes
2. Découverte des vulnérabilités	Réception des signalements de vulnérabilités, recherche de vulnérabilités non signalées, surveillance des vulnérabilités des composants de produits, identification de nouvelles vulnérabilités, métriques de découverte
3. Tri et analyse des vulnérabilités	Qualification des signalements, collaboration avec les découvreurs reconnus, reproduction des vulnérabilités
4. Remédiation	Plan de gestion de la publication des correctifs, remédiation, gestion des incidents, métriques de publication
5. Divulgation des vulnérabilités	Notification, coordination, divulgation par des avis de sécurité, métriques de divulgation
6. Formation et sensibilisation	Formation du PSIRT, des équipes de développement et de validation et des autres parties prenantes ; mécanismes de retour d'information

Un service mérite d'être distingué, car il représente désormais une grande part du travail : la surveillance des vulnérabilités des composants de produits. Sa première fonction est un inventaire des composants de produits, une liste des fournisseurs, produits et versions inclus dans chaque produit, que FIRST juge essentiel pour identifier rapidement les produits touchés par des vulnérabilités héritées. Dans un logiciel moderne, cet inventaire est une nomenclature logicielle (SBOM).

Le processus PSIRT en bref

Deux normes ISO/IEC décrivent le processus. ISO/IEC 30111:2019 couvre la façon dont un éditeur traite les vulnérabilités en interne. ISO/IEC 29147:2018 couvre la façon dont il reçoit les signalements externes et publie les informations de remédiation. La norme 30111 est conçue pour être utilisée avec la 29147, et les phases qu'elle décrit donnent un plan utile :

1. Préparation. Politique, rôles, moyen publié de signaler les vulnérabilités, méthode de notation, inventaire de ce qui est livré.
2. Réception. Recueillez les signalements des chercheurs, des clients, des partenaires et de vos propres tests, ainsi que les avis de sécurité sur les composants que vous utilisez. Accusez réception auprès du découvreur.
3. Vérification. Confirmez la vulnérabilité, reproduisez-la, notez-la et déterminez chaque produit et version touchés. Enregistrez aussi les produits non touchés, et pourquoi.
4. Développement de la remédiation. L'équipe responsable construit et teste un correctif ou une atténuation. Le PSIRT en suit l'avancement par rapport au calendrier convenu.
5. Publication. Livrez le correctif et publiez l'avis de sécurité, en coordination avec le découvreur et les éditeurs en aval qui intègrent votre produit.
6. Post-publication. Surveillez les problèmes liés au correctif, répondez aux clients et réinjectez les causes profondes dans le développement.

Chaque étape, avec ce qu'il faut enregistrer et qui en est responsable, est couverte dans le cycle de vie de la gestion des vulnérabilités. Pour décider quelles vulnérabilités traiter en premier, consultez la priorisation des vulnérabilités, avec les signaux d'exploitation d'EPSS et le catalogue CISA KEV. Une vulnérabilité exploitée avant l'existence d'un correctif est une zero-day, et le PSIRT la gère comme un incident. Le passage d'un avis de sécurité à un build corrigé et livré est couvert dans la remédiation des CVE.

Divulgation et avis de sécurité

La divulgation est la partie du PSIRT que voient les clients. La pratique habituelle est la divulgation coordonnée des vulnérabilités : le découvreur signale en privé, l'éditeur corrige, et les deux publient à une date convenue, le découvreur étant crédité. Elle commence par une politique publique de divulgation des vulnérabilités, qui indique comment signaler, ce que les découvreurs peuvent attendre et combien de temps les produits sont pris en charge. Consultez la divulgation coordonnée des vulnérabilités.

Un bon avis de sécurité indique à un client, sans coup de téléphone :

• quels produits et versions sont touchés, et lesquels ne le sont pas ;
• l'identifiant CVE et un score de gravité ;
• la version corrigée, ou une atténuation s'il n'existe pas encore de correctif ;
• qui a trouvé la vulnérabilité.

Les grands clients veulent de plus en plus des avis lisibles par machine, qu'ils peuvent confronter automatiquement à leur propre inventaire d'actifs. CSAF est le format standard OASIS pour les avis de sécurité, et VEX est le moyen d'indiquer qu'un produit n'est pas touché par une vulnérabilité de l'un de ses composants, ce qui épargne un ticket aux deux parties.

Métriques et maturité d'un PSIRT

Le cadre prévoit des métriques dans chaque domaine de services. Les plus courantes :

• le délai pour accuser réception d'un signalement, le trier et publier un correctif, par gravité ;
• les vulnérabilités ouvertes par produit, gravité et ancienneté ;
• la part de correctifs livrés dans le respect des objectifs de remédiation que vous avez publiés ;
• les vulnérabilités trouvées en interne par rapport à celles signalées de l'extérieur ;
• les avis de sécurité publiés et les corrections apportées à ces avis.

Le document complémentaire de FIRST, le PSIRT Maturity Document, répartit les services en trois niveaux :

• Niveau 1, basique : parrainage de la direction, parties prenantes, budget et politiques ; un moyen de recevoir les signalements ; un workflow de tri ; des corrections documentées ; des avis de sécurité qui utilisent CVE et CVSS et créditent le découvreur.
• Niveau 2, intermédiaire : une charte et un modèle d'organisation, des métriques de référence, un registre de produits avec cartographie des dépendances, un plan de remédiation formel, un système de notification des parties prenantes et la formation de l'équipe.
• Niveau 3, avancé : un engagement direct avec la communauté des découvreurs, la surveillance des vulnérabilités des composants de produits, des métriques de découverte et de publication, une gestion avancée des incidents et des playbooks de coordination sectorielle.

Le passage d'un niveau à l'autre va du réactif au proactif.

Comment créer un PSIRT : commencez petit

1. Obtenez un mandat écrit d'un dirigeant, avec l'autorité de demander aux équipes produit de corriger.
2. Publiez la façon de signaler une vulnérabilité : une adresse de contact sécurité, un formulaire web ou un fichier security.txt, et une courte politique de divulgation.
3. Définissez le tri et la notation : qui décide si un signalement est valide, comment la gravité est notée, et les objectifs de remédiation par gravité.
4. Sachez ce que vous livrez. Pour chaque version de produit, les composants et versions qu'elle contient. Sans cela, chaque nouvelle CVE dans une bibliothèque populaire se transforme en plusieurs jours de questions aux équipes d'ingénierie.
5. Nommez un responsable par produit, qui reçoit les vulnérabilités détectées et planifie les corrections.
6. Rédigez un modèle d'avis de sécurité et publiez le premier, même pour un problème mineur.
7. Mesurez quelques délais dès le début, pour pouvoir montrer les progrès.

La page équipes PSIRT aborde le rôle du point de vue du responsable de la sécurité produit, et les éditeurs industriels peuvent rattacher ces étapes à IEC 62443-4-1, dont les exigences de cycle de vie de développement sécurisé incluent la gestion des défauts et la gestion des correctifs.

Les réglementations qui attendent un PSIRT

Un PSIRT était autrefois la marque d'un éditeur mature. Plusieurs cadres exigent désormais ce qu'il produit. L'article 21(2)(e) de NIS2 cite le traitement et la divulgation des vulnérabilités parmi les mesures que les entités essentielles et importantes doivent prendre. Aux États-Unis, la section 524B impose aux fabricants de dispositifs médicaux de soumettre un plan de surveillance, d'identification et de traitement des vulnérabilités post-commercialisation, y compris la divulgation coordonnée des vulnérabilités, ainsi qu'une SBOM. Et le Cyber Resilience Act de l'UE impose aux fabricants de signaler aux autorités les vulnérabilités activement exploitées et les incidents graves, à commencer par une alerte précoce sous 24 heures ; consultez qu'est-ce que le CRA.

Les outils dont un PSIRT a besoin

Besoin	Pourquoi
Réception des signalements et suivi des dossiers	Chaque signalement a un responsable, un statut et un calendrier
Inventaire de ce qui est livré	Une SBOM exacte par version de produit, dépendances transitives comprises
Surveillance continue	Les nouvelles CVE sont confrontées aux composants de chaque version publiée, pas seulement de la prochaine
Tri et routage	Les vulnérabilités détectées vont à l'équipe responsable de la correction, avec le contexte nécessaire pour agir
Déclarations « touché » et « non touché »	VEX enregistre quels produits une vulnérabilité touche et pourquoi les autres ne sont pas touchés
Publication des avis de sécurité	Des avis lisibles par l'humain, et du CSAF lisible par machine pour les grands clients

Peu de produits couvrent toutes les lignes ; le comparatif des outils PSIRT montre quel outil fait quoi. L'inventaire est le point faible de la plupart des PSIRT. Un scanner qui lit les lockfiles après coup liste des dépendances de développement jamais livrées et manque des paquets que le build a téléchargés hors du gestionnaire de paquets : la réponse à « sommes-nous touchés ? » commence donc par un doute.

CRACI tire cet inventaire du build lui-même. Il exécute les builds GitHub Actions sur ses propres runners et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets restaurés depuis les caches CI et les dépendances qu'aucun lockfile ne liste. Chaque SBOM porte un état de complétude et s'exporte en CycloneDX ou SPDX. Les SBOM surveillées sont réévaluées en continu à mesure que de nouvelles vulnérabilités sont publiées, l'historique des builds montre quels builds passés contenaient une dépendance vulnérable, et la vue d'inventaire montre quelles versions logicielles sont déployées sur quels produits. Les équipes de sécurité trient les vulnérabilités détectées et les envoient aux équipes responsables de la correction, et CRACI prend en charge VEX. Consultez le suivi des vulnérabilités et CRACI pour les équipes PSIRT.

PSIRT : questions fréquentes

Que signifie PSIRT ?

PSIRT signifie Product Security Incident Response Team. FIRST le définit comme une entité au sein d'une organisation qui se concentre sur l'identification, l'évaluation et le traitement des risques liés aux vulnérabilités de sécurité des produits, offres, solutions, composants et services que l'organisation produit ou vend.

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

Un PSIRT traite les vulnérabilités des produits qu'une entreprise livre à ses clients. Un CSIRT d'entreprise traite les incidents de sécurité dans les systèmes et réseaux de l'entreprise. Les deux travaillent ensemble, par exemple lorsqu'une compromission de l'infrastructure de build touche un produit. Consultez PSIRT vs CSIRT.

Qu'est-ce que le FIRST PSIRT Services Framework ?

Un guide gratuit de FIRST, le Forum of Incident Response and Security Teams, qui liste les services qu'un PSIRT peut fournir. La version 1.1 les regroupe en six domaines : 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, formation et sensibilisation. Un document complémentaire sur la maturité répartit les services en trois niveaux.

Quelles normes décrivent le processus PSIRT ?

ISO/IEC 30111:2019 couvre la façon dont un éditeur traite les signalements de vulnérabilités en interne, de la préparation et de la réception à la vérification, au développement de la remédiation, à la publication et à la post-publication. ISO/IEC 29147:2018 couvre l'interface avec l'extérieur : la réception des signalements et la publication des informations de remédiation. La norme 30111 est conçue pour être utilisée avec la 29147. IEC 62443-4-1 fixe des exigences de cycle de vie de développement sécurisé, y compris la gestion des défauts et des correctifs, pour les produits d'automatisation industrielle.

Une petite entreprise a-t-elle besoin d'un PSIRT ?

Elle a besoin de la fonction, pas forcément d'un département. Le document de maturité de FIRST commence par un parrainage de la direction, des parties prenantes identifiées, un budget, quelques politiques, un moyen publié de signaler les vulnérabilités, un workflow de tri, des corrections documentées et des avis de sécurité qui créditent le découvreur. Une ou deux personnes dotées d'un mandat écrit peuvent s'en charger.

De quels outils un PSIRT a-t-il besoin ?

Au minimum : un moyen de recevoir les signalements, un outil de suivi des dossiers, une méthode de notation des vulnérabilités, un inventaire des composants livrés dans chaque version de produit, une surveillance de ces composants face aux nouvelles vulnérabilités, un moyen d'enregistrer si chaque produit est touché (souvent sous forme de VEX) et un moyen de publier des avis de sécurité, de plus en plus en CSAF.