Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Retour vers le futur : pourquoi votre offre commerciale actuelle est fragilisée par son passé open source ?

septembre 2018 par Christian Hindre - Directeur Commercial Europe de Flexera

Le rapport de 2018 sur les fuites de données publié par le Bureau des droits civils du Ministère de la santé et des services sociaux américain mérite que l’on s’y attarde.

Au 21 août 2018, 229 fuites auraient affecté 6,1 millions d’individus, selon des chiffres publiés par le Département de la santé et des services sociaux américain sur l’outil de signalement de failles en ligne HIPAA Breach Reporting Tool - ou « wall of shame ».

La majorité de ces fuites sont liées à l’usage abusif (intentionnel ou non) de technologies destinées aux utilisateurs finaux, comme dans le cas de l’accès à des systèmes et données sensibles ou critiques à l’aide d’appareils mobiles.

Auparavant, on utilisait des terminaux fixes connectés aux serveurs de son entreprise par un câble aussi épais que son pouce et branché sur une prise murale parfaitement étiquetée ; désormais, nous sommes entrés dans l’ère des applications distribuées, et des individus et données répartis sur des réseaux professionnels extrêmement complexes. Surtout, l’environnement de développement de logiciels est aujourd’hui plus ouvert que jamais.

Avec l’utilisation massive de logiciels open source (OSS) pour accélérer le lancement de nouvelles offres et fonctionnalités, les systèmes et produits des entreprises sont aujourd’hui exposés en raison des nombreuses failles de sécurité de ces composants. À moins que leurs développeurs et fournisseurs n’utilisent que les versions les plus sûres de ces éléments (on peut être sûr du contraire) ; elles hériteront donc de vulnérabilités vieilles de plusieurs années, voire de plusieurs décennies. Ces failles sont souvent faciles à corriger, mais difficiles à repérer.

Conséquence ? Sans un bon suivi des composants open source utilisés et de leur localisation, il sera impossible pour les organisations de régler ces problèmes, ou de découvrir et corriger et nouvelles vulnérabilités affectant des composants autrefois sécurisés. Pour exemple, de nombreuses attaques datant de 2014 exploitaient la faille « Heartbleed » au sein de la bibliothèque OpenSSL.

 Community Health Systems, la deuxième plus grande chaîne de cliniques privées aux États-Unis, a confirmé dans un rapport sur formulaire 8-K que 4 millions de dossiers médicaux avaient été dérobés d’une de ses bases de données.
 La fuite dont JPMorgan Chase a été victime en 2014 incluait pour sa part les données de plus de 370 millions de comptes, 76 millions de foyers et 7 millions d’entreprises.

Pourquoi tout cela est-il important ? Parce que les serveurs web open source tels qu’Apache et nginx utilisent cette bibliothèque :
 C’était le cas de 66 % des 958 millions de sites actifs sur Internet en 2014 (selon l’enquête sur les serveurs web publiée en avril 2014 par Netcraft),
 L’édition 2018 de la même enquête donne un pourcentage de 60 % sur 6 milliards de sites actifs.

Pire : l’OpenSSL est utilisé pour protéger des serveurs de messagerie (les protocoles SMTP, POP et IMAP), des serveurs de messagerie instantanée (le protocole XMPP), des réseaux privés virtuels (les VPN utilisant le protocole SSL), des équipements réseaux, ainsi que l’essentiel des logiciels côté client utilisés aujourd’hui dans les systèmes de santé.

Une vulnérabilité : plus d’un milliard d’instances potentielles à ce jour, et ça n’est pas près de s’arrêter !

Quatre ans après la publication du correctif, certaines entreprises retrouvent encore des versions d’OpenSSL vulnérables à cette faille dans du code client, et ce au quotidien.

Les entreprises seraient donc bien inspirées de se poser les questions suivantes :
 Se peut-il que notre équipe de développement ou nos fournisseurs introduisent des problèmes de sécurité à cause de processus mal gérés ?
 Quel serait le risque pour la réputation de notre organisation, ou l’impact sur notre activité si notre produit venait à être commercialisé ou à entrer en production avec une vulnérabilité ?
 Sommes-nous capables de déterminer rapidement si nous utilisons des composants exposés à une vulnérabilité donnée, et sommes-nous en mesure de réagir rapidement le cas échéant ?


Voir les articles précédents

    

Voir les articles suivants