Devrions-nous publier les problèmes de sécurité que nous avons trouvés dans notre produit en tant que CVE ou pouvons-nous simplement les mettre à jour sur les notes de publication hebdomadaires?
Nous sommes un fournisseur fournissant un produit utilisé dans les entreprises. Nous savons que les entreprises qui effectuent des analyses CVE périodiques sur les produits utilisent une partie de leur processus de gestion des vulnérabilités. Ma question est, devons-nous augmenter un CVE si notre propre chercheur en sécurité a trouvé une vulnérabilité dans notre produit ou nous pouvons simplement augmenter cette vulnérabilité dans les mises à jour de sécurité hebdomadaires que nous publions sur notre site officiel?
Vous pouvez le faire soit, mais je recommande de demander un CVE afin que les clients qui reçoivent des flux de renseignements sur les menaces soient plus susceptibles de remarquer le problème et d'accélérer un correctif. L'attribution d'un CVE facilite également la référence à une vulnérabilité spécifique dans les communications générales si vous en avez besoin ultérieurement. C'est également un signal pour vos clients que vous prenez la transparence de la sécurité au sérieux.
Les CVE sont attribués et gérés par MITRE, et vous pouvez utiliser le formulaire de demande CVE pour faire une demande.
Il serait utile de publier le CVE pour que les autres sachent qu'il est nécessaire de le mettre à jour: comme vous l'avez dit, ils peuvent le voir dans les flux de renseignements sur les menaces (ou les analyses CVE) au lieu d'avoir à lire le journal des modifications de chaque mise à jour pour décider s'ils doivent mise à jour.
De plus, en tant que pentester, il nous aide beaucoup dans notre travail. Si nous trouvons SAPConnectorDeluxe 4.1.39, la première chose que nous faisons est de vérifier une base de données CVE pour toute vulnérabilité. Même si le logiciel est propriétaire et n'est utilisé que par quelques sociétés, il nous est utile de connaître les risques liés à l'exécution de ce logiciel afin de pouvoir conseiller correctement le client.
Il nous indique également la fréquence et le type de problèmes rencontrés: si nous constatons qu'un petit composant logiciel avait 10 vulnérabilités de débordement de tampon au cours de la dernière année, nous savons que les développeurs n'ont pas le temps d'inclure la sécurité dans leur processus de développement . Dans un tel cas, il est très probable que davantage de vulnérabilités soient détectées ou soient déjà détectées par des parties malveillantes.
La soumission de CVE n'est pas courante si le logiciel n'est utilisé qu'en interne. Si nous trouvons un logiciel personnalisé, nous faisons une analyse (en fonction du temps dont nous disposons) et conseillons à quelqu'un d'examiner sa sécurité de manière plus approfondie. Les informations sur les produits internes n'aideraient personne en dehors de l'entreprise, il n'est donc pas nécessaire de les publier dans une base de données centrale comme CVE.
Vous n'êtes pas obligé de demander une CVE, mais vous êtes libre de le faire lorsque vous pensez que cela sera bénéfique.
Un CVE n'est qu'un numéro central qui identifie une vulnérabilité, ce qui peut aider lors de la communication sur les vulnérabilités. Les CVE sont particulièrement utiles lorsque plusieurs parties sont impliquées. Tout le monde peut demander un CVE dans votre produit, mais à mon avis, il est préférable que vous le fassiez vous-même avant quelqu'un d'autre.
Je pense que la question la plus importante est de savoir si votre produit est livré avec une mise à jour automatique. S'il se met à jour automatiquement par défaut, un CVE peut parfois faire plus de mal que de bien en plaçant votre produit dans le domaine de la sensibilisation de nombreux pirates qui, autrement, ne sauraient même pas que vous existez. Ils peuvent voir votre historique CVE et avoir une bonne idée de votre posture de sécurité. S'ils voient beaucoup de correctifs pour les erreurs "amatures", alors votre produit pourrait facilement être examiné par des personnes qui savent comment trouver les choses les plus obscures que vous auriez pu avoir la chance d'éviter.
En outre, les produits qui ne seront probablement pas corrigés même si vous publiez un CVE peuvent faire plus de mal que de bien. La plupart des appareils IoT ne sont jamais corrigés, donc les CVE indiquent simplement aux pirates quels sont des proies faciles.
En revanche, si votre produit nécessite généralement une mise à jour manuelle susceptible de se produire si vous publiez un CVE, vous devriez probablement le faire.
S'il s'agit d'un problème vraiment critique, vous pouvez corriger le problème et le garder secret aussi longtemps que possible.
Les clients disposent alors d'un délai plus long pour appliquer les mises à jour logicielles.
Assurez-vous également d'utiliser autant d'obscurcissement binaire que possible, afin d'empêcher la "rétro-ingénierie différentielle" après la livraison du patch.
Peu d'entreprises appliqueront des correctifs immédiatement, la plupart bénéficieront d'un contrôle qualité et d'une évaluation avant toute mise à jour de leurs systèmes. La définition CVE leur permet de connaître les vulnérabilités de la version actuelle du logiciel. Il peut ensuite évaluer cette vulnérabilité et faire un choix éclairé du moment où il appliquera la mise à jour.