Les cycles de développement et de mise en production d’applications et de services Web ne cessent de s’accélérer. Avec à la clé, des délais de test et de contrôle, notamment de sécurité, réduits. De quoi renforcer l’attrait des pare-feux applicatifs (WAF).
Les DevOps ? Nitzan Miron, vice-président de Barracuda Networks en charge des produits et services de sécurité applicative, résume l’élément clé de la démarche : « C’est une question de vitesse ! » Autrement dit, « au lieu d’attendre des semaines ou des mois pour la prochaine version importante, les équipes logicielles peuvent sortir des fonctionnalités en quelques jours, voire quelques heures ».
Chez Citrix, David Jack, directeur du marketing des produits réseau, développe en rappelant qu’il s’agit avant tout « d’accélérer le rythme de l’innovation pour les applications et les services - souvent en conjonction avec l’adoption de technologies de microservices telles que Kubernetes et Istio. Cette combinaison offre des bénéfices significatifs ».
Mais qui dit DevOps, ne dit pas uniquement vitesse. Arnaud Lemaire, responsable de l’ingénierie des systèmes de F5 Networks, pour la France, souligne la dimension collaborative de l’approche, tout comme Edouard Viot, chef de produits chez Rohde & Schwarz Cybersecurity : « avant le mouvement DevOps, les équipes de développement étaient séparées des équipes chargées de la mise en production. Les interactions entre les deux services étaient faibles. Pour gagner en flexibilité, le DevOps doit à la fois écrire le code, mais aussi le mettre en production. La mise en production inclut les briques de sécurité nécessaires, donc le WAF».
Des défis spécifiques
Pour Edouard Viot, l’équipe DevOps « doit donc s’assurer, à l’écriture du code, qu’il fonctionnera avec les équipements qui seront présents en production : par exemple qu’une nouvelle version fonctionne bien avec le WAF, qu’il n’y a pas de faux positifs, etc. ». Mais dans la pratique, tout n’est pas rose.
Ainsi, Arnaud Lemaire relève que « ce que l’on observe actuellement, dans la plupart des initiatives DevOps, c’est que les efforts se concentrent sur la fourniture du code, avec toutes les questions de sécurité associées laissées de côté ».
Nitzan Miron ne dit pas autre chose : « l’augmentation de la vitesse des déploiements signifie également que le nouveau code n'est testé que pendant quelques heures avant d'être utilisé en production. Ce n'est pas assez pour qu’une équipe de sécurité puisse procéder à une vérification et détecter les problèmes de sécurité, comme elle l'aurait fait si les versions étaient espacées de plusieurs semaines ou mois. Déployer du code non audité en production signifie qu'il existe un risque important qu'un problème de sécurité soit résolu et découvert pour la première fois lorsqu'il est exploité par un attaquant ».
Le temps limité accordé à la recherche de vulnérabilités potentielles n’est pas la seule source de risques induite par le passage aux DevOps.
David Jack souligne également « le rythme accru de changement dans les applications, ainsi que la surface d’attaque étendue du fait de composants applicatifs évoluant eux-aussi plus rapidement et susceptibles d’être distribués sur plusieurs environnements, y compris des microservices tiers ».
Un plaidoyer pour le pare-feu applicatif…
Pour Arnaud Lemaire, « le WAF est aujourd’hui impératif pour qui veut protéger efficacement une application Web ». Mais dans le contexte DevOps, il prend une toute nouvelle dimension, explique Nitzan Miron : « Un WAF protège contre les attaques applicatives, de sorte que les équipes logicielles peuvent déployer en toute confiance un nouveau code à leurs clients sans se soucier de l’exploitation de potentielles vulnérabilités.
En outre, la plupart des WAF incluent des analyseurs de vulnérabilités, qui peuvent analyser de manière proactive les applications lorsque de nouveaux codes sont déployés et alerter si de nouvelles vulnérabilités sont découvertes, aidant les équipes à corriger rapidement leur code ».
Steve Mulhearn, directeur technologies améliorées chez Fortinet, précise : « souvent, lors du déploiement initial des applications, un WAF peut être mis en place pour comprendre l'activité et éventuellement identifier les failles de sécurité de l'application. Cela peut souvent se faire par apprentissage automatique des applications elles-mêmes, mais aussi par la connaissance des méthodes d’intrusion les plus courantes ».
…Mais avec de nouvelles contraintes
Cependant, comme l’explique Arnaud Lemaire, historiquement, « les WAF étaient gérés manuellement par les équipes d'exploitation du réseau et de la sécurité ». Las, « cela demande beaucoup d'énergie et de main-d'œuvre, ce qui n’est absolument pas compatible avec une méthodologie DevOps. L’introduction d'une opération manuelle rompt tous les avantages d'agilité apportés par les concepts d'orchestration d'un modèle DevOps ».
Nitzan Miron va plus loin : « puisque du nouveau code est déployé toutes les heures ou tous les jours, il n’est pas possible de reconfigurer le WAF à chaque changement. Les anciens modèles statiques établis par apprentissage, qui ont besoin d’être ré-entraînés à chaque changement, ne servent plus à rien dans ce monde ».
« Quand un développeur crée une API, il est capable de nous dire exactement quel type d’information il attend en entrée de cette API. »
Edouard ViotChef de produits, Rohde & Schwarz Cybersecurity
Alors pour Arnaud Lemaire, « la clé est ici de choisir une solution WAF qui pourrait être intégrée dans un pipeline DevOps. Cela ne se limite pas à fournir une API qui expose la configuration et les options du WAF. Elle est nécessaire, mais la solution doit intégrer d'autres concepts DevOps tels que l'automatisation des tests, l'apprentissage des politiques et les correctifs fréquents ». « Quand un développeur crée une API, il est capable de nous dire exactement quel type d’information il attend en entrée de cette API », illustre Edouard Viot, chef de produits chez Rohde & Schwarz Cybersecurity. « Et toutes les requêtes qui ne rentrent pas dans ce cadre sont automatiquement bloquées. On parle de modèle de sécurité positive », poursuit-il.
Une granularité plus poussée
Pour David Jack, c’est d’ailleurs une réalité incontournable : « lorsque l’on introduit le WAF dans un environnement DevOps, les besoins évoluent en faveur d’une protection des API ». D’où l’exigence d’une intégration avec les systèmes de développement et d’intégration continus que relève également Nitzan Miron : « le WAF doit être capable de participer à l’automatisation des workflows intrinsèque aux DevOps et s’intégrer facilement avec les outils de déploiement utilisés par les équipes DevOps ».
Mais attention à ne pas négliger la question des performances. Pour David Jack, c’est un point critique : « la distribution des instances de WAF va croître considérablement à mesure que les applications avancent vers une architecture pleinement maillée - l’efficacité CPU et la consommation de mémoire vive sont des critères essentiels ».
Arnaud Lemaire estime ainsi que « l’utilisation d'un WAF dans un pipeline DevOps réduira toutes les contraintes d'exploitation décrites [plus haut] », en simplifiant notamment la création de « politiques de sécurité près du code de l'application ». Ainsi, notamment, « l’intégration d'un analyseur de vulnérabilités Web qui peut être orchestré dans le pipeline permettra d'adapter la politique de sécurité du WAF en corrigeant toutes les vulnérabilités de sécurité connues ».
L’intelligence collective au service de la sécurité
Si à l’heure des DevOps, un WAF se doit d’être adaptable et automatisable, pour Nitzan Miron, il doit également être proactif. « Le WAF ne doit pas seulement détecter et bloquer les attaques, il doit aussi intégrer des fonctionnalités actives pour analyser les applications, faire un rapport sur les menaces et ajuster sa configuration en fonction de ses découvertes » affirme le vice-président de Barracuda Networks, en charge des produits et services de sécurité applicative.
« Le WAF [...] doit aussi intégrer des fonctionnalités actives pour analyser les applications, faire un rapport sur les menaces et ajuster sa configuration en fonction de ses découvertes. »
Nitzan MironVice-président Barracuda Networks
En outre, relève Steve Mulhearn, « la qualité d'une solution de WAF dépend de l'intelligence qu'elle utilise au cœur de son processus de prise de décision. Pour que cela fonctionne efficacement, il faut une compréhension globale du paysage de la menace ». Pour lui, la capacité à ingérer du renseignement sur les menaces de manière industrialisée permet « de réduire le risque pour l’entreprise de manière significative ».
Et cela ne relève pas du fantasme : « L’un des défis liés la réutilisation de composants logiciels est qu'une vulnérabilité peut apparaître dans de nombreux endroits différents avec les mêmes caractéristiques. L'utilisation d'une solution WAF permet non seulement de réduire ce risque, mais peut également être déployée facilement pour protéger plusieurs plates-formes et applications des vulnérabilités communes. »
Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)
