Regards sur la partie loggée de l'iceberg

Quitte à apporter un vent froid chez certains, quelques jours après le passage à l'été, analysons les enjeux et les besoins d'une stratégie de supervision des logs.

"Que faisiez-vous dans la nuit du 30 septembre au 1er avril ?" demande l'inspecteur de police à l'administrateur système inuit pétrifié.

"Si vous me le permettez, je dirai que vous pointez là du doigt seulement la partie immergée de l'iceberg !" lui répondit l'administrateur.

Regards sur l'iceberg

La gestion des logs au sein d'une infrastructure informatique est avant tout fortement liée à la vision que nous nous en faisons. Pour reprendre l'analogie qu'ont employé deux collègues récemment (merci Eric & Stéphane), l'observateur aguerri devrait apercevoir ceci :

• Au premier étage, bien en vue de tous, un joli système de supervision
• Plus bas sur la couche de glace, à peine visible, un système de rémédiation
• Au fond de l'océan enfin, un merveilleux système de communication

Pourquoi cette glace aux 3 parfums ?

Les trois couches vues à l'instant correspondent aux besoins bien réels et contemporains associés à la gestion des logs :

1. Supervision: inutile de mettre en oeuvre une infrastructure de collecte des logs sur vos systèmes (serveurs et/ou réseaux) si vous n'êtes pas en mesure de les superviser. Ceci a pour effet immédiat de vous pencher sur la question des solutions logicielles adéquates, car à partir d'un certain volume, il devient difficile à un opérateur de calculer rapidement que "l'adresse IP a.b.c.d a tenté 1396 fois de se connecter en ssh au compte root de la machine w.x.y.z durant les 3 dernières minutes".

2. Rémédiation: une fois les informations collectées et pré-analysées, un mécanisme analyse-action serait le bienvenu mais rien ne pourra se faire sans l'apport notable de ressources humaines dans votre équipe. Le système a repéré que quelqu'un essayait de se connecter en SSH au compte root du système le plus critique de votre infrastructure ? Très bien, quelle action entreprendre à présent ? Il est fort probable que vous souhaitiez qu'un "humain" réponde à cette question, afin de ne pas voir votre dernier système automatisé se faire blacklister automatiquement sous prétexte que le mauvais mot de passe a été configuré.

3. Communication: vous avez dépensé des fortunes pour vous équiper des firewalls, IDS, IPS dernières génération malgré leur prix élevés. A présent, vous souhaitez sans doute obtenir un minimum de retour sur investissement : au mieux un arrêt notable des intrusions sur vos systèmes, au pire un joli tableau de bord, en couleur et en 3D, qui vous réconforte chaque jour sur vos choix et vous permet d'aborder le comité technique suivant avec un sourire ravageur. Déchantez immédiatement, le module "Reporting" n'était pas inclus et vous découvrez que tout ceci nécessite une bonne dose de processus à mettre en place.

La chaine du froid

Vous l'aurez compris, 3 étapes ne suffiront pas à mettre en oeuvre une gestion complète des vos logs, car bien des éléments sont susceptibles de modifier vos coûts matériels et humains :

Sans rentrer dans le détail de chaque brique, vous trouverez ici quelques étapes importantes à mettre en oeuvre pour la gestion de vos logs:

• Journalisation : si vos composants (matériels, logiciels) ne stocke rien, la chaine se brise dès le premier maillon. Inutile de préciser que si rien n'est loggé, l'objectif de gestion est immédiatement atteint.
• Collecte : un tri et un étiquetage des logs originaux est nécessaire pour pouvoir identifier la source de ces derniers (nom du composant ou du sous-composant, ...).
• Centralisation : l'étape primordiale d'un point de vue sécurité consiste à externaliser en un point unique tous vos logs (si vous ne souhaitez pas lire des pages blanches après attaque).
• Archivage: certaines autorités obligent, sous certaines conditions, les professionnels à stocker les activités de leurs services informatiques. De même l'analyse d'une attaque vous demandera peut-être de fouiller dans les logs d'il y a 6 mois.
• Restitution: inutile d'inonder votre équipe de supervision sécurité avec un ensemble d'informations redondantes ou sans réel apport pour leur activité (les logs concernant le changement de résolution d'écran d'un utilisateur est rarement analysé).
• Corrélation: c'est une étape que nous avons abordé plus haut. Un système permettant de calculer en temps-réel les occurences d'apparition de certains logs (rappelez-vous les 1396 tentatives en 3 minutes) vous simplifiera grandement la vie.
• Analyse: voir également plus haut, c'est à cette étape que votre retour sur investissement sera le plus important car votre capacité à prendre une décision en fonction des informations en votre possession est capital.
• Reporting: que vous soyez RSSI ou pas, la consultation des indicateurs de sécurité sera grandement améliorée si vous mettez en oeuvre un reporting régulier et pertinent sur les étapes précédemment décrites.

Questions au marchand d'iceberg

Vous vous sentez à présent prêts à lancer un projet de gestion de logs pour votre infrastructure ? Voici quelques questions à se poser pour quelques-uns des étapes abordées :

Journalisation

• Disposons-nous de services NTP pour l'horodatage de nos logs ?
• Chaque log comporte-il bien le nom du composant émetteur ?
• Chaque log comporte-il bien l’adresse IP du composant émetteur ?
• Chaque log est-il bien caractérisé par une notion de priorité (info, warning, debug, ...) ?

Collecte

• Nos fichiers de logs sont-ils archivés quotidiennement et compressés ?
• Nos fichiers de logs sont-ils conservés sur une période de X jours glissants ?
• Disposons-nous d'un système d'émission de logs en temps-réel (ex: syslog) ?
• Disposons-nous d'un système d'émission de logs en différé (pour les logs Windows par ex) ?
• Avons-nous mis en place un mécanisme de supervision des envois de logs ?
• Avons-nous mis en place un mécanisme de supervision des espaces disques utilisés pour les logs ?

Centralisation

• Quelle est l'estimation de la volumétrie journalière de logs ?
• Le système de centralisation est-il accessible via une adresse DNS ou IP ?
• Le système de centralisation offre-t-il un mécanisme de répartition de charge ?
• Quel est le protocole utilisé par le système de centralisation (syslog, port UDP 1514 par ex) ?

Archivage

• Les logs centralisés sont-ils archivés quotidiennement et compressés ?
• Les logs centralisés sont-ils conservés sur une période de N mois glissants ?
• Les logs centralisés sont-ils stockés dans une arborescence unique ?
• Quels sont les niveaux d'arborescence mise en place pour les logs centralisés ?

Conclusion

En espérant avoir pu vous aiguiller dans votre réflexion sur le sujet, je vous conseille pour aller plus loin la lecture du document "Guide to Computer Security Log Management" publié par le NIST (National Institute of Standards and Technology).