Que faites-vous lorsque vous avez besoin de deux choses, mais que « tout le monde sait » qu’elles sont incompatibles ?
Un mythe tenace circule depuis longtemps au sein des communautés des réseaux et de la sécurité : les architectures logicielles sécurisées seraient rigides, tandis que les logiciels développés selon des méthodes agiles seraient moins sûrs. Mais un instant : existe-t-il la moindre preuve qu’un logiciel développé selon un modèle itératif soit intrinsèquement moins sûr ? Si c’est le cas, mes « recherches » (comprenez : mes recherches sur Google) ne m’ont pas vraiment permis d’en trouver.
En effet, on peut raisonnablement affirmer qu’un cycle de livraison plus rapide et un processus de mise en production automatisé et rationalisé réduisent les risques en diminuant la durée globale d’exposition aux vulnérabilités.
Alors, existe-t-il vraiment un fossé entre flexibilité et sécurité ? Malheureusement, je dirais que oui, encore aujourd’hui.
Cependant, je ne suis pas convaincu qu’un cycle de vie logiciel agile introduise davantage de vulnérabilités intrinsèques dans le code (même si certaines nouvelles plateformes, comme les systèmes de gestion de conteneurs, créent assurément de nouvelles surfaces d’attaque), car le code applicatif ne constitue qu’une partie de la posture globale de sécurité d’une organisation.
Sachant que tous les logiciels comportent des défauts, les piles technologiques informatiques intègrent également des dispositifs de sécurité externes au code applicatif, tels que des pare-feu réseau, des systèmes de détection d’intrusion et des pare-feu applicatifs web. Bon nombre de ces systèmes doivent surveiller le comportement des applications et réagir aux menaces nouvellement découvertes dans les frameworks ou les systèmes d’exploitation. Dans l’idéal, ces systèmes doivent être aussi agiles que le cycle de livraison des logiciels. Dans le cas contraire, l’une des deux situations suivantes se produira : soit les dispositifs de sécurité seront perçus comme nuisant à la rapidité de livraison et au délai de création de valeur, soit ils n’assureront pas la protection pour laquelle ils ont été mis en place. Aucune de ces deux situations n’est vraiment optimale.
La solution évidente consiste à rapprocher le modèle de contrôle de la sécurité de celui du cycle de vie de la livraison logicielle. De fait, le mouvement DevSecOps commence à appliquer les pratiques de l’ingénierie logicielle et du DevOps à la mise en œuvre des contrôles de sécurité, ainsi qu’à partager la responsabilité de la sécurité entre tous les membres d’une équipe, même si l’expertise approfondie reste l’apanage d’une équipe spécialisée de professionnels très expérimentés.
Cette transformation culturelle s’accompagne d’une évolution technologique, dans laquelle la mise en œuvre des contrôles de sécurité est intégrée au pipeline de livraison logicielle. Les contrôles de sécurité accompagnent ainsi chaque nouvelle itération du logiciel tout au long des phases de test, de préproduction et de déploiement, au lieu d’être simplement ajoutés à la fin. Des éléments de télémétrie et de traçabilité sont intégrés et suivis à différents niveaux de la pile technologique. De nouvelles métriques permettant d’identifier et de suivre les adversaires, ainsi que de produire des rapports à leur sujet, peuvent être rapidement recueillies et analysées.
Pour que cela soit possible, votre pile technologique doit collaborer autant que vos équipes. C’est l’une des perspectives les plus intéressantes qu’offre une future organisation F5 + NGINX. Avec un portefeuille qui s’étend du pare-feu réseau au serveur d’applications et couvre toutes les couches intermédiaires, les possibilités de mettre en place un ensemble de contrôles de sécurité plus agiles, mieux intégrés et plus riches en informations sont immenses. La promesse d’une sécurité et d’une visibilité de niveau entreprise, alliées à une agilité légère, pourrait offrir à chaque membre de l’équipe les outils, les informations et la tranquillité d’esprit (relative) qu’il recherche.
Pour en savoir plus sur les avantages du rapprochement entre F5 et NGINX, consultez l’article du PDG de F5 qui présente la série d’articles de blog « Bridging the Divide ».
À propos de l’auteur
Articles 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.