Alors que la place de l’Intelligence Artificielle grandit dans les entreprises, allant de la maintenance prédictive à l’optimisation tarifaire, de nouveaux outils dits « intelligents » se développent pour la cybersécurité. Comment ces outils exploitent-ils les récents développements du Machine Learning ? Quelles étapes suivre pour développer une solution de détection intelligente et surtout pertinente dans son contexte ?
Des méthodes de détection statiques à de l’analyse comportementale
Les attaques évoluant de plus en plus rapidement et de manière toujours plus élaborée, le SOC (Security Operations Center) est forcé de revoir son approche concernant les outils en place car les mécanismes de détection statiques deviennent trop rapidement obsolètes :
- L’approche historique repose sur la reconnaissance de comportements et d’empreintes connues (ex : signatures de malwares). Cette méthode, appelée misuse-based, remonte des alertes explicites et simples à analyser pour les opérationnels, mais seules les attaques déjà subies et détectées pourront être reconnues.
- La nouvelle approche vise à analyser les actions déviant du comportement normalement observé sans avoir à définir explicitement et exhaustivement un acte malveillant (ex : comportement d’un individu s’éloignant de celui de ses collègues). Cette approche anomaly-based permet de détecter des attaques non renseignées directement dans les outils mais nécessite d’exploiter de plus larges volumes de données.
L’approche anomaly-based exploite les capacités de corrélation des algorithmes d’apprentissage non supervisé mettant en avant des liens dans des données non labellisées (non catégorisées comme normales ou anormales).
Recette de l’été : détection d’anomalies sur lit de Machine Learning
Pour savoir si le Machine Learning convient à son contexte, la meilleure solution reste de réaliser un PoC (Proof of Concept). Comment l’implémenter ? Quels sont les points d’attention ? Voici les étapes clés de notre développement.
Entrée, plat ou dessert : définir le cas d’usage
Faire du Machine Learning, c’est bien. Savoir pourquoi, c’est mieux. Définir un cas d’usage revient à répondre à la question « Que voulez-vous observer ? » et déterminer les moyens disponibles pour y répondre.
Dans notre contexte, un cas d’usage est un scénario de menace portant sur un ou des groupes de comptes (administrateurs malveillants, exfiltration de données sensibles…). Pour les évaluer, plusieurs critères sont à prendre en considération :
- Utilité: quel serait l’impact si le scénario se réalisait ?
- Disponibilité des données: quelles sont les sources de données utiles disponibles ?
- Complexité des données: les données disponibles sont-elles structurées (nombres, tableaux) ou non structurées (images, texte) ?
Nous avons choisi de travailler sur la compromission de comptes de services : certains peuvent avoir des droits importants, et leurs actions automatisées génèrent des données relativement structurées. Dans le cadre d’un PoC, un périmètre restreint et des sources de données homogènes et facilement accessibles sont à privilégier pour obtenir des résultats concrets et exploitables, avant d’envisager des cas d’usages plus ambitieux.
Pesée des ingrédients : déterminer le modèle de données
Afin d’exploiter au mieux les données, il est nécessaire de définir une représentation permettant de modéliser un comportement à partir des informations disponibles. Ici intervient notamment l’expertise métier : une action isolée peut-elle être signe de compromission ou faut-il plutôt prendre en compte une série d’actions pour détecter un comportement malveillant ?
Dans un premier temps, nous avons défini un modèle basé sur l’analyse de logs unitaires et de même famille (ex : connexions, accès aux ressources…) pour évaluer le fonctionnement global. Cependant, un modèle trop simple ignorera des signaux faibles cachés dans des corrélations d’actions, tandis qu’une représentation trop complexe ajoutera du temps de traitement et sera plus sensible aux biais de modélisation.
Sélection des ustensiles : choisir l’algorithme
Plusieurs types d’algorithmes peuvent être employés pour la détection d’anomalies :
- Certains tentent d’isoler chaque point : si un point est facile à isoler, il est éloigné des autres et donc plus anormal.
- Les algorithmes de clustering créent des groupes de points qui se ressemblent et calculent le barycentre de chacun correspondant au comportement moyen : si un point est trop éloigné du barycentre, il est considéré comme anormal.
- Moins fréquents, les auto-encodeurs sont des réseaux de neurones artificiels qui apprennent à recréer le comportement normal avec moins de paramètres : les erreurs de reproduction du comportement pourront être considérées comme un score d’anomalie.
D’autres approches existent encore, jusqu’aux plus exotiques systèmes immunitaires artificiels qui imitent les mécanismes biologiques pour créer un outil de détection évolutif. Il faut cependant ne pas oublier qu’un outil simple et bien optimisé est souvent plus efficace qu’un outil trop complexe.
L’algorithme de clustering des k-moyennes a été sélectionné dans notre cas : utilisé notamment dans la détection de fraude bancaire, il simplifie le réentrainement qui permet à l’outil de rester adapté malgré les évolutions des comportements.
Tous ces algorithmes peuvent également être enrichis, selon le modèle de comportements choisi, pour prendre en compte une suite d’actions. Ainsi, des réseaux de neurones convolutifs ou récurrents peuvent être ajoutés en amont pour prendre en compte des séries temporelles.
Préparation des ingrédients : transformer les données
Une fois que l’algorithme a été sélectionné, il faut traiter les données brutes afin de les rendre exploitables. Ce traitement s’effectue en plusieurs étapes :
- Le nettoyage: correction des erreurs de parsing, suppression des informations inutiles et ajout des informations manquantes
- L’enrichissement: ajout des données venant d’autres sources et retraitement des champs pour mettre en avant une information (ex : indiquer si une date est un jour férié…)
- La transformation: création de colonnes binaires pour les données qualitatives (ex : nom de compte, type d’événement…) ne pouvant pas être directement transformées en nombres (une colonne pour chaque valeur unique, indiquant si la valeur est présente ou non)
- La normalisation : retraitement des valeurs afin qu’elles soient toutes comprises entre 0 et 1 (pour éviter qu’un champ ne prenne l’ascendant sur un autre)
En raison de la variété d’événements possibles et de la complexité des logs, nous avons fait le choix d’automatiser ce processus : pour chaque champ, l’algorithme détecte le type de données et sélectionne la transformation adaptée dans une bibliothèque prédéfinie. L’opérateur peut ensuite interagir avec l’outil pour modifier ce choix avant de continuer le processus.
Assaisonnement : tester et optimiser l’outil
Une fois le modèle défini, l’algorithme choisi et les données transformées, l’outil développé devrait être en capacité de lever des alertes sur des anomalies. Ces alertes ont-elles du sens ou sont-elles des faux positifs ?
Afin d’évaluer la performance de l’outil, nous avons effectué deux types de tests :
- La simulation d’intrusion en effectuant des actions malveillantes pour vérifier si elles sont bien détectées comme anormales (cette approche peut être également traitée en ajoutant directement de « faux » logs dans les sets de données)
- L’analyse des anomalies en vérifiant si les alertes levées correspondent effectivement à des comportements malveillants
De nombreux paramètres peuvent être ajustés dans les algorithmes permettant d’affiner la détection. L’optimisation des performances se fait par itérations, en modifiant les paramètres et en observant l’effet sur un set de données de validation. Chronophage manuellement, elle peut être améliorée par l’approche AutoML qui cherche à automatiser certaines étapes par l’utilisation d’algorithmes d’optimisation.
Cependant, l’optimisation des paramètres ne suffit pas : les résultats de notre PoC nous ont permis de constater que la qualité d’une détection basée sur de l’analyse comportementale repose en grande partie sur la pertinence des comportements définis en amont du développement de l’algorithme.
ML or not ML: that may not be the question
Malgré ses atouts indéniables, le Machine Learning est un outil à utiliser de manière raisonnée : les frameworks deviennent de plus en plus accessibles et simples d’utilisation, mais les étapes cruciales restent la définition du use-case et du modèle de comportement. Ces choix, où l’expertise métier est indispensable, influenceront de manière irréversible le choix des données, la sélection de l’algorithme de détection et les tests à effectuer.
La question n’est donc plus « Où puis-je mettre du Machine Learning dans mon SOC ? », mais « Parmi toutes les approches disponibles, quelle est la plus efficace pour répondre à mon problème ? ».
Pour le savoir, une seule solution : allumez les fourneaux !
Pour aller plus loin…Voici les outils utilisés lors de notre POC :
|
