Vulture 3 - Machine Learning

Le WAF d’aujourd’hui…

Dans le petit monde des Firewalls Applicatifs Web, le filtrage des requêtes malicieuses est réalisé grâce aux techniques suivantes :

• Réputation des adresses IP source
• Filtrage par recherche de mots clés (modèle de sécurité négative)
• Acceptation du trafic reconnu comme légitime (modèle de sécurité positive)
• Techniques de scoring permettant aux règles de détection de travailler en collaboration afin de minimiser les faux positifs
• Intégration de scanner de vulnérabilités : création automatique de règles basées sur les vulnérabilités remontées par le scanner (Virtual Patching)

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 :

• Qu’ils utilisent toujours des règles
• Qu’ils confondent détection d’anomalie et réputation de l’IP source
• Qu’ils ne gèrent pas toujours les derniers protocoles (HTTP/2)
• Qu’ils utilisent encore SQL pour stocker les logs (et recommandent parfois de désactiver les logs pour améliorer les performances…)
• Qu’ils ne sont pas vraiment scalables en terme de performance 

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.

Le WAF de demain

Dans le meilleur des mondes possibles, on teste les applications Web avant de les mettre en production :

• Tests unitaires, tests de non régression, tests fonctionnels, audit de code, scan de vulnérabilités…

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 :

• Il faut tester toute l’application pour identifier toutes les URIs et tous les paramètres utilisés
• Il faut générer des règles « justes » : pas trop permissives et pas trop contraignantes
• Une règle oubliée => Utilisateurs bloqués

Ça ne fait pas vraiment rêver… et toujours pas « nouvelle génération ». Pour nous, le WAF de demain doit :

• Etre capable de gérer une quantité astronomique de logs en temps réel (stockage No-SQL)
• Disposer d’une interface de recherche puissante et rapide pour constituer des échantillons de trafic légitime
• Disposer d’algorithmes pour comparer en temps réel les requêtes reçues avec ces échantillons représentatifs

Le tout sans écrire une ligne de code ni une seule règle barbare…Impossible ?

Allez, on essaye…

Machine Learning pour les nuls

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 ?

Principes du Machine Learning ou « comment détecter le vilain mouton » ?

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 :

• Capturer les éléments caractéristiques de cet évènement
• Appeler la fonction de prédiction avec ces éléments

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.

Apprentissage supervisé vs non-supervisé

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 ».

Notre idée

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 :

• Vulture capture les logs et permet de les fouiller rapidement grâce à son moteur MongoDB
• L’administrateur crée un échantillon qu’il juge sain (période de recette par exemple)
• L’administrateur choisi les algorithmes parmi ceux proposés par Vulture
• Vulture calcule les fonctions de prédictions

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.

A propos de Vulture

Vulture est un WAF Open Source qui propose des mécanismes de filtrage et de protection des applications Web basés sur :

• Un OS sécurisé basé sur FreeBSD
• Un firewall réseau haute-performance
• La réputation des connexions source
• Le filtrage Web par liste noire ou blanche
• Le scoring collaboratif entre les règles
• Le virtual Patching multi-scanner (Acunetix, Qualys WAS, Zed Attack Proxy)

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.