État des lieux
Log Management
A ne pas confondre avec les SIEM, les solutions de gestion des journaux sont avant tout de puissants outils d’agrégation et de recherche.
La confusion est commune entre les SIEM (Security Information & Event Manager) et les solutions de gestion des journaux (log management). Et l’on peut le comprendre : dans les deux cas les journaux produits par les équipements, les applications et les postes de travail constituent leur matière première.
Cependant les finalités ne sont pas les mêmes : tandis que le SIEM est avant tout un outil dédié à la sécurité (analyse et alerte), l’outil de gestion des logs sera tout autant utilisé par la SSI que par la DSI, voire par la conformité !
Bien que leurs usages puissent être très différents, la confusion est telle qu’il n’est pas rare de voir des entreprises acquérir un SIEM alors qu’elles n’auraient besoin, en définitive, que d’un outil de gestion des journaux !
Avant tout des outils d’archivage
Les solutions de gestion des journaux ont pour objectif de centraliser et de conserver la multitude de journaux produits au quotidien par les équipements du SI. Leur objectif est d’être exhaustif. Ils sont ensuite en mesure de conserver cette masse documentaire de manière fiable, sur de longues périodes de temps. Ils proposent alors des outils d’indexation et de recherche avancés afin de procéder à des requêtes puissantes sur ce corpus de données.
Un outil industriel
Le focus d’un outil de log management porte réellement sur l’industrialisation de la collecte : il doit être en mesure de collecter rapidement un volume très important d’éléments à travers des sources très variées, et ceci sans interruption. Ces solutions sont couramment utilisées sur des volumétries très importantes et bénéficient donc d’optimisations spécifiques en ce sens.
Attention à la recherche
C’est l’usage premier d’un outil de gestion des logs : faire des recherches ciblées, que ce soit pour des questions de sécurité, de conformité ou pour trouver l’origine d’un dysfonctionnement du SI. Une attention particulière doit donc être apportée aux fonctions d’indexage (essentiel pour les performances) et sur la qualité du moteur de recherche (réactivité, pertinence, présentation).
État des lieux
Audit de code source
Si quatre paires d’yeux valent mieux que deux lorsqu’il s’agit d’examiner un code source à la recherche de vulnérabilités potentielles, que penser alors d’une multitude d’yeux automatiques affûtés ? C’est encore mieux !
Les vulnérabilités applicatives sont aujourd’hui à l’origine de l’essentiel des incidents de sécurité (42% des intrusions externes selon une étude Forrester), et notamment sur le web. L’un des meilleurs exemples dans ce domaine est la fameuse injection SQL, où un attaquant est en mesure de s’emparer du contenu de la base de données d’une application web en exploitant un défaut de validation des entrées de l’utilisateur.
Ces vulnérabilités trouvent leur origine dans des erreurs de conception ou de programmation commises au moment du développement et découvertes ensuite par un attaquant un peu curieux.
Dans le cas des applications sur étagère, l’entreprise ne peut compter que sur le sérieux et le professionnalisme de l’éditeur pour espérer sinon éviter entièrement les vulnérabilités, du moins en réduire le nombre.
Mais en ce qui concerne celles développées en interne, elle peut agir ! A commencer, bien entendu, en instaurant des revues de code fréquentes, et en formant ses développeurs aux techniques de développement sécurisé (voir notamment page 104 les offres de sécurité dans un contexte de DevOps). Sur ce point, Microsoft a notamment réalisé un excellent travail en documentant abondamment son cycle de développement sécurisé (SDL, pour Security Development Lifecycle : https://www.microsoft.com/en-us/sdl/).
Analyse automatisée du code source
Si de nombreux cabinets de conseil proposent aussi d’auditer les codes source, il est également possible d’automatiser ce processus en interne. Le marché propose pour cela des outils logiciels capables d’explorer le code source (et ses dépendances) afin d’identifier des structures de code dangereuses, des oublis pouvant mener à une faille de sécurité ou des mauvaises pratiques.
Ces outils sont livrés sous forme de solution logicielle à installer localement, mais aussi désormais en mode SaaS avec une facturation à l’usage. Certains sont disponibles sous licence Libre, tandis que d’autres sont commerciaux.
Pour bien choisir, il sera nécessaire de s’assurer que le produit considéré supporte bien entendu les langages de développement utilisés en interne, mais aussi qu’il s’intègre à l’IDE choisi par l’équipe, ou puisse être utilisé dans le cadre d’un cycle de développement sécurisé.
Et puis il sera plus sage d’en utiliser plusieurs afin de s’assurer d’une meilleure couverture de l’analyse…
