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 ?
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 :
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.
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 :
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 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.
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 :
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.
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.
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.
