_edited.png)
Le développement interne de solutions logicielles permet aux entreprises de répondre à leurs besoins spécifiques ou à ceux de leurs clients sans acheter ou sous-licencier de solutions auprès d’organismes tiers. A ce titre, les entreprises éditrices sont responsables du développement, de la maintenance et de la sécurité des solutions logiciels développées. En matière de sécurité, les éditeurs doivent intégrer dès la conception de leurs solutions des mesures de gouvernance et de gestion technique de la sécurité de leur système d’information. Ainsi, la mise en œuvre d’un SMSI (i.e. Système de Management de la Sécurité de l’information) performant nécessite, en autres choses, de rester attentifs aux potentielles failles de sécurité ou vulnérabilités présentent dans leurs logiciels.
En-dehors du développement sécurisé des solutions logicielles, de la surveillance des vulnérabilités et de leur résolution technique, il peut s’avérer nécessaire de déclarer publiquement une vulnérabilité. En effet, attribuer un numéro CVE (i.e. Common Vulnerabilities and Exposure) à la faille de sécurité, permet d’assurer une transparence à l’égard de vos clients en développant la confiance qu’il vous porte, d’assurer votre conformité réglementaire, et de prévenir l’exploitation de la vulnérabilité en proposant et diffusant des correctifs adéquats ou des alternatives de sécurité pertinentes.
Afin de pouvoir réagir efficacement et fournir aux autorités compétentes l’ensemble des informations nécessaires en vue de la publication d’une vulnérabilité dans votre solution logicielle, vous devez établir une procédure de divulgation des vulnérabilités qui doit être validée par la direction.
Quelles sont les vulnérabilités qui nécessitent de faire l'objet d'une publication ?
Les identifiants CVE ne sont attribués qu’aux failles de sécurité qui répondent à un ensemble de critères spécifiques. Ainsi, vous devez vous assurer de pouvoir offrir une correction indépendante de toute autre vulnérabilité, et qu’il n’existe pas de solution de contournement de ladite vulnérabilité. Il est également nécessaire de reconnaître publiquement que cette vulnérabilité conduit à une baisse notable de la sécurité de vos produits.
Comprendre le fonctionnement des autorités de numérotation des CVE (CNA)
Les CNA (i.e. CVE Numbering Authority) sont les autorités en charge d’attribuer les numérotations aux CVE découvertes. Lorsqu’une faille de sécurité est détectée par un éditeur dans son propre logiciel et qu’elle répond à l’ensemble des critères susmentionnés, il est alors nécessaire de soumettre une demande permettant d’obtenir un numéro d’identification (CVE) de la vulnérabilité auprès d’une autorité de numérotation. Celle-ci se chargera d’étudier votre demande et de publier la vulnérabilité si toutes les informations requises lui sont soumises.
Les CNAs sont des autorités de natures diverses, chargées de détecter et publier des vulnérabilités. Elles sont toutes coordonnées par la MITRE Corporation, l’autorité racine en dernier recours (CNA-LR). MITRE supervise l’ensemble du programme CVE et propose un registre complet des vulnérabilités publiées à l’échelle internationale.
Il n’est ainsi pas possible de publier une sans l’attribution préalable d’un identifiant CVE par une CNA. La numérotation d’une CVE est composée d’une nomenclature bien spécifique débutant par l’acronyme CVE, suivi de l’année de publication de la CVE, et enfin de l’identifiant (ou du numéro) de la vulnérabilité. Les CVE s’apparentent à un enregistrement et une codification des vulnérabilités qui permettent aux organismes d’assurer une veille des vulnérabilités, d’implémenter des mesures préventives ou des correctifs, et, plus généralement, de simplifier le suivi des vulnérabilités.
Choisir une autorité de numérotation des CVE
Vous ne pouvez pas divulguer de vulnérabilités auprès de n’importe laquelle CNA. En effet, elles ont chacune une portée et une responsabilité ou compétence spécifique. Certaines sont dédiées à des types de produits particuliers, d’autres à des fournisseurs spécifiques, ou encore à des rapporteurs spécifiques.
Exemples :
La portée de la CNA Apple Inc. se résume seulement aux vulnérabilités Apple.
La portée de la CNA AppCheck Ltd. se résume seulement aux vulnérabilités découvertes par AppCheck et n’entrant pas dans le champ d’une autre CNA.
La portée de la CNA Indian Computer Emergency Response Team (CERT-In) se résume seulement aux vulnérabilités ayant un impact sur tous les produits conçus, développés et fabriqués en Inde.
Ainsi, vous devez trouver dans la liste des CNAs partenaires du MITRE les CNAs dont la portée correspond au contexte de votre organisme et à la nature de la vulnérabilité détectée dans votre logiciel.
Si vous êtes un éditeur de logiciel, vous devez rechercher dans la liste du MITRE des CNAs dont la portée recouvre un ou plusieurs des critères suivants :
Une CNA dont la portée s’applique dans votre région ;
Une CNA qui vous permet de signaler vous-même la vulnérabilité ;
Une CNA qui ne porte pas sur un type ou sur une marque de produit en particulier.
En dernier recours, si vous ne trouvez pas de CNAs dont la portée vous permet de soumettre une demande, vous pouvez demander un numéro d’identification de la vulnérabilité auprès du MITRE Corporation, dont la compétence recouvre les « vulnérabilités des produits logiciels Open Source, non déjà couvertes par un CNA répertoriée ».
Les étapes clés du processus de publication d'une vulnérabilité
Tout au long du processus de publication de la vulnérabilité, il est essentiel d’assurer l’ensemble de vos obligations réglementaires que ce soit en matière de protection des données personnelles ou de respect des normes de référence en matière de cybersécurité. Gardez toujours les traces de journaux et autres documents conformément à votre procédure ou politique de gestion des vulnérabilités ainsi que l’historique de vos communications avec le CNA.
Les informations requises par l'autorité de numérotation
Pour signaler une vulnérabilité à une CNA ou au MITRE Corporation, vous devez fournir un ensemble de documents et renseignements concernant la vulnérabilité détectée dans votre produit. Il s’agit par exemple de précisions sur votre solution (type, nom, versions, etc.), la cause et l’impact de la vulnérabilité sur la sécurité de votre produit ainsi que les types d’attaques encourues si un correctif n’est pas mis en œuvre. Il est également obligatoire de soumettre un lien ou une référence publique permettant de synthétiser l’ensemble de vos connaissances sur la vulnérabilité détectée, sans quoi votre vulnérabilité ne sera pas publiée.
Les différents statuts de la demande de la publication des vulnérabilités
Lorsque vous effectuez une demande de publication auprès d’une CNA pertinente pour la vulnérabilité que vous avez détectée dans votre solution logicielle, l’autorité attribue un numéro d’identification de la CVE. Tant que vous n’avez pas communiqué à l’autorité l’ensemble des informations requises, votre identifiant est classé comme « Attribué » puis « Réservé » par la CNA.
Une fois toutes les informations transmises, si la vulnérabilité n'est pas confirmée ou si elle ne concerne pas un produit couvert par la CNA, l’identifiant CVE peut être classé comme « rejeté ».
En revanche, si la CNA valide les informations, l’identifiant CVE attribué à votre vulnérabilité est publié et classé comme tel.
Une fois publiée, si certaines informations doivent être revues ou si d’autres doivent venir compléter les informations initialement publiées, vous pouvez soumettre au CNA compétent (celui en charge de la publication initiale de la vulnérabilité) une demande de mise à jour des informations relatives à la vulnérabilité.
Pour conclure
Le processus de publication des vulnérabilités découvertes dans une solution logicielle nécessite d’être formalisé dans une procédure de publication des vulnérabilités. Celle-ci vous permettra de réagir rapidement et efficacement en cas de découverte d’une faille de sécurité dans votre produit. Néanmoins, cette procédure s’imbrique dans un ensemble plus large d’outils et de documents nécessaires à la mise en œuvre d’une bonne gouvernance de votre SMSI. En effet, les politiques et procédures de gestion des événements de sécurité, de gestion des incidents et des vulnérabilités sont autant de documents qu’il est nécessaire de tenir à jour pour parvenir à une gestion adéquate des failles de sécurité dans vos produits.
Articles complémentaires :
Vous avez apprécié cet article de blog ?
Retrouvez plus de contenus en rapport avec la cybersécurité et la conformité réglementaire au RGPD sur le blog de CyberSecura !
Nous avons besoin de vos réponses !
En répondant à cette enquête, vous nous permettez de mieux comprendre vos interactions avec notre site ainsi que vos potentiel besoins.
Vos réponses sont anonymes, et à moins que vous ne demandiez à être re-contacté(e) par nos équipes, aucune information personnelle ne vous est demandée !
Merci pour vos réponses !
Vous souhaitez être informé(e) de nos actualités, et recevoir nos derniers articles de blog directement dans votre boite mail ? Abonnez-vous à notre newsletter mensuelle !
Vous souhaitez discuter de vos difficultés, de vos besoins, de nos offres ? Demandez à être contacté, gratuitement et sans engagement, par l'un de nos expert en cybersécurité !