Prenons, par exemple, deux événements distincts détectés par un pare-feu d’un côté et une solution antivirus de l’autre. Ceux-ci peuvent paraître anodins, mais une fois corrélés, ils présentent les signes d’une tentative d’intrusion. La collecte des logs est donc la brique fondatrice d’un projet SIEM, qu’il convient de prévoir et préparer de manière adéquate.
Le premier piège à éviter est celui de « collecter pour collecter »
Il est trop souvent remarqué, en entreprise, que de nombreuses sources de logs remontent au sein d'un SIEM sans qu’une utilisation ne soit faite de ces données. La bonne question à se poser est donc : « Quels sont les risques cyber dont je veux me prémunir au travers d’un SIEM ? », plutôt que : « Quelles sont mes sources de logs ? ». Des risques, on peut ensuite en établir des scénarios redoutés, les décomposer en cas d’usage de détection, et enfin en déduire les logs à collecter pour détecter ces cas d’usage.L’identification de la méthode de collecte adaptée à chaque source est la prochaine étape. La plupart des solutions de sécurité supportent l’envoi en syslog (protocole de transports de logs défini par le RFC5424) ou d’autres formats plus verbeux comme le CEF (Common Event Format) ou LEEF (Log Event Extended Format). Même s’il était traditionnellement basé sur une couche transport en UDP (sur le port 514), la plupart des implémentations de syslog permettent maintenant d’utiliser une couche TCP, beaucoup plus robuste en raison des valeurs de contrôle qu’elle apporte. Le TCP permet également d’encapsuler le protocole syslog dans une session TLS (Transport Layer Security), permettant ainsi de chiffrer le contenu du paquet syslog. Au vu de la criticité que représentent généralement les logs de sécurité, il est primordial de les chiffrer (avec une authentification TLS mutuelle si possible).
Avec l’avènement des solutions cloud, une nouvelle méthode de collecte est de plus en plus utilisée également, celle passant par des requêtes API (Application Programming Interface). Le principe est d’utiliser des scripts ou bibliothèques de code déjà existantes pour interroger l’API de la solution via des méthodes HTTP GET - afin de récupérer les logs de celles-ci. On remarque rapidement que cette méthode présente plusieurs failles : l’information n’est pas récupérée en temps réel, elle peut nécessiter du développement et, surtout, elle nécessite de stocker des informations d’identification sur l’API (clé API, certificat ou mot de passe) - sur la machine effectuant les appels. Certaines solutions proposent le mécanisme inverse, en effectuant les appels API (sous forme de webhook) depuis la solution qui génère les logs vers un serveur web qui expose une API.
L’architecture de journalisation
Une fois les méthodes de collecte listées, il faut ensuite en déduire l’architecture. En règle générale, au minimum un collecteur de logs intermédiaire sera utilisé. Il peut servir à héberger les scripts interrogeant les API, un serveur web (dans le cas d’utilisation de webhook) et recevoir les envois de logs en syslog. Cette machine devant être en mesure de gérer de nombreux flux en parallèle, la plupart des solutions utilisent des principes de file d’attente pour traiter les différentes arrivées de données - sans perte. Dans certains cas (notamment pour récupérer des logs système), un déploiement d’agents de collecte sur les sources de logs peut être nécessaire. La configuration de ces agents doit être soigneusement étudiée afin d‘assurer qu’elle ne pose pas de problèmes de ressources (on pense notamment à des agents qui utiliseraient une configuration Sysmon trop gourmande).D’un point de vue architectural, la gestion des flux réseau au sein du SI est aussi un vaste sujet. L’envoi de logs depuis un SI tiers (client ou partenaire), par exemple, peut nécessiter la mise en place d’un VPN site-à-site entre les deux SI. Dans le cas où cela n’est pas possible, des redirections d’adresse ou de port (NAT / PAT) peuvent être effectuées, mais ces configurations ne sont pas recommandées.
Concernant la collecte des logs, l’ANSSI conseille de mettre en place un SI dédié à celle-ci, utilisant donc des équipements et interfaces réseaux dédiés. Cette solution n’est cependant pas toujours possible, pour des raisons de complexité d’administration et de coûts.
Mettre ses logs au même format : la normalisation
La dernière étape avant de pouvoir traiter les logs au sein d’un SIEM est de les parser. Cette opération consiste à convertir les logs, des différentes sources, en un seul et même format - afin de pouvoir les corréler de manière plus efficace. Ainsi, un champ correspondant à une adresse IP source sera désigné de la même manière, qu’il provienne d’un log d’EDR (Endpoint Detection & Response) ou d’un log de pare-feu. Un format assez répandu est ECS (Elastic Common Schema), qui a été popularisé par l’éditeur Elastic Search. Cette étape de parsing peut parfois être assez longue, selon la multiplicité du format des logs, et nécessite généralement l’emploi de fonctions REGEX.Les logs sont alors prêts à être traités et agrégés au sein de la solution SIEM. Il est assez courant de les envoyer, parsés ou non, dans une solution d’archivage afin de les conserver pour des besoins juridiques et légaux. En effet, le décret 2021-1363 stipule que toute entité fournissant un accès Internet (comme une entreprise proposant un service de Wifi à ses employés) doit conserver, pendant un an, les logs concernant les connexions de ses utilisateurs. En général, les logs des pare-feu et/ou proxy Internet suffisent à cet usage. L’archivage peut également être utilisé à des fins d’investigation, dans le cas où la solution SIEM ne propose pas de fonctionnalité de stockage de longue durée.
Enfin, il convient de superviser de manière efficace tous les maillons composant la collecte de logs. Cela peut être effectué via le protocole SNMP ou via des agents de surveillance, sur les différentes machines. Une grande importance doit être accordée à d'éventuels délais de traitement ou de collecte (notamment sur le collecteur), car ceux-ci peuvent induire des pertes de logs ou retards de détection au sein du SOC.
Les bonnes pratiques techniques décrites ici ne suffisent pas, à elles seules, à assurer un service de SOC (Security Operation Center) efficace. Elles doivent toujours être accompagnées de moyens organisationnels (procédures de gestion d’incident, d’escalade, documentations) et de moyens humains pour les mettre en œuvre.
Par Pierre Tabary, consultant Sécurité Opérationnelle chez Synetis
