L'analyse de logs, partie intégrante de la politique de sécurité

Peu de projets d'analyse de logs sont menés aujourd'hui en France. Il existe deux façons de l'aborder : l'archivage des logs d'une part, leur exploitation d'autre part.

Il est étonnant de constater actuellement le peu de projets, en cours ou réalisés, d'analyse de logs, en France. Or, le besoin de centraliser et de conserver, voire d'analyser les « fichiers journaux » autrement appelés logs, fait dorénavant partie intégrante de la politique de sécurité de l'entreprise.

Cela pose souvent question au DSI. Doit-on obligatoirement mettre en place une politique d'analyse de logs pour être en conformité avec les lois financières et juridiques ? Est-ce vital pour la sécurité ? Pour la conformité ? Pour la gouvernance ?

Tout d'abord, il convient de distinguer deux approches, qui n'ont ni les mêmes implications ni les mêmes finalités : l'archivage des logs, d'une part, et leur exploitation d'autre part.

D'un point de vue législatif, les textes ne sont pas simples à appréhender. La Loi de Sécurité Financière (LSF -2003) n'oblige pas à leur archivage. En revanche, la Loi dite Sarkozy, entrée en application en 2006, pose l'obligation d'archiver les logs de connexion.

C'est un point de départ. En effet, si toute entreprise doit pouvoir fournir ses logs, sur simple demande ou sur injonction, il n'est pas forcément indispensable d'initier un projet dans ce sens. Dans certains cas, la mise en place de « scripts » ou la collecte manuelle des logs suffisent à être en conformité avec ces règles juridiques.

Ce qui est primordial, c'est que l'entreprise soit en mesure de démontrer qu'elle a, au minimum, mis en place les outils nécessaires à cet archivage, en cas de contrôle, mais également en cas de problème. En l'absence de ce préalable, sa responsabilité pénale peut-être engagée.

Un employé qui consulte, par l'intermédiaire de son poste de travail, des sites interdits par les lois françaises, demeure sous la responsabilité de l'entité qui lui a fourni la possibilité d'accéder à ceux-ci, c'est-à-dire l'entreprise qui l'emploie ou qui l'héberge.

Attention toutefois à la forme. Le contrôle des connexions via l'archivage des logs peut entraîner l'invocation d'atteinte à la vie privée dans certains litiges. La meilleure façon de se prémunir pour l'employeur est de diffuser une charte d'utilisation d'Internet et de prévenir ses collaborateurs que les connexions pourront être contrôlées. De même, cette charte peut établir les limites de l'utilisation d'Internet (horaires, types de sites etc.).

Pour se conformer aux aspects légaux, l'entreprise n'est donc pas obligée de mettre en place un projet de grande envergure. Si elle le souhaite, la question utile qu'elle devra en revanche se poser sera plutôt liée à la finalité d'un tel projet : est-ce que je souhaite « seulement » archiver les logs ou est-ce que je souhaite également les exploiter ?

Les deux approches sont différentes. Les logs permettent de voir beaucoup de choses, des connexions à Internet, jusqu'au contrôle des lecteurs de pointage ou d'accès de l'entreprise, mais peuvent représenter des volumétries très importantes (plusieurs giga voir dizaine de giga octets par jour). La DSI, en accord avec la Direction Générale, devra donc définir avec précision les informations recherchées et ce dans quel but, sous peine de se trouver noyée sous un flux qu'elle ne pourrait traiter et qui s'avèrerait donc inutile.

Sur un plan pratique, ces deux objectifs distincts pourraient être :

-          La mise en conformité, donc l'archivage des logs uniquement

-          L'optimisation de la sécurité du SI, donc l'exploitation des logs collectés.

Ces projets, pour être efficaces, doivent s'inscrire dans la durée, évoluer selon les besoins de la société et surtout dans un périmètre « raisonnable » en commençant, par exemple, par la sécurité d'infrastructure (firewall, sonde, proxy, serveur de messagerie, antivirus, filtrage, antispam, ...).

Il est primordial d'étudier d'abord le comportement général de son activité en terme de sécurité, afin de déterminer des seuils qui permettront la mise en place d'une politique d'alerting.

Dans le cas contraire, l'administrateur risque de recevoir de multiples alertes quotidiennes dont il ne pourra extraire aucune information pertinente. Mieux vaut étudier pendant un temps donné les rapports et statistiques sur les logs, puis définir les niveaux d'alerte et les seuils de déclenchement.

L'analyse de logs peut également s'inscrire dans une démarche ponctuelle d'enquête, lorsque le suivi régulier des logs est établi. Par exemple après une attaque informatique ou physique (tentative d'effraction, vol, ...) l'exploitation des logs collectés peut fournir des indications précieuses.

Le besoin de mise en place de tableaux de bord, permettant la vérification et le contrôle du niveau de sécurité, tant au niveau fonctionnel qu'au niveau organisationnel, peut également recourir à l'analyse de logs. Le tableau de bord de sécurité ainsi créé donnera des indicateurs sur le niveau de qualité de la politique mise en oeuvre. Les logs font partie de ces indicateurs.

Pour terminer, s'il n'existe pas aujourd'hui, d'outils d'analyse de logs universels, il est cependant possible de répondre à la globalité des besoins, en les intégrant. Chaque projet étant différent, il est nécessaire pour les entreprises de définir comme préalable : le but recherché, le temps souhaité pour l'atteindre, et les ressources humaines et financières à allouer.