Les logiciels open source sont de plus en plus courants au sein des organisations, apportant un ensemble différent de risques et de défis perçus par rapport à la source fermée ou aux logiciels propriétaires.
Le Forum sur la sécurité de l’information (FSS) a publié aujourd’hui un rapport pour aider les professionnels de la sécurité à reconnaître les avantages et les défis perçus de l’utilisation des logiciels open source.
« Deploying Open Source Software: Challenges and Rewards », que l’IFS appelle un document d’information, met l’accent sur la mise en place d’un programme de mesures de protection pour gérer efficacement le déploiement de l’OSS.
L’un de ses objectifs est de détailler la différence entre les mythes et les réalités entourant l’utilisation open source. Cette compréhension est essentielle à la sécurisation des composants open source dans les applications de code mixte, selon l’ISF.
Open Source Software est en train de faire partie intégrante de l’infrastructure et des applications informatiques. Ce statut est dû en grande partie à la popularité croissante des méthodologies de développement agiles et des pratiques DevOps, selon l’ISF. Avec un nombre important d’applications commerciales et sur mesure incorporant oss, il ne peut pas et ne doit pas être ignoré.
Comme OSS devient le pilier du développement et de l’infrastructure des applications, les professionnels de la sécurité devront comprendre le système d’exploitation et gérer les défis associés à ses composantes. Les solutions à ces défis en matière de sécurité devraient être mises en œuvre dans le cadre d’un programme de gestion du SSO, dirigé par une personne âgée nommée au poste de gestionnaire de programme du SSO, exhorte l’organisation.
L’intégration de toutes ces mesures dans un programme global unique permettra une approche holistique et coordonnée de la gestion des risques liés au SSO, a déclaré Paul Holland, analyste principal de la recherche à l’ISF. C’est un besoin essentiel pour s’assurer que la sécurité demeure intacte.
« De nombreuses organisations adoptent des méthodologies agiles et DevOps, qui sont à l’origine d’une participation accrue à l’OSS et, à son tour, de la création de nouvelles applications de sources mixtes », a déclaré M. Holland.
Objectifs ambitieux
Le guide ISF sur le déploiement de logiciels open source rassemble une étude rapide pour les travailleurs informatiques et autres utilisateurs open-source en entreprise. Il fournit des approches utiles pour la façon dont les organisations peuvent gérer efficacement les défis liés à l’utilisation du SSO et pourquoi elles doivent le faire.
Le guide parle également de la façon de maximiser les avantages et de récolter les fruits de l’utilisation de logiciels open-source. D’une certaine manière, ce guide pratique de l’ISF est une tentative de fermer la porte de la grange logicielle avant que plus de chevaux malware entrer.
Les logiciels source fermés ont été un élément essentiel des applications et de l’infrastructure informatiques organisationnelles. Mais de nombreux logiciels bien établis et populaires sont en fait open source. Ainsi, les organisations doivent reconnaître que le SYSTÈME d’exploitation existe peut-être déjà dans leur propre environnement. Il est souvent utilisé en combinaison avec un logiciel source fermé, créant ce qu’on dit un « logiciel source mixte ».
Les logiciels de source mixte peuvent être dérivés de n’importe quel nombre de combinaisons de composants OSS. Les possibilités incluent le logiciel source fermé, le code acheté et le code interne. Les développeurs peuvent ensuite intégrer ces composants ensemble pour créer une application logicielle source mixte personnalisée.
Les risques pour la sécurité liés à l’utilisation d’OSS au sein de l’infrastructure et des applications informatiques apportent des défis fondamentaux qui doivent être minimisés, met en garde le guide. Cette tâche est rendue plus complexe si les organisations ont une connaissance limitée des composantes du SSO utilisées. Il s’agit notamment d’obligations complexes en matière de licences et de propriété intellectuelle, d’une pénurie de compétences pertinentes en matière d’OSS et de l’absence de sécurité dans les pratiques de DevOps.
Équilibre nécessaire
Un effort concerté pour gérer l’utilisation du SSO de façon appropriée et efficace est nécessaire. La prévalence croissante de l’OSS doit être équilibrée, a exhorté la Hollande. Pour certaines organisations, la première étape consiste à réaliser que les mythes entourant le SSO ne sont que des illusions.
Pour d’autres organisations, l’attrait de l’OSS et des logiciels mixtes est déjà évident. Cela leur permet de développer de nouvelles applications en toute sécurité et d’augmenter la vitesse de cédant de nouvelles idées, a-t-il expliqué.
OSS est souvent considéré comme étant peu sûr et non pris en charge. Comme ces connotations négatives continuent de salir sa réputation, certaines organisations l’interdisent officiellement, même si elles utilisent le système d’exploitation sans le savoir.
D’autres adoptent avec enthousiasme oss, exploitant ses avantages, tels que l’aide au développement flexible et rapide. OSS peut avoir une influence positive sur le développement de logiciels. Mais cela ne peut se produire que s’il est utilisé et géré de manière responsable, selon le dernier guide de l’ISF.
Le soutien est essentiel
Le guide recommande d’appuyer le gestionnaire de programme du SSO de l’organisation avec les fonds et les ressources nécessaires à l’élaboration d’un programme et d’une équipe viables. Alors que dans certains cas, les outils existants pour les logiciels sources fermées peuvent être étendus pour sécuriser et gérer oss.
D’autres cas d’intégration exigent que l’équipe du programme se procure des outils supplémentaires pour améliorer davantage la sécurité du SSO. L’équipe devrait également surveiller les flux de renseignements sur les menaces à la recherche de mentions des composants du SSO que l’organisation utilise, selon le guide de l’ISF.
« Résister au passage au système d’exploitation pourrait limiter la capacité d’une organisation de progresser et d’évoluer. S’il est exploité efficacement, OSS peut potentiellement être un accélérateur pour l’entreprise », a déclaré Holland. « La promotion d’un programme de gestion du SSO est donc essentielle à la sécurisation et à la gestion du SSO, ce qui permet à l’organisation de l’utiliser en toute sécurité. »
Préparation requise
La combinaison de la dynamique de l’open source avec des pratiques établies autour de la gestion des logiciels à source fermée fournira un programme cohérent et global de gestion de logiciels. Le résultat sera la meilleure occasion de succès, a ajouté Holland.
De nombreux fournisseurs de logiciels sources traditionnellement fermés adoptent les principes de l’OSS. Cela signifie que l’OSS est là pour rester, a déclaré l’ISF.
La flexibilité des logiciels open et mixed source pourrait entraîner une baisse des logiciels à source fermée. À son tour, cela pourrait provoquer un changement fondamental dans la gestion des logiciels, l’octroi de licences et la sécurité.
Réparer ce qui est cassé
« Déploiement de logiciels open source : défis et récompenses » présente une série de défis et de solutions proposées pour un certain nombre de situations informatiques typiques. L’information cite des questions spécifiques qui impliquent l’utilisation de composants open source.
L’un des défis présentés concerne la façon dont certaines organisations utilisent des applications logicielles qui ont inclus par inadvertance du code open source dans l’infrastructure informatique. Ou l’organisation n’a pas une vue complète de tous les composants OSS déployés dans leur environnement.
La situation consiste à faire mettre en œuvre des composants open source de manière incontrôlée et potentiellement laissés dans un état d’insécurité avec des exploits obsolètes, non patchés et sujets à la vulnérabilité. Sans une connaissance adéquate de l’endroit et de la façon dont le système d’exploitation est utilisé, l’organisation risque d’autoriser les vulnérabilités dans leur infrastructure dont le personnel informatique n’est pas au courant et ne peut donc pas s’y attaquer de façon proactive.
Le guide note que cela illustre ce qui a mené à la violation d’Equifax en septembre 2017. Dans ce cas, les acteurs malveillants ont exploité une version obsolète d’Apache Struts, un framework d’application Web OSS pour les applications Java. Le personnel informatique ne savait pas que ce composant de plate-forme OSS existait dans l’environnement de l’entreprise. Par conséquent, il n’avait pas été inclus dans les processus et les calendriers de gestion des correctifs de l’entreprise.
Corrections en devenir
Le guide de l’ISF explique une solution à ce défi brisé. Il suggère aux organisations de créer et de maintenir un inventaire précis et à jour de tous les composants du SSO dans leur environnement d’entreprise. Une première phase d’interrogatoire préalable peut être nécessaire si un inventaire n’est pas déjà en place ou si l’organisation envisage la possibilité que le SSO soit utilisé sans être officiellement reconnu ou documenté.
Les informations cataloguées devraient inclure la reproduction de détails sur les logiciels sources fermés, la source du système d’exploitation (p. ex. fournisseur, développeur tiers, référentiel OSS ou projet de développement interne), les versions déployées des composants OSS, les dépendances logicielles, les fournisseurs de soutien et les emplacements des mises à jour sûres disponibles au téléchargement.
La compilation d’un tel inventaire peut être créée manuellement. Une autre option consiste à déployer un outil de découverte automatisé qui scanne et surveille l’infrastructure pour créer une base de données de logiciels et les versions en cours d’utilisation.
Absence de sécurité dans les pratiques DevOps
Un autre défi crucial dans le guide ISF utilise l’exemple des développeurs agiles et DevOps qui privilégient le déploiement rapide des applications par rapport à la sécurité du code. Les correctifs suggérés fixent le rythme de ce qui devrait être une pratique exemplaire pour le codage des applications.
Le guide isf suggère que les développeurs à l’interne devraient être informés et formés aux pratiques de codage sécurisées liées au système d’exploitation et à certains des défis que le système d’exploitation présente pour rendre les applications sources mixtes sécurisées par la conception. Les responsabilités de codage sécurisé des développeurs doivent être décrites dans un cycle de vie de développement sécurisé (SDL) spécifique à OSS.
Cela, à son tour, devrait être étroitement lié à la méthodologie SDL pour les logiciels sources fermées. Les délais et les délais d’écriture du code doivent tenir compte de l’intégration de la sécurité dans la phase de conception.
Comment les choses fonctionnent
Si une organisation utilise des logiciels open source et utilise un modèle informatique central, il devrait y avoir des opérateurs, ou quelqu’un, responsable des opérations informatiques en général. Cette personne est responsable de la maintenance des correctifs et s’assure que les mises à niveau sont effectuées, selon Wei Lien Dang, co-fondateur, et directeur de la stratégie chez StackRox.
« Cela pourrait également être géré par quelqu’un sur le développement ou l’équipe DevOps. Bien que les logiciels open-source sont souvent un choix soucieux des coûts, cela ne signifie pas qu’il n’est pas sans frais généraux. Cela prend la forme d’une expérience et/ou d’une formation pour s’assurer que le code OSS est patché et sécurisé », a-t-il déclaré à LinuxInsider.
C’est l’une des raisons pour lesquelles les organisations vont avec des logiciels commerciaux ou un service géré par le cloud. Dans ces cas, il est de la responsabilité du fournisseur de logiciels ou de cloud de mettre des correctifs à disposition. Vous bénéficiez de l’avantage supplémentaire d’un niveau de soutien et d’entretien externalisés, a-t-il ajouté.
Le travailleur informatique moyen peut ne pas savoir comment patcher le code OSS. Mais il n’est pas rare que la personne qui a pris la décision de tirer parti de l’OSS au sein d’une organisation soit responsable de son maintien, a expliqué M. Dang.
« Mais le défi est que la maintenance de ce logiciel devient une connaissance tribale. Donc, si cette personne s’en va, les autres membres de l’équipe de l’IT doivent trouver quoi faire », a-t-il suggéré.
Fonctions variées
Les fonctions des travailleurs de l’it varient considérablement d’une organisation à l’autre. Mais un grand nombre d’organisations ont très peu de ressources informatiques qui sont axées sur le patching, selon Thomas Hatch, directeur technique et co-fondateur de SaltStack.
« Les professionnels modernes de l’informatique passent beaucoup plus de temps à gérer les API et les OV de haut niveau. Ils doivent faire face à un grand groupe de systèmes et de services et ne sont pas aussi axés sur le système et la gestion de l’OSS qu’ils l’étaient il y a 10 ans », a-t-il déclaré à LinuxInsider.
La sécurité continue des composants logiciels ouverts est un problème, a convenu Hatch.
« La capacité de prendre des quantités massives de logiciels gratuits, non testés, non vérifiés, et pas nécessairement sécurisés sur le plateau a créé une responsabilité profondément ancrée dans les domaines qui font un usage important de logiciels open-source, at-il dit.
Formation pour tous
Si nous parlons de personnel it central ou quelqu’un avec un rôle i / O, alors oui, Dang croit. Toute personne responsable de la partie de l’environnement dans laquelle l’OSS est utilisé devrait avoir ces connaissances.
Si vous utilisez open source, vous assumez la responsabilité du suivi des correctifs et des informations de sécurité. Cela devrait être la responsabilité du décideur qui a décidé d’utiliser le SSO, fait-il valoir.
« Ils devraient assumer la responsabilité de l’exploitation de cette partie de la pile et de l’environnement dans laquelle l’OSS s’exécute. Ils devraient également être responsables de travailler avec leur équipe pour mettre en œuvre un processus de maintien des correctifs, sinon ils courent le risque de perdre les connaissances critiques s’ils quittent l’organisation », a déclaré M. Dang.
Est-ce que tous les OSS utilisent le coupable?
Les avantages proviennent de l’utilisation de logiciels open source, mais les organisations doivent faire attention à ce qu’elles comprennent comment traiter les vulnérabilités et les problèmes de licence qui pourraient créer des expositions, a mis en garde Dang.
Les développeurs de logiciels se concentrent sur la construction et l’expédition de logiciels. Il existe des pratiques de développement de logiciels, quelle que soit la méthodologie. Ceux qui empruntent à l’open source doivent rendre compte de la sécurité des produits, a exhorté Dang.
« Il n’est pas unique à DevOps. Si vous négligez le processus de correction du SSO, vous pouvez facilement mettre votre organisation en danger », a-t-il dit.
Il y a deux considérations fondamentales lors de l’utilisation d’OSS dans le développement de logiciels. La première est que vous avez le bon outillage en place pour assurer la protection. L’autre est que vous avez les bons processus en place pour gérer les correctifs.
Vous devez avoir un moyen de découvrir les vulnérabilités, les problèmes de licence et d’autres risques associés à l’utilisation d’OSS.
La méthodologie, Agile, DevOps, ou autrement, ne devrait pas faire de différence. »,"\"Si vous choisissez d’utiliser OSS,
