Dans la chronique précédente de cette série sur le développement d’une solution de cybersécurité à l’aide du Big Data, nous avons parlé intensément des SIEM. Comme vous l’avez vu, 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, les SIEM posent 2 grands problèmes :
- ils sont orientés-règles : cela signifie que la seule façon de détecter des cyberattaques c’est lorsque l’attaque est déjà arrivée. Ce n’est que lorsque l’attaque arrive qu’on essaye de comprendre son schéma et qu’on le modélise dans le SIEM à l’aide de règles de corrélation. Donc, dans un SIEM, on ne peut détecter que des cyberattaques qui ont déjà eu lieu, et selon un schéma pré-défini. Il n’y’a aucune possibilité d’anticipation d’un risque d’intrusion.
- ses fonctionnalités sont limités : à partir du moment où on souhaite diversifier les sources de données d’entrée au SI en dehors des simples logs des serveurs, il devient difficile de le faire avec un SIEM. Ses composants sont vite limités par 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 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. Il y’a également les exigences d’archivage des réglementations pour les audits de système d’information, que la solution doit être 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 fonctionnalités d’analyse de données sont très limitées dans un SIEM.
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, l’architecture d’une solution de cybersécurité en environnement Big Data doit répondre aux exigences suivantes :
- La solution doit ê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 technologique que nous recommandons est une approche par couche technologique basée sur les technologies de l’écosystème Hadoop, la stack ELK (Elasticsearch, Logstash, Kibana) et Apache Spark. Dans cette chronique, nous allons vous montrer l’architecture technologique qui répond aux besoins de cybersécurité à l’heure actuelle.
Architecture fonctionnelle de la solution de cybersécurité
Avant d’aller plus loin dans l’architecture technique de la solution, il est important de rappeler l’architecture fonctionnelle de la solution (quoique nous l’ayons déjà vu en détail dans la chronique précédente sur les SIEM), pour mieux comprendre les technologies choisies (notamment la stack ELK et Apache Spark). La solution 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.
La solution fonctionne en plusieurs phases (10 au total), mais ce qui est important à retenir c’est qu’à un moment, 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. On peut alors aller plus loin en mettant en place les approches analytiques pour fournir un score du niveau de vulnérabilité de chaque point d’entrée au système et pour anticiper des intrusions. Des modèles statistiques pourront ê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. Les briques technologiques sélectionnées dans le cadre de l’architecture doivent donc permettre de collecter les données indépendamment de leur format, de les interroger facilement, et d’y appliquer des modèles de Data Science.
Architecture technique de la solution : stack ELK + Spark
La stack ELK ainsi que Spark répondent parfaitement à ces besoins : Dans la suite ELK, Logstash fournit des connecteurs avec lesquels on est capable de se connecter à n’importe quelle source de données de n’importe quel format ; Elasticsearch permet le stockage et l’indexation d’une volumétrie quasi-illimitée de données (tout ceci en étant scalable) ; Apache Spark, un moteurs de calcul In-Memory massivement parallèle et polyglotte permet d’effectuer des analyses de Data Science et des travaux d’ingénieure de données avancées sur une très grande échelle de données ; et Kibana offre une plateforme de visualisation très diversifiée pour le rendu des résultats et de la restitution des données à large échelle. Notre approche consiste à utiliser ces composants couche par couche pour répondre aux besoins d’une solution de Security Analytics.
La solution est donc construite autour de quatre grands composants technologiques de l’écosystème Hadoop, superposés sous forme de couches applicatives : Logstash, ElasticSearch, Apache Spark et Kibana. Nous allons vous donner un aperçu de ces technologies ici, mais plus tard dans d’autres chroniques, nous étudierons chacune d’elle séparément.
Logstash
Le premier logiciel de la stack ELK est Logstash. Logstash est un logiciel open source spécifiquement conçu pour la gestion des logs. Il permet de se connecter à des logs, les collecter, parser et les stocker à l’aide d’entrées, de filtres et de sorties (Input, filter, output). Ce logiciel est tout à fait indiqué pour la collection des différents logs, car il est capable dans sa version actuelle de se connecter à plus de 37 formats d’entrée de données, possède 39 filtres pour le parsing et pour ajouter de la sémantique aux événements détectés dans les logs et 51 types de sortie pour le stockage. Il dispose d’un langage qui permet de décrire la façon dont on veut transformer les données, les champs à récupérer, et les différentes transformations à opérer dans les données du log. Dans le cadre d’un projet de cybersécurité, il va permettre de venir à bout des limitations des mécanismes de collecte utilisés par les SIEM, en élargissant la gamme de format de logs auxquels on peut accéder. De plus, Logstash possède des plugins pour des formats spécifiques qui peuvent être rajoutés en cas de besoin.
Pour accéder à des logs avec Logstash, il suffit de définir un fichier de configuration en JSON qui spécifie les opérations à mener pour exploiter le log en 3 blocs : un bloc Input (pour décrire la source de données), un bloc filter (pour les transformations et filtres à appliquer) et un bloc output (pour décrire le fichier de sortie).
Voici un exemple de fichier de configuration JSON utilisé par Logstash pour se connecter à un log, le parser et le stocker. Par défaut, Logstash stocke les données du log dans ElasticSearch et embarque son propre moteur ElasticSearch.
Bloc Input : Import d’un log Apache stocké en local, import de données d’hôtes distants
file {
path => "/var/log/apache2/*access.log"
type => "apache-access"
}
lumberjack {
port => 12345
ssl_certificate => ssl.crt
ssl_key => ssl.key
}Bloc filter : parsing des logs sous logstash
filter {
if [type] == "syslog" {
date { match => [ "timestamp", "MMM dd HH:mm:ss" ] }
} else if [type] == "apache-access" {
grok { match => ["message" ,"%{COMBINEDAPACHELOG}"] }
}
if "_grokparsefailure" not in [tags] {
date { match => ["timestamp" ,"dd/MM/yyyy:HH:mm:ss"]}
mutate { remove_field [ "message" ] }
}
if [file] =~ /other_vhosts_access.log$/ {
grok { match => ["message","%{DATA:vhost} %{COMBINEDAPACHELOG}"]}
}
}Nous verrons Logstash plus en profondeur dans une chronique dédiée.
ElasticSearch
ElasticSearch est un Système de Gestion de Base de Données Open-Source scalable et distribué, de recherche et d’indexation de documents (et de texte) s’appuyant sur des approches NoSQL. Il est le deuxième logiciel de la stack ELK.
En réalité, ElasticSearch n’est pas elle-même un SGBD, c’est un moteur de recherche qui utilise Apache LUCENE pour le stockage et l’indexation de contenu. Les données y sont stockées en utilisant le format JSON, ce qui rend l’exploitation des données possible à partir de n’importe quel langage de programmation possédant des API permettant de lire du JSON.
Dans un projet de cybersécurité, nous utilisons ElasticSearch pour répondre au problème d’archivage, d’historisation des données, et de scalabilité non-adressées par les SIEM pour les analyses poussées des actifs du réseau. Pour plus de détail sur ElasticSearch, nous vous recommandons de cliquer sur le bouton suivant.
Apache Spark
Apache] Spark est un Framework de calcul distribué. Il ne fait pas partie de la stack ELK, mais est approprié dans le cadre d’un projet de cybersécurité. Il dépasse le simple cadre de règles de corrélation imposées par une solution SIEM. Spark est un moteur de calcul nativement In-Memory multi-fonction qui permet d’effectuer des travaux avancées d’ingénirie de données et de Data Science. Contrairement aux autres moteurs de calcul du Big Data, notamment le modèle de programmation MapReduce, Spark distribue de façon native les calculs à effectuer sur la mémoire (RAM) de chaque nœud du cluster, ce qui permet d’obtenir des vitesses potentiellement 100 fois plus élevées que celles du MapReduce qui lui fonctionnait selon un mode batch. Ce qui est intéressant sur Spark pour ce projet en plus de sa scalabilité, c’est son écosystème, qui offre des bibliothèques qui permettent d’effectuer une large panoplie d’analyse de données. Par exemple MLib pour le « Machine Learning », GraphX pour les calculs de graphes et Spark SQL, une implémentation SQL-like d’interrogation de données. Spark peut être exploité en utilisant soit du Java, soit du Scala, ou du Python. Spark sera utilisé comme le moteur Analytics de la solution de Security Analytics.
Kibana
Kibana fait partie de la stack ELK. C’est la plateforme d’exploration et de visualisation des données de la suite. Il a été conçu pour fonctionner avec ElasticSearch.
Kibana permet de visualiser de façon interactive les données stockées à large échelle dans les clés des documents stockés dans ElasticSearch. Les tableaux de bords qui y sont développés sont affichés sur un navigateur Web. Dans le cadre d’un projet de Security Analytics, Kibana est parfait pour la restitution et la visualisation des résultats d’analyse des scénarios d’intrusion de et de cyberattaques. Nous allons lui consacrer une chronique toute entière.
