Qualys

Security CommunityLa communauté des experts sécuritéen savoir plus

SecurityVibesQualys Community

Left content

Petit-Déjeuner SecurityVibes : gérer les événements sécurité

auteur de l'article Jerome Saiz , dans la rubrique Conformité & Bonnes pratiques

Commentaires Commentaires fermés sur Petit-Déjeuner SecurityVibes : gérer les événements sécurité

Le second Petit-Déjeuner SecurityVibes consacré à la gestion des événements sécurité a été l’occasion d’explorer toute la complexité d’un projet de gestion et de corrélation des logs. Mais aussi de découvrir une série de briques Open Source et de bonnes pratiques pour mener à bien une telle aventure sans trop de casse.

Collecter, centraliser, stocker, visualiser, traiter et corréler. Prises séparément, chacune de ces étapes pourrait donner lieu à un projet IT déjà bien garni. Mais un projet de gestion des événements de sécurité devra, lui, les adresser toutes simultanément. Et c’est bien ce travail de chef d’orchestre que Stéphane Omnès, RSSI du groupe Adeo, est venu présenter lors du second Petit-Déjeuner SecurityVibes. Une vingtaine de membres SecurityVibes étaient réunis pour l’occasion dans l’historique Salle de Bal du Macéo , à Paris, devenue le temps d’une matinée le Quartier Général de SecurityVibes.

Stéphane Omnès a mis en oeuvre, alors qu’il travaillait pour Atos, une plate-forme de gestion des événements sécurité basée sur des briques Open Source. Celle-ci s’est révélée en mesure, à partir d’un serveur de puissance tout à fait standard (bi-processeur 2,8ghz avec 1go de RAM dans le meilleur cas) de traiter jusqu’à 4gb de logs par jour sur des volumétries allant jusqu’à 400 machines et équipements à surveiller.

La première étape de la réflexion a été d’identifier les sources d’événements à collecter, et le format de ces derniers. Pour les machines et équipements capables de produire des traces au format syslog (très nombreux, particulièrement sous *nix), le problème de la collecte ne se pose pas car c’est le format étalon choisi pour le projet. Sous Windows, les entrées event log (événements de type System, Security et Application) peuvent être reformatées et renvoyées au format syslog par l’outil libre NT Syslog .

D’autres formats, tels les trap SNMP ou les traces SNARE (une extension noyau Linux générant des traces beaucoup plus granulaires, également disponible pour Windows ) sont également collectés mais doivent faire l’objet d’un développement particulier.

Les événements sont alors envoyés par le réseau, via une connexion UDP, à une série de collecteurs qui peuvent être répartis sur le réseau en fonction des besoins. Ces derniers exploitent Syslog-NG, véritable pierre angulaire du projet. Les collecteurs Syslog-NG récupèrent les événements remontés par les équipements et leur appliquent une série de traitements cruciaux : filtrage, remise en forme, gestion des queues, et si nécessaire traçabilité (horodatage pour la version commerciale).

Une fois traité, le flot d’événements est envoyé à une machine centrale via une connexion TCP, cette fois-ci. Ils seront alors stockés dans une base de données afin de pouvoir être explorés en ligne, et simultanément stockés dans des fichiers à plat sur des disques afin de pouvoir être présentés en cas d’audit ou d’enquête. Ces journaux sont alors hashés (SHA-256) quotidiennement avant la rotation avant d’être archivés.

A ce stade un filtre est appliqué aux événements : Stéphane Omnès préconise de distinguer les événements connus pour lesquels aucune action n’est nécessaire, ceux connus pour lesquels une action est nécessaire, et enfin les événements inconnus. Les premiers sont ignorés, les seconds envoyés au moteur de corrélation pour traitement, et les derniers mis de côté pour une revue manuelle par un administrateur, qui aura alors la tâche de les traiter et de s’assurer qu’ils soient pris en charge automatiquement à l’avenir (via un filtre ou une règle de corrélation).

Bâtir ces listes d’événements à filtrer demandera du temps, et ce ne sera jamais une tâche achevée : il s’agit en fait d’un processus itératif qui doit être suivi au quotidien. Toutefois, pour la mise en route initiale, la « liste blanche » des événements à ignorer peut être bâtie en faisant tourner sur l’ensemble des logs remontés par les collecteurs (sur la machine centrale, donc) une moulinette (sed, awk) qui ne présentera qu’une fois les lignes multiples. Cela permettra d’obtenir un instantané des événements les plus courants.

C’est maintenant que la corrélation peut avoir lieu. Il s’agira, par exemple, d’être en mesure de ne générer une alerte qu’à partir d’un certain nombre d’authentifications ratées dans une fenêtre de temps donnée, et non à chaque échec. C’est bien sûr ici que réside toute l’intelligence de la solution.

Stéphane Omnès a fait le choix pour cela d’un autre outil Libre, Simple Event Correlator (SEC). Bien que développé en Perl, SEC semble largement tenir la charge d’après les observations de Stéphane Omnès. Mais bien qu’il offre déjà des règles par défaut, SEC doit bien entendu être configuré avec les règles propres à l’entreprise, ce qui est presque un projet dans le projet.

Le corrélateur, une fois correctement configuré, pourra alors ne générer que des alertes réellement significatives, à transmettre à l’outil de supervision déjà en place. C’est d’ailleurs l’un des pré-requis de la solution développée par Atos : qu’elle puisse fonctionner avec n’importe quel outil de supervision.

Plusieurs enseignements peuvent être tirés de l’expérience de Stéphane Omnès. Tout d’abord qu’il s’agit d’un projet complexe et « casse figure ». Plusieurs RSSI présents lors de notre petit-déjeuner ont confirmé avoir vécu des expériences bien moins concluantes en la matière. Piste évoquée pour expliquer ces échecs : un périmètre trop important pour les équipes en place, et trop de « tuning » nécessaire au quotidien.

La sécurité de la plate-forme elle-même est à prendre en compte : puisqu’elle centralise des données sensibles, elle devient critique. Plutôt que de perdre du temps sur le chiffrement SSL des flux de logs, il a été jugé plus efficace et plus pragmatique de sécuriser convenablement l’accès à la console d’administration elle-même.

Sur le front de la collecte, si les logs réseau sont relativement standards il n’en n’est pas de même pour les journaux applicatifs. L’extension de la plate-forme à des applicatifs tiers peut alors être compliquée à moins de recourir à des développements propriétaires, et même dans le cadre des développements internes il faudra mettre en place une convention de journalisation avec les développeurs.

Les membres ont enfin également soulevés la question de la déclaration de la plate-forme à la CNIL. Le consensus semble être que si (ou car) la destination de l’outil est de pouvoir tracer des usages et aller jusqu’à la sanction, il est nécessaire de traiter et conserver des données qui peuvent être considérées comme nominatives (adresses IP associées à un login utilisateur, etc). La déclaration à la CNIL s’impose donc.

Consultez la présentation de Stéphane lors du second Petit-Déjeuner SecurityVibes Omnès ci-dessous. Si vous n’avez pu vous joindre à nous pour cet événement, nous serons heureux de vous acceuillir pour la prochaine édition qui aura lieu après l’été.


Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Notez L'article

Participez ou lancez la discussion!

Les commentaires sont fermés.

Catégories

Étiquettes

Archives

Ce site est une archive des messages à SecurityVibes de Septembre 2000 à Juillet 2014. S'il vous plaît visitez le Qualys Community pour les dernières nouvelles.