Dans la chronique précédente de cette série sur la cybersécurité et le Big Data, nous avons expliqué que la cybersécurité fournit une vision du niveau d’exposition d’une entreprise à une attaque, en s’appuyant sur les données internes du Système d’Information de l’entreprise.
Dans la même chronique, nous vous avons également expliqué que le but d’une solution de Security Analytics est d’identifier et remonter les anomalies sur les logs de données internes et pouvoir corréler ces anomalies avec des sources de données externes pour ressortir les scénarios d’attaque possible et évaluer la risque de survenance de ces scénarios. Il faut comprendre pourquoi on en arrive là. Pourquoi en arrive-t’on à vouloir créer une solution basée sur l’exploitation de données alors qu’on a déjà une panoplie de solutions qui existent ? (SIEM, pare-feu, anti-virus, etc.). C’est ce que nous allons tenter de vous faire comprendre ici. Plus précisément, nous allons vous montrer l’intérêt et l’approche de cybersécurité adoptée par les SIEM (Security Information and Event Management).
Sommaire
Définition d’un SIEM
Le SIEM (Security Information and Event Management) est malheureusement souvent réduit à l’outil technique qui va permettre de gérer les logs générés par les différents équipements / applicatifs (de sécurité ou non) qui composent un système d’information. L’objectif d’un SIEM est de permettre aux équipes sécurité de détecter des attaques grâce à l’exploitation, le filtrage et à la corrélation de ces (millions) de logs provenant de multiples sources d’information (interne ou externe à l’organisation).
Le SIEM est avant tout un système de supervision centralisé de la sécurité. Il se compose de deux solutions qui se complètent : le SIM – Security Incident Management, qui sera focalisé sur l’analyse à-postériori, l’archivage, la conformité et le Reporting et le SEM – Security Event Management qui cherche à collecter et traiter des données en quasi temps réel. Il semble plus pertinent de parler de démarche SIEM car l’outil n’est qu’une brique de ce système de gestion des évènements de sécurité. Cette démarche doit en effet également prendre en compte les aspects organisationnels, humains et juridiques qui se posent inévitablement lors d’un projet SIEM. Ci-après un tableau très ancien de l’ensemble des solutions SIEM du marché.
Sinon, voici quelques solutions de SIEM bien connus :
- IBM QRadar
- Splunk Enterprise Security
- McAfee Enterprise Security Manager
- RSA NetWitness
Fonctionnement d’un SIEM
Le fonctionnement d’un SIEM s’articule autour de 5 fonctions :
- La collecte des évènements : passive ou active avec la mise en place d’agents directement sur les différents équipements ou à distance.
- La normalisation des évènements : conservation des logs bruts pour valeur juridique puis enregistrement de ces logs dans un format interprétable.
- Le stockage et l’archivage des évènements en fonction de leur nature.
- La corrélation des informations recueillies : mise en place de règles de corrélation permettant d’alerter sur un incident en cours et permettant d’identifier les causes d’un événement a posteriori.
- Le Reporting : génération de tableaux de bord et de rapports pour avoir une visibilité sur la sécurité et la conformité du SIEM.
Quels sont les apports d’une démarche SIEM ?
Faites attention à ne pas réduire le SIEM à une énième solution technique de sécurité ! Le SIEM doit s’envisager comme une démarche globale d’entreprise. Le SIEM va viser à faire atteindre à l’organisation plusieurs objectifs :
- Détecter des attaques (simples et complexes) en maintenant une surveillance continue du SI de l’organisation (tentative d’exfiltration de données, communication avec un serveur, etc.).
- Contrôler la conformité à des contraintes réglementaires et la politique de sécurité en détectant des anomalies ou des non-conformités.
- Répondre aux incidents et permettre des analyses de type forensics (investigation numérique) exploitant au maximum les traces (logs) récoltées.
- Améliorer son système d’archivage (configuration de la durée de rétention par équipement, garantie de l’intégrité des logs,…).
- Détecter les comportements anormaux d’utilisateurs, des serveurs, des applicatifs et du réseau.
- Élaborer des tableaux de bord de sécurité opérationnelle à destination des responsables techniques mais aussi de la direction. Cette phase nécessite la définition, en amont, d’indicateurs pertinents et réalistes à suivre.
- Les réglementations auxquelles doivent se conformer les organisations sont de plus en plus contraignantes (PCI, SOX, Informatique & Liberté, HIPAA, CRBF, etc.) et nécessitent un contrôle fin de la sécurité du système d’information. Dans ce cadre, l’organisation devra justifier son respect de la réglementation. Une démarche SIEM permettra alors d’assurer un contrôle continu de la sécurité de ses SI et de produire ainsi des indicateurs par rapport à son niveau de sécurité et de conformité.
Les limites des approches SIEM
Bien que les solutions des approches SIEM aident avoir une visibilité globale du niveau d’exposition du système d’information de l’entreprise, elles restent très limitées cependant pour assurer la sécurité d’un SI. Nous allons aborder ici les ponts de faiblesses des solutions et de l’approche SIEM.
– Les règles de corrélations
Le SIEM s’appuie sur des règles de corrélation pour détecter des éventuelles attaques. De ce fait, il n’est pas capable d’anticiper un évènement malicieux, sa capacité à détecter dépend étroitement des règles qui sont construites par les administrateurs et ne peux donc pas détecter tout événement nouveau inconnu de l’administrateur. Les menaces sont nouvelles, les attaques sont nouvelles, il est urgent d’être capable au moins de fournir un score de sécurité à tout évènement qui s’est produit dans un SI pour savoir si l’événement est potentiellement porteuse d’une future attaque ou pas.
– La standardisation des logs
Les SIEM s’appuient sur les journaux de différents équipements de sécurité pour détecter des événements malicieux. Cependant, La journalisation n’étant pas encore commune et mature pour certains équipements de sécurité, les SIEM (en dehors des formats SYSLOG) ne sont pas capables d’exploiter en l’état les journaux d’évènements pour ceux-ci, rendant ainsi impossible la surveillance du périmètre couvert par l’équipement en question. Des modifications sont donc à prévoir dès la source de la génération du log pour l’exploiter.
– La volumétrie des logs
Les équipements de sécurité génèrent de très gros volume de données (puisqu’ils enregistrent tous les évènements qui sont effectués dans un système d’information). Les solutions de SIEM ont de plus en plus de mal à gérer et à exploiter la volumétrie des données de logs. De plus, des raisons légales ou de compliance (SOX, ISO 17799/27001/BS7799, PCI, GLBA, HIPPA, FISMA) exigent d’archiver toutes les données du SI pour pouvoir effectuer des audits. Il convient alors de trouver de nouvelles approches qui permettent d’archiver convenablement ces logs pour répondre aux exigences de ces normes.
– La Corrélation
Les attaques qui sont perpétrées malgré la présence des dispositifs de SIEM remettent en question la pertinence des règles de corrélation utilisées par les SIEM. L’expérience montre que la mise en place de celles-ci fait l’objet de limitations techniques, dont la principale est la lenteur dans la détection des événements malicieux dû à la désynchronisation des logs elle-même provoquée par la latence réseaux. Il est donc nécessaire de penser à une autre approche analytique.
– Le nombre de faux-positifs des alertes
Comme vu plus haut, le SIEM s’appuie sur des règles de corrélation. Ces corrélations sont effectuées sur de nombreuses sources de logs. De nombreux faux-positifs sont alors générés. Les équipes de traitement deviennent vite débordées par des alertes qui n’ont pas lieu d’être. Le risque est simple : qu’un réel incident ne soit pas traité dans cet amas de fausses alertes. Il devient dès lors urgent de développer des approches analytiques qui réduisent au moins le taux de faux-positifs.
Nouvelle approche en matière d’Analytics
Comme nous l’avons mentionné plus haut, les approches de Data Science traditionnelles en matière de cybersécurité comme les SIEM sont orientées « Règle de corrélation ». Malheureusement cette approche génère beaucoup trop de faux positifs, restent très difficiles à implémenter dans le SIEM et l’évolution des règles se fait uniquement à la discrétion des administrateurs.
Nous proposons un mixte de deux approches : Une approche Data Science basée sur le Risque (Risk-based approach) et une approche basée sur la détection d’anomalies (Anomaly-based approach).
L’approche Data Science basée sur les Risques d’intrusion
L’approche Analytics basée sur le risque que nous recommandons est une approche qui consiste à croiser les données des points d’accès au SI à l’aide de modèles statistiques pour fournir pour chaque point d’accès, un score qui indique son niveau de vulnérabilité, et donc par ricochet une mesure du risque d’attaque provenant de ce point d’entrée.
L’avantage de cette approche devant le SIEM est sa capacité en amont à fournir une mesure globale de la vulnérabilité du Système d’Information et en aval d’anticiper l’attaque. Le risque de faux-positif est plus faible ici puisque l’approche est préventive. En plus de son action préventive, cette approche devant l’approche traditionnelle a l’avantage d’être plus souple que des règles de corrélation, car les modèles utilisés « apprennent » automatiquement des données de logs qui sont fournis en entrée. Il n’est donc plus nécessaire de mettre à jour manuellement une base de données des règles de corrélation pour tenir compte de nouveaux scénarios d’attaque. Dans cette approche, des modèles probabilistes tels que des régressions, des réseaux de neurones, des arbres de décisions, des modèles bayésiens, des forêts aléatoires vont être utilisés.
L’approche Data Science basée sur la détection d’anomalies sur le réseau
Cette approche est une approche basée sur de la simulation et de l’intelligence artificielle dans le but de modéliser le fonctionnement normal du réseau informatique sous forme d’états-transitions.
Une fois le comportement normal du réseau connu, tout comportement (états-transitions) non-conforme à celui qui sera implémenté sera considéré comme une anomalie et donc une tentative probable soit d’intrusion, soit d’attaque. L’avantage de cette approche est sa capacité à anticiper en temps réel et de façon quasi-certaine (une fois que le fonctionnement normal du réseau a été bien modélisé) des intrusions/des attaques.
Elle ne souffre pas de faux-positifs et son évolution va dépendre uniquement de l’évolution du réseau informatique considéré. Pour réussir à implémenter cette approche, nous utiliserons des modèles d’intelligence artificielle pour simuler d’une part le fonctionnement du réseau, et d’autre part pour implémenter ce comportement normal dans la plate-forme, plus précisément les réseaux de pétri et les chaîne de Markov.
La combinaison des 2 approches permettra de fournir des niveaux de précision bien supérieurs à toutes les autres approches de Data Science qui sont implémentées à l’heure actuelle.
Nouvelle approche en matière d’infrastructure
Comme nous l’avons vu précédemment, les architectures des solutions SIEM s’appuient sur 3 grands composants : un composant de collection de logs, un composant d’archivage de ces logs et un moteur de gestion des règles de corrélation. Cependant, ces composants deviennent limités avec la grosse volumétrie de données de sécurité, la diversité des points d’entrée au SI et la diversité des composants technologiques qui assurent la sécurité du SI. Les réglementations exigent l’archivage des logs pour les audits de système d’information, il faut donc que la solution soit capable de stocker et conserver dans le temps et sans limitation de durée les données acquis des différents points d’accès au Système d’Information. De plus, les solutions SIEM actuelles sont pour une grande partie incapable de parser (ou lire) les données provenant d’autre formats que le format natif SYSLOG. Cela a pour conséquence de restreindre le périmètre de protection du système d’information. Les solutions SIEM ont été conçues plus pour la centralisation de la gestion des logs de sécurité que pour l’analyse.
Pour toutes ces raisons, il est devenu urgent de changer d’approche en matière d’infrastructure technologique et penser à de nouvelles capables de dépasser les limitations présentées ci-dessus. Plus précisément, Les nouvelles architectures doivent :
- être capable de se connecter à n’importe quelle source de données, c’est-à-dire être capable de lire les données de n’importe quel format et pas seulement le format SYSLOG ;
- être capable de stocker et conserver sans limitation de durée toutes les données acquises ;
- permettre d’effectuer des analyses, des modélisations et des croisements entre les données en temps quasi-réel ;
- permettre de faire du Reporting, de l’analyse visuelle pour la présentation des résultats des analyses.
L’approche que nous recommandons donc est une approche par couche technologique basée sur des composants de l’écosystème Hadoop. Les technologies Big Data répondent aujourd’hui à ces besoins : des connecteurs sont capables de se connecter à n’importe quelle source de données de n’importe quel format, des moteurs de bases de données dits « NoSQL » scalables permettent le stockage et l’indexation d’une volumétrie quasi-illimitée de données, des moteurs de calcul en mémoire et massivement parallèle permettent d’effectuer des analyses statistiques ou non à très grande échelle et des solutions de visualisation à grande échelle existent pour le rendu des résultats et la restitution. Notre approche consiste à utiliser ces composants couche par couche pour répondre aux besoins d’une solution de Security Analytics.
Architecture fonctionnelle d’une solution de cybersécurité au delà du SIEM
L’architecture fonctionnelle constitue le process à mettre en place (ou à encapsuler) dans la solution pour lui permettre de répondre à ses objectifs. Dans le cadre de ce projet, la solution que nous allons développer s’appuie sur un processus fonctionnel constitué de 10 phases successives. Ce process est un process itératif qui est continuellement alimenté par des hypothèses de scénario d’intrusion. La figure suivante illustre ce process.
Phase 1 : « Hypothesis »
La solution globale dépend entièrement de l’hypothèse que l’on fait du point de provenance de l’attaque. Celle-ci est vraiment cruciale, car d’elle dépend les sources de données et les types d’analyses qui pourront être menées sur ces données. Par exemple, une hypothèse est de se dire que les attaques proviennent de l’ouverture des ports sur certaines adresses IP, ports sur lesquels les vulnérabilités de l’application y répondant seraient connues. Un hackeur peut profiter des vulnérabilités d’une application qui répond à un port pour s’introduire dans le système ou lancer une attaque.
L’hypothèse globale sur laquelle repose notre solution est celle-ci : une attaque peut être anticipée lorsqu’on est capable de détecter les tentatives d’intrusion dans le système ou lorsque les scénarios d’intrusion peuvent être anticipés. Cela dit, nous ne cherchons pas à détecter des attaques, mais détecter des scénarios d’intrusion. L’hypothèse d’intrusion par défaut est le passage par l’ouverture des ports sur les adresses IP.
Phase 2 : « First Data Entry Point » (DEP)
Dans cette phase, il est question de définir la première source de données à exploiter conformément à l’hypothèse d’intrusion qui a été faite à la première phase. Cette phase intervient parce que nous nous sommes rendus compte qu’il n’est pas évident de répertorier en amont toutes les sources de données qui peuvent potentiellement être exploitées pour atteindre l’objectif d’anticipation d’attaque. Le domaine de la sécurité étant un domaine relativement complexe, et la Data Science en contexte de sécurité étant nouveau, nous pensons qu’il est plus prudent d’adopter une approche d’intégration de données itérative, chaque itération d’intégration fournissant des pistes quant aux nouvelles sources de données à intégrer. Par exemple, le premier DEP à intégrer serait les logs des serveurs Web ou les logs des scans des adresses IP conformément à l’hypothèse selon laquelle le point d’entrée des attaques serait l’ouverture des ports sur certaines adresses IP.
Phase 3 : « Descriptive Analytics »
Dans cette phase, il faut analyser les données issues de la phase précédente, les analyses à mener ici sont du type descriptif. D’une part, Il s’agit de ressortir des métriques pertinentes pour permettre d’infirmer ou de confirmer l’hypothèse de base, et d’autre part de ressortir des indices quant aux sources de données supplémentaires à intégrer et aux éventuelles corrélations possibles à ressortir entre les données. Cette phase va mettre beaucoup d’accent sur la Data Visualisation et la Visual Analytics.
Phase 4 : « Data Entry Point » (DEP)
Cette phase consiste à récupérer et à intégrer des sources de données supplémentaires pour alimenter et fournir plus de précision dans les analyses. La difficulté ici revient à identifier les données en question. Elle ne dépend pas étroitement de la phase précédente.
Phase 5 : « Data Consolidation »
Cette phase consiste à consolider toutes les sources de données intégrées dans la phase précédente avec les données issues de la première phase. Il s’agit de trouver ou d’établir un lien logique entre les données de la quatrième phase avec celle de la première phase.
Phase 6 et 7 : « Advanced Analytics »
A cette phase, on possède une vaste gamme de données, par conséquent une vision assez claire des scénarios d’attaques contenues dans les données, des tentatives d’intrusion, une analyse assez précise de l’état du réseau. Cette phase va permettre d’aller plus loin en mettant en place les approches analytiques que nous avons décrit plus haut pour fournir un score du niveau de vulnérabilité de chaque point d’entrée au système et pour anticiper des intrusions.
Plus précisément, des modèles statistiques vont être utilisés, des modèles d’intelligence artificielle (chaîne de Markov, réseau de Pétri). La modélisation prédictive étant un process itératif de nature, plusieurs modèles vont être lancés et seul celui qui fournira la meilleure précision sera retenu. Les résultats des analyses vont être présentés de façon visuelle, pour le confort de l’utilisateur final.
Phase 8, 9, 10 : « Security Intelligence »
Les trois dernières phases sont essentiellement des phases consacrées à la « Security Intelligence », c’est-à-dire les phases dans lesquelles des décisions et des actions doivent être prises. En effet, une fois que la solution fournit des indicateurs de niveau de vulnérabilité, identifie des attaques ou des intrusions potentielles, il faut un cadre de gouvernance qui définit ce qu’il faut faire, qui doit le faire et quand l’action doit être faite. Cette intelligence dépend exclusivement de l’Homme et de l’entreprise. De plus, de nouvelles hypothèses concernant les scénarios d’intrusion doivent être définies afin de lancer l’itération suivante de l’analyse.
Nous sommes arrivés au terme de cette deuxième chronique. Ce qu’il faut retenir c’est que l’évolution technologique a fragilisé les systèmes d’information. Leur exposition irréversible et grandissante sur Internet oblige les entreprises à repenser leurs processus de risques technologiques. Pour répondre à ces nouveaux enjeux, il est possible d’utiliser des solutions innovantes pour protéger l’image, maîtriser le degré d’exposition et sécuriser les périmètres critiques des organisations. C’est dans ce cadre qu’une solution de Security Analytics est nécessaire. Pour nous, les approches classiques de cybersécurité (anti-virus, pare-feu, SIEM) ne sont plus suffisantes pour défendre un SI contre des intrusions. Une meilleure approche serait de combiner cette approche classique à l’exploitation intelligente des données réseau de l’entreprise. Dans cette chronique, nous vous avons montré comment bâtir une telle solution d’un point de vue fonctionnel. Dans la troisième chronique de la série, nous vous expliquerons comment bâtir ce type de solution d’un point de vue technologique.
