SIEM : le kit de survie

Des solutions de gestion des informations et des événements de sécurité (Security Information and Event Management, SIEM) sont aujourd’hui déployées dans la plupart des entreprises. Si le sujet pourrait être vu comme mature, force est de constater que, dans bien des cas, l’intégration de ces systèmes s’avère difficile, et leur valeur ajoutée réelle reste parfois limitée. 

Quelques réflexes simples peuvent néanmoins prévenir les pires écueils. Et cela commence par ne pas négliger la collecte. Les logs sont l’essence faisant tourner le moteur du SIEM. Il est donc primordial de s’assurer de leur qualité et de leur exhaustivité. Cela suppose quelques précautions de bon sens :

• définir en amont des standards de configuration garantissant un niveau d’audit suffisant pour alimenter les principaux scénarii et règles de détection ;
• les déployer de manière homogène sur l’ensemble du parc ;
• s’assurer de la robustesse de la chaîne de collecte lorsque le SIEM est considéré comme un service critique (redondance des collecteurs, répartition de charge, supervision, etc.).

Cette approche simple peut s’accompagner d’une réflexion plus poussée en termes d’urbanisation. Les couches de collecte sont de ce point de vue des composants distincts de ceux dédiés à l’analyse et à la corrélation, et une approche découplée présente de nombreux avantages :

• possibilité de s’appuyer sur des solutions open-source ou moins coûteuses que le SIEM ;
• capacité de filtrage permettant de limiter le coût des licences SIEM utilisées en aval ;
• capacité d’aiguillage des logs collectés vers d’autres consommateurs (par exemple une architecture Big Data) ;
• meilleur levier vis-à-vis du fournisseur de services de sécurité managés (MSSP) dans une situation d’externalisation avec une réversibilité se résumant à un changement de destination des logs, en ce qui concerne le SIEM.

Mais il ne faut pas, non plus, négliger le post-traitement des logs. Natives ou personnalisées, les règles de corrélation qui font tout l’intérêt du SIEM ne fonctionnent que si les logs collectés sont compris par l’outil. Ceci suppose à la fois un travail sur leur structure (pour isoler et indexer, si besoin, les informations pertinentes : adresse IP source, utilisateur, etc.) et un travail sémantique (que signifie chaque événement : une authentification manquée, un fichier mis en quarantaine, etc.).

Les solutions SIEM sont bien sûr livrées avec des bibliothèques extensives de parseurs et connecteurs correspondant aux principales sources du marché. Mais l’effort complémentaire à fournir reste important et s’avère largement sous-estimé :

• prise en charge de la langue dans certains logs (par exemple, les événements Windows) ;
• impact de l’ordre des champs lorsque celui-ci est complètement configurable (cas de certains proxies, notamment) ;
• impact des concentrateurs en amont (quelle IP source sera vue par le SIEM, celle de la source ou celle du concentrateur syslog ?) ;
• prise en compte des sources exotiques ou des dernières versions d’équipement (le temps que l’éditeur du SIEM livre les évolutions correspondantes).

En concrétisant le passage symbolique du I au E de SIEM, un post-traitement efficace des logs maximise largement le retour sur investissement de la solution. Mais il ne faut pas non plus négliger l’intelligence humaine : au-delà d’une logique technique et sur les besoins, l’acquisition d’un outil est souvent aussi portée par une dynamique marketing et commerciale mettant plus en valeur les points forts que les défauts des solutions. Il est de bon ton pour l’éditeur d’insister sur le caractère « clé en main » de sa solution, et pour le client de le croire au moment de remplir sa grille CAPEX/OPEX.

Cette lune de miel passée, les entreprises sont ramenées à une réalité voulant que l’intelligence reste plus derrière l’écran que dans la boîte :

• paramétrage de règles de détection personnalisées, avec prise en compte des chaînes de liaison de l’entreprise, des attaques et incidents déjà survenus et analysés, et lien avec les activités de veille et d’analyse des risques en amont ;
• enrichissement des logs avec les données issues des référentiels d’entreprise ;
• analyse ouverte des logs en complément des alertes déclenchées, i.e. avec un œil d’expert tentant de déceler des patterns anormaux dans des rapports sur les logs.

Les SIEM restent intrinsèquement assez simples à déployer et les jeux de rapports et d’alertes natifs proposés par les éditeurs ont l’énorme avantage d’éviter tout effet tunnel en démontrant une valeur ajoutée à très court terme (dès l’arrivée du premier log potentiellement). Ce constat ne doit pas en masquer un autre : les projets les plus réussis à terme sont toujours ceux où la démarche technique est doublée d’un travail sur l’organisation, les processus, et la gestion des compétences requises pour exploiter la solution.

Le SIEM est un excellent outil dès lors qu’il est entre les mains d’un bon analyste, mais il ne reste in fine qu’un outil.