Les SIEM (Security Information and Event Management) : Gestion

1
Les SIEM (Security Information and Event
Management) : Gestion de la sécurité
centralisée
N. Cherriere, G. Montassier, R. Picard et E. Thuiller, Sujet R1
Etude—Ce document de recherche se concentre sur la
gestion centralisée de la Sécurité des Systèmes
d'Information, et plus particulièrement sur les SIEM
(Security Information and Event Management). Nous
allons nous intéresser à l'utilité d'une telle gestion en
comprenant pourquoi les entreprises en ont besoin de nos
jours, puis étudier le fonctionnement théorique d'un tel
système, et enfin nous plonger dans quelques mises en
pratique. Enfin, nous comparerons nos résultats pour
déterminer le meilleur moyen de protéger le système de
sécurité d'une entreprise.
Mots Clés— Gestion centralisée de la sécurité, LogLogic,
Prelude, Security Information and Event Management,
SIEM
I. INTRODUCTION
D
epuis plusieurs décennies, l'information est
devenue, pour l’entreprise, une ressource
essentielle qu’elle soit privée ou publique. Une
guerre de l’information est donc apparue et est devenue
presque plus intraitable que les guerres meurtrières.
Beaucoup d'activités de l'entreprise se sont
informatisées. On peut citer un certain nombre de
déclarations de taxes et impôts et enfin les systèmes
industriels informatisés et/ou reliés au système
d'information avec une gestion de la qualité des produits.
Avec l’augmentation du nombre de processus métier
transitant par voies informatiques, tout un panel de
matériels, logiciels et personnes travaillent pour assurer
les sécurités des actifs de l’entreprise. Même les
éléments qui ne sont pas, a priori, des éléments apportant
des fonctions de sécurité sont utilisés à des fins
« détournées »
pour
apporter
une
sécurité
supplémentaire : les VLAN sur un switch.
Le système d’information et la loi
Quelles informations sont autorisées à être collecter et
traiter? Combien de temps l'entreprise peut-elle les
garder ? Par quels moyens, sur quels supports ?
C'est tout autant de réponses apportées par les textes
législateurs français et européens et auxquels les
entreprises doivent se conformer sous peine de sanction.
Depuis peu de temps, des données informatiques
peuvent constituer des preuves recevables par un juge
(en France) sous certaines conditions. Ainsi, pour
pouvoir, après un préjudice, retrouver le malfaiteur (qu’il
soit en interne mais aussi en externe) et que les
informations recueillies puisse appuyer les accusations
de l’entreprise vis-à-vis du fautif ayant agi
volontairement ou non.
Changements et émergence d’un nouveau besoin : la vue
globale de la SSI.
Une attaque ne se prépare pas du jour pour le
lendemain, il y a quantité d'étapes préalables pour la
mettre en place. Ces étapes peuvent représenter des
mois, voire plusieurs années de travail de la part des
pirates. Le pirate a besoin d'avoir une vision très précise
du réseau qu'il convoite. Certaines de ces étapes sont
directement de la recherche d'information sur les SI,
donc il est possible de les repérer. En soi, si une seule
étape est effectuée, elle n'est pas spécialement
dangereuse (des scans de ports ont lieu tous les jours)
mais associée à une tentative d'intrusion ou l'installation
d'un morceau de code (par exemple, une backdoor) sur
un PC qui n'a pas été demandé ou effectué par le
personnel de la direction des systèmes d'information
alors on peut avoir de forte présomption qu'une attaque
est en train de se préparer. Ce scénario simple met en
évidence le besoin d'avoir une vue globale de tout ce qui
se passe sur le réseau pour non seulement identifier les
incidents mais aussi les associer entre eux pour déceler
des attaques bien plus complexes.
2
Complexification des Systèmes d’Information
Les systèmes d'information se sont complexifiés car
en plus des éléments permettant de faire fonctionner le
réseau, des éléments utiles pour permettre les processus
métier sont venus se greffer par-dessus. De plus en plus
de technologies sont implantées dans le réseau, de
nouveaux services, l'émergence des réseaux sociaux
(pouvant amener à des fuites d'information) précédée par
l'avènement de la téléphonie mobile et des smartphones.
Globalement, la mobilité des collaborateurs est
problématique (avec les téléphones, PDA, PC portables,
netbook, Tablet PC dans des environnements non sûrs
tels que les cybercafés et réseaux publiques, les réseaux
d'entreprises clientes, les transports...).
Complexification des attaques
Les attaques informatiques se sont multipliées depuis
plusieurs dizaines d'années et sont devenues de plus en
plus complexes. Le mythe du hacker agissant seul,
simplement motivé par le fait d'être le premier à trouver
une faille dans un système a petit à petit laissé place à un
cyber crime organisé. Les commanditaires (les clans
mafieux, des états, des clans terroristes, des
organisations professionnelles) disposent de moyens
financiers pour « acheter » une attaque contre une cible.
Plus les sommes d'argent en jeu sont élevées (bénéfice
pour le commanditaire si l'attaque est réussie ; paie des
techniciens élaborant l'attaque), plus les attaques peuvent
être sophistiquées.
La constante augmentation de la complexité des
systèmes d'information, base de l'entreprise, pose la
sécurité des SI au cœur des problématiques de
l'entreprise. Les enjeux de sécurité, de sûreté de
fonctionnement et la gestion des incidents sur les SI sont
énormes et font l'objet d'attaques à la hauteur de ces
enjeux. Ainsi, les Security Information and Event
Management (SIEM) sont la réponse à ce besoin de
vision globale de la sécurité des SI.
Les SIEM proposent de centraliser la gestion des
alertes de sécurité alors qu’on attend des systèmes
actuels qu’ils ne s’arrêtent jamais, ainsi n’allouer qu’une
machine pour superviser la sécurité du SI parait risqué.
Pour pallier à une interruption de service, il est par
contre possible de créer une machine maitresse (master)
et une machine secondaire (slave), comme il est possible
de faire avec les serveurs DNS, DHCP, afin de garantir
une continuité de fonctionnement par redondance.
Dans un premier temps, nous étudierons les normes
qu’utilisent les SIEM et les étapes clés de leurs
fonctionnements. Fort de cette approche générale, nous
nous attarderons sur deux propositions logicielles :
Loglogic et Prelude. Enfin, nous montrerons les atouts
que comportent les deux solutions, l’une par rapport à
l’autre pour ensuite les confronter à la théorie des SIEM.
II. THEORIE
A. Présentation
Les SIEM sont des outils de supervision de la sécurité,
ils utilisent les informations en provenance de divers
équipements et logiciels de sécurité. Les SIEM
combinent deux éléments [1] :
--Les SIM (Security Information Management) :
Outils de supervision de la sécurité qui se concentrent
principalement sur l’analyse d’informations de
sécurité passées, en vue d’améliorer l’efficacité pour
la gestion à long terme du système d’information [1].
--Les SEM (Security Event Management) : Outils
de supervision de la sécurité s’orientant sur la collecte
de données dans le but de fournir une grande quantité
d’informations pouvant être traitées immédiatement
[1].
La fusion des SIM et des SEM dans un processus
intégré de contrôle de la sécurité avec des informations
pertinentes recueillies dans l’infrastructure du système
d’information est résumée sous le terme de SIEM [1].
Les SIEM utilisent des étapes de récupération, analyse
et gestion de l’information, ce sont la collecte, la
normalisation, l’agrégation, la corrélation, le reporting et
la réponse [2]. (figure 2)
B. Collecte
Les équipements et logiciels de sécurité sont
nombreux dans un système d’information, ils gèrent
généralement de façon indépendante des informations de
sécurité dites « locales ». Le principe de l’étape de
collecte est de fournir au SIEM des données à traiter.
Ces données peuvent être de nature diverse en fonction
de l’équipement ou du logiciel, mais aussi être envoyées
de manières tout à fait différentes. On distingue deux
modes de fonctionnement [3]:
--Mode actif : Le SIEM possède un ou plusieurs
agents déployés sur les équipements à superviser. Ces
agents ont pour fonction de récupérer les informations
des équipements et logiciels de sécurité et de les
envoyer au SIEM. Un élément de sécurité qui a été
conçu nativement pour être un agent du SIEM est
appelé une sonde.
--Mode passif : Le SIEM est en écoute directe sur
les équipements à superviser. Pour cette méthode, c’est
l’équipement ou le logiciel qui envoie des informations
sans intermédiaire au SIEM.
3
C. Normalisation
Les informations collectées viennent d’équipements et
logiciels hétérogènes ayant pour la plupart leurs propres
moyens de formater les données. Cette étape permet
d’uniformiser les informations selon un format unique
pour faciliter le traitement par le SIEM. Des formats ont
été mis au point par IETF pour structurer les
informations de sécurité et pouvoir les échanger et les
traiter plus facilement, ce sont :
--IDMEF (Intrusion Detection Message Exchange
Format) : C’est un standard, défini dans la RFC 4765,
permettant l’interopérabilité entre les systèmes
commerciaux, open-source et de recherche. Il est basé
sur le format XML et est un format conçu pour définir
les évènements et des alertes de sécurité. Il est
également adapté pour le stockage en base de données,
l’affichage et la gestion des informations [4].
Le format IDMEF permet de décrire les évènements
de sécurité et Heartbeat. Selon un modèle hiérarchique,
les évènements de sécurité sont décrits avec les sources
et cibles des attaques mais aussi la sonde
correspondante ainsi que les différents temps de
création et de détection. (figure 1)
fig 1 : Format du message IDMEF
--IODEF (Incident Object Description and
Exchange Format) : C’est un standard, défini dans la
RFC 5070, représentant les informations de sécurité
échangées entre les équipes CSIRTs (Computer
Security Incident Response Teams). Il est basé sur le
format XML et est un format conçu pour transmettre
des incidents de sécurité entre les domaines
administratifs et les parties qui ont une responsabilité
opérationnelle. Ce modèle de données encode
l’information des hôtes, des réseaux, des services [5]…
Le format IDMEF est utilisé juste après la collecte, il
permet ainsi aux informations normalisées en
évènements de sécurité d’être agrégées, corrélées,
stockées en base de données et affichées [4].
Le format IODEF est plus complet que le format
IDMEF, il est utilisé après l’étape de corrélation pour
structurer les données en vue d’un reporting et du
traitement par un système de réponse [5].
D. Agrégation
L’agrégation est le premier traitement des évènements
de sécurité. Il consiste en un regroupement
d’évènements de sécurité selon certains critères. Ces
critères sont généralement définis via des règles appelées
règles d’agrégation et s’appliquent à des évènements
ayant des similarités [6]. Le rôle principal de
l’agrégation est de réduire le nombre d’évènements en
associant un « poids » à ceux-ci. Ainsi un regroupement
de trois évènements de sécurité selon un critère défini
sera un seul évènement avec un poids de trois. Cela
facilite notamment le traitement de l’étape de
corrélation, qui gère alors non plus des évènements
individuels, mais des groupes d’évènements [7].
E. Corrélation
La corrélation correspond à l’analyse d’évènements
selon certains critères. Ces critères sont généralement
définis via des règles appelées règles de corrélation. Le
but de cette étape est d’établir des relations entre
évènements, pour ensuite pouvoir créer des alertes de
corrélations, des incidents de sécurités, des rapports
d’activité… La corrélation se différencie sur plusieurs
points [8] :
--Auto-apprentissage
et
connaissances
rapportées: Pour pouvoir fonctionner, les moteurs de
corrélation ont besoin d’informations sur les systèmes
et réseaux de l’infrastructure. Ces informations
peuvent être collectées automatiquement et/ou saisies
manuellement par un opérateur [8].
--Temps réel et données retardées : Dans certains
cas, les évènements bruts sont forgés et envoyés
directement pour être corrélés en temps réel. Dans
d’autres cas, les évènements sont d’abord stockés, et
envoyés après un premier traitement (ex : agrégation),
leur envoi peut être alors conditionné [8].
4
--Corrélation active et passive : La corrélation
active a la possibilité de compléter les évènements
reçus en recueillant des informations supplémentaires
pour prendre des décisions. La corrélation passive est
une corrélation qui ne peut pas interagir avec son
environnement, elle reçoit des évènements et prend
des décisions [8].
La « cross-correlation » est une corrélation capable
d’associer et de prioriser les évènements de sécurité
reçus, mais aussi d’autres informations (scanners de
vulnérabilité, NMS…). C’est une corrélation active
élargie à de nombreux outils [9].
fig 2 : schéma du fonctionnement théorique d'un SIEM
F. Gestion des alertes
Il y a plusieurs façons pour un SIEM de gérer des
alertes, plusieurs d’entre elles peuvent être utilisés
simultanément :
--Le « reporting » : les rapports générés
contiennent à la fois une synthèse des alertes et une
vue d’ensemble de la sécurité du système à un instant
T (statistiques, intrusions, vulnérabilités exploitées,
classification des attaques) [7].
--Le stockage : les alertes, incidents et rapports
peuvent être stockés dans des bases de données pour
pouvoir être analysés ultérieurement par des moteurs
de corrélation [8].
--La réponse : les mécanismes de réponse aux
alertes doivent permettre de stopper une attaque ou de
limiter ses effets de façon automatique. La réponse à
une intrusion dépend de la politique de sécurité [10].
III. PRATIQUE 1 : PRELUDE
A. Présentation
Prelude est un SIEM issu d’un projet open source qui
fut créé en 1998 par Yoann Vandoorselaere [11]. Ce
projet est né de l’idée que le nombre de systèmes de
détection d’intrusion augmentait mais qu’il n’existait pas
de système pour les faire communiquer entre eux, ce qui
diminuait leur efficacité [12]. (figure 3)
B. Collecte
Prelude fonctionne en mode actif, c’est à dire qu’il
utilise des agents qui sont installés sur les systèmes à
surveiller et qui vont s’occuper de la phase de collecte.
Dans un premier temps, l’agent (appelé Prelude-LML)
doit être configuré, Il faut indiquer à celui-ci les formats
de logs des logiciels à surveiller pour que celui-ci puisse
les prendre en compte.
Ensuite, l’agent démarré peut collecter les logs de
deux façons différentes : soit il surveille les journaux
systèmes de l’hôte sur lequel il est installé, soit il reçoit
les journaux venant de différentes machines placées sur
le réseau. Ces messages sont sécurisés (en TLS) et
possèdent un mécanisme d'autorégulation pour ne pas
surcharger le réseau. L’intérêt de cette deuxième
méthode est de permettre aux systèmes ne supportant pas
l’agent Prelude de pouvoir être surveillés en envoyant
leurs logs à un agent distant.
Une fois les informations récupérées, l’agent les
compare avec ses jeux de règles (basés sur des
expressions régulières) et si une condition précise est
reconnue, un évènement de sécurité est créé. [14].
L’avantage de cette méthode de collecte est la
flexibilité par rapport au réseau. Les mécanismes mis en
place empêchent la perte de paquet (autorégulation,
réémission) et assurent leurs intégrités. Par contre, la
confidentialité (chiffrement TLS) n’est pas assurée
totalement car seuls les échanges entre l’agent et le
manager sont sécurisés, contrairement aux échanges
entre l’agent et les systèmes distants, qui lui envoient
leurs logs.
5
Un autre avantage est le mode « sonde » : ce mode
permet qu’un agent soit directement « patché » au code
source d’un logiciel de sécurité (ils sont alors
indissociables). [13], [14]
C. Normalisation
Prelude a participé au projet “Intrusion Detection
Message Exchange Format” (IDMEF). C’est donc
évidement ce format qui fut choisit pour le SIEM. [12],
[16]
La normalisation est réalisée par l’agent Prelude-LML
qui formate les évènements avant de les envoyer au
manager.
L’IDMEF est un format de message pour les
évènements de sécurité et les alertes de corrélation. Il
sert donc uniquement à « mettre en forme » ceux-ci.
Les évènements et alertes sont donc décrits par ce
format de manière à être traité plus facilement par le
SIEM.
--Lorsque que des évènements sont détectés, il
affiche les alarmes via sa console graphique Prewikka.
--Il peut aussi prendre la décision de transmettre
l’alerte à un autre manager Prelude (dans le cas d’un
fonctionnement hiérarchique).
--Il peut également, grâce à un « plugin », envoyer
des mails d’alerte contenant l’alerte détectée.
Prelude possède des ajouts transmettant les alertes à
des moteurs de réaction.
L’atout principal de faire normaliser les logs par
l’agent est d’alléger le traitement réalisé par le manager.
De plus, le choix d’un format normalisé permet une
compréhension simplifiée et une plus grande
adaptabilité.
D. Agrégation
Prelude ne fait pas d’agrégation car il n’y a aucun
traitement sur les évènements, cependant il possède un
système pour améliorer le traitement des informations
par les utilisateurs.. [15]
E. Corrélation
Tous les évènements envoyés au manager sont stockés
puis transmis au moteur de corrélation appelé PreludeCorrelator. Ce moteur se base sur des règles (écrites en
langage python) pour analyser les évènements de
sécurité et ainsi créer des « alertes de corrélation ». Ces
alertes sont alors renvoyées au manager qui les
stocke.[17], [18]
Le système de corrélation est encore instable, on
pourra mettre en avant que l’écriture des règles est
complexe, car elle demande une bonne compréhension
du langage python, de la norme IDMEF, du réseau
surveillé et des attaques surveillées.
F. Gestion des alertes
Prelude peut réaliser le « reporting » de trois façons :
Fig 3 : schéma du fonctionnement du SIEM Prelude
IV. PRATIQUE 2 : LOGLOGIC
A. Présentation
Loglogic, anciennement “Exaprotect” a été créé en 2004
par la société française Exaprotect. Celle-ci a été
rachetée en 2009 par l’entreprise américaine LogLogic et
est donc devenu « LogLogic » par la même occasion. De
plus, LogLogic est une « appliance », c'est-à-dire que le
logiciel est indissociable du matériel. [19] (figure 4)
B. Collecte
Loglogic fonctionne en mode actif, il faut donc
déployer des agents sur les équipements à surveiller pour
qu’ils réalisent la collecte.
Les agents n’ont presque pas de configuration, ils
déterminent lors de l’installation le format des logs à
collecter et agissent ensuite en autonomie. C’est à dire
6
qu’ils collectent les logs, les normalisent, puis les
envoient de façon sécurisée au SIEM.
Si un agent n’est pas nativement compatible avec un
équipement, il faut alors configurer l’agent pour qu’il
puisse comprendre ceux-ci à l’aide de règles pour
« parser » ceux-ci.
L’avantage de Loglogic est sa simplicité de mise en
œuvre. Les agents s’installent facilement et la
configuration est simplifiée. La configuration peut de
surcroit être réalisée à distance depuis le manager de
Loglogic.
Les échanges entre les agents et le SIEM sont
sécurisés par TLS. [20]
De plus Loglogic réalise automatiquement des rapports
dynamiques, qui sont composés de graphiques et de
résumes des attaques répertoriées. [21] [23]
La réponse se fait à par l’envoi d’incidents IODEF ou
Alertes de corrélation IDMEF à un moteur de réaction
quelconque. Celui-ci agira en fonction des évènements
reçus.
C. Normalisation
Loglogic utilise le format normalisé IDMEF.
Les Logs sont normalisés par les agents avant qu’ils
envoient les alertes au manager.
Le choix d’un format normalisé (IDMEF) permet que
les logs soient « compréhensibles » par le SIEM et
facilement traité par celui-ci. [21]
D. Agrégation
LogLogic
possède
un
moteur
d’agrégation
paramétrable à l’aide de règles. C’est une étape
importante qui détermine comment les évènements
seront regroupés avant d’être envoyés au corrélateur. En
plus d’être affichés dans la console graphique de
LogLogic, les évènements agrégés sont regroupés par
critères définis au préalable, ce qui permet une meilleure
corrélation car les évènements sont déjà rassemblés pour
être corrélés, et peuvent même être fusionnés ou
redéfinis. [21] [22] [23]
E. Corrélation
Toutes les alertes reçues par LogLogic sont transmises
au moteur d’agrégation, puis au corrélateur et celui-ci les
traite en fonction de ses règles de corrélation. Quand une
alerte de corrélation est créée, elle est stockée dans la
base de données et est affichée dans la console
graphique. LogLogic permet de définir des « scénarios »
qui sont des regroupements d’alertes de corrélation. Cela
ajoute un traitement supplémentaire par le SIEM. [23]
F. Gestion des alertes
Loglogic peut réaliser un « reporting » en fonction du
type d’alerte détectée. On peut donc décider que pour un
type d’attaque détecté on réalise une action particulière.
Les actions réalisables par Loglogic sont nombreuses :
on peut envoyer un mail, un SMS, envoyer l’incident à
un autre serveur, ou même créer un « trap » SNMP…
Fig 4 : schéma de fonctionnement d'un SIEM dans LogLogic
V. COMPARAISONS
A. Prelude / LogLogic
Collecte
Les deux logiciels fonctionnent en mode actif : le
manager reçoit donc les informations de la part des
agents. Les deux propositions logicielles permettent de
superviser des machines où des agents ne peuvent pas
être installés. Donc, le déploiement peut se faire dans un
réseau hétérogène. Cependant, l’agent Prelude a un net
avantage sur son concurrent, car il est compatible avec
beaucoup plus de logiciels et équipements de sécurité
grâce à la communauté open-source.
Normalisation
Dans les deux cas, les logs sont formatés en IDMEF
par l’agent qui les reçoit et celui-ci les envoie au
manager. Les deux logiciels fonctionnent donc de la
même façon pour la normalisation
7
Agrégation
Loglogic est le seul logiciel parmi les deux à proposer
un réel système d’agrégation. Cela évite une surcharge
d’évènements en utilisant un système de regroupement,
ce qui facilite le travail de corrélation. On économise
donc les ressources réseau et de calcul.
Corrélation
Les deux SIEM proposent une corrélation entre
évènements et un stockage en base de données pour être
ensuite affiché à l’aide d’une interface. Cependant,
Loglogic ajoute la possibilité de créer des scenarios, ce
qui augmente un niveau de traitement pour les alertes de
corrélation.
Reporting
Le système de « reporting » de Loglogic est plus
complet que celui de Prelude. Les deux logiciels
proposent l’affichage dans une interface, ce qui parait
être le minimum mais le premier est capable d’envoyer
des mails ou de générer des « trap » SNMP et permet de
créer des rapports plus complets (avec graphes), ce qui
peut être utile dans une démarche continue d’analyse de
risques. Le second n’est capable de faire que du
« reporting » simpliste, à moins que l’on utilise la
version payante, qui possède également des graphes
statistiques, et de la génération de rapports en PDF.
Pour aller plus loin
LogLogic peut envoyer des messages au format
IDMEF et IODEF à un moteur de réaction pour répondre
à une attaque. Ce moteur n’est pas inclus dans Loglogic
mais l’utilisation de messages dans un format normalisé
permet de s’interfacer avec un module chargé des
contre-mesures. Prelude est lui aussi capable d’envoyer
des informations à un moteur de réaction, mais
seulement au format IDMEF.
Puisque l’idée sous-jacente des SIEM est de centraliser
les alertes de sécurité, Loglogic et Prelude (en version
professionnelle) donnent les moyens de configurer les
agents directement à partir du manager. Les deux SIEM
permettent aussi la gestion de tickets d’incidents.
B. Théorie / Logiciels
Les logiciels étudiés sont une interprétation générale de
la théorie, et des implémentations particulières qui leurs
sont propres. L’absence d’agrégation pour Prelude et la
gestion de l’IODEF par LogLogic en témoignent. Le
fonctionnement des deux produits repose tout de même
sur des formats de messages standardisés (IDMEF et
IODEF) ce qui les rend facile à traiter.
Les logiciels respectent donc les standards, mais les
constructeurs ont orienté leurs produits vers des chemins
divers
VI. CONCLUSION
L’objectif de ce rapport était d’apporter des réponses
quant au fonctionnement des SIEM dans le cadre d’une
gestion centralisée. Pour cela, nous avons commencé par
expliquer le contexte : l’intérêt de l’utilisation de cette
méthode centralisé. Nous avons ensuite étudié le
fonctionnement théorique de cette méthode, ainsi que
deux implémentations concrètes.
Notre étude nous a aussi permis d’étudier les
principaux avantages de la gestion centralisée :
- la simplicité de configuration du manager
- la visibilité globale du réseau par le manager
- la cohérence des alertes et des décisions menées
Cependant cette technique possède aussi des
faiblesses. Par exemple la centralisation peut amener
rapidement un problème de disponibilité du service si le
manager est défaillant.
Nous pouvons conclure que les SIEM en gestion
centralisée permettent une réelle sécurisation du
système, mais que l’on doit s’assurer de leur
disponibilité, et qu’il semble malvenu d’utiliser les
envois non sécurisés de logs.
Les deux SIEM étudiés ont chacun leurs particularités.
Prelude vient du monde open-source, ce qui lui permet
une très large compatibilité avec d’autres logiciels et
équipements. LogLogic est, quant à lui, un produit issu
de l’industrie et possède un système de traitement des
alertes très performant. Le « reporting » est presque
identique, puisque Prelude en version professionnelle a
de nombreux ajouts. Les deux SIEM sont de plus très
évolutifs car leurs auteurs permettent aux diverses
entreprises de demander des améliorations et
modifications
sur-mesure,
moyennant
finance
évidemment.
Une théorie des SIEM existe donc, ainsi que des
standards. Les développeurs de logiciels de SIEM ont un
panel de caractéristiques possibles à exploiter et ceux-ci
choisissent ce qui les intéresse en fonction de leur
politique technique, organisationnelle et commerciale.
Nous pouvons donc trouver une multitude de SIEM sur
le marché avec aussi bien des ressemblances que des
divergences qui font les faiblesses et forces de chacun.
8
Nous conclurons sur l’intérêt de l’utilisation d’un
système tel que le SIEM pour une entreprise. En effet, la
possibilité de pouvoir récupérer et agréger la totalité des
logs du réseau permet d’avoir à la fois une vision
complète, mais aussi une compréhension affinée des
évènements qui se passent sur celui-ci. La combinaison
de ces deux éléments (vison + compréhension) fait des
SIEM un élément nécessaire en terme de sécurité
informatique et est donc indispensable pour les
entreprises.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
Gabriel, R. et al. Analyzing Malware Log Data to Support
Security Information and Event Management: Some Research
Results. First International Conference on Advances in
Databases, 2009.
Zoho Corp. Analyzing Logs For Security Information Event
Management, 2007. Whitepaper.
http://www.manageengine.com/products/eventlog/AnalyzingLogs-for-SIEM-Whitepaper.pdf
Stevens, M ; CERT. Security Information and Event
Management, 2005, Nebraska
www.certconf.org/presentations/2005/files/WC4.pdf
The IETF TRUST. RFC 4765, 2007.
http://www.ietf.org/rfc/rfc4765.txt
The IETF TRUST. RFC 5070, 2007.
http://www.ietf.org/rfc/rfc5070.txt
Cuppens, F. Managing Alerts in a Multi-Intrusion Detection
Environment. www.acsac.org/2001/papers/70.pdf
Reddy, R. ; Reddy, S. Facilitating Alerts Analysis and Response
Decision Making. Conference paper of csreaSAM, Security and
Management, p448-455. 2006
Mullet, A. Master’s Thesis Event Correlation Engine Computer,
Engineering and Networks Laboratory, 2009. 0x7.ch/text/eventcorrelation-engine-slides.pdf
AlienVault. SIEM System Description AlienVault LLC, 2010.
www.alienvault.com/docs/AV%20SIEM%20System%20Descri
ption-v4.pdf
Debar, H. Analyse et détection d’intrusions. Sécurité des
systèmes d'information, Techniques de l'ingénieur, 2004.
Site officiel de Prelude. http://www.preludetechnologies.com/fr/menu/a-propos-de-prelude/index.html
Vandoorselaere, Y. Foreword. https://dev.preludetechnologies.com/wiki/prelude/PreludeForeword
Site officiel de Prelude. http://www.preludetechnologies.com/fr/solutions/les-briques-preludepro/index.html
Site officiel de Prelude. http://www.preludetechnologies.com/fr/developpement/documentation/compatibilit
e/index.html
Vandoorselaere, Y. IDMEF Criteria, Wiki on Prelude
Technologies, 2006.
RFC 4765. http://www.ietf.org/rfc/rfc4765.txt
Vandoorselaere, Y. Prelude Correlator., Wiki on Prelude
Technologies, 2006.
Chifflier, P. ; Tricaud, S. Intrusion Detection Systems
Correlation: a Weapon of Mass Investigation, CanSecWest
Vancouver 2008.
Site officiel de LogLogic. http://www.loglogic.com/
Papiers blancs de LogLogic.
http://www.loglogic.com/resources/white-papers/
[21] Données techniques de LogLogic.
http://www.loglogic.com/resources/datasheets
[22] Kelly, D. Information Security mag. SIMs : More than just a
pile of logs. pp. 13-19.
http://media.techtarget.com/searchSecurity/downloads/0609_IS
M.pdf
[23] McGuire, M. ; Briguet, C. Introduction to Secure Event
Manager, Visibility & Controlon IT Security, LogLogic, 2008.