Gestion des vulnérabilités NIS 2 au titre de l'article 21(2)(e)
La gestion des vulnérabilités a deux faces sous NIS 2. La manière dont vous traitez les faiblesses de vos propres systèmes. Et la manière dont vous traitez les faiblesses qui vous sont signalées. L'article 21(2)(e) est le siège de cette obligation, le CIR (UE) 2024/2690 §6.10 en précise les modalités, et le §30(2)(5) BSIG la transpose en droit allemand.
En bref
La gestion des vulnérabilités est le point (e) de la liste de l'article 21(2). Le CIR intitule la section correspondante « Traitement et divulgation des vulnérabilités ». Ce titre est révélateur. NIS 2 se soucie de deux choses à la fois : les faiblesses présentes dans les systèmes que vous exploitez, et les faiblesses que des tiers trouvent dans vos produits et veulent vous signaler.
Le CIR §6.10 énonce cinq actions. Recueillir l'information sur les vulnérabilités auprès des CSIRT, des autorités, des fournisseurs et des prestataires de services. Mener des analyses de vulnérabilités à une cadence documentée. Remédier sans délai aux vulnérabilités critiques. Articuler le traitement des vulnérabilités avec vos processus de gestion des changements, des correctifs, des risques et des incidents. Et mettre en place une procédure de divulgation coordonnée des vulnérabilités (CVD) alignée sur la politique CVD nationale.
L'Allemagne transpose la même règle en droit national par le §30(2)(5) BSIG. Le cadre CVD national passe par le programme de divulgation coordonnée CERT-Bund du BSI. NIS 2 lui-même met également en place une base de données européenne des vulnérabilités au titre de l'article 12, exploitée par l'ENISA, où les entités peuvent procéder à une divulgation volontaire.
Article 21(2)(e) de la directive NIS 2 (2022/2555)
La sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités.
Point (e) de la liste des dix mesures. Notez la formulation : le traitement et la divulgation des vulnérabilités s'inscrivent dans une obligation plus large autour de l'acquisition, du développement et de la maintenance. Le CIR la scinde en sections distinctes (§6.9 acquisition, §6.10 vulnérabilités). La moitié « divulgation » est celle qui est sous-estimée.
CIR (UE) 2024/2690, annexe §6.10
Les entités concernées obtiennent des informations sur les vulnérabilités techniques de leurs réseaux et systèmes d'information, évaluent leur exposition à ces vulnérabilités et prennent les mesures appropriées pour les gérer.
Droit de l'UE directement contraignant pour les secteurs cités dans l'annexe du CIR (DNS, TLD, cloud, centres de données, MSP, services de confiance et les autres). Le §6.10.2 énumère cinq actions concrètes. Le §6.10.3 dispose que lorsque vous renoncez à l'atténuation, vous en consignez la raison par écrit. Le §6.10.4 dispose que vous réexaminez périodiquement les canaux que vous utilisez pour surveiller l'information sur les vulnérabilités.
§30(2)(5) BSIG (Allemagne)
Les mesures de sécurité pour l'acquisition, le développement et la maintenance des systèmes, composants et processus de technologie de l'information, y compris la gestion et la divulgation des vulnérabilités.
L'Allemagne reprend le texte de l'UE. Le cadre CVD national passe par le programme de divulgation coordonnée CERT-Bund du BSI, ce à quoi renvoie en Allemagne la mention « aligné sur les politiques CVD nationales applicables » du CIR §6.10.2(e).
Faire entrer l'information
Suivez l'information sur les vulnérabilités auprès des CSIRT, des autorités, des fournisseurs et des prestataires de services. Menez des analyses de vulnérabilités à une cadence adaptée à votre environnement. Les outils d'analyse (Tenable, Qualys, Nessus, OpenVAS) sont le côté ingénierie. Les flux (lettre d'information CERT-Bund, avis des fournisseurs, NVD) sont le côté veille. Les deux sont nécessaires.
Corriger les critiques, documenter le reste
Les vulnérabilités critiques sont corrigées sans délai. Le traitement des vulnérabilités doit s'articuler avec votre gestion des changements, votre gestion des correctifs, votre gestion des risques et votre gestion des incidents. Lorsque vous décidez de ne pas atténuer, le §6.10.3 impose de créer un plan d'atténuation documenté ou de consigner par écrit pourquoi aucune action n'est nécessaire. Pas de retard silencieux.
Mener un processus de divulgation coordonnée
Établissez une procédure de réception des signalements de vulnérabilités émanant de tiers et de coordination de leur divulgation, alignée sur la politique CVD nationale applicable. Mécanique minimale : un canal de contact publié (boîte security@ ou un fichier security.txt), un délai d'accusé de réception, un calendrier de remédiation et une publication coordonnée. CERT-Bund servira d'intermédiaire si nécessaire.
Périodique, pas réactif
Le §6.10.2(b) dispose que les analyses ont lieu « périodiquement, selon les besoins ». Le §6.10.4 dispose que vous réexaminez périodiquement les canaux que vous utilisez pour surveiller l'information sur les vulnérabilités. Les deux formulations signifient : cadence écrite. Documentez la fréquence de vos analyses, documentez la fréquence de réexamen de votre liste de flux, et tenez-vous-y. Une analyse une fois par an parce que quelqu'un s'en est souvenu n'est pas périodique.
La divulgation coordonnée est une obligation, pas une option
Le §6.10.2(e) dispose que la procédure doit exister. Pas « si vous recevez des signalements ». La procédure existe pour que, lorsqu'un chercheur trouve effectivement quelque chose, il dispose d'un canal et vous d'un processus. Minimum viable : une boîte security@votredomaine.com que quelqu'un lit, un délai d'accusé de réception (couramment 7 jours) et un délai de divulgation (couramment 90 jours). Documentez-la, publiez-la, faites pointer un fichier security.txt vers elle.
BSI / programme CVD CERT-Bund
Le BSI exploite CERT-Bund, le CSIRT fédéral, et opère un programme de divulgation coordonnée des vulnérabilités. Les chercheurs peuvent signaler via CERT-Bund et le BSI coordonnera avec les fournisseurs concernés. Le §30(2)(5) BSIG renvoie à cela. Si vous mettez en place un processus CVD pour la première fois, aligner vos délais et vos canaux de contact sur le modèle CERT-Bund est l'option par défaut la plus sûre.
Base de données européenne des vulnérabilités (article 12 de NIS 2)
L'article 12 de NIS 2 met en place une base de données européenne des vulnérabilités exploitée par l'ENISA. Les entités peuvent y divulguer volontairement des vulnérabilités. Ce n'est pas un canal de notification obligatoire au titre de l'article 23. C'est une ressource de référence à l'échelle de l'UE qui agrège l'information sur les vulnérabilités à travers les États membres.
Les CSIRT nationaux comme coordinateurs CVD
Chaque État membre a son CSIRT national agissant comme coordinateur CVD (NCSC-NL aux Pays-Bas, CERT.at en Autriche, CCB en Belgique). L'obligation est la même à l'échelle de l'UE. Ce qui diffère : le CSIRT auquel vous vous adressez et la mécanique exacte de leur processus de coordination.
Nous appliquons les correctifs le Patch Tuesday, c'est suffisant.
Non. Le §6.10.2(c) dispose que les vulnérabilités critiques sont corrigées sans délai. Le Patch Tuesday est une cadence de publication des fournisseurs. Une faille zero-day divulguée un jeudi avec une exploitation active n'attend pas le mardi suivant. Il vous faut une cadence de correctifs pour les correctifs de routine et un processus hors cycle pour les problèmes critiques.
Nous n'avons pas de processus CVD parce que personne ne nous signale jamais de vulnérabilités.
Le §6.10.2(e) ne dit pas « mettez en place un processus quand les signalements commencent à arriver ». Il dit que la procédure doit exister. L'enjeu est de garantir que, lorsqu'un chercheur trouve effectivement quelque chose, il dispose d'un canal clair et que votre équipe sait quoi faire. Une boîte security@ et une politique d'une page suffisent à satisfaire l'obligation. Ne pas en avoir est un constat d'audit.
L'analyse des vulnérabilités, c'est le travail de l'équipe de sécurité.
Oui, jusqu'à ce que vous lisiez le §6.10.2(d) : le traitement des vulnérabilités doit être cohérent avec la gestion des changements, la gestion des correctifs, la gestion des risques et la gestion des incidents. Et le §6.10.4 : réexaminer les canaux à l'échelle de l'organisation. Cela fait de la gestion des vulnérabilités un processus transverse touchant l'exploitation informatique, le développement, le risque et l'organe de direction, pas une activité de sécurité cloisonnée.
Le côté ingénierie est en général dans un état raisonnable. La plupart des équipes informatiques du Mittelstand exploitent déjà un scanner (Tenable, Qualys, Nessus, OpenVAS) et ont une forme de cadence de correctifs, même si ce n'est que « Patch Tuesday pour les postes clients, trimestriel pour les serveurs ». Les obligations du CIR §6.10.2(a)+(b)+(c) consistent surtout à consigner par écrit ce qui se passe déjà et à resserrer le délai de correction des vulnérabilités critiques.
Le côté CVD est la moitié sous-documentée. Minimum réaliste : une boîte security@votredomaine.com routée vers deux personnes, une politique de divulgation d'une page (accuser réception sous 7 jours, divulguer sous 90 jours, créditer les chercheurs qui le souhaitent), et un fichier security.txt à /.well-known/security.txt pointant vers la boîte. Une demi-journée de travail. La partie que les audits signalent réellement.
Le module PRO capture votre inventaire de vulnérabilités, votre calendrier d'analyses, vos tâches de remédiation et vos décisions d'acceptation en un seul endroit. Chaque constat d'analyse est routé vers une tâche avec un titulaire, une date d'échéance et une validation. Le « documenter pourquoi aucune action n'est nécessaire » du §6.10.3 emprunte le même chemin de validation : justification écrite, approbateur nommé, piste d'audit. Pas de tableur séparé.
Nous livrons aussi un modèle de politique CVD (mise en place de la boîte security@, contenu du security.txt, délais d'accusé de réception et de divulgation alignés sur CERT-Bund). Vous y insérez votre domaine et vos contacts et l'obligation du §6.10.2(e) est couverte. Les signalements entrants sont routés vers le même pipeline de tâches que les constats d'analyse, de sorte que le délai de réponse est suivi de la même manière.
- Directive (UE) 2022/2555 (NIS 2), article 12 et article 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §6.10 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi BSI (BSIG), §30(2)(5) tel que modifié par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
- Programme de divulgation coordonnée des vulnérabilités BSI / CERT-Bund — bsi.bund.de
- Base de données européenne des vulnérabilités de l'ENISA (article 12 de NIS 2)