Logging & Monitoring : définitions et bonnes pratiques

vaadata.com/blog/fr/logging-monitoring-definitions-et-bonnes-pratiques/

January 21, 2020

Le top 10 OWASP 2017 introduit

comme risque l’insuffisance de
logging et de monitoring. En effet,
les problèmes inhérents à cette
pratique sont souvent sous-évalués
et mal compris. Mais pourquoi une
tâche simple en apparence est
finalement un point crucial de la
sécurité des systèmes d’information
?

1/ Définissons logging
Le logging est un terme signifiant la gestion des logs. Les logs sont des journaux
d’événements où sont collectés les événements relatifs à l’état d’un système. Il existe une
multitude de logs en fonction des différents systèmes.

Prenons l’exemple d’une application web : les logs peuvent être toute action effectuée sur le
service web, comme la connexion d’un utilisateur à la plateforme, une génération d’erreur
HTTP ou encore un accès à une ressource sur le serveur.

Une grande quantité de données est rapidement collectée, ce qui implique un coût matériel et
humain important. De plus, pour que les logs soient utiles, ils nécessitent les actions
suivantes :

Sélectionner les informations utiles à stocker et archiver

Garantir la sécurité et la confidentialité des journaux stockés
Contrôler la qualité des données des journaux en analysant et en ajoutant aux journaux
les informations manquantes
Analyser les logs (souvent confondu avec le monitoring d’une application)
Contextualiser les évènements (enrichissement des logs)
Adresse IP ayant générée les logs
Utilisateur concerné
Fonctionnalité concernée
Détail de l’erreur

1/6
La contextualisation des logs est la partie qui requiert le plus d’expérience et de
connaissances du système surveillé, afin de savoir quelles informations doivent être retenues
et lesquelles sont inutiles. Cette tâche demande également beaucoup de temps humain.

Une fois toutes ces actions réalisées, les logs vont permettre d’investiguer sur un
dysfonctionnement de l’application pour qu’il ne se reproduise plus. Dans le cadre d’une
attaque, cela permettra notamment de connaître les acteurs à l’origine de celle-ci. De plus, il
sera possible de savoir quelle fonctionnalité a été abusée, afin de corriger la faille qui a
permis l’attaque.

2/ Définissons monitoring
Le monitoring, ou supervision d’une application, est la capacité à avoir une vue globale sur
une application à un instant T mais aussi un historique des états passés pour plusieurs
éléments :

les performances, temps de réponse des différentes ressources du serveur ;

l’intégrité, vérification que le contenu des pages web ne change pas ;
et la disponibilité, vérifier que l’application assure l’intégralité de ses fonctionnalités
(UP/DOWN).

Le monitoring est aussi important pour détecter tout ce qui relève du manque de
performance du serveur et pour la détection d’attaques en temps réel. En effet, si un serveur
nécessite une grande disponibilité, le fait de surveiller les actions des utilisateurs permet de
repérer quelle fonctionnalité de l’application demande beaucoup de ressources et serait
susceptible de causer des ralentissements. Pour une attaque, si un grand nombre de
connexions affluent sur le service, une tentative de déni de service est peut-être en cours. Une
alerte pourrait permettre à l’équipe de sécurité de réagir en bloquant par exemple les
adresses IP effectuant des connexions TCP partielles ou trop de connexions TCP trop
rapidement.

Dans le but de détecter ces anomalies, un outil de supervision global doit être utilisé pour
centraliser les différents journaux. Celui-ci a besoin d’interroger en temps réel les services à
monitorer. Il peut se baser sur de multiples éléments, appelés métriques, comme :

la charge CPU ;
le nombre de connexions simultanées (TCP, UDP, applicative…) ;
les erreurs du serveur ;
la simulation d’une interaction avec l’application ;
la charge du réseau (QOS, latence, ping) ;
les tentatives de connexions bloquées par le pare-feu (détection d’un Nmap par
exemple).

2/6
La supervision de ces éléments doit permettre de créer des événements (alertes). Ces
éléments sont des changements d’état significatifs. Cela peut être une charge CPU trop
élevée, un push vers un dépôt, une erreur de build, un nombre de connexions TCP
simultanées trop élevées. Pour un suivi efficient, il convient ensuite de mettre des niveaux de
criticité sur les événements. Cela permet de les traiter avec un ordre de priorité, comme pour
une application de gestion de tickets.

Le logging et monitoring sont souvent assimilés, car le système de monitoring a comme

données principales les logs, et sans logs de qualité, il n’y a pas de monitoring efficace.
Cependant, il ne faut pas confondre l’analyse des logs avec le monitoring. L’analyse des logs
est un travail post incident tandis que le monitoring est un travail permanent.

3/ Pourquoi l’absence de logging et de monitoring est une

vulnérabilité ?
Comme nous venons de le voir, la mise en place de telles techniques peut être très complexe.
En effet, il faut être capable de stocker, trier et traiter ces informations. Sans une bonne
connaissance des éléments à monitorer, plusieurs problèmes peuvent avoir lieu :

Changement d’état non logué.

Journalisation uniquement des erreurs du système, ce qui ne permet pas de traiter tous
les problèmes. Cependant, si l’on commence à journaliser trop d’éléments, un problème
d’espace de stockage peut vite arriver. Il faut donc savoir ce qui est important à loguer
et ce qui l’est moins (mise en place d’une classification des logs). De cette manière, le
temps de stockage des informations peut être adapté en fonction de leur criticité.
Trop d’informations dans lesquelles chercher.
Manque de corrélation entre les données. Dans le cas où plusieurs micro-services sont
monitorés ensemble, il est possible que les éléments pris de manière individuels n’aient
aucun sens. Il faut donc un travail humain afin de relier ces informations
(contextualisations des logs).
Mauvaise configuration des événements. Par conséquent, certaines alertes passent
inaperçues pour l’équipe de monitoring.

L’accumulation de ces problèmes fait que les logs sont inutilisables. Les systèmes de
monitoring deviennent alors plus une contrainte et une perte de temps qu’une aide. C’est là
que l’on parle d’insuffisance de logging et monitoring, qui peut vite devenir un gros problème
et une vulnérabilité importante.

A partir du moment où la gestion de logs n’est plus efficace, il devient effectivement

compliqué pour l’équipe de développement de détecter un problème avant que l’impact soit
important. Un attaquant pourrait donc se dissimuler à l’intérieur d’une application ou d’un
système sans être détecté avant qu’il n’effectue des actions dommageables.

3/6
En effet, la majorité des attaques informatiques pourrait être anticipées et/ou arrêtées si les
systèmes de logging et de monitoring sont correctement configurés. Il y a une multitude de
cas réels attestant du danger d’une telle vulnérabilité.
Par exemple, l’entreprise Citrix fournissant une plateforme de digital workspace a constaté
que des attaquants étaient infiltrés dans leur réseau seulement 6 mois après leurs intrusions
(d’octobre 2018 à mars 2019). Cela leur a permis de voler et supprimer des fichiers sur les
employés (nom, numéro de sécurité social et informations financières). L’intrusion a été
effectuée par brute force de mot de passe sur les comptes utilisateurs (source). Ce type
d’attaque aurait pu être détectée beaucoup plus tôt si un système de monitoring avait détecté
un grand nombre de tentatives de mot de passe erronés.
Il est donc important de sélectionner les bonnes informations afin de ne pas être noyé sous
les alertes, qui seront sinon ignorées.

4/ Bonnes pratiques logging et monitoring

Nous avons vu qu’il était complexe de mettre en place un système de logging et monitoring
performant. Afin vous aider sur ce point, nous allons préciser quelques bonnes pratiques à
mettre en place pour faciliter l’implémentation et augmenter l’efficacité de tels systèmes.

Connaître ses métriques : (Qu’est-ce que je peux loguer ou non ?). Cela implique de
bien connaître son système afin de savoir quoi mesurer. Nous pouvons différencier
deux types de métriques. Cette définition doit être prise en compte dès la conception de
l’application.
Les métriques métiers, ce qui concerne l’applicatif. Cela peut être le pourcentage
de panier abandonné sur un site e-commerce, ou le nombre de pages servies par
le serveur à la seconde.
Les métriques concernant les ressources. Cela concerne les ressources mises en
œuvre pour servir l’application. Cela pourrait être le nombre de CPU actifs, ou la
RAM demandée par le serveur à un instant T.

Sélectionner ses métriques (ce que je dois loguer) : pour cela, il est d’abord
recommandé de classifier ses métriques, des moins importantes (informations inutiles
pour la santé de votre application) aux plus importantes (informations critiques).
En fonctions de cette classification, sélectionnez les métriques à monitorer en
partant des plus importantes aux moins importantes. En fonctions des ressources
allouées au serveur de monitoring (espace disque, RAM), vous pourrez
sélectionner plus ou moins de métriques. Cette classification vous permettra de
revenir sur la sélection des métriques si le service de monitoring se voit attribuer
plus de ressources dans le futur.

Définir ses alertes : les alertes levées par le système de supervision ne doivent
concerner que les métriques que vous venez de sélectionner. Il convient maintenant de
définir pour chaque métrique à partir de quel seuil une alerte est remontée.

4/6
Classifier vos alertes (informationnelles, faibles, moyennes, importantes, critiques)
: en fonction de leurs classifications, certaines actions peuvent être déclenchées.
Informationnelle : aucune notification n’est levée.
Faible : une notification est créée dans le système de monitoring.
Moyenne : un email est envoyé à la personne responsable de la ressource
concernée.
Importante : un email et un SMS sont envoyés à la personne responsable de la
ressource concernée.
Critique : un appel est effectué au responsable technique de l’application en plus
d’un email.

Gérer et classer les métriques : c’est un travail itératif. À la manière d’un

développement agile, la gestion des règles de logs n’est pas quelque chose de définitif. Il
faut revenir sur ces règles à chaque implémentation de fonctionnalités. De plus, si une
information lève régulièrement une alerte qui n’est pas utile (faux positif) il faut revoir
la classification.

Séparer les logs : les logs d’une application web ne doivent contenir que des
informations liées aux fonctionnalités de l’application et non des problèmes inhérents
au serveur.

Définir une structure de log : les logs doivent avoir un format qui permet d’exfiltrer
facilement les informations utiles. Le format JSON ou clef->valeur sont souvent
appropriés.

Centraliser les logs : la supervision doit être centralisée et gérée par un serveur
externe à l’application. Cela permet au système récupérant toutes les informations
d’ajouter un contexte à ces informations et de les corréler. La corrélation est très
importante pour identifier rapidement le problème. Par exemple, l’application génère
un nombre important d’erreurs 500 sur une fonctionnalité. Dans le même temps, le
serveur voit sa charge CPU augmenter considérablement. Pris de manière
indépendante, il est difficile de connaître l’origine du problème de l’augmentation de la
charge CPU. Alors qu’en corrélant ces deux informations, cela nous indique que la
génération d’erreurs 500 sur telle fonctionnalité implique une charge serveur
considérable, pouvant provoquer un déni de service de l’application. De plus, le
contexte des logs va permettre de détecter ce qui génère une erreur 500 et donc gérer
cette exception dans le code.

Avoir une duplication de la supervision : en effet, si le serveur de monitoring est

hors service (saturation espaces disque, mise à jour…), il faut prévoir un plan de
secours. En fonction des moyens de l’entreprise, cela peut être une duplication du
serveur avec des disques durs en RAID5 ou une solution dégradée (stockage des
informations brutes sur un disque dur externe au système).

5/6
 Choisir un framework de log correspondant à l’infrastructure de l’application.

Documenter l’infrastructure gérant les logs.

Évaluer son système de logging et monitoring.

5/ Évaluer son système de logging & monitoring

Une fois les différents systèmes mis en place, il faut maintenant évaluer leur efficacité.

Un premier indicatif très simple à vérifier est le fait qu’aucune alerte pour une longue durée
ne soit remontée. En effet, il y a toujours une anomalie à remonter même si cela relève d’une
simple information. De plus, si le SI comporte un problème connu et que le système de
monitoring ne lève aucune alerte, il y a forcément un problème de configuration du système.

Un bon test à effectuer serait de lancer un scanner de vulnérabilité type OpenVas ou Burp sur
votre serveur et application. Ce type de scanner devrait remonter une multitude d’alertes. De
plus, en fonctions des tests qu’ils effectuent, ils vous permettront d’ajouter des informations
aux alertes remontées. Par exemple, si vous configurez un scanner pour tester l’injection de
commandes sur une fonctionnalité, les alertes remontées pour l’abus d’une fonctionnalité
pourraient être classées comme tentatives d’injection de commandes.

Une fois ces ajustements et tests internes effectués, un ou plusieurs pentests applicatifs sont
de très bons tests pour vos systèmes de monitoring. En effet, ils permettent souvent de
mettre en avant de potentiels problèmes. Cependant, il n’est généralement pas possible pour
un pentester d’évaluer si l’entreprise auditée effectue de manière consciencieuse la gestion
des logs et la supervision du serveur audité. De manière générale, toutes les actions
entreprises par un pentest doivent faire remonter des alertes sur votre système.

Pour être exhaustif, il est possible d’effectuer un audit interne en mode white box : dans ce
cas-là, l’auditeur pourrait avoir accès à toute l’infrastructure et vérifier en temps réel que, en
fonction des tests qu’il effectue, les alertes correspondantes sont levées.

6/6