Mise en place du SIEM Prelude en entreprise – Retour d'expérience

1. Introduction

1.1 Qu'est-ce qu'un SIEM ?

Avant l'apparition du terme SIEM (Security Information and Event Management) en 2005, il faut bien comprendre qu'il y avait deux méthodes distinctes de gérer les événements de sécurité d'un système d'information.

D'une part, nous avions, notamment, l'analyse en temps réel de fichiers de journalisation (logs) d'équipements réseau. Par exemple, l'analyse des logs d'un pare-feu en temps réel afin de détecter une attaque et mettre en place une règle de filtrage adéquate. D'autre part, l'externalisation des logs sur un serveur central afin de conserver les événements de sécurité et les analyser en cas de problème.

Un SIEM permet de faire converger ces deux fonctionnalités et de fournir une solution complète permettant de collecter, de normaliser, d'agréger, d'archiver, d'analyser, d'alerter, de corréler et de fournir des tableaux de bords des événements de sécurité du système d'information.

1.2 Présentation de Prélude

Prelude a été créé en 1998 par Yoann Vandoorselaere et était à l’origine une solution de détection d'intrusion (IDS). Depuis, le projet a évolué jusqu'à rejoindre le mode de fonctionnement d'un SIEM.

En janvier 2012, la solution Prelude a été rachetée par la société C-S possédant déjà plusieurs solutions de surveillance de zones. Il existe à ce jour trois versions de Prelude :

- Une version communautaire nommée OSS publiée sous licence GPLv2 : Elle fournit les fonctionnalités de base de la solution, mais est limitée en terme de performances ;

- Une version professionnelle : Cette version intègre de nouvelles fonctionnalités (gestion de tickets, génération de rapports, gestion d'une authentification LDAP, etc.) et fournit des performances supérieures à la version communautaire en utilisant des bibliothèques spécifiques ;

- Une version entreprise : Cette version est assez similaire à la version professionnelle et se différencie, notamment, par l'intégration de quelques fonctionnalités avancées (cartographie et inventaire du réseau entre autres). L'éditeur considère que cette solution permet de mettre en place un SOC (Security Operation Center) au sein d'une organisation.

Un comparatif détaillé des trois versions est présent sur le site de l'éditeur [SITE].

L’architecture de la solution Prelude repose sur un modèle distribué composé d’un manager et de différentes sondes. Les sondes sont chargées d'envoyer les informations relatives aux événements de sécurité au manager, qui se charge de l'analyse.

 

 

Il est à noter que toutes les communications effectuées entre les différents éléments de l'architecture sont chiffrées à l'aide d'une clé RSA de 2048 bits par défaut. Lors de l'enregistrement d'une sonde auprès d'un manager, cette dernière récupère un certificat unique de type x509 afin de protéger les futures communications. L'échange de clé est détaillé dans cet article [CLES].

Prelude reçoit, analyse, corrèle et normalise les informations des différents équipements du système d'information sous un format universel. De plus, la solution est en mesure d'ajouter des informations spécifiques, sous la forme de méta-données, en fonction de la criticité de l'équipement émetteur. On peut ainsi modifier le type (admin, dos, fichier, utilisateur, etc.) ou la pertinence d'une alerte. Par exemple, les alertes émises par le pare-feu en frontal peuvent être considérées moins pertinentes.

Pour communiquer, la solution utilise le format standardisé IDMEF [RFC] afin de décrire une alerte de façon exhaustive en suivant un modèle dit objet. Ce format permet aux solutions commerciales et celles sous différents types de licences de communiquer dans un langage commun au sujet des événements de sécurité.

Le standard IDMEF offre un vocabulaire précis dans le domaine de la détection d'intrusion et permet, notamment, de savoir si une alerte a déjà été traitée, son état, l'émetteur de l'alerte, etc. L'implémentation des messages est simplifiée afin de limiter l'ajout d'informations inutiles lors des différents transferts entre les services de la solution.

Voici un extrait d'une alerte sous le format IDMEF :

Dans notre contexte, la version communautaire était suffisante pour répondre à nos besoins décrits dans la section suivante. Nous parlerons uniquement de cette version dans la suite de cet article.

1.3 Infrastructure cible

L'objectif de notre projet se concentrait sur la possibilité de détecter des attaques informatiques sur notre système d'information. La solution utilisée ne devait pas avoir d'impacts importants sur les performances réseau et systèmes (perte de performance engendrée par l'installation d'un agent, ouverture de flux supplémentaires, etc.). En outre, la solution devait être en mesure de détecter les événements de sécurité au travers de journaux d'événements et des messages spécifiques de certaines solutions (notamment Snort).

De plus, la mise en place d'une solution de type SIEM devait nous donner la possibilité de sélectionner de manière précise le périmètre à surveiller et permettre l'analyse des journaux d’événements sur un équipement de centralisation. L'idée était de sélectionner uniquement les équipements qui nous semblaient être les plus critiques de l'entreprise (manipulation d'informations sensibles, contraintes de disponibilités, etc.). Aucun poste utilisateur n'a été sélectionné car peu d'informations sensibles sont stockées en local et il s'agit principalement de postes nomades (l'inconsistance des logs dans le temps pouvant représenté une difficulté supplémentaire). Il est tout de même à noter que les postes nomades sont particulièrement sensibles et que leur supervision ne doit pas être négligé, bien que nous ayons fait le choix de ne pas les intégrer à notre périmètre.

Nous avons donc décidé de surveiller les équipements suivants de notre infrastructure :

-3 routeurs Linux kernel 2.6 ;

-2 pare-feu Linux avec IPtables ;

-100 serveurs Linux ;

-2 serveurs Windows 2008 : un serveur mail Exchange et un serveur de fichier;

-Une sonde Snort IDS chargée de collecter les intrusions sur le réseau ;

-Un commutateur CISCO.

Voici un schéma simplifié de l'infrastructure cible :

 

 

Enfin, la solution devait aussi proposer une interface de management regroupant toutes les alertes, être libre de droits et être déployable sur des équipements utilisant un noyau Linux. Ces contraintes ont écarté de facto des solutions telles que Splunk ou OSSIM dans leurs versions gratuites. On notera également que la version libre de Prelude n'intègre pas toutes les fonctionnalités disponibles en version Enterprise (par exemple : fonctionnalités de gestion de tickets et graphiques d'évolution).

Afin de répondre à cette problématique, nous nous sommes tournés vers la solution Prelude et sa console de management Prewikka.

Pour notre plate-forme SIEM Prelude, nous avons mis en place deux serveurs :

-Un serveur de centralisation des logs (8GB de RAM, Processeur intel XEON E7 et 500GB d'espace disque) : Ce serveur permet de centraliser et d'archiver les logs des différents équipements de l’infrastructure. Il disposait du composant prelude-lml ;

-Un serveur maître de management (16GB de RAM, Processeur intel XEON E7 et 250GB d'espace disque) avec les composants prelude-manager, prelude-correlator, MySQL et Apache pour l'accès à l'interface de management Prewikka.

Il est à noter que dans le cadre de la solution Prelude, il est très important d'avoir des machines performantes (RAM, CPU et espace disque) afin de traiter rapidement les données reçues par les différentes sondes.

Au niveau des alertes nous avons constaté un volume d’environ 80 GB par trimestre en période de tests et de configuration. La volumétrie a ensuite diminuée aux alentours de 35 GB tous les trois mois.

La période de rétention des données fut décidé de manière arbitraire à trois mois. Cette période nous a permis ainsi de garder des traces des actions passées mais aussi de limiter l'utilisation de l'espace disque des équipements.

2. Étude de la solution

2.1 Composants

Comme expliqué précédemment, la solution utilise un modèle distribué et est composée des éléments suivants :

- Prelude-Manager ;

- Prelude-LML ;

- Prelude-Correlator ;

- Une interface de gestion ;

- La bibliothèque transverse libprelude ;

- Des sondes tierces (par exemple la solution Snort).

2.1.1 Bibliothèque Prelude

Libprelude est le composant principal de la solution. Cette bibliothèque contient tous les modules de Prelude et permet aux développeurs d’intégrer les fonctionnalités de la solution aux autres produits présents dans le Système d'Information de l'entreprise. Par exemple, il est possible d'intégrer cette bibliothèque, moyennant un développement spécifique, à divers produits de détection d'intrusion, (par exemple la solution Bro) afin que les messages soient directement émis sous le format de détection utilisé par la Libprelude. La bibliothèque fournit aussi une interface unique et standard de communication entre les différents éléments du système de détection. Afin de respecter les standards et de permettre une interopérabilité de la solution, le format des messages utilisé par Libprelude est IDMEF.

Outre une standardisation des procédures, la bibliothèque incorpore aussi tous les outils nécessaires à l’authentification mutuelle et au chiffrement des communications entre les différents composants de la solution. Il est nécessaire d'installer cette bibliothèque sur chaque sonde de l'infrastructure Prelude.

La configuration de la bibliothèque est simple et rapide. Il est, cependant, nécessaire de configurer la fréquence d'envoi des heartbeats dans le fichier /etc/prelude/default/global.conf en accord avec l'intervalle TCP dans le fichier /etc/prelude/default/client.conf afin de ne pas voir ses sondes apparaître régulièrement comme « mortes » dans le manager.

2.1.2 Prelude-Manager

Prelude-manager a pour but de recevoir les alertes générées par les sondes dont il a la charge et est en mesure de les stocker sous différents formats :

- Fichiers plats : stockage des données en mode texte ;

- Fichiers XML-IDMEF : format de stockage en accord avec le standard RFC permettant l'export et l'import des données vers n'importe quel service Prelude ;

- Base de données SQL : utilisation d'une base de données pour le traitement des informations par des logiciels tiers.

Il est aussi possible de transférer les alertes selon deux mode :

Avant chaque insertion d'une alerte, il est possible de configurer un ensemble de filtres pour rejeter certaines alertes. Cela permet d'alléger la base de données et d'effectuer différents types d'actions à la réception d'un événement de sécurité. La configuration de ces filtres est présentée dans la section 2.3.

Il est à noter qu'il est possible de configurer prelude-manager pour qu'il soit esclave d'un autre manager sur un site distant. Dans ce cas, le manager esclave concentre les informations de la zone dont il a la charge avant d'envoyer les alertes pertinentes au manager maître.

Afin de stocker les événements de sécurité et les différentes alertes, nous avons décidé d'utiliser le système de gestion de bases de données MySQL afin que la console Prewikka puisse avoir accès aux alertes. Nous n'avons pas décidé d'utiliser les autres formes de stockages afin de ne pas surcharger l'espace disque du manager Prelude.

2.1.3 Prelude-lml

Prelude-lml est la sonde chargée de collecter et formater les logs pour les envoyer au manager pour interprétation.

La collecte des logs peut être effectuée selon deux modes :

- Analyse des fichiers de logs envoyés par les équipements sur le serveur hébergeant la sonde ;

- Réception des logs des équipements directement par le protocole UDP.

Dans notre situation, nous avons mis en place un serveur de centralisation de log sur lequel était installé la sonde.

Afin d'effectuer cette tâche, la sonde va analyser l'ensemble des fichiers de logs mis à sa disposition à l'aide des expressions régulières Perl PCRE. Les événements de sécurité contenus dans les logs sont ensuite transformés dans le format IDMEF et envoyés au manager.

Un ensemble de règles prédéfinies est disponible dans les fichiers /etc/prelude-lml/ruleset/pcre.rules et /etc/prelude-lml/ruleset/single.rules.

L'utilisation du format PCRE pour la reconnaissance des fichiers de log permet de modifier et d'ajouter rapidement des règles supplémentaires.

Le format par défaut défini par la sonde est celui du gestionnaire syslog. Il est néanmoins possible de créer ses propres règles dans le cas où les fichiers d'événements produits par les équipements du réseau ne seraient pas compatibles nativement avec la solution Prelude.

Le temps nécessaire à la mise en place de nouvelles règles de lecture pour des logs spécifiques est très rapide via l'utilisation d'expressions régulières.

Voici un exemple de configuration pour l'utilisation du format rsyslog :

Dans le cas de certains types de machine, Windows NT par exemple, un logiciel supplémentaire est requis pour convertir les journaux d'événements au format syslog.

2.1.4 Prelude-Correlator

Prelude-correlator est le composant de l'architecture qui va regrouper les différentes alertes afin de générer des groupements d'alertes et des schémas d'attaques. De plus, Prelude-correlator est en mesure de détecter les faux positifs selon des règles prédéfinies.

Pour effectuer cette tâche, le service Prelude-correlator va régulièrement consulter les alertes stockées dans la base de données, en plus de celles reçues en temps réel, et rechercher des liens entre ces dernières afin de faire des groupements d'alertes.

En effet, chaque alerte remontée peut être la partie émergée d’un problème bien plus grand et bien plus grave en conséquences.

La corrélation d’une alerte par cette sonde va suivre le cheminement logique suivant :

1. Récupération des données de l’alerte (IP source et destination, processus, interfaces réseaux, ports, message, etc.) ;

2. Recherche de correspondance avec les alertes, corrélées ou non, dans la base de données du manager ;

3. Analyse heuristique du comportement par rapport aux schémas d'attaques les plus courants ;

4. Vérification des déplacements réseau entre les alertes pour détecter un éventuel pivot(par exemplecompromission d'un équipement par brute force puis rebond sur les équipements du sous réseau);

5. Remontée de l'alerte de corrélation au manager en adaptant le niveau de sévérité en fonction des alertes corrélées. Si la nouvelle alerte rentre dans les paramètres des règles de filtrages, l'action correspondant au filtre utilisé est déclenchée (par exemple l'envoi d'un mail d'alerte).

 

 

Afin de faciliter ce raisonnement, toutes les alertes remontées sont triées et regroupées en fonction de critères prédéfinis (criticité, processus, etc.).

La corrélation étant basée sur un système d’analyse des attaques informatiques, certaines actions déclencheront une mise en marche automatique du diagramme de recherche :

- Collecte d'informations sur le réseau (prise d’empreinte, scan de ports, etc.) ;

- Recherche de vulnérabilités ;

- Exploitation des vulnérabilités identifiées en vue d'obtenir un accès à un équipement ;

- Tentative d'élévation des privilèges sur l'équipement compromis ;

- Maintien de l’accès (installation de portes dérobées, effacement des traces, etc.).

Chacune de ces actions peut être un signe d’une attaque imminente ou en cours de réalisation. C’est pourquoi dès qu’une alerte répondant à un ou plusieurs de ces critères est remontée, le scénario de corrélation s'activera.

Le service Prelude-correlator va aussi tenter, à intervalles réguliers, d'effectuer de nouveaux liens entre plusieurs alertes corrélées précédemment et des alertes isolées afin de compléter les corrélations passées.

Ce système permet ainsi de détecter des attaques s'étalant sur une période de temps importante.

Par défaut, Prelude-correlator intègre un certain nombre de plugins disponibles dans le fichier /etc/prelude-correlator/prelude-correlator.conf permettant l'analyse des alertes dans leurs domaines de compétences respectifs.

En voici une liste non exhaustive :

-EventStorm : permet de regrouper un grand nombre d'alertes possédant un ou plusieurs points communs mais sans corrélation particulière. Par exemple, une attaque de Déni de service créera un grand nombre d'alertes qui seront regroupées sous la dénomination EventStorm ;

-OpenSSHAuth : permet de gérer les corrélations d'alertes impliquant les services OpenSSH ;

-Worm : intègre les divers comportements des vers informatiques permettant de déterminer la présence éventuelle d'une telle menace en corrélant diverses alertes ;

-Firewall : permet la corrélation d'alertes remontées par les pare-feux surveillés.

Le mécanisme de corrélation repose sur l'utilisation du langage Python permettant une grande flexibilité dans l'écriture de nouvelles règles. Afin de de créer un nouveau plugin, il est nécessaire de déclarer une nouvelle classe Python où le scénario sera défini à l'aide du langage IDMEF.

Pour faciliter l'écriture des scénarios, les classes suivantes fournissent un ensemble de fonction destinées à manipuler les informations :

-PreludeCorrelator.context ;

-PreludeCorrelator.pluginmanager.

Les nouveaux plugins doivent ensuite être déposé dans le répertoire /usr/lib/pymodules/python2.6/PreludeCorrelator/plugins

2.1.5 Prewikka

Prewikka est la solution officielle du projet Prelude fournissant une console de visualisation et de gestion des alertes stockées en base de données remontées par Prelude-manager.

On notera l'existence de précédentes solutions, non maintenues, permettant la visuation d'alertes Prelude :

-Prelude-PHP-Frontend : solution développée en PHP et destinée à être installée sur un serveur séparé des composants de la solution.

-Prelude-Perl-Frontend : interface du projet « Le Routier » développé en Perl offrant les mêmes possibilités que son homonyme PHP. 

Nous nous concentrerons sur les atouts et le fonctionnement de Prewikka puisque cette solution est devenue l’interface officielle du projet Prelude.

Prewikka intègre les caractéristiques suivantes nécessaires à l’architecture SIEM de Prelude :

- Gestion des heartbeats (Equivalent des TTL réseaux) : permet de définir quand chaque sonde a communiqué pour la dernière fois avec le contrôleur.

- Exportation et visualisation des tableaux de bord graphiques ;

- Règles de filtrages avancées permettant des recherches logiques ou dichotomiques.

 

 

Il est à noter que la version professionnelle de Prelude permet la gestion de tickets et la génération de rapports et de statistiques au travers de l'interface Prewikka.

2.2 Filtres d'alertes

Le système de filtres utilisé par le manager repose sur la définition de critères d'identification en accord avec le standard RFC IDMEF. Les filtres sont ensuite traités séquentiellement.

En d'autres termes, les règles sont exécutées dans l'ordre de définition (comme pour les règles d'un pare-feu).

La création d'un filtre est effectuée selon trois paramètres :

- Nom du filtre entre les symboles '[' et ']' ;

- Le type d’événement à traiter à l'aide du format IDMEF au sein de la variable « rule »;

- L'action à effectuer quand une alerte correspond au filtre avec la variable « hook ».

Il est possible d'affiner l'action d'un filtre avec l'ajout de l'instruction thresholding. Cette instruction est définie par un nom de la même manière que le filtre ci-dessus mais possède en plus les attributs « count », « path » et « limit ».

Ainsi en empilant ces deux systèmes de filtres, on est en mesure d'effectuer plusieurs actions précises sur un même type d'alerte.

Prenons par exemple le cas où un éventuel attaquant exécute une attaque par brute force sur un service SSH. En l'absence du filtre thresholding, chaque connexion fera l'objet d'une alerte « Tentative de connexion SSH avec l'utilisateur root » qui sera suivie d'un envoi de mail à l'administration. Sous le coup d'une attaque de force brute, un nombre important de mails peut être envoyé à l'administrateur, noyant ainsi les autres informations pertinentes du réseau.

Il est donc possible de limiter l'envoi de mail par l'empilement de filtres suivant :

Ce filtre peut être traduit ainsi : « Les alertes de BruteForce entrantes (option 0) ne sont remontées qu'une seule fois (count=1) toutes les heures (limit=3600) si la connexion provient de la même adresse IP (path) ».

2.3 Remontée des alertes

La solution Prelude intègre un système de remontée des alertes. Ce mécanisme repose sur l'utilisation de plugins intégrés à prelude-manager permettant d'enregistrer les alertes sous trois formats.

2.3.1 Mail

Pour mettre en place ce dispositif, il suffit d'éditer le fichier /etc/prelude-manager/prelude-manager.conf et recherchez le bloc [smtp]. Voici un exemple de configuration :

Voici un exemple d'un template mail défini dans le fichier : /etc/prelude-manager/smtp-template/template1

2.3.2 Fichiers texte

Le plugin Textmod permet de stocker les alertes remontées dans un fichier texte.
Pour activer ce plugin, il faut retirer les instructions de commentaires sur les lignes suivantes dans le fichier /etc/prelude-manager/prelude-manager.conf en renseignant le fichier de destination:

2.3.3 XML

Le plugin XML permet de stocker les différentes alertes dans un fichier XML.
Ce formatage permet d'exporter facilement les données vers une autre infrastructure et d'assurer ainsi l'interopérabilité de la solution.
Pour activer ce plugin, il suffit de décommenter les lignes suivantes du fichier /etc/prelude-manager/prelude-manager.conf :

3. Points forts

Le grand avantage de cette infrastructure est de permettre l'analyse à distance d'informations sur un serveur de centralisation. Cette concentration d'information est alors accessible à l'ensemble des services Prelude sans avoir à installer d'agent (exception faite de certaines solution nécessitant une conversion des journaux d'événements au format syslog) sur les machines supervisées.

La personne en charge de surveiller l’activité du Système d'Information se voit ainsi attribuer une console de gestion où sont concentrées les informations de sécurité de tous les équipements.

Il est à noter que la possibilité d'empiler les filtres permet d'affiner les recherches et les actions à effectuer sur des scénarios ou des alertes complexes.

De plus, la solution Prelude possède une compatibilité native avec de nombreux équipements du marché et divers systèmes d'exploitation. Il est donc possible de configurer rapidement, comme nous l'avons vu précédemment, les différentes sondes et de déployer l'infrastructure en production. Ceci permet de mutualiser des ressources humaines expertes, rares et coûteuses, nécessaires à la mise en place des solutions de sécurité.

Grâce à cette architecture, nous avons été en mesure d'identifier rapidement les comportements suspects contraires à la politique de sécurité de l'entreprise. Par exemple, nous avons été en mesure d’identifier rapidement le contournement de proxy ou encore le raccordement de deux sous-réseau isolés par défaut.

Cet outil permet de dresser des statistiques sur le nombre d'attaques subies par l'entreprise qui permettront, par exemple, de justifier des demandes d'augmentation de budgets pour améliorer la sécurité du Système d'Information, ou de suivre leurs évolutions dans le temps.

L'utilisation de cette solution donne la possibilité, grâce à l'étude des alertes remontées, de mettre en avant les points du réseau où un durcissement de la sécurité est nécessaire.

4. Points faibles

Les alertes générées par Prelude dépendent totalement des logs fournis par les équipements du réseau.

En effet, seuls les fichiers de logs ou les équipements intégrant la bibliothèque Prelude permettent la remontée d'alertes auprès du manager.

Ainsi, dans le cas où une machine n’envoie plus ces fichiers d'activités, par exemple suite à une compromission, un lien défectueux ou encore une personne interne réalisant une écoute active en filtrant les flux, il n'est plus possible d'obtenir les événements de sécurité.

Il en va de même lorsqu'un éventuel attaquant utilise la fragmentation IP afin de passer inaperçu auprès des sondes réseaux telles que Snort. Si la sonde ne relève pas de trafic suspect alors la solution Prelude non plus.

Un SIEM n'est donc pas une solution miracle permettant de voir toutes les attaques et tous les comportements suspects sur un réseau. Cette infrastructure fonctionne sous une forme pyramidale et repose avant tout sur le bon fonctionnement des sondes qui la composent ainsi que sur les fichiers d'événements propres à chaque équipement.

De plus, au sein de cette solution, les faux positifs peuvent être nombreux. Il est donc nécessaire de posséder un œil critique sur les différentes alertes remontées et de bien configurer les règles afin de ne pas surcharger la base de données ainsi que la personne en charge de l'analyse des événements de sécurité.

Ce genre de situation nécessite un temps de travail quotidien important afin de surveiller les actions journalières, généralement nombreuses, et d'affiner les filtres pour écarter les faux positifs. Il est aussi à noter que chaque alerte nécessite une vérification manuelle par l'administrateur qui est elle aussi consommatrice de ressources humaines et de temps.

En ce qui concerne la mise en place d'une solution SIEM, il faut être conscient que cela prend du temps sur plusieurs niveaux. D'une part, il est nécessaire de définir rigoureusement le périmètre à surveiller ainsi que les ressources qui seront attribuées pour supporter l'infrastructure. Par la suite, il nécessaire de configurer tous les équipements du périmètre afin de centraliser les logs, dans notre cas, sur une machine.

Dans le cadre d'un réseau entre plusieurs datacenters, le temps de mise en place est multiplié par la nécessité d'installer une infrastructure par sous-réseau.

Conclusion

La solution communautaire Prelude permet, à moindre coût, de mettre en place une solution SIEM au sein de son organisation afin d'observer, de quantifier et d'analyser les différents événements de sécurité d'un système d'information.

Après configuration des filtres, il est possible d'identifier les parties du réseau, les systèmes d’exploitation ainsi que les services nécessitant un durcissement de la configuration et de la sécurité.

A moyen terme, les rapports du SIEM permettent de concentrer les efforts sur les points névralgiques du réseau et aussi d'augmenter de manière significative la sécurité du Système d'Information.

Il apparaît donc clairement que l'utilisation d'un SIEM ne permet pas de se prémunir de tous les types d'attaques et que l'application des bonnes pratiques en matière de sécurité reste indispensable. En effet, une architecture SIEM typique ne propose pas de sécurité active et les actions de protections doivent par la suite être apportées manuellement.

Il est important de comprendre que ce genre de solution ne peut pas non plus être implémenté dans de très petites structures et être rentables. En effet, le temps passé à s'occuper des différentes alertes est non négligeable et ne peut être utilisé pour effectuer d'autres actions de maintenance. Il a été nécessaire dans notre cadre d’affecter une personne à temps partiel sur l'analyse des alertes.

Pour information, la solution fût mise en production après trois mois d'étude, de configuration et d'analyse. Une fois en production, un mois et demi supplémentaire a été nécessaire afin d'affiner les résultats et la remonté pertinente d'alerte.

Il est à noter que cette solution, dans sa version communautaire, n'est pas non plus adapté à de grosses structures. En effet, les performances de l'outil diminue proportionnellement au nombre d’événements de sécurité traités et la version communautaire ne profite pas des améliorations apportées par les solutions payantes (Archivage, gestion et indexation des journaux d'événements bruts).

Ainsi, un SIEM peut être utilisé afin de mettre en avant les problèmes de sécurité d'un Système d'Information ,d'appuyer les demandes de moyens en vue d'élever la sécurité mais aussi pour observer l'évolution de cette dernière au fil du temps.

Pour finir, la solution Prelude est bien pensée, facile à prendre en main (indépendamment de l'implémentation générale d'un SIEM) et dispose d'une architecture modulaire permettant de l'adapter à la plupart des infrastructures. On regrettera seulement que certaines fonctionnalités soient devenues payantes après le rachat par C-S.

Remerciements

Nous tenons à remercier Cédric pour sa relecture attentive et minutieuse.

Références

[SITE] http://www.prelude-ids.com/en/products/compare-products/index.html

[RFC] http://www.ietf.org/rfc/rfc4765.txt

[COMPATIBILITES] https://www.prelude-ids.org/wiki/prelude/PreludeCompatibility

[CLES] https://www.prelude-ids.org/wiki/prelude/InstallingAgentRegistration