Leçons tirées de MongoDB et MongoBleed

Les logiciels libres sont une réalité de l'informatique moderne, et il n'existe pratiquement aucun domaine où ils n'influencent pas, au moins partiellement, l'infrastructure informatique. Même les logiciels les plus propriétaires intègrent des bibliothèques et des utilitaires issus de projets libres, créés par des développeurs bien intentionnés pour résoudre des problèmes du quotidien. 

Le problème, c'est que si les logiciels libres offrent de nombreux avantages, ils créent également des surfaces d'attaque que les organisations ne peuvent pas contrôler.

Cette réalité est revenue en force avec la récente divulgation de la vulnérabilité MongoBleed, qui affecte les déploiements MongoDB. Si les détails techniques de MongoBleed sont préoccupants en soi, le problème plus large ne se limite pas à MongoDB. Il concerne les défis structurels en matière de sécurité et de conformité qui se posent lorsque des logiciels libres deviennent une infrastructure critique.

Comprendre MongoBleed sans se focaliser dessus

MongoBleed fait référence à une grave vulnérabilité de divulgation de mémoire dans MongoDB qui permettait à des attaquants non authentifiés d'extraire des données sensibles à partir d'instances de base de données exposées. 

Qu’est-ce qu’une vulnérabilité de divulgation de mémoire ? En raison de failles telles qu’une mauvaise gestion de la mémoire ou des dépassements de tampon, des attaquants peuvent récupérer des fragments de mémoire contenant des identifiants, des jetons, des données de configuration et potentiellement des informations réglementées.

Plusieurs caractéristiques de MongoBleed le rendaient particulièrement dangereux :

• La vulnérabilité pourrait être exploitée sans authentification.
• L'exploitation ne nécessitait pas d'outils avancés une fois le code de preuve de concept publié.
• De nombreuses instances de MongoDB étaient directement exposées à Internet.
• Des données sensibles pourraient fuiter sans générer d'erreurs évidentes au niveau de l'application.

D'un point de vue organisationnel, cela a révélé la fréquence de déploiement de MongoDB et, dans des conditions par défaut et avec une exposition à Internet, comment une simple vulnérabilité peut devenir un risque systémique. 

Le mythe des logiciels libres sécurisés

Dans le milieu technologique, il est communément admis que les logiciels libres sont intrinsèquement plus sûrs car leur code est public. On avance que la transparence favorise l'évaluation par les pairs et accélère le diagnostic des bogues, ce qui est vrai dans les cas où les enjeux sont faibles. Cependant, l'idée qu'une bonne sécurité dispense d'obfuscation est erronée, et il existe plusieurs cas d'utilisation où la protection de la logique d'une application la protège des attaques. 

Les projets open source présentent une grande hétérogénéité en termes de maturité, de gouvernance, de financement et de rigueur d'évaluation. Certains bénéficient du soutien de fondations bien dotées et d'équipes de sécurité dédiées. D'autres sont maintenus par de petites équipes de bénévoles, même si des milliers d'entreprises utilisent leurs logiciels.

MongoBleed démontre que la visibilité publique du code source offre autant d'avantages aux attaquants qu'aux défenseurs. Lorsque le code source est public, les adversaires peuvent :

• Étudier la logique interne à grande échelle
• Identifier les cas limites que les tests automatisés pourraient ne pas détecter.
• Développer discrètement les exploits avant leur divulgation publique
• Développez rapidement des preuves de concept à des fins d'exploitation dès que les vulnérabilités sont connues.

Pour les décideurs, cela déplace le débat de « les logiciels libres sont-ils sécurisés ? » à « comment gérer les risques liés aux logiciels libres de manière responsable ? »

Pourquoi les vulnérabilités des logiciels libres deviennent des problèmes de conformité

MongoBleed illustre que, bien que la vulnérabilité elle-même résidât dans le code de MongoDB, l'impact sur la conformité dépendait entièrement de la manière dont chaque organisation déployait et gérait ses instances MongoDB. 

Cela pose problème aux organisations qui adoptent des logiciels sans vérification préalable. Une fuite de données ou une exploitation de faille zero-day peut engendrer des problèmes. GDPR, HIPAA, SOC 2, ISO 27001et les exigences propres à l'industrie.

Du point de vue de la conformité, la cause importe moins que le résultat. Les organismes de réglementation et les auditeurs posent généralement des questions plus détaillées qui vont au-delà de la simple constatation de l'existence d'une vulnérabilité :

• L’organisation a-t-elle rapidement pris connaissance de la vulnérabilité et peut-elle démontrer comment elle a acquis cette connaissance (par le biais de flux de renseignements sur les menaces, d’alertes de fournisseurs ou d’une surveillance interne) ? 
• L'organisation disposait-elle d'un processus de gestion documenté qui traitait explicitement des composants open source et des dépendances tierces ? 
• À quelle vitesse les vulnérabilités sont-elles identifiées, et qui les identifie ? 
• Des mesures correctives et d'atténuation ont-elles été prises dans le respect des objectifs de niveau de service définis en fonction de la gravité et de l'exposition ? 
• Le système concerné était-il configuré conformément aux référentiels de sécurité documentés plutôt qu'aux paramètres par défaut du fournisseur ? 
• Des mécanismes de surveillance et d'enregistrement étaient-ils en place pour détecter toute exploitation potentielle ou tout comportement anormal pendant la période d'exposition ? 
• Existe-t-il des preuves ? Les leçons tirées ont-elles été intégrées aux futures évaluations des risques et aux améliorations des contrôles ?

L'open source complique ces questions car la responsabilité est partagée, mais pas l'obligation de rendre des comptes.

Où se situe la responsabilité ?

L'une des réalités les plus difficiles à accepter pour les organisations est que l'utilisation de logiciels libres n'entraîne pas un transfert de risques. Le simple fait d'utiliser du code provenant d'un projet open source ne signifie pas que le responsable de ce projet soit tenu de garantir votre conformité. Ceci, même en supposant que le responsable soit connu et non une personne pseudonyme. 

MongoBleed confirme plusieurs vérités gênantes qui reviennent fréquemment lors des analyses portant sur MongoDB et des plateformes open source similaires :

• Les fournisseurs peuvent divulguer rapidement les vulnérabilités, mais la mise en œuvre des correctifs dépend toujours des processus internes et peut ne pas être suffisamment rapide pour résoudre le problème. 
• Les fournisseurs de services cloud ne sécurisent pas automatiquement les services autogérés, même lorsque des vulnérabilités sont mises en évidence. 
• Les configurations par défaut sont rarement conformes, et pourtant de nombreuses organisations considèrent les outils OSS comme des systèmes prêts à l'emploi.

Autrement dit, l'open source accélère l'innovation, mais il exige également une gouvernance interne plus forte.

Les angles morts de sécurité créés par l'open source

MongoBleed met en lumière plusieurs angles morts récurrents qui affectent de nombreuses organisations utilisant une infrastructure open source, en particulier des bases de données telles que MongoDB, qui se situent souvent à l'intersection du développement d'applications et de la sécurité.

• Dépendances Les applications modernes reposent sur de multiples dépendances, telles que des bases de données, des bibliothèques de compression, des pilotes, des plugins et des outils d'orchestration. Une vulnérabilité peut exister loin de la logique applicative. Sans analyse continue de la composition logicielle, les organisations risquent de ne se rendre compte de la vulnérabilité qu'une fois l'exploitation en cours. 
• Latence des correctifs : Même lorsque des correctifs sont disponibles, les organisations retardent souvent leur déploiement par crainte de perturber le système ou de compromettre la gouvernance en place. Dans le cas de MongoBleed, le délai entre la divulgation publique et l'exploitation à grande échelle a été extrêmement court, ce qui s'est avéré particulièrement problématique pour les organisations gérant elles-mêmes leurs clusters MongoDB sans processus automatisé de mise à jour. 
• Dépendance excessive aux contrôles périmétriques : De nombreux environnements partent encore du principe que les pare-feu ou les limites du réseau empêcheront toute exploitation. 

Repenser la gouvernance des logiciels libres

Relever ces défis ne signifie pas abandonner l'open source. Ce serait irréaliste et contre-productif. Les organisations doivent plutôt faire preuve de plus de maturité dans leur gouvernance de l'open source.

Une gouvernance efficace des logiciels libres inclut généralement un registre à jour des composants open source. De plus, elle exige que toute personne impliquée dans la conformité et la gestion informatique comprenne l'évolution des éléments d'infrastructure critiques. Il ne suffit pas de confier la gestion des logiciels à un collectif décentralisé comme s'il faisait partie de vos équipes de sécurité ou informatiques. 

Alignement de la gestion des logiciels libres avec les cadres de conformité grâce à Continuum GRC

L'un des moyens les plus efficaces de justifier un investissement dans la sécurité open source est de l'aligner sur les exigences de conformité existantes. La plupart des principaux référentiels exigent déjà une gestion rigoureuse des vulnérabilités, même s'ils ne mentionnent pas explicitement l'open source. N'imaginez pas que vous deviez entreprendre ce processus seul. 

Nous fournissons un soutien en matière de gestion des risques et de conformité pour chaque cadre réglementaire et de conformité majeur du marché, notamment :

• FedRAMP
• GovRAMP
• GDPR
• NIST800-53
• DFARS NIST 800-171, 800-172
• CMMC
• SOC 1, SOC 2
• HIPAA
• PCI DSS 4.0
• IRS 1075, 4812
• COSO SOX
• Série ISO 27000
• Série ISO 9000
  
• CJIS
• Plus de 100 cadres

Et bien plus encore. Nous sommes la seule solution de gestion des risques et de conformité autorisée par FedRAMP et StateRAMP au monde.

Continuum GRC est une cybersécurité proactive® et le seul FedRAMP et Autorisé par l'ÉtatRAMP Plateforme mondiale d'audit de cybersécurité. Appelez le 1-888-896-6207 pour discuter des besoins de votre organisation en matière de cybersécurité et découvrir comment nous pouvons vous aider à protéger vos systèmes et à garantir votre conformité.