Guide Logpoint : Qu’est-ce que la gestion de logs et pourquoi est-elle si importante ?

Par Nils Krumrey, Global Customer Success Manager, Logpoint

Lorsque les clients nous parlent, l’exigence qui figure en première position sur leur liste est souvent la « gestion de logs ». Cette tâche semble assez simple, mais si vous ne voulez pas vous limiter à cocher uniquement des cases, vous devez alors sans hésiter vous plonger dans ce que signifie véritablement la gestion de logs.  

Logpoint Converged SIEM collecte les données de log des systèmes endpoint, qui sont des appareils et des applications au niveau de l’ensemble de l’infrastructure IT. Ces logs sont ensuite transformés en données de haute qualité grâce à la normalisation et aux corrélations. Ensuite, la solution identifie et envoie automatiquement des alertes sur les incidents et les anomalies à l’aide d’algorithmes d’apprentissage automatique (ML).

La journalisation est l’enregistrement d’un événement. Tout type de donnée temporelle concernant un événement (comme par exemple les séquences d’événements ou les données de log Web) est un log. Traditionnellement, nous considérons les logs comme des fichiers texte longs et compliqués, mais les logs actuels peuvent provenir de pratiquement n’importe où, sous n’importe quelle forme. Un antivirus qui garde une trace des événements de mise à jour du client dans sa base de données ? C’est un log. Des données de flux réseau à partir d’un Cloud privé virtuel (Virtual Private Cloud) dans AWS, il s’agit également d’un log. Et bien sûr, vous avez tous les grands classiques comme les logs d’événements Windows, les logs de serveur Web, les logs d’accès aux fichiers.

Si nous avons des logs, pourquoi doivent-ils être gérés ? Le terme « gestion de logs » est apparu à une époque où les logs étaient principalement des fichiers texte et où les administrateurs luttaient pour conserver de l’espace disque, et log99 est donc passé à log00. C’est à ce moment-là que les logs ont dû être « gérés à distance » afin que le système source puisse respirer à nouveau.

Alors que les fichiers texte ont fait place à Syslog, aux API et aux bases de données, l’exemple simple de log00 reste le point de départ de la gestion de logs. Aujourd’hui, l’objectif poursuivi n’est plus l’espace disque mais plutôt la garantie de capturer les logs avant qu’ils ne disparaissent. Il est surprenant de voir combien de systèmes écrasent encore leurs logs et à quelle vitesse ils le font d’ailleurs. Souvent, les logs n’existent que pendant 24h ou moins avant d’être écrasés et de disparaître. Si nous voulons donner un sens à ces données de log plus tard, nous devons nous assurer qu’elles soient bien collectées et non perdues.

Nous avons déterminé ce qu’était un message de log et pourquoi il devait être capturé, mais comment faire en sorte que cela fonctionne dans la pratique ?

Tout d’abord, le message de log doit être collecté. Il doit être récupéré ou bien un mécanisme doit nous le faire parvenir. La collecte de logs peut être réalisée pour les fichiers log authentiques en se connectant à un système et en les récupérant à l’aide de SCP ou SFTP.

Le système source peut, sinon, être configuré pour envoyer régulièrement les logs via le serveur FTP intégré de la solution concernée. Outre les fichiers, il peut s’agir de données Syslog (plutôt répandues pour les périphériques réseau) ou de traps SNMP. Dans l’univers Windows, il peut s’agir d’un agent, d’un Windows Event Forwarding Collector ou bien de WMI. Il pourrait aussi s’agir d’ODBC pour les bases de données, de l’API de gestion Office 365, de celle de Defender Alert ou d’EventHubs, ou encore d’un compartiment S3.  

Les méthodes de collecte de logs sont en effet infinies. Mais il est essentiel que la solution de gestion de logs prenne en charge les plateformes et les techniques que vous utilisez pour générer des données de log pour vous éviter de créer des angles morts.

L’une des raisons principales qui justifie la collecte des logs est de pouvoir s’assurer qu’ils se trouvent dans un endroit sûr et accessible rapidement. Il est inutile d’avoir des fichiers de log à plusieurs endroits où ils ne pourront vous être d’aucune utilité. Vous devez savoir où ils se trouvent et comment y accéder à tout moment. L’agrégation centralisée des logs est donc un moyen rapide d’obtenir concrètement de la valeur.

Vous devez être en mesure de déployer une solution de manière efficace, de préférence sans coûts additionnels, dans des environnements distribués. Par exemple, un site distant peut produire un nombre surprenant de messages de log qui satureraient la liaison WAN. Sur d’autres plateformes Cloud, la sortie et l’entrée des logs peuvent entraîner des coûts exorbitants. Dans de tels scénarios, il peut être vital d’avoir ses logs stockés localement ou bien de les conserver dans le Cloud, tout en pouvant les parcourir à distance à partir d’une Search Head centrale. Le Converged SIEM est suffisamment flexible pour s’adapter à vos besoins et à votre environnement.

Une décision que chaque client doit prendre concerne la durée de stockage des messages de log. Il faut prendre en compte, ici, un certain nombre de paramètres :

• Conformité : existe-t-il des raisons réglementaires pour lesquelles les messages de log doivent être conservés ou supprimés ? Les réglementations PCI, GDPR et les politiques d’entreprise entrent en jeu ici, à la fois pour les données qui doivent être conservées et celles qui doivent être supprimées. La définition de politiques de conservation granulaires est bénéfique. Peut-être que des messages de log spécifiques contenant certaines informations personnellement identifiables (Personally Identifiable Information) devraient être conservées pendant une durée plus courte, ou bien certains de leurs champs devraient être chiffrés.
• Besoins opérationnels : existe-t-il certains cas d’usage où avoir un message de log serait bénéfique après coup ? Par exemple, combien de temps après qu’une activité a eu lieu, une atteinte aux droits d’auteur peut être formulée par un tiers, raisonnablement ou légalement, à l’encontre d’un étudiant ayant téléchargé des films illégalement sur le réseau universitaire ?
• Volumes et coûts des logs : les messages de log occupent de l’espace disque et celui-ci coûte de l’argent. Certains fournisseurs facturent même la quantité de données stockées à l’aide de leurs outils. Cette pratique entraîne un coût spécifique pour chaque jour où les messages de log sont stockés et conservés. En fin de compte, il existe un moment où le coût de la conservation prolongée des logs stockés dépasse la valeur qu’ils pourraient réellement offrir. Ainsi, passé un tel délai, ils devraient probablement être supprimés.

Concernant le stockage des logs eux-mêmes, il existe différentes manières de l’aborder. Certains services Cloud et managés incluent tous les coûts de stockage dans un tarif d’abonnement. Cependant, une conservation supplémentaire a tendance à être coûteuse. De plus, il y a peu de contrôle sur ce qui est stocké, où et pendant combien de temps, les données n’étant plus véritablement dans les mains du client.

Avec d’autres solutions, les données appartiennent aux clients qui déploient ses propres niveaux de stockage. Selon l’architecture, le système peut déplacer automatiquement les données plus anciennes vers un niveau de stockage plus lent (comme un NAS à disque plus lent plutôt qu’un DAS/SAN et SSD). Certains fournisseurs envoient des données de log à un niveau hors ligne ou de type « archive », nécessitant ainsi un processus de restauration lent si les données de log sont réellement nécessaires.

Comme d’habitude, une solution flexible donne plus de contrôle sur la conservation des logs et les coûts. Le maintien de la propriété des données, le stockage de différents messages de log pendant différentes durées, la protection des données sensibles tout en pouvant les parcourir et la gestion automatique des niveaux de stockage par la solution devraient éliminer la plupart des défis que représentent une solution de gestion de logs inflexible.

Alors, où en sommes-nous ? Nous avons collecté des logs et nous nous sommes assurés qu’ils étaient bien stockés de manière centralisée et pour une durée adaptée. Mais, après tout ce travail, il est certainement logique de les utiliser dans un but bien précis !

C’est là que la simple gestion de logs est liée à la solution Converged SIEM (Security Information and Event Management). Alors que la sécurité est un centre d’intérêt majeur, avec une solution SIEM, tout événement au niveau d’un fichier de log peut être trouvé, faire l’objet d’une alerte et enfin être visualisé via des tableaux de bord et des rapports.

Ainsi, la collecte et le stockage des logs constituent une première étape importante. Parfois, la collecte et le stockage des logs suffisent pour répondre à certaines exigences en matière de conformité. Cependant, la véritable valeur ajoutée commence vraiment à émerger grâce à tout ce que les logs vous permettent de faire par la suite. Par exemple, l’analyse des logs.

Avec Converged SIEM, vous avez accès à toute la puissance des logs. Tous les messages de log sont immédiatement disponibles de manière centralisée. Cela signifie que vous saurez toujours où intervenir. Peu importe s’il s’agit de problèmes de connectivité réseau, d’alertes en provenance d’un scanner de virus, d’utilisateurs qui ne cessent d’être verrouillés. Il peut aussi s’agir de toutes sortes d’autres cas de figure qui auraient probablement nécessité une recherche manuelle dans les fichiers de log difficiles à consulter au sein d’une multitude de systèmes, en partant bien sûr du principe que ces derniers soient toujours disponibles.

Pour des fonctionnalités encore plus avancées qui vont au-delà des outils de gestion de logs, assurez-vous de consulter certains des autres articles sur le site Logpoint !