Firewalls applicatifs : quelques conseils pour bien les utiliser par Jérémie Jourdin, Advens

[box style=’note’]

Les firewalls applicatifs sont souvent présentés comme la solution ultime pour protéger les applications Web des menaces qui pèsent sur elles : Déni de service, vol de données, intrusion… S’il est vrai que les WAF contribuent à améliorer le niveau de sécurité et de maitrise d’un parc d’applications Web, ce n’est pas pour autant une solution miracle. Dans ce billet nous revenons sur quelques mythes et réalités à propos des WAF et proposons des règles pragmatiques pour réussir leur intégration et bien les utiliser au quotidien. Que vous soyez déjà équipés ou que vous envisagiez de le faire, cet article vous éclairera sur les bonnes questions à se poser pour réussir l’intégration de ce composant dans le Système d’Information. Car le WAF est un composant à part, à la croisée des chemins du réseau et des applications. Au-delà de son intégration dans le réseau il est fondamental de se doter d’une organisation et de processus de gestion permettant de le faire vivre au quotidien. Car non, n’en déplaisent aux éditeurs, un firewall applicatif ça ne fonctionne pas tout seul… ça se saurait !

[/box]

Le sujet de la sécurité des applications Web est toujours d’actualité. Rien d’étonnant, lorsqu’on sait que la proportion des applications vulnérables reste constante année après année. Dans ce contexte, les vendeurs se bousculent pour proposer produits et services tous plus innovants les uns que les autres. Firewalls Applicatifs nouvelle génération et sites d’évaluation de la sécurité en ligne pullulent : on peut désormais s’offrir un scan de vulnérabilités en ligne en moins de 2 minutes avec une carte bleue et protéger ses applications avec un WAF en moins de 15 minutes… on n’arrête pas le progrès !

L’objectif de ce billet n’est pas de revenir sur les détails techniques des firewalls applicatifs, mais plutôt de faire le point sur leur usage en général et sur les bonnes questions à se poser pour en tirer un maximum de bénéfices.

Plantons maintenant le décor et voyons ce que propose le marché. On aura vite fait le tour… car les éditeurs proposent tous à peu près la même chose et mettent en avant les 5 bénéfices suivants :

– La Prévention

• « Identification automatique » des applications
• Evaluation des risques (certains intègrent des scanners de vulnérabilités)

– La Protection

• – Filtrage HTTP, XML, AJAX…
• – Modèles de sécurité négatifs ou positifs (ou « Human Assisted Learning » ça fait plus cool)
• – Génération automatique des politiques de filtrage
• – Analyse comportementale (d’ici quelques années on pourra attraper le vilain avant qu’il ne lance un scanner de vulnérabilité)
• – Préservation des applications Web des attaques DOS (le WAF sera le fusible, l’application survivra)

– L’analyse post-intrusion

• – Journalisation avancée des flux à destination des applications
• – Possibilité de rejouer des attaques pour valider le comportement de l’application / du WAF

– La Facilité de déploiement

• – En 15 minutes l’application est protégée (avec un certain nombre de paramètres standards bloquant les attaques connues) et le RSSI dispose d’un reporting « clé en main »

– La conformité au standard PCI-DSS

• – Seul PCI-DSS exigerait de se doter d’un WAF ? (il ne l’exige pas. Il faut avoir un WAF si on ne teste pas les applications et que l’on ne fait pas de revue de code ; ce n’est pas ENCORE obligatoire. Cela le sera peut être en PCI-DSS 3.0…A voir…)

Les personnes ayant évalué un peu sérieusement ces technologies (ie : ayant été plus loin que l’analyse des plaquettes PDF et étant sorties des labos pour les tester dans le monde réel), pourront faire les constats suivants :

• – Oui, ça bloque des attaques et ça peut nettement améliorer le niveau de sécurité des applications Web
• – Non, ce n’est pas parfait et on peut les contourner – mais cela suppose de bien connaitre les applications derrière et il est possible d’agir sur la couche applicative
• – Ca reste globalement compliqué et long à mettre en place :
  • -Ca se déploie effectivement en 15 minutes avec une protection « de base »
  • – Ca protège efficacement au bout de plusieurs jours voir plusieurs mois
  • – Il est nécessaire de revoir à chaque modification applicative la configuration pour ne pas bloquer de trafic légitime. (comprendre par là que seul le modèle dit de ‘liste blanche’ est la bonne solution)
• – Ca demande un effort constant (et oui, les menaces évoluent…) pour les maintenir à niveau dans le temps

Il n’est donc pas si évident de démontrer l’efficacité (le ROI) de ces solutions. D’ailleurs, le marché semble partager ce point de vue, s’il l’on en juge par le taux d’équipement en WAF qui reste faible (c’est ce que nous constatons chez nos clients) et le niveau de sécurité des applications Web qui reste globalement inchangé depuis plusieurs années (cf. Le Top10 OWASP).

Il faut donc des arguments pour convaincre !

Si les arguments techniques sont pour la plupart recevables, les arguments suivants ne le sont pas :

N’importe quel administrateur lambda peut administrer la solution et décider si un faux-positif nécessite une gestion d’exception ou pas.

• – Il n’est pas nécessaire de comprendre comment fonctionne l’application pour la protéger efficacement.
• – Leur solution est particulièrement efficace dans le Data Loss Prevention (DLP) car ils filtrent les flux sortants
• – …

Comment espérer qu’un administrateur puisse protéger « sans effort » des applications Web développées par des stagiaires, eux-mêmes pilotés par des chefs de projets qui voient la sécurité comme une verrue dans les plannings ? A plus forte raison si l’administrateur (c’est souvent le cas !) vient du monde « système & réseau », bien loin des applications, des frontaux Web, des serveurs d’applications, des bases de données, des annuaires, … car une application c’est tout ça à la fois : elles sont massivement interconnectées et constituées d’un empilage de technologies diverses, qui rendent l’application d’une politique de sécurité consistante très compliquée. Le tout étant exacerbé par des cycles de développement de plus en plus courts et des mises à jour au fil de l’eau (les processus « Agile » se généralisent indéniablement).

Pour protéger correctement une application

Il faut commencer par la développer correctement – mais ce n’est pas le sujet de ce papier. Partons du principe que l’application existe, avec ses forces et ses faiblesses : C’est là que le firewall applicatif entre en jeu.

Pour protéger l’application, il faut paramétrer le WAF avec une politique de filtrage adaptée (en liste blanche idéalement). Et pour définir cette politique, il faut :

• – Identifier tous les points d’entrées de l’application
• – Comprendre le fonctionnement de l’application (si vous avez déjà paramétré un WAF devant une application SAP vous comprenez ce que je veux dire…)
• – Identifier les failles de sécurité de l’application, pour créer des règles additionnelles si nécessaire
• – Tester cette politique dans le cadre d’une phase de recette fonctionnelle de l’application. C’est-à-dire vérifier avec le métier que l’application fonctionne correctement, que rien n’est bloqué et qu’aucun impact de performance n’est constaté
• – Tester l’efficacité de la solution face à des attaques automatisées et manuelles
• – …

Alors oui, les WAF savent plus ou moins bien automatiser certaines tâches – et c’est tant mieux – mais ça ne se fait pas tout seul : collecter ces informations techniques et les analyser demande de l’expertise humaine, des processus et du temps. Une organisation peut donc avoir les meilleures technologies, si elle n’a pas de processus de pilotage de la sécurité ou les compétences techniques nécessaires, ça ne fonctionnera pas.

Par « compétences techniques », on entend « une expertise dans le domaine de la sécurité des applications » :

• – Capacité à détecter des failles de manière proactive
• – Capacité à proposer des plans d’action réalistes et pragmatiques (demander d’appliquer un patch ou de recoder l’application ce n’est pas pragmatique et souvent irréaliste)
• – Capacité à proposer immédiatement des solutions techniques en réponse à un incident ou en mitigation d’une faille de sécurité ne pouvant être immédiatement corrigée dans le code
• – Capacité à piloter l’amélioration continue
• – Capacité à délivrer un reporting pour rendre compte de l’évolution du niveau de sécurité au management ou aux auditeurs externes
• – …

Pour en revenir à nos moutons, si vous souhaitez protéger vos services en lignes et êtes convaincus de l’intérêt d’un firewall Applicatif : voici les bonnes questions que vous devez vous poser :

• – Maitrisez-vous votre parc applicatif ?
• – Connaissez-vous votre niveau de sécurité applicatif ?
• – Avez-vous les compétences techniques pour gérer un WAF dans le temps ?
• – Avez-vous l’organisation pour gérer un WAF dans le temps ? (cf le papier => https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls), le schéma est assez intéressant….

Si la réponse à l’une de ces 3 questions est « non », il est urgent de ne pas vous précipiter. Cela ne veut pas dire qu’il ne faut rien faire, mais tout simplement que vous n’avez pas la maturité, les compétences ou l’organisation pour déployer et gérer ces technologies dans le temps.

Que faire alors ? Plusieurs options :

1. Vous n’êtes pas encore équipés :

• Faites-vous accompagner pour un état des lieux de votre sécurité applicative
• Faites-vous accompagner dans le choix de la technologie ou du service de protection
• Faites-vous accompagner dans la définition des politiques de filtrage et dans la définition du processus de maintient en conditions opérationnelles

2. Vous êtes déjà équipés et souhaitez optimiser l’efficacité (la rentabilité) de vos WAF

• Confiez la gestion du WAF à un spécialiste et exigez un contrat de service
• Ce contrat de service doit couvrir, à minima :
  • L’ajout de nouvelles applications
  • Le maintient à jour des politiques de filtrage
  • La supervision des équipements
  • L’analyse des logs
  • Les contrôles de sécurité « proactifs » sur les applications

Pour le point 2, en fonction de votre architecture, les composants WAF pourront être externalisés en dehors du Système d’Information (attention à ne pas payer deux fois les débits réseaux – vérifiez les capacités de votre fournisseur WAF à vous proposer des solutions réseaux adaptées).

Qui dit « externalisation » ne signifie pas absence de contrôle, bien au contraire !

Exigez de vos fournisseurs un reporting complet présentant des indicateurs vous permettant de valider le respect des exigences contractuelles :

• – Informations techniques sur les WAF
• – Historique des changements de configuration
• – Synthèse des contrôles de sécurité réalisés
• – Synthèse des attaques subies / bloquées
• – Synthèse des incidents de sécurité et des contre-mesures déployées
• – …

Encore une fois, manager un WAF ne s’improvise pas, il faut savoir orchestrer des compétences et des processus autour de technologies en constante évolution.

[box style=’note’] Et si vous voulez aller plus loin sur ce sujet ou plus globalement sur la protection des applications, rejoignez l’Application Security Academy que nous venons de créer sur www.advens.fr/ApplicationSecurityAcademy. [/box]