Il a été dit – et pas seulement par moi – qu’un code malveillant chiffré reste toujours un code malveillant. Le chiffrement n’y change rien, si ce n’est qu’il peut éventuellement empêcher les systèmes de sécurité et l’infrastructure applicative de détecter son transit sur le réseau.
Il en va de même pour les applications et les plateformes exécutées dans des conteneurs. Si une application présente une vulnérabilité, elle reste vulnérable, qu’elle s’exécute sur un système d’exploitation, dans une machine virtuelle ou, désormais, dans un conteneur. Si elle est vulnérable dans le centre de données, elle l’est aussi dans le cloud. Et inversement.
Les conteneurs ne sont pas conçus pour protéger comme par magie les applications. Ils offrent une sécurité de base au niveau de la couche réseau, mais le réseau n’est pas l’application. Les applications possèdent leur propre surface d’attaque, qui comprend leur code et leurs interfaces (API), ainsi que les protocoles (HTTP, TCP) et la pile applicative dont elles ont besoin. Rien de tout cela ne change lorsque l’on ajoute une entrée à une table IP ou que l’on restreint, d’une autre manière, les requêtes entrantes à celles provenant du point d’entrée de l’environnement conteneurisé.
Si j’aborde ce sujet, c’est grâce à l’enquête DevSecOps 2017 de Sonatype. Dans cette enquête, 88 % des plus de 2 200 personnes interrogées estimaient que la sécurité des conteneurs était importante, mais seulement 53 % utilisaient des produits de sécurité pour détecter les applications, systèmes d’exploitation ou configurations vulnérables dans les conteneurs.
Les deux premiers éléments de cette statistique — les applications et les systèmes d’exploitation — m’ont interpellé, car ils font partie des composants d’une pile applicative complète qui ne changent pas nécessairement selon l’emplacement ou le modèle d’exploitation (cloud, conteneurs, virtualisation, etc.). Une application ou une API présentant une vulnérabilité de type injection SQL ou XSS ne bénéficie pas comme par magie d’une protection lorsqu’elle passe d’un modèle à un autre. Cette vulnérabilité se trouve dans le code. Il en va de même pour les plateformes, qui font incontestablement partie de la pile de sécurité applicative. Une vulnérabilité liée au traitement des en-têtes HTTP dans Apache sous Linux subsistera si l’application passe d’un modèle traditionnel reposant sur un système d’exploitation à un modèle conteneurisé.
Il est important – voire impératif – que nous continuions à identifier les vulnérabilités dans l’ensemble de la pile applicative quel que soit l’endroit où l’application est déployée ou la forme sous laquelle elle l’est.
Lors du passage aux conteneurs, il est tout aussi important de conserver les protections déjà utilisées pour les applications traditionnelles. Un pare-feu d’applications web est tout aussi utile pour les applications déployées dans des conteneurs que pour celles déployées dans le cloud ou dans des environnements traditionnels.
Il en va de même pour les autres outils de sécurité que les répondants à l’enquête ont déclaré utiliser, tels que les solutions d’analyse statique et en temps réel (SAST, DAST, IAST et RASP). Bien que l’utilisation des pare-feu d’applications web (WAF) soit supérieure à celle des autres outils, les outils SAST et SCA (analyse du code source) sont également courants. La SCA est une méthode statique permettant d’éliminer les problèmes avant la livraison. Au risque de trahir mon âge, je précise que des outils comme lint relèvent de la catégorie des outils SCA. Bien qu’ils ne détectent pas en temps réel les vulnérabilités résultant de l’interaction du code, notamment avec les utilisateurs, ils peuvent repérer 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 ce que vous pensez. Vous vous dites : « 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 comme JavaScript est interprété, toutes ces histoires de dépassements de mémoire tampon et de fuites de mémoire ne sont que de mauvais souvenirs de l’époque où vous programmiez en C/C++. »
Sauf que JavaScript — comme d’autres langages interprétés modernes — est en définitive implémenté dans un langage plus proche du matériel, tel que C/C++. Et comme cela a déjà été démontré par le passé, une personne suffisamment ingénieuse peut exploiter ce fait pour concevoir une attaque contre le système.
Et même si ce n’est pas un sujet de préoccupation, il existe de nombreuses autres vulnérabilités dans n’importe quel code, dues aux bibliothèques utilisées ou à un appel système mal employé qui compromet la sécurité côté serveur. Selon les études actuelles, 80 % des applications sont constituées de composants open source. L’étude de Sonatype a également relevé une hausse de 50 % des violations avérées ou présumées liées à des composants open source entre 2014 et 2017. Bon nombre de ces composants sont écrits dans des langages qui se prêtent à des erreurs plus spectaculaires, à la fois parce qu’ils sont moins encadrés et parce que de moins en moins de développeurs maîtrisent ces langages.
En résumé, tout code est susceptible de contenir des vulnérabilités. Et puisque le code constitue la pierre angulaire des applications, qui sont aujourd’hui la vitrine de l’entreprise, il est important de les analyser et de les protéger, quels que soient leur mode et leur environnement de déploiement.
Conteneurs ou cloud. Environnement traditionnel ou virtuel. Toutes les applications doivent faire l’objet d’une analyse des vulnérabilités et être protégées contre l’exploitation des failles des plateformes et des protocoles. Point final.
Les applications doivent faire l’objet d’analyses et de tests approfondis pendant leur développement, puis être à nouveau testées en production. Ces deux étapes sont nécessaires, car le sophisme de décomposition nous enseigne que l’introduction de nouveaux composants modifie la situation de référence. De nouvelles interactions peuvent faire apparaître des vulnérabilités jusque-là inconnues.
Pour protéger les applications, tenez compte des points suivants :
- Utilisez des outils d’analyse du code et des applications pendant le développement. Intégrez-les si possible au pipeline CI/CD.
- Effectuez de nouveaux tests en production, au cas où l’interaction avec d’autres composants ou applications ferait apparaître des problèmes.
- Tenez-vous informé des vulnérabilités des protocoles et des plateformes, ainsi que de celles découvertes dans les bibliothèques tierces que vous pourriez utiliser
- Intégrez un pare-feu applicatif web à votre architecture. Même si vous ne l’utilisez pas en mode blocage, il constitue une ressource inestimable en cas de découverte d’une vulnérabilité zero-day affectant un protocole ou une plateforme, ou d’une vulnérabilité dans une bibliothèque.
Restez en sécurité !
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.