wikinotes

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>cours informatique sécurité cybersécurité}}

Notes et transcriptions du cours "[[000_start|Défis et enjeux de la cybersécurité]]" proposé par l' **UBS**((Université Bretagne Sud)) sur la plateforme [[https://lms.fun-mooc.fr/|FUN MOOC]].


====== SIEM : introduction et définitions ======

Le terme SIEM a été défini en 2005 par une équipe du cabinet **Gartner**. L’utilité première du SIEM est de pouvoir surveiller l’activité d’un périmètre technique que l’on souhaite sécuriser. Généralement, ce périmètre sera un Système d’Information (SI).

Bien que la terminologie **SIEM** ait été définie en 2005, il existait déjà à ce moment-là des outils permettant de surveiller l’activité d’un système. Le SIEM est le résultat de l’association entre deux grands types de service : le **SIM** (**S**ecurity **I**nformation **M**anagement) et le **SEM** (**S**ecurity **E**vent **M**anagement).

Il ne faut pas percevoir un SIEM de manière abstraite. En effet, c’est d’abord une infrastructure technique qui demande un effort de déploiement et de maintenance. L’activité principale du SIEM (la surveillance) est rendue possible grâce aux **données** qui lui sont **envoyées**. En effet, ces données sont issues des processus exécutés sur l’ensemble des machines et serveurs compris dans le périmètre à sécuriser. Elles représentent
l’activité générale du périmètre à sécuriser, elles sont donc primordiales au bon fonctionnement de notre SIEM. À noter que, dans la suite du cours ces « données » seront appelées « **évènements de sécurité** ».

Dans l’histoire des SIEM, on peut différencier **trois grandes phases**. Approximativement, la première se situe entre 2005 et 2010, la deuxième entre 2010 et 2015 et la dernière de 2015 à aujourd’hui.

Le besoin initial qui a poussé des entreprises et organisations à s’équiper de SIEM n’était pas réellement celui de la sécurisation de leurs environnements mais plutôt de la mise en conformité vis-à-vis de nouvelles lois et normes internationales (PCI DSS, HIPAA, …).

Ainsi, le besoin n’étant pas purement sécuritaire pour les structures, les fonctionnalités des SIEM en ont été impactées. Tout d’abord, au niveau de leur mode de déploiement centralisé. De ce fait, ils n’avaient pas la capacité d’évoluer et de s’adapter à la croissance des Systèmes d’Informations qu’ils devaient sécuriser. De plus, les capacités d’historisation, de traitement et de visualisation des évènements de sécurité étaient très limitées.

La deuxième phase a débuté lorsque les structures ont réellement identifié un besoin important de sécurité : il est devenu essentiel d’avoir une vue macro et micro de son Système d’Information. Ainsi, les fonctionnalités des SIEM se sont développées avec, en premier lieu, leur mode de déploiement décentralisé permettant d’ajuster les ressources du SIEM à l’évolution du périmètre à sécuriser. Le management des logs a aussi été grandement amélioré, permettant de collecter et traiter plus d’informations simultanément, de
les enrichir, etc.

Grâce à ces améliorations, les limites connues de la « première version » des SIEM ont pu être solutionnées, ou du moins en grande partie. Cependant, cela a soulevé une nouvelle problématique : les faux positifs. En effet, en associant l’avalanche d’évènements de sécurité et des règles de détection d’incidents parfois mal définies, les équipes de sécurité se retrouvèrent submergées de faux positifs (activité légitime détectée
comme malveillante). A noter que, le SIEM identifie et remonte des alertes qui pourront après analyse être qualifiées d’incidents de sécurité.

C’est alors que la troisième version des SIEM est apparue, autour de 2015. L’idée première a été d’intégrer cette infrastructure technique (SIEM) au sein d’une équipe opérationnelle de sécurité : le « **SOC** » pour **S**ecurity **O**peration **C**enter. Cette cellule a la charge du déploiement et du maintien en conditions opérationnelles de l’équipement. De plus, c’est elle qui traite et qualifie les alertes remontées en temps réel par le SIEM.


Toujours dans cette optique de diminuer le nombre de faux positifs et d’augmenter la détection de réels incidents de sécurité, deux grandes fonctionnalités ont été ajoutées. La première est la capacité du SIEM à récolter de l’information issue du renseignement de la menace (**CTI** : **C**yber **T**hreat **I**ntelligence) dans le but de mettre en correspondance des indicateurs de compromissions connus de systèmes aux évènements de
sécurité propres au périmètre que l’on souhaite sécuriser. Nous en parlerons un peu plus loin dans ce cours.

La seconde est la possibilité de déployer directement sur les systèmes monitorés des logiciels utilisant le machine learning afin de détecter au plus tôt des incidents de sécurité. Nous en parlerons aussi un peu plus loin dans ce cours.

Un SIEM va tout d’abord permettre de collecter un ensemble de logs depuis de multiples sources. Cela permet aux utilisateurs de définir le périmètre à sécuriser et de transmettre les évènements de sécurité au collecteur.

Une fois collectées, ces données doivent être stockées. Pour plusieurs raisons, la première, étant de se donner la possibilité de travailler sur un historique de données. Cela est aussi nécessaire pour des questions de conformité vis-à-vis de lois et normes internationales. 

Enfin, cela permet d’assurer la gestion de la preuve :
on cherchera toujours à stocker des données à l’état brut, notamment lors de leur archivage.
Une fois stockées, on peut requêter sur ces données, faire des sélections, les trier, etc.
Une fois nos données (évènements de sécurité) collectées, stockées et requêtables (normalisés), on peut les manipuler.

Tout d’abord, on va pouvoir les **agréger**. Cela consiste à **regrouper** des évènements selon des critères de sélection, l’agrégation est très souvent la première étape lors du traitement des évènements de sécurité.

On peut aussi **normaliser** un ensemble de données en fonction de leur type et de leur source. Pour cela, il est important de connaître la structure des évènements que l’on veut normaliser. Ce procédé permet in fine de simplifier l’analyse des évènements de sécurité : ayant une structure prédéfinie, il est plus simple de travailler sur ces évènements.

La normalisation permet de faciliter la **corrélation** d’évènement. La corrélation consiste à **mettre en correspondance différents évènements de sécurité** provenant de différentes sources. Cette fonctionnalité est très importante, c’est notamment elle qui permettra de détecter des comportements potentiellement malveillants et ainsi de créer des alertes qui seront transmises aux équipes de sécurité pour qualification.

Par définition, un **SIEM c’est l’association entre un SIM et un SEM**. Comme le SIM, Il doit tout d’abord permettre de faire du **log management** : collection de données, indexation, stockage, requêtage. Comme le SEM il doit aussi permettre de traiter
et d’analyser les données en temps réel de manière collaborative grâce à un outil de ticketing.

[[610_introduction_sequence_6|◁ Précédent]] | [[000_start|⌂ Sommaire]] | [[630_siem_modernes|Suivant ▷]]
wikinotes

Outils pour utilisateurs

Outils du site

Outils de la page
