Le WAF est mort (et nous savons qui l'a tué)

Au cours des deux dernières décennies, le pare-feu applicatif Web (WAF) est devenu une pièce essentielle du kit de sécurité. Toutes les organisations disposant d'une application web (donc la plupart des grandes entreprises) ont installé un WAF pour protéger leurs données et leurs actifs contre toute faille. Les meilleures pratiques en matière de sécurisation des applications web ont évolué et consistent désormais à déployer un WAF en amont des applications.

Mais la vérité, c'est qu'aujourd'hui avec le cycle de vie des applications modernes qui permet aux DevOps de publier des mises à jour à une fréquence beaucoup plus élevée, le WAF traditionnel n'est plus en mesure de suivre, et la maintenance d'un WAF est devenue à la fois laborieuse et complexe.

Face à ce défi, que doivent faire les professionnels de la sécurité ? Qu'est-ce qui empêchera les applications web de devenir la porte d'entrée d'une organisation ? Sachant que les DevOps vont continuer à produire du nouveau code, comment savoir si leur WAF vaut la peine d'être maintenu et s'il est toujours viable ?

Examinons de plus près ce qu'il faudrait pour que le WAF puisse suivre le rythme des DevOps.

Le contexte est primordial

Alors que la sécurité des réseaux consistait à surveiller des réseaux statiques utilisant les mêmes protocoles, les WAF ont été conçus pour protéger les applications web qui sont nettement différentes les unes des autres. Chaque application est unique et chaque morceau de code est différent et nuancé, avec son propre ensemble de vulnérabilités. Même avant l'introduction du stockage en Cloud et la vitesse vertigineuse du DevOp, les WAF étaient reconnus comme n'étant qu'une solution de sécurité « médiocre ».

Utiliser une solution qui se trouve devant l'application, plutôt qu'en ligne signifie forcement que l'analyse contextuelle est impossible. Sans contexte pour comprendre le contenu de l'application avec laquelle on interagit, il est impossible d'automatiser l'évolution du WAF parallèlement à celle de l'application.

Formation, formation, formation.

Les améliorations de l'apprentissage automatique n'ont résolu cette énigme que dans une certaine mesure. Les WAF les plus sophistiqués n'ont besoin « que » d'un mois pour s'installer silencieusement et apprendre à créer une configuration de base pour l'application. Problème : Laisser une application sans protection pendant un mois, c'est très long !

Une intervention humaine est inévitable pour aider à calibrer le WAF, et c'est à ce moment-là que la maintenance devient lourde. Si le WAF a besoin de temps pour apprendre et créer une ligne de base à chaque fois que le contenu ou le code change, l'administrateur a beaucoup de travail à faire pour réduire les alertes et créer des exceptions.

Automatiser ou désintégrer

Avec la livraison en continue, il est tout simplement impossible pour un WAF de protéger une application web contre les attaques logiques sans intervention humaine. En réalité, la plupart des WAF ne sont qu'en mode alerte. Il est trop dangereux de les laisser tout bloquer, car les volumes élevés d'alertes créeront une lassitude à leur égard.

Un administrateur peut peut-être procéder à quelques ajustements mineurs pour que les parties sensibles de l'application soient couvertes par des règles de blocage, mais le reste de l'application sera protégé par le WAF en mode alerte avec la correspondance de motifs et d'autres techniques grossières. La solution de sécurité ne peut donc pas se déployer automatiquement et se protéger des nouvelles attaques logiques au fur et à mesure que l'application évolue.

Aller vite ou rentrer chez soi !

Tout est une question d'agilité quand il s'agit du cloud computing. Ce qui prenait deux semaines à créer en 2015 ne prend plus que quelques secondes. En exploitant les nouveaux micro-services, il est possible de modifier radicalement une application en quelques minutes. Dans ce nouvel environnement, il est absurde d'envisager d'utiliser une solution standard de sécurité des applications pré-cloud qui se base sur l'apprentissage ou les configurations manuelles.

A chaque fois qu'un développeur modifie un code et l'envoie dans la nature, il prend une décision unilatérale sans consulter les équipes de sécurité. Utiliser un WAF qui repose sur l'hypothèse que TOUT ce qui se trouve dans son environnement est générique, ça n'est clairement plus possible aujourd'hui.

En d'autres termes, le WAF est mort, et DevOps l'a tué. Il est dès lors grand temps de procéder à une analyse médico-légale et de déterminer si son WAF a encore un pouls ou s'il est définitivement inutile. Et pour cela, voici bonnes questions à se poser :

Est-ce que son WAF est conçu pour le cloud ?
Est-il capable de déterminer si le trafic est légitime ou malveillant ?
Peut-il déchiffrer les bots et autres vecteurs d'attaque OWASP des demandes légitimes ?

Si la réponse à ces questions est non, cela signifie qu'il est temps pour d'évaluer/réévaluer la sécurité de ses applications dans le Cloud.

TJ Gonen, Responsable des produits sécurité du Cloud - Check Point Technologies.