Contenu
- Juste les faits
- Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire
- Comptabilisation de l'impact?
- Il est temps de changer le système?
Source: BrianAJackson / iStockphoto
À emporter:
Il est temps de modifier notre vision de l’évaluation du risque pour les composants open source.
Développer un système pour évaluer le sérieux avec lequel la communauté du développement logiciel devrait prendre les vulnérabilités est un défi, pour le dire à la légère. Le code est écrit par des humains et aura toujours des défauts. La question qui se pose alors, si nous supposons que rien ne sera jamais parfait, est de savoir comment classer au mieux les composants en fonction de leur risque, de manière à nous permettre de continuer à travailler de manière productive.
Juste les faits
Il existe de nombreuses approches différentes pour aborder ce problème, chacune avec sa propre justification valable, mais la méthode la plus courante semble être basée sur un modèle quantitatif.
D'une part, le recours à une approche quantitative pour évaluer la gravité d'une vulnérabilité peut être utile car il est plus objectif et mesurable, en fonction des seuls facteurs liés à la vulnérabilité elle-même.
Cette méthodologie examine le type de dommages pouvant survenir si la vulnérabilité était exploitée, en fonction de la fréquence d'utilisation du composant, de la bibliothèque ou du projet dans l'ensemble du secteur du logiciel, ainsi que de facteurs tels que le type d'accès que ce produit pourrait donner à un attaquant les dégâts causés par l'épave devraient-ils l'utiliser pour percer leur cible? Des facteurs tels que l’exploitabilité potentielle facile peuvent jouer un rôle important dans l’affectation du score. (Pour plus d'informations sur la sécurité, consultez Cybersécurité: comment les nouvelles avancées apportent de nouvelles menaces - et vice-versa.)
Si nous voulons regarder au niveau macro, la perspective quantitative examine comment une vulnérabilité pourrait nuire au troupeau, en se concentrant moins sur les dommages pouvant toucher les entreprises qui sont réellement touchées par l'attaque.
La base de données nationale de vulnérabilité (NVD), peut-être la base de données de vulnérabilités la plus connue, adopte cette approche pour les versions 2 et 3 de leur système de score de vulnérabilité commun (CVSS). Sur leur page expliquant leurs mesures d'évaluation des vulnérabilités, ils écrivent au sujet de leur méthode:
Son modèle quantitatif assure une mesure précise reproductible tout en permettant aux utilisateurs de voir les caractéristiques de vulnérabilité sous-jacentes qui ont été utilisées pour générer les scores. Ainsi, CVSS convient parfaitement comme système de mesure standard pour les industries, les organisations et les gouvernements qui ont besoin de scores d’impact de vulnérabilité précis et cohérents.
Sur la base des facteurs quantitatifs en jeu, le NVD est alors en mesure d’obtenir un score de sévérité, avec un chiffre sur l’échelle - 1 à 10, 10 étant le plus grave - ainsi que dans les catégories LOW, MEDIUM et HIGH. .
Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire
Vous ne pouvez pas améliorer vos compétences en programmation lorsque personne ne se soucie de la qualité des logiciels.
Comptabilisation de l'impact?
Cependant, le NVD semble s'efforcer d'éviter ce qu'on peut appeler une mesure qualitative de la vulnérabilité, en fonction de l'impact qu'un certain exploit a eu sur les dommages. Pour être juste, ils intègrent l'impact dans la mesure où ils mesurent l'impact de la vulnérabilité sur le système, en examinant les facteurs de confidentialité, d'intégrité et de disponibilité. Ce sont tous des éléments importants à examiner - comme le vecteur d’accès, la complexité de l’accès et l’authentification plus facilement mesurables - mais ils ne se sentent pas à la hauteur de la tâche de relier l’impact sur le monde réel lorsqu’une vulnérabilité entraîne des pertes réelles pour une organisation.
Prenons, par exemple, l'infraction d'Equifax qui a révélé les informations personnellement identifiables de quelque 145 millions de personnes, notamment les détails de leur permis de conduire, leurs numéros de sécurité sociale et d'autres éléments pouvant être utilisés par des personnages peu scrupuleux pour mener des opérations de fraude massives.
C'est la vulnérabilité (CVE-2017-5638) découverte dans le projet Apache Struts 2 qu'Equifax a utilisé dans son application Web qui a permis aux attaquants de franchir la porte d'entrée et de se sortir les bras chargés d'informations personnelles juteuses. .
Bien que le NVD lui ait attribué à juste titre un score de gravité de 10 et HIGH, sa décision était due à son évaluation quantitative des dommages potentiels et n’était pas affectée par les dommages importants qui ont été commis plus tard, lorsque la violation d’Equifax est devenue publique.
Ce n'est pas un oubli du NVD, mais une partie de sa politique déclarée.
Le NVD fournit les "scores de base" CVSS qui représentent les caractéristiques innées de chaque vulnérabilité. Nous ne fournissons pas actuellement de "scores temporels" (mesures qui changent au fil du temps en raison d'événements extérieurs à la vulnérabilité) ni de "scores environnementaux" (scores personnalisés pour refléter l'impact de la vulnérabilité sur votre organisation).
Pour les décideurs, le système de mesure quantitative devrait avoir moins d’importance, car il examine les risques de propagation des dommages dans l’industrie. Si vous êtes le CSO d’une banque, vous devez vous préoccuper de l’impact qualitatif qu’un exploit peut avoir s’il est utilisé pour exploiter les données de vos clients, ou pire, leur argent. (Découvrez les différents types de vulnérabilités dans Les 5 menaces les plus effrayantes de la technologie.)
Il est temps de changer le système?
La vulnérabilité dans Apache Strusts 2 utilisée dans l’affaire Equifax devrait-elle être mieux classée compte tenu de l’ampleur des dommages, ou bien rendre ce changement beaucoup trop subjectif pour un système comme le NVD suivre?
Nous concédons qu’il serait extrêmement difficile de disposer des données nécessaires à l’établissement d’un «score environnemental» ou d'un «score temporel», ce qui serait extrêmement difficile, ce qui ouvrirait les gestionnaires de l'équipe de CVSS libre à une critique sans fin et à une tonne de travail. NVD et d’autres pour la mise à jour de leurs bases de données au fur et à mesure de la diffusion de nouvelles informations.
Bien sûr, la question se pose de savoir comment un tel score serait compilé, car très peu d’organisations sont susceptibles de fournir les données nécessaires sur l’impact d’une violation sauf si la loi sur la divulgation les y oblige. Nous avons vu dans le cas d’Uber que les entreprises sont disposées à payer rapidement dans l’espoir d’empêcher que les informations relatives à une violation ne soient communiquées à la presse de peur de subir un contrecoup public.
Peut-être que ce qui est nécessaire est un nouveau système qui pourrait incorporer les bons efforts des bases de données de vulnérabilité et ajouter leur propre score supplémentaire lorsque les informations deviennent disponibles.
Pourquoi créer cette couche supplémentaire de résultats alors que la précédente semble avoir suffisamment bien fait son travail pendant toutes ces années?
Franchement, il en va de la responsabilité des organisations d'assumer la responsabilité de leurs applications. Dans un monde idéal, tout le monde vérifierait les scores des composants utilisés dans leurs produits avant de les ajouter à leur inventaire, recevrait des alertes lorsque de nouvelles vulnérabilités seraient découvertes dans des projets précédemment considérés comme sûrs, et implémenterait les correctifs nécessaires de manière autonome. .
Peut-être que si une liste montrait à quel point certaines de ces vulnérabilités pourraient être dévastatrices pour une organisation, les organisations pourraient alors ressentir davantage de pression pour ne pas se laisser prendre à des composants risqués. À tout le moins, ils pourraient prendre des mesures pour dresser un inventaire réel des bibliothèques à code source ouvert dont ils disposent déjà.
À la suite du fiasco d’Equifax, plus d’un dirigeant au niveau C s’efforçait sans doute de s’assurer qu’ils ne possédaient pas la version vulnérable de Struts dans leurs produits. Il est regrettable qu’un incident de cette ampleur ait été nécessaire pour pousser l’industrie à prendre au sérieux sa sécurité open-source.
Espérons que la leçon que les vulnérabilités des composants open-source de vos applications peuvent avoir des conséquences réelles aura une incidence sur la façon dont les décideurs accordent la priorité à la sécurité, en choisissant les bons outils pour protéger leurs produits et les données de leurs clients.