Les entreprises contemporaines investissent des milliards de dollars dans le développement de nouveaux logiciels. En effet, les applications développées en interne permettent aux entreprises leaders de prendre l’ascendant sur leurs concurrentes. Afin d’y intégrer des fonctionnalités critiques, les développeurs utilisent fréquemment des composants logiciels open source (OSS) et propriétaires. Les applications orientées vers des utilisateurs externes représentent une énorme opportunité en matière de rentabilité, cependant, en l’absence d’une solide supervision, l’utilisation de composants tiers est également un risque potentiel…
Selon une enquête publiée récemment, près de 90 % des attaques portées contre des logiciels cibleraient la couche application.
Pour faire face à ce problème, les responsables de la sécurité des systèmes d’information (RSSI) investissent donc dans des pare-feu, et des systèmes d’authentification Web, de détection d’intrusion et de gestion des identités. Cependant, ces solutions ne sécurisent que le périmètre du SI en gérant le trafic vers les applications. Aucune d’entre elles ne protège les applications de l’intérieur vers l’extérieur en en renforçant le code ou en en gérant les failles.
Assurer la sécurité des applications malgré une stratégie axée sur l’intégration de composants tiers nécessite la mise en place de processus, ainsi que de l’entraînement et des outils adéquats. Il faut également établir un réel partenariat entre les équipes dédiées et de conception autour de deux éléments clés : la création par les développeurs d’un inventaire précis des composants open source et propriétaires utilisés ; et un système permettant de faire le lien entre les projets en cours et les vulnérabilités connues et divulguées, géré par l’équipe de sécurité.
La nécessité de veiller à la sécurité des OSS
Les produits open source présentent des avantages évidents : ils réduisent les coûts et raccourcissent les cycles de développement, et peuvent diminuer le coût total de possession des applications s’ils sont bien gérés. Il peut s’agir de composants et applications célèbres tels que Linux, Open Office ou Android ; ou de composants d’infrastructure plus méconnus tels qu’OpenSSL, zlib, ou des millions d’autres composants open source.
La composition classique des applications a évolué : de quelques composants tiers, nous sommes désormais passés à plusieurs centaines, la majorité d’entre eux provenant de projets open source.
L’une des différences entre composants open source et propriétaires est le fait que contrairement aux systèmes d’exploitation et applications packagées open source disposant d’un support commercial, seul un grand projet purement open source sur 10 s’appuie sur une communauté offrant de tels services. Les équipes de développement utilisant des composants OSS doivent donc essentiellement s’occuper elles-mêmes des correctifs, mises à niveaux, évaluations des vulnérabilités et autres tâches similaires normalement comprises dans un contrat de services commerciaux.
En outre, bien que les développeurs du monde entier peuvent incorporer des éléments open source, des logiciels libres, des produits tombés dans le domaine public, des démos de logiciels commerciaux, etc. dans le code qu’ils écrivent, ils le font sans passer par les points de contrôle habituels du processus d’achat. Or, sans ces contrôles, les composants tiers ont tendance à passer inaperçus, et donc à ne faire l’objet d’aucune supervision ou autre forme de suivi. Résultat : les équipes informatiques ne connaissent pas la composition réelle de leur code. De récentes études menées ont révélé que les applications écrites ces cinq dernières années contenaient au minimum 50 % de code open source par ligne, plus de 70 % n’étant pas documenté et étant même inconnu des développeurs. La présence de tels éléments au sein d’applications d’entreprise nuit à la sécurité de cette ressource aussi intangible qu’essentielle qu’est le code source.
Développer une stratégie de sécurité des applications
Il est de la responsabilité des équipes chargées de la sécurité, du développement et des systèmes d’information de s’assurer que leurs développeurs respectent des processus permettant de produire des logiciels sécurisés. Ensemble, ces trois départements parviendront à intégrer la sûreté des applications utilisant des composants open source au cœur de la stratégie globale :
– En menant des pré-déploiements, en analysant la sécurité du code et en réalisant des tests de pénétration pour le code développé en interne
– En faisant en sorte que des audits soient réalisés par leurs partenaires de développement et commerciaux externes
– En s’assurant que tout autre code tiers inclus dans leurs applications soit identifié et fasse l’objet d’un suivi en quête d’éventuelles failles de sécurité ou de mises à jour
– En s’assurant que les applications développées en interne passent par les points de contrôle adéquats afin d’établir des pistes d’audit précises.
Les développeurs, responsables de la sécurité et services informatiques doivent donc travailler main dans la main. Aucun de ces trois groupes ne peut exister seul dans son coin. Par exemple, l’assurance qualité et la prévention contre les virus ne sont pas incompatibles dans le cadre du développement d’applications.
Les développeurs considèrent souvent à tort que la sécurité est uniquement la responsabilité de professionnels dédiés. Pour beaucoup d’organisations, le processus de développement se limite à la conception, au codage et aux tests permettant de s’assurer que les produits remplissent leurs exigences fonctionnelles. À cause des budgets et des ressources limités des entreprises contemporaines, les applications ne sont souvent pas correctement testées à la recherche de défauts, de vulnérabilités ou de conditions susceptibles de les rendre vulnérables aux pirates.
Selon le même principe, la mission des équipes de sécurité et des responsables des SI consiste généralement à protéger le périmètre des organisations des attaques provenant de l’extérieur. Cependant, les professionnels de la sécurité n’étant pas des codeurs, ils ignorent souvent que les décisions prises au cours du développement ont un impact concret sur les applications déployées qu’ils sont censés protéger.
Ni les développeurs, ni les équipes chargées de la sécurité/les services informatiques ne peuvent gérer les problèmes au niveau des applications seuls. À l’inverse, les pirates, eux, sont au fait des différentes méthodologies et problématiques contemporaines, et profitent donc de cette faille béante.
Les RSSI devraient confier aux responsables de la conception la mission de faire en sorte que les équipes de développement, de sécurité et informatiques travaillent main dans la main pour sécuriser les applications déployées. Un bon point de départ serait de commencer par superviser les sites des projets open source et d’autres sources d’information sur les vulnérabilités, basées sur les inventaires OSS existants. Elles pourront ainsi évaluer la pertinence des alertes concernant les usages internes, et fournir des recommandations quant aux mises à niveau et autres patches le cas échéant. Le développement et la mise en œuvre d’une stratégie de sécurité des applications permettront à l’organisation de tirer parti de composants OSS, tout en s’assurant de maintenir les niveaux de sécurité les plus stricts. Aujourd’hui, il existe des outils facilitant l’adoption d’une approche pragmatique en matière de sûreté des applications. Il est grand temps pour les RSSI de s’y intéresser.
_______________
Christian Hindre est Directeur Commercial Europe de Flexera