
Dans le petit monde des Firewalls Applicatifs Web, le filtrage des requêtes malicieuses est réalisé grâce aux techniques suivantes :
Globalement on peut dire qu’un WAF est efficace pour lutter contre les attaques du TOP10 de l’OWASP : les attaques par injection, le cross-site scripting et autres défauts de configuration… Cependant ça ne reste qu’un outil ; il faut savoir s’en servir et prendre le temps de le gérer au quotidien.
En regardant de plus près les technologies derrière les WAF actuels, même ceux auto-proclamés « Next-gen », on s’aperçoit :
Parfois on nous explique même que, pour détecter des anomalies et tirer pleinement profit du WAF, il faut… acheter un SIEM J Bref, aucune critique derrière ces lignes, juste un constat : la plupart des WAF actuels n’ont guère changé depuis des années et utilisent toujours les mêmes techniques de filtrage et de fonctionnement.
Dans le meilleur des mondes possibles, on teste les applications Web avant de les mettre en production :
Sans oublier le sacro-saint test d’intrusion la veille de la mise en production ! Malheureusement en ce bas-monde, on n’a rarement les compétences, jamais le temps de rien, ni même l’envie de faire des tests de sécurité. Tout juste arrivons-nous à constituer un panel d’utilisateurs pour valider fonctionnellement l’application et donner un GO avant la mise en production.
Alors rêvons un peu : si le WAF pouvait analyser le trafic durant cette phase de recette fonctionnelle, il verrait donc l’intégralité des requêtes susceptibles de parvenir à l’application. Ces requêtes ne sont pas des attaques, elles sont a priori légitimes et représentatives d’une activité normale sur l’application. Intéressant… et c’est généralement ce que l’on fait pour constituer une liste blanche (liste exhaustive des requêtes valides sur une application).
Les listes blanches soulèvent toutefois plusieurs problèmes :
Ça ne fait pas vraiment rêver… et toujours pas « nouvelle génération ». Pour nous, le WAF de demain doit :
Le tout sans écrire une ligne de code ni une seule règle barbare…Impossible ?
Les vulnérabilités des systèmes d’informations sont si nombreuses et variées que nombre d’entreprises et d’organisations ont mis en place, ou font appel aux services des CERT afin de recenser les nouvelles failles découvertes.
Les failles 0-day sont légion et peuvent provoquer des incidents de sécurité aux impacts forts pour les entreprises. On sait aujourd’hui écrire des règles plus ou moins complexes pour détecter ces attaques, de manière plus ou moins efficace (multiples variantes d’une menace, offuscation, chiffrement, techniques d’évasions…).
Ecrire une règle de détection et de blocage c’est comme prendre un train en marche : parfois on y arrive et on a de la chance, parfois on court derrière, on se fatigue ou on se fait mal.
C’est ici qu’entre en jeu le Machine Learning : le principe est de faire en sorte que la machine apprenne d’elle-même et de son environnement. Une machine qui connaît son environnement saura tout naturellement détecter une anomalie. Imaginez un mouton dans la savane ou une mobylette à contresens sur l’autoroute… Vous saisissez le concept ?
La première chose à faire est de réussir à modéliser l’environnement dans lequel on évolue.
Pour cela il faut choisir un modèle mathématique adapté.
Ce modèle permettra de générer une fonction qui, sur la base des évènements survenus, permettra de prédire les événements attendus (on l’appelle « fonction de prédiction »).
Concrètement, lorsqu’un événement survient (ex : une requête sur une application Web), il faut :
La fonction de prédiction indiquera alors si cet évènement est « habituel » ou « inhabituel ». S’il est inhabituel, c’est une anomalie, il faut investiguer.
La problématique principale dans l'élaboration d'un système de détection d'anomalies est celle des faux-positifs. La machine doit donc connaître suffisamment son environnement pour ne pas détecter comme anormaux des évènements légitimes. Les anomalies doivent donc être analysées par des experts, car un nombre élevé de faux-positifs détournera les utilisateurs de l’outil de par son imprécision.
On distingue deux grandes familles d’algorithmes de Machine Learning.L’algorithme d’apprentissage supervisé nécessite une action en amont de l’utilisateur afin de « tagguer » chaque événement et de le classer dans une catégorie. On dit que les événements sont « labellisés ».
L’algorithme d’apprentissage non-supervisé apprend lui-même en se basant sur un set d’entraînement et en regroupant les événements dans des zones appelées cluster. Les événements sont dits « non-labellisés ».
En se basant sur les travaux récents du MIT sur le sujet (intelligence artificielle AI2), nous avons décidé de transposer cette stratégie pour tenter de tirer parti des deux types d’algorithmes de Machine Learning (supervisés & non-supervisés). L’idée est la suivante : on se base sur un fonctionnement classique d’apprentissage non-supervisé où la machine créée son propre modèle.
Après cette étape, on fait intervenir un analyste expert afin d’aider la machine à prendre des décisions sur les événements les plus incertains. Cette « rétroaction de l’utilisateur » induit alors le principe de l’apprentissage supervisé mais pour un nombre restreint de données, évitant d’y investir trop de temps.
Une fois ces données labellisées, on les réintègre au modèle qui devient plus précis que lors de l’itération précédente. Au cours du temps, le modèle fait de moins en moins appel à l’analyste puisque la précision s’accroît linéairement.
Ce principe d’analyse est au cœur de notre SOC nouvelle génération : « mySOC », mais c’est une histoire dont nous reparlerons plus tard.
Pour l’heure nous avons essayé de transposer ces concepts dans le WAF Open Source Vulture, en implémentant des algorithmes de machine learning basé sur les « Machines à Vecteur de Support » à base de noyau gaussien (SVM-RBF).
Le principe de configuration est le suivant :
Ensuite, en temps réel, chaque requête reçue par Vulture est traitée par les fonctions de prédiction. L’administrateur pourra alors valider ou invalider ces anomalies, sans qu’il y ait le moindre blocage pour les utilisateurs. Une fois le modèle suffisamment éprouvé, l'algorithme peut passer en mode « blocage » : dès qu'une requête est détectée comme anormale, elle sera bloquée par Vulture, via un module développé en C pour être très performant.
L’intérêt de cette technique est qu’il n’est pas utile de tester 100% de l’application. Il suffit d’avoir un échantillon représentatif de logs (à partir de quelques milliers de lignes) pour avoir des modèles efficaces, avec un taux de faux positif proche de zéro.
Vulture est un WAF Open Source qui propose des mécanismes de filtrage et de protection des applications Web basés sur :
Depuis 2015, Vulture intègre des algorithmes avancés de machine learning permettant de détecter des anomalies comportementales en temps réel. La version 2016 intègrera le premier moteur de filtrage Web basé sur des mathématiques pures : aucune règle ne sera nécessaire pour protéger les applications Web.
Restez à l’écoute et suivez-nous sur https://www.vultureproject.org.