Qu’est ce qu’une stratégie »orientée Open Source » ?
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 concurrents. Afin d’y intégrer des fonctionnalités critiques, les développeurs utilisent fréquemment des composants logiciels Open Source (OSS), c’est-à-dire à code source ouvert ainsi que des logiciels propriétaires. Pour leur part, 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… Comment les entreprises réagissent-elles ?
Pour faire face à ce problème, les responsables de la sécurité des systèmes d’information (RSSI) investissent dans des pare-feux 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 système d’information (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.
Protéger de l’intérieur vers l’extérieur, qu’est ce que cela signifie pour vous ?
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 des composants 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é.
Quels sont les apports d’une stratégie Open Source ?
Les produits Open Source présentent des avantages évidents : ils réduisent les coûts, 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.
Même si l’incorporation d’éléments Open Source comprend de nombreux avantages, cette incorporation n’augmente-t-elle pas également le niveau de vulnérabilité de l’entreprise ?
Bien que les développeurs du monde entier incorporent des éléments 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és 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.
Que conseillez-vous vous pour 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. Ils doivent aussi s’assurer que des audits soient réalisés par leurs partenaires de développement et commerciaux externes, pour se garantir 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. Les applications développées en interne doivent aussi passer par les points de contrôle adéquats afin d’établir des pistes d’audit précises.
En d’autres termes, 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 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é, ni 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.
Comment est-il possible de fédérer ces différents services ?
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 de la DSI 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 patchs de mise à jour, 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.
Propos recueillis par Ségolène Kan
Commentez