Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 





















Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Laurent Besset, I-TRACING : SIEM, les pièges à éviter

février 2013 par Laurent Besset, Directeur Senior Associé I-TRACING

Portées par les exigences réglementaires, le contrôle, la sécurité et le maintien en condition opérationnelle des SI, les solutions de SIEM (Security Information and Event Management) font aujourd’hui partie de l’arsenal de toute direction informatique qui se respecte. Force est pourtant de constater que la mise en œuvre et l’exploitation de ces solutions ne sont pas triviales, et que la valeur ajoutée réelle n’est pas toujours à la hauteur des investissements consentis par les entreprises !

Laurent Besset, Directeur Senior Associé chez I-TRACING

Piège numéro 1 : Mal dimensionner son architecture

Une solution SIEM corrèle potentiellement des événements extraits de tous les composants d’un SI, certains pouvant se révéler extrêmement verbeux (firewalls, proxies ou contrôleurs de domaine Active Directory par exemple). La question de la volumétrie est donc essentielle.

Elle se pose à plusieurs niveaux :
 La capacité de collecte, mesurée en nombre d’événements par seconde, avec des entreprises souvent réticentes à généraliser les agents locaux proposés par les éditeurs et permettant de filtrer à la source les seuls événements pertinents pour la corrélation. Les flux de collecte sont donc souvent bien plus importants que ce que requiert la fonction de corrélation ;

 La capacité de stockage, avec des durées de rétention pouvant aller jusqu’à plusieurs années selon les environnements ;

 Les performances de corrélation, avec des valeurs affichées correspondant généralement à une activation des règles natives de la solution, sans compter les règles plus ou moins complexes pouvant être ajoutées par chaque entreprise. Ces dernières peuvent rapidement dégrader les performances.

Piège numéro 2 : Brûler les étapes

La détection en temps réel de comportements informatiques suspicieux nécessite une connaissance poussée des patterns d’attaque, des chaînes de liaison de l’entreprise, des différents équipements générant des logs sur ces chaînes de liaison et du contenu de ces logs.
Le SIEM est donc par essence une solution d’experts requérant une forte maturité des processus internes de sécurité informatique (veille, journalisation, contrôles, etc.).

Piège numéro 3 : L’illusion de la solution clé en main

L’argumentaire commercial des éditeurs met souvent en avant le caractère « clé en main » de leurs produits au travers des connecteurs normalisant les messages des principaux types d’équipement, de packages de rapports prédéfinis et d’alertes pré-paramétrées.
Si ces ressources sont utiles pour démontrer rapidement une certaine valeur ajoutée, elles ne doivent surtout pas conduire à mésestimer le travail de personnalisation propre aux projets de SIEM.
Certains écueils sont fréquents comme se fier aveuglément aux parseurs nativement fournis par les solutions. Il est souvent utile de vérifier qu’ils sont complètement compatibles avec la configuration réelle des sources de logs et traitent bien l’intégralité des événements collectés. Il convient aussi d’éviter d’activer tous les rapports par défaut et de se demander s’ils sont pertinents dans le contexte spécifique du client et si les processus d’analyse et de réaction ont été définis en aval. De même, il est préférable de ne pas activer toutes les alertes de corrélation par défaut. Sont-elles toutes pertinentes ? L’usage montre que c’est rarement le cas, à part pour quelques unes, les plus simples, complètement indépendantes des architectures en place (alertes sur les attaques de type brute force par exemple).

Portrait-robot d’une success story

S’il n’est donc pas simple de réussir son projet SIEM, les entreprises qui y arrivent partagent souvent certains éléments de contexte favorables :
 Une expérience préalable en termes de gestion des logs : mise en place d’une solution de centralisation sur un périmètre technique étendu, indicateurs volumétriques sur les différents logs à collecter, revue régulière des logs pour identifier certains comportements anormaux, mise en place d’alertes en temps réel sur des événements unitaires (connexion au DHCP avec un nom de machine exotique par exemple) ;
 Une architecture dimensionnée avec des marges de sécurité conséquentes et s’appuyant sur des composants techniques permettant d’étendre simplement les capacités de collecte, de stockage ou de corrélation ;
 Un véritable investissement sur des compétences permanentes dédiées à l’exploitation du SIEM : ajout de nouvelles sources, développement de parseurs, création de nouvelles règles de corrélations, ajustement des règles existantes pour suivre l’évolution des chaînes de liaison, gestion des alertes, investigation, etc.
 Une utilisation très progressive des fonctionnalités de corrélation : activation des règles natives correspondant à des scénarii simples (partage d’un même compte depuis deux adresses IP différentes, tentative de brute force sur un compte, bypass de proxy), définition de quelques règles personnalisées plus complexes correspondants à des attaques déjà survenues et analysées après coup.

Le SIEM n’est donc pas voué à rester un gadget coûteux, mais plus qu’à la mise en œuvre d’une « simple » solution technique, il doit donc également donner lieu à une réflexion plus globale autour des processus, des compétences et de l’organisation de la sécurité des SI.


Voir les articles précédents

    

Voir les articles suivants