Quelques enjeux pour votre SIEM

Comment concevoir et optimiser la mise place d’infrastructures de type SIEM, dans des environnements relativement complexes ? Hétérogénéité des composants, tailles des infrastructures, limitations sur les moyens humains et financiers, défis technologiques et organisationnels, pressions et menaces internes et externes…

Cet article propose d’aborder la thématique du SIEM, afin d’échanger en toute simplicité sur la mise en place d’infrastructures qui cherchent à combiner les ingrédients de la réussite. De la collecte des logs jusqu’aux alertes réelles, comment réussir votre projet SIEM quand il contient quelques complexités ou spécificités : SCADA, IOT, multiples pays, réseaux immenses, infrastructures hétérogènes et distribuées, soucis de débits, liaisons non résilientes, intrusions existantes et inconnues, risques d’espionnage ou de sabotage internes et externes, visiteurs et menaces internes, problèmes organisationnels, faibles moyens, etc.

Cet article vise à offrir un retour d’expérience d’experts opérationnels, mais il doit aussi conserver une taille raisonnable ; nous prendrons donc la liberté de contourner certains détails ou éléments que le lecteur attentif reconnaitra. L’idée n’est donc pas d’aborder tous les points techniques possibles au monde, mais de partager une vue rapide globale. D’autres façons de penser ou discussions pourraient donc exister en dehors de cet article précisément.

1. Préparer son infrastructure

Lorsque vous composez une infrastructure SIEM, de nombreux défis techniques et humains s’imposent, et les outils seuls ne peuvent répondre à tous les besoins. Bien évidemment, dans le meilleur des mondes (possibles), on pourrait prendre son temps, analyser la totalité de l’infrastructure, ou même avoir des budgets et des équipes illimités.

En réalité, lorsqu’une entité souhaite mettre en place un projet SIEM, nous distinguons en général deux cas un peu extrêmes : ceux qui souhaitent un SIEM pour des raisons quelque part « externes » (risques autour de la GDPR, traçabilité/surveillance à justifier pour des problèmes de conformité, etc.), et ceux qui veulent un SIEM pour des usages « internes » (aspects opérationnels de lutte contre l’espionnage, etc.).

Les deux mondes savent se retrouver, mais les parties prenantes sont parfois distinctes, et le sponsor du projet pourra influencer des choix allant jusqu’à la technique. Après une danse complexe entre les acheteurs, les juristes, les dirigeants, les services IT, les équipes SSI, les prestataires, etc., on peut commencer à mettre en place son infrastructure efficace, en optimisant les coûts. Le but est d’éviter le projet se soldant au final par une gestion de faux positifs liés à des spectres techniques imparfaits. Cette efficience est complexe à trouver, et elle peut nécessiter de sacrifier quelques points grâce à une savante alchimie allant du management à la technique.

En guise d’exemples introductifs, voici des questions qui reviennent souvent sur ces aspects : à quoi bon collecter et stocker toutes les alertes de type SYSLOG qui proviennent :

  • De switches réseaux avec de nombreuses traces inutiles indiquant que l’interface lambda est up ou down ?
    • D’équipements qui n’ont même pas de traces utilisables pour de la cybersécurité (une borne wifi qui ne partage pas d’infos techniques utiles par exemple) ?

Ces deux questions sont assez anodines ou simples, mais c’est exactement le problème de certains projets SIEM : il faut savoir arbitrer, car le projet trop maximaliste pourrait s’éloigner de la réalité opérationnelle. On pourrait vouloir tout conserver, sans regarder le contenu, mais l’entreprise risquerait d’avoir besoin d’une base de stockage potentiellement coûteuse avec une utilité à prouver. Au-delà de ce sujet, ce qu’on illustre ici, c’est l’art du consensus : dans un projet SIEM réussi, on doit rassembler les différentes parties prenantes, avec des experts capables d’honorer et de comprendre les besoins de chacun et du groupe, afin de trouver les plus grands dénominateurs communs offrant la plus large assise de compromis, sur tous les paramètres. Petits exemples :

  • Les financiers et les dirigeants surveilleront avec justesse les dépenses voire les discours commerciaux ;
    • Les admins surveilleront l’arrivée d’agents ou de traces dans leurs systèmes, avec la crainte de performances amoindries ou de surplus inutile de travail et de reconfigurations ;
    • Les développeurs voudront utiliser le SIEM pour faire autre chose que de la sécurité comme du debug ou une « télémétrie propre » ;
    • Les admins réseaux craindront de voir les bandes passantes occupées par des flux nouveaux ou difficilement calculables à l’avance ;
    • Les employés seront rencontrés pour justifier la mise en place d’une traçabilité positive qui n’est pas là pour surveiller ce qu’il font, mais qui peut générer des craintes de dérives sur la surveillance ;
    • Les équipes de sécurité espéreront avoir enfin une vision sur leur parc…

C’est évidemment un art complexe, où le responsable trouvera intéressant de s’entourer de personnes efficaces, humainement respectueuses et positives, en prévision des situations où les rouages historiques et les problèmes culturels (aspects internationaux) peuvent ralentir le projet.

2. Collecter les logs​

Unifier les traces

Lorsque l’on souhaite collecter des logs, le premier problème qui peut exister, c’est la multiplicité des types de composants d’une infrastructure. Ils sont parfois tellement différents, qu’ils vont générer des traces (logs, événements) a priori incompatibles. Certains pionniers ont lancé des pistes pour tenter de les traiter de manière homogène.

Nous citerons déjà l’exemple d’une norme, même si elle est peu adoptée ou connue au niveau des outils commerciaux les plus déployés dans le monde. Elle s’appelle IDMEF, Intrusion Detection Message Exchange Format (RFC 4765, 4766 et 4767) et vise à formater l’ensemble des traces de manière unifiée afin d’optimiser échanges et analyses.

Dans la pratique, quand on a des moyens limités, et qu’on ne veut pas consommer du CPU pour trop retransformer ses propres messages bruts, on essaiera de travailler directement avec ces derniers, sans passer à une grande normalisation spécifique. Donc si vous n’aimez pas certains aspects de XML, vous pourriez ne pas apprécier l’enrichissement et le traitement natif de IDMEF.

Au-delà, que trouvons-nous réellement au niveau des formats propriétaires ? On citera les deux standards du marché : LEEF avec le produit IBM Qradar et CEF avec le produit HP ArcSight. Le lecteur consciencieux pourra étudier les autres formats ouverts (MITRE, DMTF), mais aussi se porter sur des analyses expertes associées, exemple : [FORMATS].

De manière générale, soyez rassurés, tous les produits SIEM vont de toute façon rassembler les traces intéressantes, dans leur format, afin de vous permettre de travailler dessus, que ce soit sur des types connus ou internes, le tout pour vous apporter la meilleure vitesse de traitement, et le meilleur stockage possible.

Les formats classiques

Supposons que l’on souhaite traiter des logs qui viennent de marques et outils différents : des serveurs, des stations, des routeurs, des switches, des access points, des points d’authentification, des proxies, des antivirus, des produits dans le Cloud… Comment récupérer ces traces et faire un travail efficace ?

En pratique, les solutions SIEM sont en général compatibles avec tous les formats classiques à supporter pour couvrir la plupart des parcs sans risque. En fonction de ses besoins, on s’intéressera donc à la compatibilité d’un SIEM avec des formats et des méthodes de récupérations de logs comme par exemple :

    • Le syslog, car il est majoritairement supporté par presque tous les produits : l’ancien format BSD (RFC 3164) et le format actuel de l’IETF (RFC 5424, 5425 et 5426) ;
    • Les événements de type Windows, si ce système d’exploitation est présent (les classiques événements systèmes/applications/sécurité, etc., mais aussi ceux des applications propriétaires intéressantes comme les logs du DNS voire du DHCP, etc.) ;
    • Les grands standards comme le W3C (Web), le JSON, le XML, le CSV, le traitement des formats de type Clef-Valeur où l’on appréciera le jeu sur les délimiteurs ou les échappements surtout quand on s’installe dans des environnements où n’importe quel type de traces est possible : UCS*, UTF*, etc. ;
    • La lecture de lignes à lignes (logs de nombreuses applications) ou parfois la lecture de multilignes, souvent pratique pour gérer du propriétaire voire de l’inconnu ou du spécifique ;
    • La possibilité de faire du SQL pour aller taper dans des bases ;
    • La possibilité de récupérer des fichiers de traces à distance (FTP (?), SSH/SCP/SFTP, GET/POST…) pour leur traitement et incorporation ;
    • Les formats propriétaires vus précédemment comme CEF et LEEF.

D’autres formats

Moins utilisés dans les projets de SIEM faciles, mais parfois présents dans certaines expressions de besoins, on notera la présence de nombreux formats particuliers qui peuvent exister. Sans pouvoir tous les citer, on indiquera en exemple :

  • Les logs de IBM AIX pour la partie audit (événements du kernel) ;
  • Les logs de Apple avec son format de fichiers Apple System Log (ASL) ;
  • Les logs des systèmes SUN pour la partie Basic Security Module utilisée au niveau des audits ;
  • Le GELF (Graylog Extended Log Format) qui se fait une place en cas d’adoption de Graylog, et de même le GROK lors de l’usage de Logstash ;
  • Le Netflow qui commence à se faire aussi une place dans certaines infrastructures de type SIEM, afin de mélanger les aspects réseaux pour répondre par exemple à la question : qui a parlé à qui, quand, combien de temps, avec quoi comme « flags » sur la session et quel protocole, ainsi que le nombre et la taille des paquets ;
  • Les traps SNMP, qui sont très utilisées dans le milieu de la supervision ;
  • Les logs compliqués issus du monde du Mainframe, toujours très présents dans certains milieux professionnels.

Enfin désormais, de nombreux logs sont mis à disposition dans le Cloud, mais il faut aller les récupérer régulièrement, avec des formats totalement propriétaires, parfois inconsistants. Si une entreprise a une stratégie, par exemple de messagerie et travail collaboratif totalement sous-traité chez un grand constructeur (étranger) qui est leader au niveau mondial, il est fortement conseillé d’aller au moins enregistrer régulièrement les traces de connexions aux boîtes aux lettres, aux répertoires de partage, etc. On sera surpris (ou pas) de se rendre compte que la boîte d’un admin du domaine, ou du PDG, est régulièrement lue la nuit depuis des adresses IP à plusieurs milliers de kilomètres de ces personnes.

Avec ou sans agent

On sera particulièrement sensible à différentes méthodes pour récupérer les traces à distance sur de multiples sources de données. On citera plusieurs méthodes :

  • En mode « agent-less » : vous n’aurez pas besoin de mettre un agent sur la machine qui doit envoyer ses sources, et vous devrez en général juste reconfigurer la source pour qu’elle parle à votre SIEM. Le cas classique, c’est le SYSLOG, où vous allez indiquer à une source vers quelle adresse IP elle doit parler ;
  • En mode « agent » : vous devez installer un outil de plus, qui aura pour mission sur la source de récupérer les traces et de les envoyer vers votre SIEM.

Sur certains systèmes d’exploitation, la version native agent-less par exemple avec SYSLOG ne vous conviendra pas, parce que vous avez besoin de renvoyer vos logs d’une façon particulière non supportée nativement, par exemple avec une couche de chiffrement type TLS non proposée par le produit.

Dans ce cas, vous aurez besoin de trouver un agent supporté sur cette plateforme, et c’est lui qui devra assumer l’émission des traces. Cela rajoute un processus non natif à déployer, qu’il faudra alors superviser : sa présence, sa consommation de ressources en local, etc. Certains n’aimeront pas ajouter des processus dans une infrastructure de production existante, et l’on comprendra alors que le mode « agent-less » demeure le plus natif et le plus simple, même s’il n’a peut-être pas certaines fonctionnalités d’un agent.

Risques sur les limites

Dans les projets SIEM, il peut y avoir une forte dimension économique, notamment sur ce sujet complexe de la récupération des traces. Sans rentrer dans les détails, on citera dans les risques à maitriser :

  • Le problème de la limite sur le nombre d’événements par seconde (EPS) captés par un SIEM : pouvez-vous accepter le risque de