Les éléments vulnérables exécutés dans des conteneurs restent des éléments vulnérables

Il a été dit – et pas seulement par moi – qu’un code malveillant chiffré reste un code malveillant. Le cryptage ne change rien à cela, à part peut-être rendre la sécurité et l'infrastructure des applications aveugles quant à leur transport à travers le réseau.

Il en va de même pour les applications et les plateformes exécutées dans des conteneurs. Si l’application est vulnérable, elle l’est qu’elle s’exécute sur un système d’exploitation, dans une machine virtuelle ou, de nos jours, dans un conteneur. Si l’application est vulnérable dans le centre de données, elle est vulnérable dans le cloud. Et vice-versa.

Les conteneurs ne sont pas conçus pour protéger les applications comme par magie. Ils fournissent une sécurité de base au niveau de la couche réseau, mais le réseau n’est pas l’application. Les applications ont leur surface d'attaque, comprenant leur code et leurs interfaces (API) ainsi que les protocoles (HTTP, TCP) et la pile d'applications dont elles ont besoin. Rien de tout cela ne change en ajoutant une entrée à une table IP ou en limitant les demandes entrantes à celles provenant de l'entrée vers l'environnement conteneurisé.

La raison pour laquelle j'évoque ce sujet est grâce à l'enquête DevSecOps 2017 de Sonatype. Dans cette étude, 88 % des plus de 2 200 personnes interrogées ont convenu que la sécurité des conteneurs était importante, mais seulement 53 % d'entre elles utilisent des produits de sécurité pour identifier les applications/systèmes d'exploitation/configurations vulnérables dans les conteneurs.

Les deux premiers éléments de cette statistique – les applications et le système d’exploitation – m’ont sauté aux yeux, car ce sont deux des composants d’une pile d’applications entièrement réalisée qui ne changent pas nécessairement en fonction de l’emplacement ou du modèle opérationnel (cloud, conteneur, virtualisation, etc…). Une application ou une API présentant une vulnérabilité SQLi ou XSS n’est pas dotée comme par magie d’une protection lorsqu’elle se déplace entre les modèles. Cette vulnérabilité est dans le code. Il en va de même pour les plateformes, qui font incontestablement partie de la pile de sécurité des applications. Une vulnérabilité dans la gestion des en-têtes HTTP dans Apache lors de l'exécution sous Linux existera toujours si cette application est déplacée d'un modèle traditionnel basé sur le système d'exploitation vers un modèle conteneurisé.

Il est important, voire impératif, que nous continuions à identifier les vulnérabilités dans l’ensemble de la pile d’applications , quel que soit l’endroit ou la forme sous laquelle l’application est déployée.

Il est également tout aussi important de conserver en place les protections d’application déjà utilisées pour les applications traditionnelles lors du passage aux conteneurs. Un pare-feu d’application Web est tout aussi bénéfique pour les applications déployées dans des conteneurs que pour les applications déployées dans le cloud ou dans des environnements traditionnels.

Comme d'autres outils de sécurité utilisés par les répondants, l'enquête a révélé que les solutions d'analyse statique et en temps réel ( SAST, DAST, IAST et RASP ) sont utilisées. Bien que l'utilisation du pare-feu d'application Web (WAF) dépasse celle des autres outils, SAST et SCA (analyse du code source) sont également courants. L’ACS est un moyen statique d’éliminer les problèmes avant la livraison. Je vais me dater et noter que des outils comme Lint entrent dans la catégorie des outils SCA, et bien qu'ils n'exposent pas les vulnérabilités résultant de l'interaction du code (et avec les utilisateurs) en temps réel, ils peuvent trouver certaines des erreurs les plus courantes commises par les développeurs qui entraînent des fuites de mémoire, des plantages ou le tristement célèbre dépassement de tampon.

Je sais à quoi tu penses. Vous pensez : « Lori, je viens de lire les résultats de l'enquête 2017 de Stack Overflow auprès des développeurs , et JavaScript est de loin le langage préféré des développeurs. Et JavaScript est interprété, donc tous ces débordements de tampon et ces fuites de mémoire ne sont que de mauvais souvenirs de l'époque où vous codiez en C/C++.

Sauf que JavaScript – et d’autres langages modernes interprétés – sont finalement implémentés dans un langage plus proche du circuit imprimé, comme C/C++. Et comme cela a été démontré dans le passé , si l’on est suffisamment intelligent, on peut utiliser ce fait pour créer un exploit du système.

Et même si cela ne pose pas de problème, il existe de nombreuses autres vulnérabilités dans tout code basé sur les bibliothèques utilisées ou un appel système mal utilisé qui viole la sécurité côté serveur. Les enquêtes actuelles indiquent que 80 % des applications sont composées de composants open source. L'enquête Sonatype a également noté une augmentation de 50 % des violations vérifiées ou suspectées liées aux composants open source entre 2014 et 2017. Beaucoup d’entre eux sont écrits dans des langages qui se prêtent à des erreurs plus spectaculaires, à la fois parce qu’ils sont moins contrôlés et parce qu’il y a de moins en moins de développeurs maîtrisant ces langages. 

Le fait est que tout code est susceptible de contenir des vulnérabilités. Et comme le code est la pierre angulaire des applications, qui sont le visage de l’entreprise aujourd’hui, il est important de les analyser et de les protéger, peu importe où et comment elles sont déployées.

Conteneurs ou cloud. Traditionnel ou virtuel. Toutes les applications doivent être analysées à la recherche de vulnérabilités et protégées contre les exploits de plateforme et de protocole. Période.

Les applications doivent être soigneusement analysées et testées pendant le développement, puis testées à nouveau en production. Les deux sont nécessaires, car l’ erreur de décomposition nous dit que l’introduction de nouveaux composants modifie la ligne de base. De nouvelles interactions peuvent mettre en évidence des vulnérabilités jusque-là inconnues.

Pour protéger les applications, tenez compte des éléments suivants :

• Utiliser des outils d’analyse de code et d’application dans le développement. Intégrez-les au pipeline CI/CD si possible.
• Testez à nouveau en production, au cas où l'interaction avec d'autres composants/applications poserait des problèmes.
• Restez informé des vulnérabilités du protocole et de la plateforme , ainsi que de celles découvertes dans les bibliothèques tierces que vous pouvez utiliser
• Intégrez un pare-feu d'application Web à votre architecture. Même si vous ne l'utilisez pas en mode blocage, il s'agit d'une ressource inestimable dans le cas où une vulnérabilité zero-day ou une vulnérabilité de bibliothèque d'un protocole/d'une plateforme est découverte.

Soyez prudent!