Archives de catégorie : Mise à jour

Banque, Base de données, Chiffrement, Cybersécurité, Entreprise, Fuite de données, Mise à jour, Securite informatique

Fuite de données : Un espace anonyme de discussion Bloomberg le devient beaucoup moins à cause d’une erreur

Près de mille utilisateurs d’un espace de discussion anonyme Bloomberg se retrouvent affichés après qu’une société d’investissement de Londres diffuse la liste des participants par erreur.

La société Bloomberg a organisé, la semaine dernière, un chat avec un millier de participants. Des « posteurs » de messages anonymes qui venaient parler « bourse » ; « argent » … Une société d’investissement de Londres a fait une boulette en envoyant une liste des participants – comprenant les noms et les employeurs – aux personnes présentes dans la salle de discussion. Cette violation de données est l’une des plus importantes pour l’entreprise d’information financière de l’ancien maire de New York, Mike Bloomberg. Bilan, les modérateurs ont du fermer plusieurs espaces de discussions accès sur les données macroéconomiques et l’énergie. Pour les 866 participants impactés par cette fuite, un événement déconcertant. Il expose leurs commentaires sur leurs concurrents et les entreprises qu’ils analysaient. Ce service Bloomberg comporte 325 000 abonnés. L’impact sur l’image de marque risque d’en prendre un coup. (NYP)

Base de données, Cloud, Cybersécurité, Entreprise, Fuite de données, ID, Identité numérique, Mise à jour, Particuliers, Sauvegarde, Securite informatique

Fuite de données pour 52 loueurs de voitures néerlandais

Plus de 180 000 clients de loueurs de voitures des Pays-Bas accessibles sur Internet sans aucune sécurité, ni restriction.

La cybersécurité prend un coup dans l’aile pour des loueurs de voitures. Dans quelques 52 entreprises de location de véhicules opérant aux Pays-Bas, cette sécurité informatique était si mauvaise qu’il n’aura fallu que quelques clics de souris pour accéder à 180 000 dossiers de clients. La fuite a été découverte par la société ESET, société basée à Sliedrecht, qui recherchait un nouveau fournisseur d’automobiles d’entreprise pour son personnel. La fuite partait du logiciel professionnel LeaseWise. Via ce logiciel, les loueurs se partagent une base de données. Un partage non protégé des regards extérieurs ! Les données divulguées incluaient les adresses des clients, les contrats de location et le nombre total de kilomètres parcourus par voiture. (NLT)

Base de données, BYOD, Chiffrement, Cloud, Cybersécurité, Entreprise, Mise à jour, Sauvegarde, Securite informatique

Oups ! Cisco efface des données clients par erreur dans le cloud

La société Cisco a admis avoir perdu, accidentellement, des données du client lors d’une erreur de configuration du cloud de sa filiale Meraki.

Ahhhh, le cloud, petit bonheur numérique qui permet, selon les plaquettes publicitaires de « se faciliter la vie » ; « d’économiser de l’argent » ; « de renforcer son potentiel économique« . Bref, le cloud c’est bien… sauf quand ça bug. Le dernier incident en date concerne CISCO. L’entreprise américaine a confirmé, et donc avoué, avoir perdu des données clients. Un accident en raison d’une erreur de configuration du cloud de sa filiale Meraki.

La semaine dernière, l’équipe d’ingénierie cloud de CISCO a effectué un changement de configuration sur son service de stockage basé en Amérique du Nord. Sauf que cette mise à jour a supprimé certaines données clients. Meraki est une filiale de Cisco qui offre des technologies d’information gérées par le cloud pour les caméras sans fil, et tout ce qui concerne les communications de sécurité via une interface Web.

Un outil pour savoir ce qui a été perdu dans le cloud !

L’entreprise a déclaré que son équipe d’ingénieurs a travaillé pendant le week-end de 5/6 août pour voir si elle pouvait récupérer les données de ses clients. CISCO va fournir, ce 7 août, un outil pour « aider nos clients à identifier précisément ce qui a été perdu ». Cisco n’a pas précisé combien de clients ont été impactés par cet incident. Meraki est utilisé par plus de 140 000 clients et 2 millions de périphériques réseau y sont connectés.

En juillet dernier, des centaines d’entreprises, dont la Compagnie météorologique d’IBM, Fusion Media Group et Freshworks, utilisateurs de Google Groups pour leurs messages internes et privés, ont accidentellement exposé des informations sensibles publiquement en raison d’une erreur de configuration par les administrateurs de groupe. La société Dow Jones & Co a récemment confirmé que des données personnelles et financières de près de 2,2 millions de clients avaient été exposées en raison d’une erreur de configuration dans le seau S3 d’Amazon. Plus tôt cette année, la panne massive de S3 de Amazon Web Services, pendant plusieurs heures, a été causée en raison d’une erreur d’ingénierie.

Quelques jours auparavant, Verizon avait confirmé qu’un fournisseur tiers avait exposé des millions d’enregistrements d’abonnés sur un serveur de stockage Amazon S3 non protégé. Toujours en juillet, WWE confirmait qu’une base de données non protégée contenant les détails de plus de 3 millions d’utilisateurs avait été trouvée stockée en texte brut sur un serveur Amazon Web Services S3.

 

Cyber-attaque, Cybersécurité, escroquerie, ID, Identité numérique, Logiciels, Microsoft, Mise à jour, Particuliers, Patch, Piratage, Securite informatique, Social engineering

Les auteurs de Fireball arrêtés

Un commentaire

Le logiciel malveillant Fireball a infiltré plus de 250 millions d’ordinateurs. Onze personnes soupçonnées d’être derrière cet outil pirate arrêtées.

La police Chinoise vient d’arrêter 11 présumés pirates informatiques auteurs de l’infiltration de plus de 250 millions d’ordinateurs. Les personnes sont soupçonnées d’avoir développé des logiciels malveillants nommés Fireball. Parmi les dispositifs infectés, 20% appartiennent à de grands réseaux d’entreprises dans divers pays. Le programme malveillant Fireball a été découvert il y a deux mois par des chercheurs de la société Proofpoint.

Fireball avait pour mission de se cacher dans les ordinateurs et d’afficher des publicités dans les navigateurs. Pour piéger les internautes, les pirates passaient par un éditeur de logiciels Chinois, Rafotech. Les publicités affichés, rapportaient de l’argent aux pirates à chaque diffusion. Les 11 personnes arrêtées travaillaient pour Rafotech. Les pirates informatiques auraient gagné 80 millions de yuans (Plus de 10 928 290 millions d’euros) avec leur campagne de logiciels malveillants, rapporte le Beijing Youth Daily. Au moment de la découverte de Fireball, les chercheurs ont trouvé 25,3 millions d’appareils infectés en Inde, 5,5 millions d’appareils aux États-Unis, 24,1 millions au Brésil, 16,1 millions au Mexique, 13,1 millions en Indonésie.

APT, backdoor, Communiqué de presse, Cyber-attaque, Cybersécurité, Leak, Mise à jour, Piratage, Securite informatique

Infy : Prince of Persia persiste et signe

En février 2017, l’Unit42, unité de recherches de Palo Alto Networks a observé une évolution du malware “Infy” que nous avons appelée « Foudre ». Les acteurs concernés semblent avoir tiré les enseignements suite à notre démantèlement et notre sinkholing (redirection vers un serveur que nous contrôlons) de leur infrastructure de commande et de contrôle (C2). En effet, Foudre intègre désormais de nouvelles techniques anti-démantèlement censées éviter que ses domaines C2 ne soient détournés vers un site sinkhole comme nous l’avions fait en 2016.

L’Unit42 a documenté ses travaux de recherche originels sur cette campagne vieille de dix ans en utilisant le malware Infy en mai 2016. Un mois après la publication de ces travaux, l’Unit42 a donné une description détaillée de notre démantèlement et de notre sinkholing des serveurs C2 de l’acteur. En juillet 2016, au congrès Blackhat U.S.A, Claudio Guarnieri et Collin Anderson ont présenté des preuves montrant qu’un sous-ensemble des domaines C2 redirigés vers notre sinkhole avaient été bloqués par falsification DNS et filtrage HTTP par la Telecommunication Company of Iran (AS12880), empêchant l’accès depuis le territoire national iranien à notre sinkhole.

Voici les modifications apportées au malware dans ce blog post dédié, quelques informations et précisions ci-dessous. L’Unit42 en profite également pour mettre en avant certaines erreurs courantes, et explique comment elle les a exploitées pour en savoir plus sur cette campagne.
Cartographie des victimes

L’Unit42 avait prévu l’un des noms de domaine DGA et l’avait enregistré avant que l’adversaire ne puisse le faire.

Les victimes ont tenté de se connecter à un C2 dans ce domaine, mais, ne possédant pas la clé privée RSA, l’Unit42 n’a pas pu vérifier son domaine auprès d’elles. Cependant, elle a pu établir une cartographie géolocalisant les victimes à l’aide de GeoIP (voir pièce jointe).

On remarque la prépondérance des victimes sur le territoire national iranien, ce qui rappelle fortement les campagnes d’Infy. Les attaques menées contre les États-Unis et l’Irak sont aussi familières. Ici encore, le très petit nombre de cibles fait penser à une motivation non financière.

L’une des victimes en Irak utilise une adresse IP dans le même réseau de classe C que l’une des victimes Infy déjà observées, ce qui laisse à penser que l’adversaire cible la même organisation, voire le même ordinateur.

Même si, en l’absence de la clé privée RSA, l’Unit42 n’a pas réussi à établir la communication avec les victimes, elle a découvert qu’en envoyant un fichier de signature non valide à la victime, du fait de l’absence de validation en entrée du contenu/de la taille de ce fichier, elle arrive à faire échouer le processus rundll32 qui exécute la DLL malveillante de Foudre. Cela permet de désactiver l’infection jusqu’à ce que la victime réinitialise sa machine.
Conclusion

Dans son post, blog Prince of Persia, l’Unit42 avait indiqué que cette campagne durait depuis au moins une dizaine d’années. Ainsi, elle a poursuivi le sujet avec son blog Prince of Persia: Game Over, qui documente son démantèlement et son sinkholing de l’infrastructure C2 de l’adversaire.

En ce qui concerne les actions de la Telecommunication Company of Iran en vue d’empêcher les C2 d’être redirigés vers notre sinkhole, Guarnieri et Anderson font observer que « la politique de filtrage indique que les autorités iraniennes sont intervenues spécialement pour bloquer l’accès aux domaines de commande et de contrôle d’une campagne d’intrusion visant l’État, au niveau national. »

L’Unit42 s’attend à voir Infy faire son retour : dans les grandes lignes, ce sera toujours le même malware, ciblant les mêmes victimes.

Les acteurs ont compris qu’ils avaient besoin d’une infrastructure C2 plus robuste pour empêcher l’infiltration et le démantèlement. L’algorithme DGA apporte une dose de résilience, mais n’est pas invulnérable à un démantèlement.

Toutefois, l’utilisation de la signature numérique constitue un dispositif de défense contre un C2. Sans accès aux clés privées, il n’est pas possible d’usurper l’identité d’un C2 même si un domaine DGA est enregistré par un chercheur. Il se peut que les clés privées résident localement sur le serveur C2, mais sans accès au C2, nous ne pouvons pas confirmer cette vulnérabilité potentielle de leur infrastructure.

Décidément, Prince of Persia persiste et signe.

Chiffrement, cryptage, Cyber-attaque, Cybersécurité, DDoS, IOT, Leak, Mise à jour, Patch, Piratage, Securite informatique

Devil’s Ivy : une vulnérabilité aux dizaines de millions d’objets connectés

Devil’s Ivy, un bug récemment découvert affecte des dizaines de millions de périphériques connectés de part le monde.

La problématique du piratage informatique, de la mise à jour des objets connectés ne fait que commencer. Suite à la découverte par la Senrio Labs d’une vulnérabilité qui concernerait potentiellement une dizaine de millions d’objets connectés, la question se pose encore aujourd’hui. Que va-t-il se poser le jour [demain, NDR] ou les objets connectés se compteront par milliard ? Le bug a été découvert dans le code gSOAP  (Simple Object Access Protocol). Pour faire simple, une gSOAP est une série d’outils qui permettent aux objets connectés de parler et de se faire comprendre sur Internet.

Genivia, la société qui gère gSOAP, annonce avoir plus d’un million de téléchargements, et possède comme client IBM, Microsoft, Adobe ou encore Xerox. « Il est probable que des dizaines de millions de produits – produits logiciels et périphériques connectés – sont affectés par Devil’s Ivy dans une certaine mesure », déclarent les chercheurs de chez Senrio « Nous avons nommé la vulnérabilité Devil’s Ivy car, comme la plante, il est presque impossible de la tuer et elle se propager rapidement grâce à la réutilisation du code« .

Si l’impact de la vulnérabilité Devil’s Ivy est relatif, elle ne permettrait « que » de voir le flux vidéo ou d’interdire l’accès au flux vidéo des caméras concernées, celle-ci montre néanmoins l’importance du risque qui peut en découler et l’intérêt pour les pirates d’identifier des vulnérabilités similaires. « Du fait de l’industrialisation de ces objets et de leur sécurité, une fois une vulnérabilité identifiée, un groupe de malveillants peut très rapidement l’utiliser à des fins d’espionnage, de destruction » souligne Vincent Lavergne, Expert chez F5 Networks. L’internet des objets (IoT) offre un effet de levier sans précédent pour constituer très rapidement un nid conséquent de BotNets, comme ce fût le cas avec Miraï. Miraï ne comportait qu’une centaine de milliers de caméras de vidéo surveillance dans son portefeuille pirate.

Devil’s Ivy

« Dans le cas de cette vulnérabilité, les objets concernés étant déjà déployés, il va être difficile de mettre en place une action corrective à grande échelle pour combler la vulnérabilité. Et c’est l’un des principaux défis de l’IoT : comment gérer la réponse aux incidents pour ce type d’équipement ?  L’internet des objets introduit en effet de nouvelles problématiques pour la sécurité et beaucoup d’entre elles mériteraient des analyses approfondies ou une collaboration entre industriels afin de définir une approche optimale à long terme. La conception et l’implémentation de systèmes IoT vont venir empiler des protocoles, des couches techniques complexes et des programmes qui souffrent parfois de failles de sécurité. On met ainsi le doigt sur le manque de maturité des standards autour de l’internet des objets et d’un cadre de meilleures pratiques à respecter par les développeurs. Chacun se positionne en effet avec ses interfaces, ses plateformes, ses protocoles et – inévitablement – ses vulnérabilités. » termine Vincent Lavergne.

Un exploit utilisant l’idée du Devil’s Ivy entraînerait une exécution de code à distance – dans le boîtier de la caméra – et donc d’accéder à un flux vidéo, ou de couper ce dernier. Étant donné que des caméras de vidéo surveillance sont destinées à sécuriser quelque chose, le danger est réel. Le constructeur de caméra Axis a déclaré que ce problème était présent dans 249 de ses modèles, à l’exception de trois anciens models.

Cybersécurité, loi, Mise à jour

Neutralité du net. Qui va payer ? En profiter ?

Neutralité du net ? Aux Etats-Unis, des dizaines d’acteurs, parmi lesquels Google, Facebook ou encore Twitter, ont appelé à la mobilisation ce mercredi 12 juillet en faveur de la neutralité du net, un principe dont l’objectif est de garantir l’accès à internet pour tous et à l’intégralité des contenus, quel que soit le fournisseur d’accès à internet (FAI). Cette journée d’action fait suite à la remise en cause par la FCC (Commission fédérale des communications aux USA) d’un texte adopté par l’administration de Barack Obama concernant le renforcement de cette neutralité du net.

Google, Facebook ou encore Twitter, ont appelé à la mobilisation ce mercredi 12 juillet en faveur de la neutralité du net ! Il existe trois piliers fondamentaux sur lesquels repose internet, et qui sont aujourd’hui des droits, pas seulement des privilèges : la vie privée en ligne, la sécurité et l’accessibilité. Bien que cette dernière soit un principe fondateur, la neutralité du net n’est en revanche pas aussi évidente. Entre les fournisseurs de contenu et ceux d’accès à internet, les arguments pour ou contre sont nombreux d’un point de vue économique. Dans ce contexte, la question aujourd’hui est de savoir qui va payer et qui va en profiter ?

Imaginons par exemple que Google et Facebook soient des constructeurs, et que les FAI soient des entreprises de camionnage qui livrent de la marchandise. Dans ce cas, ces derniers vont effectuer des livraisons sans frais pour le fabricant. Au lieu de cela, ils facturent à chaque consommateur utilisant leurs services un montant forfaitaire mensuel qui leur permet de recevoir des biens ; ces derniers pouvant être lourds et imposants ou petits et légers. Dans cet exemple, les FAI imposent évidemment des coûts bien plus élevés pour la livraison de colis plus volumineux.

En ayant toujours en tête la problématique de la neutralité du net, les fournisseurs de contenu profitent essentiellement de la livraison gratuite de leurs produits, peu importe le type, tout en sachant que les vidéos coûtent plus cher qu’un simple email à délivrer. Les FAI, contre la neutralité du net, veulent être en mesure de leur imposer des frais pour ce service ou bien pour contrôler que la livraison n’impacte pas le réseau. De leur côté, les producteurs de contenu, favorables à cette neutralité, souhaitent qu’internet soit un service gratuit. Bien sûr, il y a également la question du respect de la sphère personnelle : laisser tomber la neutralité du net entrainerait-elle une violation de la vie privée par les FAI ?

A l’heure actuelle, le débat se résume à une bataille entre ceux qui veulent que le contenu soit délivré par internet, et ceux qui se chargent de le faire transiter et qui fournissent des efforts considérables pour en tirer profit. Qui supportera la charge financière pour développer et assurer l’avenir de cette infrastructure critique, vitale pour le fonctionnement de la société et de l’économie ? Ceux qui s’opposent à la neutralité du net devront payer pour l’infrastructure et la diffusion de contenus, tandis que les autres bénéficieront des investissements réalisés par les entreprises de télécommunications. Mais il faut avoir à l’esprit qu’une résolution ne sera adoptée que si le public s’exprime à ce sujet, auprès de l’Arcep par exemple. (Par Vince Steckler, Président Directeur Général d’Avast)

Cybersécurité, Entreprise, Fuite de données, Mise à jour, Patch, Propriété Industrielle, ransomware, Securite informatique

Failles de sécurité : responsables de la sécurité des systèmes d’information, pourquoi faire l’aveugle ?

Selon une enquête réalisée par ServiceNow, 90 % des responsables de la sécurité des systèmes d’information français déclarent que les failles de données dont ils ont connaissance ne sont pas traitées. Les RSSI augmentent l’efficacité de leur réponse aux incidents de sécurité en automatisant les tâches de sécurité et en hiérarchisant les menaces en fonction du risque pour l’entreprise.

Une nouvelle enquête menée par ServiceNow, the enterprise Cloud company, auprès de 300 responsables de la sécurité des systèmes d’information (RSSI — Chief Information Security Officer, CISO) du monde entier souligne la nécessité d’adopter une nouvelle approche pour répondre à l’augmentation du nombre de menaces qui pèsent sur la sécurité des données, ainsi qu’à la hausse de leur coût. Selon cette étude intitulée « The Global RSSI Study: How Leading Organizations Respond to Security Threats and Keep Data Safe », 90 % des RSSI français indiquent que les failles de données détectées ne sont pas traitées (80 % au niveau mondial) et 68 % déclarent pour leur part éprouver des difficultés à hiérarchiser les menaces en fonction du risque qu’elles représentent pour l’entreprise.

Ces lacunes ont un coût : 14 % des RSSI français (13 % au plan mondial) déclarent avoir vécu au cours des trois dernières années une importante faille de sécurité ayant eu un impact important sur l’image ou les finances de leur entreprise. Les processus manuels, le manque de ressources et de talents, ainsi que l’impossibilité de hiérarchiser les menaces grèvent l’efficacité de la réponse aux incidents de sécurité. Résultat, les RSSI augmentent l’automatisation des tâches de sécurité pour répondre et remédier aux failles de sécurité avec une plus grande efficacité.

« En France, les RSSI consacrent de plus en plus de temps à prévenir et détecter des failles de sécurité, mais notre étude souligne que c’est sur la réponse à apporter qu’ils devraient se concentrer », a déclaré Matthieu de Montvallon, Directeur Technique de ServiceNow France. « L’automatisation et l’orchestration de la réponse aux incidents de sécurité constituent le chaînon manquant qui empêche les RSSI d’accroitre de façon significative l’efficacité de leurs programmes de sécurité ».

Principales conclusions de l’étude menée en France via la réponse de responsables de la sécurité des systèmes d’information

· seulement 18 % des RSSI interrogés considèrent que leur entreprise lutte très efficacement contre les failles de sécurité (19 % à l’échelle mondiale) ;

· ce sont les clients qui souffrent le plus de ces lacunes : seulement 38 % des RSSI — en France et dans le monde — pensent protéger les données de leurs clients de façon très efficace contre les failles de sécurité ;

· environ un cinquième des RSSI français (22 %) déclare que les processus manuels entravent la capacité de leur entreprise à détecter des failles de sécurité et à y faire face ; 26 % d’entre eux imputent cette difficulté au manque de ressources ;

· seulement 4 % des RSSI français estiment que leurs employés disposent des compétences nécessaires pour hiérarchiser avec succès les menaces qui pèsent sur la sécurité, contre 7 % au plan mondial.

Au sein du panel couvert par cette enquête, un petit groupe (11 % à l’échelle mondiale et 14 % en France) de « leaders dans la lutte contre les incidents de sécurité » affiche une tendance différente en ce sens où ils souhaitent :

· automatiser un pourcentage supérieur d’activités de sécurité, en incluant des tâches plus avancées telles que les rapports de tendances ;

· hiérarchiser les réponses aux alertes de sécurité en fonction du niveau de risque pour l’entreprise ;

· et nouer des relations plus étroites avec la DSI et autres services de l’entreprise.

Cyber-attaque, Cybersécurité, DDoS, Mise à jour, Piratage, Securite informatique

Final Fantasy 14 subit une série d’attaques DDoS

La seconde extension de Final Fantasy 14, Stormblood, était attendue par tous les « afficionados » du célèbre jeu sur Playstation 4, Mac et PC. Un lancement qui a été perturbé par une série d’attaques par déni de service.

Le 20 juin 2017 sortait la seconde extension de Final Fantasy 14, Stormblood. Des pirates ont tenté de perturber ce lancement par un déni distribué de service (DDoS). « Aujourd’hui, les botnets comme celui qui a affecté les serveurs du jeu Final Fantasy 14 n’ont pas de limites. Chaque imprimante, console de jeux ainsi que n’importe quel appareil connecté à internet peut être utilisé par un botnet pour lancer une attaque par déni de service (DDoS). confirme Jean- Baptiste Souvestre, Software Engineer, chez Avast. Jusqu’à présent, les cybercriminels ont seulement pu exploiter cette méthode pour paralyser ou prendre le contrôle de sites internet, des actions ennuyeuses mais sans mise en danger vital. En ce qui concerne les conséquences sur Final Fantasy, les attaques DDoS en particulier n’entrainent pas de perte de données relatives aux personnages ou bien au profil de l’utilisateur mais elles peuvent nuire à la performance et à l’expérience de jeu ».

En réalité, le pouvoir de ce type de piratage ne cessera d’augmenter. A l’avenir, nous pourrions voir de nombreuses attaques entièrement autonomes et basées sur l’intelligence artificielle qui opèreront de façon indépendante, sauront s’adapter pour échapper aux outils de détection, et prendront les décisions seules, exposant ainsi les services digitaux et les infrastructures web à des risques encore plus importants.

C’est pourquoi nous devons tous nous montrer responsables en prenant des mesures proactives pour protéger nos systèmes et équipements, quelle que soit l’activité à partir du moment où nous sommes connectés à internet. Cela passe notamment par l’utilisation de mots de passe forts et uniques, mais également par l’installation de solutions de sécurité afin de prévenir toute attaque. En outre, la mise en place d’un anti-malware fait partie des bonnes pratiques à adopter, à la fois par les particuliers et les entreprises. Enfin, dès lors qu’un utilisateur soupçonne qu’une attaque est en cours au cœur de ses appareils, il doit contacter son fournisseur d’accès à internet afin que ce dernier puisse analyser immédiatement si tout est normal sur le réseau ou bien si un hacker est parvenu à s’infiltrer. Si tel est le cas, les mesures nécessaires pourront être appliquées pour l’arrêter avant qu’il ne parvienne à ses fins.

APT, Base de données, BYOD, Chiffrement, Cloud, Cybersécurité, Entreprise, Mise à jour, Securite informatique

Les risques, les vulnérabilités, les licences des logiciels open source

Les risques concernant la sécurité et la conformité des composants tiers atteignent des proportions incontrôlables, et menacent l’intégrité même de la chaîne d’approvisionnement de logiciels.  Il suffit de voir l’impact de la faille Heartbleed pour s’en convaincre !

Aujourd’hui, les entreprises incluent davantage de code open source que d’éléments conçus en interne ou propriétaires dans leurs produits.  Malheureusement, en profitant de ces logiciels open source (OSS) pour accélérer le développement de leurs produits, la plupart d’entre elles ne respectent pas les licences open source associées à ces composants.  Bien que les OSS soient gratuits, leurs utilisateurs ne sont pas pour autant libres de toute obligation les concernant.  Celles-ci peuvent aller de la reproduction de déclarations de droits d’auteur ou d’une copie d’un document de licence à la divulgation de l’intégralité du code source de leurs produits.  Des enquêtes récentes ont montré que la plupart des entreprises ne connaissent qu’un faible pourcentage des composants open source sur lesquels elles s’appuient, et ne sont donc pas en mesure de respecter les obligations indiquées dans les licences de ces éléments.  En outre, ces logiciels peuvent comporter des bugs ou des vulnérabilités susceptibles d’affecter votre produit.  Sans un suivi adéquat, ce dernier peut passer à côté de mises à jour ou de patches corrigeant des vulnérabilités connues. Mais malgré cela l’open source offre de précieux avantages.

Découverte, gestion et conformité en cinq étapes

Face aux problématiques de conformité ou de gestion des vulnérabilités des OSS, la première question est généralement : « Comment savoir quels composants open source nous utilisons ? » Il est possible de mieux comprendre ce que l’on fait et de mettre en place un processus pour découvrir, gérer et s’assurer de la conformité avec ces OSS en cinq étapes.

Étape 1 :  comprendre comment les OSS sont introduits dans votre entreprise

Les OSS peuvent s’introduire de différentes façons.  Cas classique : un développeur décide d’utiliser un composant open source, télécharge le code source, et l’intègre au produit.  Ce cas est encore très fréquent, mais il existe bien d’autres scénarios.  Très souvent, les développeurs utilisent ce qu’on appelle des gestionnaires de référentiels (repository manager).  Ces outils leur permettent d’indiquer les composants qu’ils veulent utiliser, puis s’occupent eux-mêmes d’en télécharger le code source ou des fichiers binaires compilés. Ces gestionnaires stockent généralement les composants open source dans un référentiel distinct, hors du système classique de gestion des codes source.  On peut notamment citer parmi eux Maven, Nuget ou npm.

Des éléments open source peuvent également être introduits dans une organisation en tant que sous-composant d’un composant open source plus important ou commercial.  Les composants de premier niveau ont très souvent plusieurs sous-composants ou dépendances open source, qui sont rarement divulgués ou gérés.

En outre, ces éléments serviront de pièces d’une infrastructure runtime, comme des serveurs Web, des systèmes d’exploitation ou des bases de données et peuvent permettre de contrer les risques.

Étape 2 :  chercher les OSS

Une fois que vous savez comment vos composants open source sont sélectionnés et utilisés, vous pouvez évaluer les risques et ceux dont vous avez besoin, et comment ils sont utilisés ou répartis.  On appelle ça dresser une nomenclature (Bill of Materials), ou une liste de divulgation.  Cette liste sert à suivre les obligations, à modifier les politiques vis-à-vis des OSS, et à réagir aux vulnérabilités rendues publiques.  Souvent, des paquets open source comporteront des termes de licence que votre organisation ne pourra pas respecter, ce qui pose automatiquement un problème de conformité.  Dans de tels cas, le composant en question devra être supprimé et la fonctionnalité remplacée, soit par un autre composant OSS, ou en écrivant une fonctionnalité équivalente.

L’examen du code base, les risques, la tenue d’entretiens et l’utilisation d’outils d’analyse de code peuvent être utiles dans le cadre de ce processus.

Étape 3 : questionner l’équipe de développement

Les projets devenant sans cesse plus vastes, complexes et distribués, il est de plus en plus difficile de découvrir l’ensemble des éléments utilisés.  Il est donc important d’avoir des échanges réguliers avec les développeurs, équipes DevOps, ainsi que l’ensemble du personnel informatique impliqué dans la création, le déploiement et la mise en œuvre du projet en question.  Posez-leur des questions ciblées, comme « Quelle base de données utilisons-nous ? », ou « Quelle bibliothèque de chiffrement utilisons-nous ? ».  Cela peut être utile pour découvrir d’autres modules potentiellement passés inaperçus la première fois.

Demander simplement « Quel code open source utilisons-nous » permet rarement de créer une liste complète pour un certain nombre de raisons, notamment à cause d’oublis ou de l’absence de registres adéquats.

Étape 4 : comprendre comment les OSS entrants sont gérés

La gestion des composants tiers et les risques doivent faire l’objet d’un processus cohérent et correctement appliqué.  Votre organisation pourra ainsi respecter ses obligations des licences open source, mais aussi faire face à de nouvelles vulnérabilités.  Il est fréquent de voir ce processus atteindre différentes étapes et niveaux de conformité.  Certaines organisations se contentent encore de suivre les composants « sollicités » par les développeurs.  Celles-ci n’ont souvent connaissance que des éléments les plus importants, ou découvrent que certains développeurs sont plus assidus que d’autres dans le cadre du respect du processus.

D’autres entreprises utilisent des outils d’analyse pour découvrir et suivre leurs OSS.  Leurs résultats varieront en fonction des solutions utilisées ou du niveau d’analyse.  Certains outils ne découvrent que les textes de licence, pas les composants open source. D’autres ne peuvent retrouver que les composants gérés par des gestionnaires de paquets.  Il est donc important de savoir quel niveau d’analyse est adopté et ce que l’on peut espérer repérer…

Étape 5 :  cherchez des preuves de conformité des OSS

Une fois toutes ces étapes franchies, il est important de confirmer la visibilité de cette conformité.  Les déclarations et autres avis légaux (droits d’auteurs) nécessaires sont-ils présents dans les produits ou leur documentation ?  Les textes des licences sont-ils visibles comme il se doit ?  Existe-t-il une offre écrite relative au code source ou ses distributions, et ciblant du contenu rendu libre que vous utilisez ?  Tous ces éléments seront les témoins visibles de l’efficacité de votre processus de gestion des composants open source.

En suivant ces cinq étapes, en sensibilisant votre personnel à l’utilisation adaptée des OSS, et en encourageant les membres de votre écosystème à en faire de même, vous pourrez créer des applications modernes et puissantes, tout en respectant les licences open source.

En outre, plus vous en savez sur les ingrédients, les éléments tiers et les vulnérabilités de votre produit, mieux ce dernier pourra être sécurisé et pris en charge ! (Par Christian Hindre – Directeur Commercial Europe de Flexera Software)