All your logs belong to you !

*Ceci est un article basé sur la présentation de Xavier Mertens aux RSSIL*

Tous les systèmes, tous les évènements génèrent des logs. Comment les gérer ? Quelles sont les problématiques ? Comment en tirer beaucoup plus de valeurs pour pouvoir les traiter au jour le jour ?

La situation à l’heure actuelle au niveau des logs, dans les entreprises est que les personnes ne savent pas qu’elles ont des logs, où sont les logs, et celles qui le savent, considèrent que le « management » de logs est une corvée fastidieuse. Lorsqu’un incident se produit au sein d’une société, le premier réflexe est de se souvenir qu’elle a des logs et de regarder les derniers évènements avant l’incident. Il faut être préparé aux incidents et en la matière, la loi de Murphy est fondamentale. Si quelque chose peut se produire, ça va se produire, peu importe quand cela va se produire. Il faut donc se demander si en interne, la société dispose de suffisamment de ressources : procédures, personnes, outils.

Lire des logs est quelque chose de rébarbatif car il y en a des millions, ce n’est pas pratique car on peut passer à côté d’évènements très importants – il est impossible de tous les lire en temps réel – donc la visibilité va être le maître-mot de cette problématique. Les ordinateurs génèrent des logs mais on peut se servir des ordinateurs pour gérer ses logs. Afin de gérer la visibilité de ces logs, on peut intégrer différentes sources externes, comme par exemple, des blacklists d’utilisateurs, d’adresses IP, etc. Ce qui va être essentiel sera la détection d’activités qui vont passer sous le radar, ce qui se passe d’une manière discrète. Si on doit attaquer un système, on va tout faire pour ne pas être détecté au niveau des logs donc de noyer l’information au milieu de toute la masse de logs gérée de manière quotidienne.

Malheureusement, il y a trois types de problèmes à cela. Il y a tout d’abord les problèmes techniques : les réseaux gérés au jour le jour deviennent de plus en plus complexes. Il y a de plus en plus de solutions, il y a les vendeurs de sécurité qui viennent proposer de nouveaux modèles. Par ailleurs, il y a les systèmes qui deviennent de plus en plus complexes du fait de l’intégration de nouveaux systèmes. Il y a donc une augmentation des risques ainsi que de la complexité. Il convient également de souligner que la délégation de la sécurité n’est pas toujours une bonne chose selon la sensibilité de l’entreprise car le prestataire extérieur va avoir connaissance de votre système du fait que les logs sont décentralisés.

Les logs répertorient des millions d’évènements par jour. Le système informatique le plus petit soit il génère des logs tous les jours. Il est impossible de gérer cela de manière manuelle avec une personne dédiée. Chaque fonctionnalité de sécurité est livrée avec une console qui va servir d’outil de management. Mais il y a de plus en plus de fonctionnalités et il est impossible pour une seule personne de connaître à la perfection l’ensemble des outils qui vont être quotidiennement utilisé. Pourtant, à lire certaines offres d’emploi, on constate que les employeurs recherchent des personnes connaissant tout de A à Z.  Finalement, de plus en plus de protocoles sont utilisés et d’un système à l’autre, sur des erreurs similaires – par exemple un Denied IP – les écritures vont être différentes.

Le deuxième type de problème va être le problème économique. On ne peut pas avoir des gens 24h/24h qui lisent des logs. Il faut des opérations en temps réel et pouvoir analyser les incidents sans pour autant stopper les supports. Avec le contexte de crise économique, le but va être d’économiser le plus possible et de générer un maximum de revenus. Beaucoup de managers pensent qu’une gestion de logs est une forme d’assurance. Ce n’est pas totalement faux : une solution de log-management coûte de l’argent, du temps mais le retour sur investissement ne revient pas directement. Pour un manager, cela ne va rien changer au modèle économique de l’entreprise. Il y a un aspect de risque-management qui est important et il va falloir prouver que ce système est utile.

Enfin le dernier aspect est l’aspect légal. Il y a d’abord les risques relatifs aux contraintes, qui sont de deux sortes. Il y a les contraintes relatives à la confidentialité des données – notamment en matière bancaires et sanitaires – et les contraintes relatives à la vie économique de l’entreprise. Par ailleurs, il y a des lois qui imposent de garder des traces des différentes connexions.      

Mais le but n’est pas non plus de jouer les « Big Brother » et les personnes travaillant dans une entreprise doivent être informées, cela doit être spécifié dans la charte informatique, que des contrôles sont régulièrement effectués. Sur le plan externe, il faut notifier les utilisateurs et les visiteurs que des informations les concernant peuvent être stockées mais également, qu’à leur demande, peuvent être effacées.

Quels sont les objectifs du log-management ? Il faut pouvoir les collecter d’une manière efficace et propre. Une fois que les évènements ont été collectés, il faut les normaliser. La normalisation est une étape clef car elle va permettre de décortiquer ces évènements pour pouvoir les mettre dans un format unique afin d’automatiser les recherches et les procédures. Une fois que cette étape de normalisation a été faite, il faut procéder à un archivage dans un point central sécurisé, ne se trouvant pas sur la plateforme de production, afin qu’en cas d’incident, la plateforme puisse tourner sans impact et que le log-manager puisse chercher à son aise ce dont il a besoin. A partir de cette centralisation, on commence la recherche, le suivi et le report. Enfin la corrélation et le management d’incident sont les dernières étapes. Au niveau de la corrélation, il peut être très intéressant de mettre en place une convergence de sécurité. Il y a deux types de contrôles en sécurité : logique (mots de passe, IP) et physique (badge, géolocalisation). Le but de la convergence de sécurité va être d’utiliser ses deux méthodes et donc d’augmenter l’efficacité du système.

Ces différents objectifs dépendent des uns des autres.

Quelles solutions mettre en place pour un outil de log-management ? Les SI les plus performants et les plus chers ne sont pas toujours les solutions les plus adaptées. La meilleure solution sera la mieux adaptée au système et celle répondant au mieux aux problématiques de la structure. Il convient de ne pas oublier les procédures déjà établies. Enfin, il ne faut pas oublier qu’une solution de log-management n’est pas une solution de sécurité, cela va archiver, mais ne va pas protéger.

La solution OSSEC est open-source et de log-management. OSSEC est gratuite et tout le monde doit avoir une solution de log-management.

Les fonctionnalités principales d’OSSEC sont la détection d’évènements inhabituels sur les serveurs et stations de travail, l’analyse de logs, la vérification de fichiers sur les systèmes, détection de rootkit, génération d’alertes et d’actions spécifiques et l’interopérabilité du système.

OSSEC n’est pas un produit. On doit intégrer certaines procédures. Il est là pour aider à la résolution de problèmes mais c’est un simple programme donc s’il n’est pas paramétré comme il faut, il sera inutile. Il convient donc de procéder à une analyse en amont. Il faut faire des tests de A à Z.

OSSEC peut s’inter-connecter avec différents formats de logs : UNIX/Windows et les outils les plus communs, mais également avec les serveurs FTP/SMTP/http, les firewalls, les bases de données, les outils de sécurité, ainsi qu’avec des produits commerciaux et vos propres applications.

Au niveau des variables utilisées par OSSEC, on va retrouver la localisation, le nom de l’hôte, attaques éventuelles, les sources, le protocole, le type d’action, de qui provient l’action, des datas supplémentaires, etc. Grâce à ses variables, l’opération de normalisation va être accélérée et donc l’objectif de recherche va être plus rapidement atteint.

Comment gérer sa propre boîte à outils ? Tous les logs sont déjà là mais la problématique va être l’accès étendu, rapide et dans le temps. Si les logs sont hébergés ailleurs, dans un data-center ou un cloud, il faut réclamer l’accès à ces logs.

Quelles sont les sources alternatives qui peuvent être intégrées ? Il y a les bases de vulnérabilités qui sont disponibles sur Internet qu’il est possible d’intégrer dans OSSEC, il peut y avoir des blacklists (IP, nom de domaines, serveurs) et les données physiques comme la géolocalisation et les lecteurs de badges.

Comment fonctionne OSSEC ? Par défaut, il est configuré avec une centaine de règles. La détection d’évènements standards fonctionne bien mais on peut générer ces propres règles et OSSEC fonctionne sur un arbre que l’on peut niveler afin d’augmenter la granularité afin d’avoir l’information et générer l’alerte qui va être utile.

La première étape consiste à créer un décodeur afin de spécifier et d’extraire un évènement particulier. Basé sur ce décodeur, on récupère les actions et les évènements. A partir de là, on peut créer ses règles spécifiques, adaptées à ses besoins.

Il faut veiller à synchroniser tous les matériaux afin de détecter certaines alertes. Par défaut, OSSEC ne collecte pas toutes les alertes mais il est possible d’activer une copie de logs. On peut également archiver, compresser et hasher les logs. OSSEC a des agents distribués. Il y a également des fonctionnalités d’exports.

On peut aussi créer une alerte sur des clefs USB et donc contrôler les politiques de sécurité. On peut vérifier l’intégrité de MySQL. Autre petit jeu : le contrôle d’adresse IP via Google Maps.

En bref, un outil de log-management présente l’avantage d’être personnalisable et adapté aux besoins d’une structure puisque modulable.