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
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).
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.
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.
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).
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.