View
228
Download
9
Category
Preview:
Citation preview
Le guide complet de la gestion des logs et événementspar le Dr Anton Chuvakin, parrainé par NetIQ
Toutes les entreprises possèdent des logs et, par conséquent, doivent en assurer la gestion, ne serait-ce que pour se conformer aux nombreuses conditions des réglementations en vigueur. Dans le présent livre blanc, le Dr Anton Chuvakin analyse les relations entre la gestion des logs et les outils SIEM. Il met en lumière les différences techniques et les diverses utilisations de ces technologies, sans oublier l’architecture de leurs déploiements communs. Par ailleurs, il offre des recommandations aux entreprises ayant déployé une solution de gestion des logs ou des outils SIEM afin de les aider à définir leur feuille de route dans le but d’améliorer, d’optimiser et d’élargir leur déploiement. Enfin, il propose une feuille de route spécifique aux sociétés qui ont déjà déployé ces deux types de technologies.
Livre blancSentinel
Table des matières page
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Principaux atouts de la gestion des informations et des événements de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Principaux atouts de la gestion des logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Comparaison approfondie entre les outils SIEM et la Gestion des logs . . . . . . . . . 4
Cas pratiques d’utilisation des systèmes de gestion des logs et des outils SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Tendances technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Exemple de scénario de gestion des logs et des outils SIEM . . . . . . . . . . . . . . . . . . . . 8
Architecture des outils SIEM et de la gestion des logs . . . . . . . . . . . . . . . . . . . . . . . . . 9
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
À propos de l’auteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
À propos de NetIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1www.netiq.com
IntroductionLa technologie de gestion des informations et événements de sécurité (Security information and event management ou SIEM) existe depuis la fin des années 1990. Cependant, sa promesse initiale de fournir aux petites entreprises un « écran unique de sécurité » associé à un processus d’adoption lente a toujours soulevé des polémiques au sein de l’industrie de la sécurité. Récemment, la technologie SIEM traditionnelle a été combinée à l’utilisation massive de la technologie de gestion des logs. Cette dernière vise à recueillir un vaste éventail de logs à des fins multiples, de la réponse aux incidents de sécurité à la conformité aux réglementations en passant par la gestion des systèmes et le dépannage des applications.
Dans le présent livre blanc, nous analyserons les relations entre la gestion des logs et les outils SIEM.
Nous mettrons en lumière les différences techniques et les diverses utilisations de ces technologies,
sans oublier l’architecture de leurs déploiements communs. Par exemple, si vous êtes tenu de vous
conformer à des conditions de consignation de la norme de sécurité informatique des données de
l’industrie des cartes de paiement (Payment Card Industry-Data Security Standard ou PCI DSS),
quelle technologie devriez-vous déployer ? Laquelle vous permet d’optimiser votre réponse aux
incidents et vos procédures d’enquête ? Ou encore, laquelle vous fournit des informations en temps
réel sur les attaques ? Par ailleurs, nous proposerons des recommandations aux entreprises ayant
déployé une solution de gestion des logs ou des outils SIEM afin de les aider à définir leur feuille de
route dans le but d’améliorer, d’optimiser et d’élargir leur déploiement. Enfin, nous proposons une
feuille de route spécifique aux sociétés qui ont déjà déployé ces deux types de technologies.
Les outils SIEM sont apparus pour la première fois sur le marché en 1997. À l’origine, ils
visaient à diminuer les fausses alertes du système de détection des intrusions sur le réseau
(Network Intrusion Detection System ou NIDS), qui représentaient un véritable fléau à
l’époque. Ces outils étaient compliqués à déployer et à utiliser. Par conséquent, ils convenaient
2
Livre blancLe guide complet de la gestion des logs et événements
uniquement aux plus grandes entreprises disposant des programmes de sécurité les plus aboutis.
À la fin des années 1990, le marché représentait quelques millions de dollars et selon certains
analystes, il devrait atteindre des milliards de dollars au cours des prochaines années. Les outils
SIEM disponibles actuellement, notamment NetIQ Sentinel, sont prisés autant par les grandes
entreprises figurant dans les classements Fortune 1000 ou Global 2000 que par les PME.
Avant de commencer notre analyse, il est nécessaire de définir les expressions SIEM et gestion
des logs mais aussi d’expliquer leurs différences. La technologie SIEM assure la collecte, le
regroupement, la normalisation et la conservation des logs adéquats, la collecte de données de
contexte, l’analyse (y compris la corrélation et la hiérarchisation), la présentation (notamment
la création de rapports et la visualisation), mais aussi les workflows et les contenus relatifs à la
sécurité. Tous les cas pratiques d’utilisation de la technologie SIEM se concentrent sur la sécurité
des informations, du réseau et des données mais aussi sur la conformité aux réglementations.
L’expression « gestion des logs » inclut la collecte exhaustive de logs, leur regroupement, la
conservation des logs originaux (bruts, non modifiés), l’analyse du texte des logs, la présentation
(principalement sous forme de recherches mais aussi de création de rapports) ainsi que les
contenus et workflows connexes. Les cas pratiques d’utilisation des données de consignation dans
le cadre de la gestion des logs sont variés et couvrent tous les usages possibles des données de
consignation dans tous les domaines possibles, bien au-delà du secteur informatique.
De ces deux définitions se détache une différence fondamentale : la technologie SIEM est orientée
vers la sécurité (comme l’indique le premier mot de son acronyme anglais) et l’utilisation de
diverses données informatiques à des fins de sécurité. En revanche, la gestion des logs est
entièrement consacrée aux logs et au vaste éventail d’utilisations des données de consignation,
au sein du secteur de la sécurité comme dans d’autres domaines.
Principaux atouts de la gestion des informations et des événements de sécurité
Examinons plus en détail les fonctions qui caractérisent la technologie SIEM. La plupart des
utilisateurs cherchent à disposer de la majorité de ces fonctions lorsqu’ils choisissent un produit
SIEM. Les fonctions proposées sont les suivantes :
Collecte des données de contexte et des logs. Cette fonction consiste à recueillir des logs et des données de contexte, notamment des informations d’identité ou les résultats des analyses de vulnérabilité, à l’aide d’une combinaison de méthodes basées ou non sur agent.
Normalisation et catégorisation. Cette fonction convertit les logs originaux collectés dans un format universel à des fins d’utilisation au sein du produit SIEM. Par ailleurs, les événements sont classés dans des catégories utiles : Modifications de la configuration, Accès aux fichiers ou encore Attaque par surcharge de tampon.
SIEM :
Collecte, regroupement, normalisation et conservation des logs adéquats
Collecte des données de contexte
Analyse, corrélation et hiérarchisation
Présentation, création de rapports et visualisation
Workflows et contenus relatifs à la sécurité
Sécurité des informations, du réseau, des données et conformité réglementaire
3www.netiq.com
Corrélation. Cette fonction inclut la corrélation algorithmique, statistique ou basée sur des règles ainsi que d’autres méthodes, comme la mise en relation de différents événements entre eux ou la mise en relation d’événements avec des données de contexte. La corrélation peut s’effectuer en temps réel, mais tous les outils ne prennent pas en charge cette fonction. En effet, certains outils se concentrent sur la corrélation des données historiques provenant de leurs bases de données. En outre, d’autres méthodes d’analyse des logs sont parfois incluses dans cette catégorie.
Notification et alertes. Cette fonction comprend le déclenchement de notifications ou d’alertes auprès d’opérateurs ou de gestionnaires. Les mécanismes d’alerte courants comprennent les e-mails, les SMS ou même les messages envoyés via le protocole SNMP (Simple Network Management Protocol).
Hiérarchisation. Cette fonction comprend différentes options qui mettent en évidence les événements importants par rapport aux événements de sécurité moins graves. Pour ce faire, il est possible de corréler les événements de sécurité avec des données de vulnérabilité ou d’autres informations sur les ressources. Les algorithmes de hiérarchisation utilisent souvent des informations sur la gravité fournies par le log original.
Vues en temps réel. Cette fonction comprend des tableaux de bord de monitoring de la sécurité et affiche des opérations à l’usage du personnel. Ainsi, les analystes peuvent voir les informations collectées mais aussi les résultats des corrélations pratiquement en temps réel. Les données historiques et archivées peuvent également être présentées de cette manière.
Création de rapports. La création de rapports standard et planifiés prend en compte toutes les vues historiques des données recueillies par le produit SIEM. Certains produits sont également dotés d’un mécanisme de distribution des rapports aux directeurs informatiques ou au personnel en charge de la sécurité, soit par e-mail soit à l’aide d’un portail Web sécurisé dédié.
Workflow des rôles de sécurité. Cette fonction comprend la gestion des incidents, notamment la création de dossiers et l’organisation de tâches d’enquête, mais aussi la mise en place automatique ou semi-automatique de tâches types dans le cadre d’opérations de sécurité. Certains produits intègrent également des fonctions de collaboration qui permettent à plusieurs analystes de travailler sur la même initiative de réponse en matière de sécurité.
La plupart des produits SIEM commercialisés actuellement sont dotés des fonctions énumérées
ci-dessus. Toutefois, ils ont tous leurs points forts et leurs points faibles ainsi que des fonctions
supplémentaires spécifiques.
Principaux atouts de la gestion des logs
Penchons-nous d’abord sur les principaux atouts d’un système de gestion des logs. Ces atouts sont
les suivants :
Collecte des données de consignation. Cette fonction permet de recueillir toutes les données de consignation disponibles à l’aide de méthodes basées ou non sur agent, voire d’une combinaison des deux.
Conservation rationnelle. Même si la collecte et la sauvegarde de données de consignation ne constituent pas un défi technique majeur, il n’est pas simple de recueillir efficacement plusieurs gigaoctets, voire téraoctets, de ce types de données, puis de les conserver tout en fournissant des fonctions de recherche et d’accès rapides. Cette fonction est essentielle aux systèmes de gestion des logs étant donné le nombre de réglementations incluant des conditions spécifiques exigeant la conservation des données de consignation, très souvent pendant plusieurs années.
Recherche. Cette fonction est le principal moyen d’accéder aux informations contenues dans l’ensemble des logs, y compris ceux issus des applications personnalisées. En outre, elle est indispensable pour utiliser les logs à des fins d’enquête, mener des analyses d’expertise et identifier les défaillances tout en dépannant les applications à l’aide des logs. Par conséquent, il est essentiel que les systèmes de gestion des logs comprennent une interface de recherche interactive, réactive et conviviale.
Gestion des logs :
Collecte exhaustive de logs, regroupement et conservation des logs originaux (bruts, non modifiés)
Analyse du texte des logs
Présentation principalement sous forme de recherches, mais également de création de rapports
Contenus et workflows connexes
Divers cas pratiques d’utilisation couvrant tous les usages possibles des données de consignation dans tous les domaines possibles, bien au-delà du secteur informatique
4
Livre blancLe guide complet de la gestion des logs et événements
Indexation et analyse des logs. Tout système de gestion des logs repose essentiellement sur ces deux fonctions. L’indexation permet des recherches cent fois plus rapides. La technologie d’indexation crée une structure de données appelée un index. Ce dernier permet d’effectuer des recherches très rapides à l’aide de mots-clés ou d’opérateurs logiques sur l’ensemble du système de stockage des logs. Parfois, l’indexation permet d’activer d’autres techniques d’analyse en texte intégral. Ce système pourrait être qualifié de « Google pour les logs ». Tous les outils de gestion des logs ne prennent pas en charge l’indexation et n’indiquent pas les taux de collecte des logs lorsqu’ils ne sont pas pris en compte pour l’indexation. Par conséquent, les affirmations des fournisseurs sont à prendre avec des pincettes.
Création de rapports standard et planifiée. Ces fonctions concernent toutes les données recueillies par le produit de gestion des logs. Elles sont similaires aux fonctions de création de rapports comprise dans les outils SIEM. La fiabilité des rapports, qu’ils soient créés pour des raisons de sécurité, de conformité ou de fonctionnement, peut asseoir ou détruire la réputation de la solution de gestion des logs concernée. Les rapports doivent être créés rapidement, personnalisables et faciles à utiliser à diverses fins. La distinction entre les recherches et les rapports est parfaitement claire. Le processus de recherche concerne tous les logs collectés disponibles dans leur format brut d’origine, tout comme Google passe en revue les pages Web. En revanche, les rapports se fondent sur les logs analysés au sein d’une base de données, à l’instar d’une feuille de calcul Excel. Prenez bien soin d’évaluer la facilité avec laquelle vous pouvez créer un rapport personnalisé dans un outil de gestion des logs. C’est là que le bât blesse pour de nombreuses solutions. En effet, leurs opérateurs doivent étudier les aspects « ésotériques » des structures de leurs données de stockage des logs avant de pouvoir personnaliser les rapports.
À présent, comparons les fonctions des systèmes de gestion des logs à celles des outils SIEM à un
niveau supérieur.
Comparaison approfondie entre les outils SIEM et la Gestion des logs
Dans le tableau ci-dessous, nous présentons les principales fonctions et illustrons les différences
entre la gestion des logs et les outils SIEM.
Examinons les utilisations des technologies de gestion des logs et des outils SIEM.
Tous les outils de gestion des logs ne prennent pas en charge l’indexation et n’indiquent pas les taux de collecte des logs lorsqu’ils ne sont pas pris en compte pour l’indexation. Par conséquent, les affirmations des fournisseurs sont à prendre avec des pincettes.
Fonctionnalité
SIEM (Security Information and Event Management - gestion des informations et événements de sécurité)
Gestion des logs
Recueil de logs Recueil des logs relatifs à la sécurité Recueil de tous les logs, y compris les logs opérationnels et applicatifs personnalisés
Conservation des logs
Conservation limitée des données de consignation analysées et normalisées
Conservation plus longue des données de consignation brutes et analysées
Création de rapports
Création de rapports en temps réel à des fins de sécurité
Création de rapports génériques et historiques
Analyse Corrélation, évaluation des menaces, hiérarchisation des événements
Analyse en texte intégral, étiquetage
Alertes et notifications
Création de rapports avancés à des fins de sécurité
Alerte simple pour tous les logs
Autres fonctionnalités
Gestion des incidents, autres analyses des données de sécurité
Évolutivité élevée en termes de collecte et de recherche
5www.netiq.com
Récemment, la technologie SIEM traditionnelle a été combinée à l’utilisation massive de la
technologie de gestion des logs. Cette dernière vise à recueillir un vaste éventail de logs à des fins
multiples, de la réponse aux incidents de sécurité à la conformité aux réglementations, en passant
par la gestion des systèmes et le dépannage des applications.
Cas pratiques d’utilisation des systèmes de gestion des logs et des outils SIEM
Avant d’aborder l’architecture commune des systèmes de gestion des logs et des outils SIEM,
nous devons présenter brièvement les cas pratiques d’utilisation courants exigeant le déploiement
d’un produit SIEM par une entreprise cliente. Nous allons commencer par trois principaux types
de cas pratiques d’utilisation de très haut niveau :
1. Sécurité à des fins de détection et d’enquête. Ce cas pratique d’utilisation est parfois appelé gestion des menaces . Il vise à détecter et à répondre aux attaques, aux infections de logiciels malveillants, au vol de données et à d’autres problèmes de sécurité .
2. Conformité aux réglementations (mondiales) et aux stratégies (locales). Ce cas pratique d’utilisation porte sur la mise en conformité aux exigences des lois, mandats et cadres réglementaires en vigueur, mais également aux stratégies locales des entreprises .
3. Fonctionnement normal et dépannage au niveau du réseau, du système et de l’exploitation. Ce cas pratique d’utilisation est principalement spécifique à la gestion des logs . En outre, il est lié aux problèmes des systèmes d’enquête mais aussi au monitoring de la disponibilité des systèmes et des applications .
À un niveau plus détaillé, les cas pratiques d’utilisation en matière de sécurité et de conformité se
retrouvent dans plusieurs scénarios. Examinons-les en détail.
Le premier scénario implique un centre d’opérations de sécurité (Security Operations Center ou
SOC). Habituellement, il requiert l’utilisation massive de fonctions SIEM, comme les vues et la
corrélation en temps réel. Une entreprise cliente SIEM emploie des analystes connectés 24 h/24
et 7 j/7 qui gèrent les alertes de sécurité au fur et à mesure de leur signalement. Il s’agissait
du premier cas pratique d’utilisation des technologies SIEM lors de leur avènement dans les
années 1990. Aujourd’hui, seules les grandes entreprises agissent de la sorte.
Le cas pratique d’utilisation suivant est parfois qualifié de mini-scénario SOC. Dans ce cas, le
personnel en charge de la sécurité utilise des vues à retardement non prises en temps réel afin de
repérer les éventuels problèmes de sécurité (dans ce modèle, les analystes sont présents aux heures
de bureau). Les analystes ne se connectent que quelques heures chaque jour. Ils passent uniquement
en revue les alertes et rapports requis au moment de leur connexion. Par conséquent, ils ne travaillent
pas en quasi temps réel sauf si des événements surviennent lorsqu’ils sont connectés au produit.
Le troisième scénario est un scénario SOC automatisé : une entreprise configure ses outils SIEM
afin qu’ils émettent des alertes en fonction de règles précises. Puis, elle ne s’en occupe plus
jusqu’au déclenchement d’une alerte. Les analystes ne se connectent jamais sauf s’il est nécessaire
Les trois principaux cas pratiques d’utilisation sont les suivants :
Sécurité à des fins de détection et d’enquête
Conformité aux réglementations (mondiales) et aux stratégies (locales)
Fonctionnement normal et dépannage au niveau du réseau, du système et de l’exploitation
6
Livre blancLe guide complet de la gestion des logs et événements
d’enquêter sur des alertes spécifiques, de passer en revue des rapports de manière hebdomadaire
ou mensuelle ou encore d’effectuer d’autres tâches peu courantes. Il s’agit du cas pratique
d’utilisation dont souhaitent bénéficier de nombreuses petites entreprises mais que très peu de
produits SIEM proposent, tout au moins sans nécessiter une personnalisation à grande échelle. Il
convient également de noter que les sociétés achètent souvent des produits SIEM dans l’espoir de
les utiliser comme un SOC automatisé. Malheureusement, leurs attentes sont rarement satisfaites.
Les technologies de gestion des logs jouent également un rôle dans d’autres scénarios
n’appartenant pas au domaine de la sécurité. En effet, la gestion des systèmes et le dépannage
des applications représentent deux importants cas pratiques d’utilisation supplémentaires pour
les systèmes de gestion des logs. Une fois l’application déployée et sa consignation configurée,
le système de gestion des logs permet de passer rapidement en revue les logs d’erreurs et
d’exception. Il examine également les récapitulatifs de l’activité normale des applications afin d’en
déterminer la santé et de dépanner les éventuelles irrégularités.
Dans cette dernière catégorie, un scénario concerne la création de rapports sur l’état de
conformité. Dans ce cas, les analystes ou les responsables de la sécurité étudient les rapports
afin d’y déceler tout problème de conformité. Cet examen est mené toutes les semaines, tous
les mois ou selon la fréquence exigée par une réglementation spécifique. Cette tâche n’est pas
nécessairement effectuée à des fins de sécurité ou de fonctionnement. Ce cas pratique d’utilisation
constitue souvent une phase de transition. L’entreprise est susceptible de l’abandonner par la
suite au profit des cas pratiques d’utilisation précédemment cités. Ce scénario implique le plus
souvent le déploiement d’outils de gestion des logs. Toutefois, il n’est pas rare qu’un produit SIEM
soit également utilisé à des fins de conformité. Les exigences de conservation à long terme des
logs remettent fréquemment en question ce déploiement.
Étant donné que les logs sont essentiels au respect des exigences de conformité, étudions
quelques réglementations en détail.
PCI-DSS La norme de sécurité informatique des données de l’industrie des cartes de paiement (Payment
Card Industry Data Security Standard ou PCI-DSS) s’applique aux entreprises qui gèrent
des transactions par carte de crédit. Elle exige la consignation d’informations spécifiques, la
conservation des logs et la mise en place de procédures d’examen quotidien des logs.
Même si la consignation est comprise dans l’ensemble des conditions PCI, la norme PCI-DSS
intègre également la condition 10 relative à la consignation et à la gestion des logs. Dans le cadre
de cette condition, les logs de tous les composants systèmes doivent être examinés au moins
quotidiennement. Par ailleurs, la norme PCI-DSS indique que l’entreprise doit garantir l’intégrité
de ses logs en mettant en place un monitoring de l’intégrité des fichiers et un logiciel de détection
des modifications apportées aux logs. Elle exige également le stockage des logs provenant des
systèmes concernés pendant au moins un an.
En effet, la gestion des systèmes et le dépannage des applications représentent deux importants cas pratiques d’utilisation supplémentaires pour les systèmes de gestion des logs.
7www.netiq.com
FISMA La loi FISMA (Federal Information Security Management Act), votée en 2002, accentue le besoin
des agences fédérales de développer, de documenter et de mettre en oeuvre un programme au
sein de tous leurs services afin de sécuriser les systèmes d’informations sous-jacents à leurs
opérations et ressources. La publication NIST SP 800-53 intitulée « Recommended Security
Controls for Federal Information Systems » (Contrôles de sécurité recommandés pour les
systèmes d’informations fédéraux) décrit les contrôles de gestion des logs, notamment les
processus de génération, de vérification, de protection et de conservation des suivis d’audit, mais
aussi les étapes à suivre en cas d’échec d’audit.
La publication NIST 800-92 intitulée « Guide to Computer Security Log Management » (Guide
pour la gestion des logs de sécurité informatique) simplifie la conformité à la loi FISMA tout
en garantissant un dévouement complet à la gestion des logs. Elle décrit le besoin des agences
fédérales en la matière ainsi que les méthodes pour mettre en place et gérer des infrastructures de
gestion des logs efficaces prenant en charge la génération, l’analyse, le stockage et le monitoring
des logs. La publication NIST 800-92 explique deux principes importants. Tout d’abord,
il est essentiel d’analyser les différents types de logs provenant de sources variées.
En outre, il faut clairement définir les responsabilités et rôles spécifiques aux équipes et
personnes impliquées dans la gestion des logs.
HIPAA La loi fédérale HIPAA (Health Insurance Portability and Accountability Act) votée en 1996 décrit
les normes de sécurité relatives aux informations sur la santé. La publication NIST SP 800-66
intitulée « An Introductory Resource Guide for Implementing the Health Insurance Portability
and Accountability Act Security Rule » (Guide de ressources pour la mise en oeuvre de la loi de
sécurité HIPAA) répertorie les conditions requises pour la gestion des logs afin de sécuriser les
informations sur la santé protégées par un système électronique. La section 4.1 décrit la nécessité
de vérifier régulièrement les activités des systèmes d’informations, notamment les logs d’audit,
les rapports d’accès et les rapports de suivi des incidents de sécurité. La section 4.22 précise
que la documentation relative aux actions et aux activités doit être conservée pendant au moins
six ans. On considère parfois que les logs en font partie. La loi HITECH (Health Information
Technology for Economic and Clinical Health) votée en 2009 vise à accélérer la mise en oeuvre de
la réglementation HIPAA au cours des prochaines années.
Les outils SIEM disponibles actuellement, notamment NetIQ® Sentinel™, sont prisés autant par les grandes entreprises figurant dans les classements Fortune 1000 ou Global 2000 que par les PME.
La loi HITECH (Health Information Technology for Economic and Clinical Health) votée en 2009 vise à accélérer la mise en oeuvre de la réglementation HIPAA au cours des prochaines années.
8
Livre blancLe guide complet de la gestion des logs et événements
Tendances technologiques
La technologie SIEM a vu le jour il y a plus de 10 ans. Elle a connu tellement de bouleversements
au cours de cette décennie que l’on pourrait lui consacrer un livre blanc tout entier. Nous allons
cependant nous contenter de souligner quelques tendances de la technologie SIEM. À l’origine,
elle était destinée aux grandes entreprises internationales et aux agences gouvernementales
traitant des informations sensibles. Aujourd’hui, elle s’adapte graduellement aux marchés des
plus petites sociétés. De nombreux analystes avaient prédit que les principaux fournisseurs de
solutions SIEM s’attaqueraient aux marchés des moyennes entreprises à l’horizon 2011. Résultat :
les clients plus modestes bénéficient désormais d’outils optimisés de gestion de la sécurité.
Autre tendance : la technologie SIEM et la gestion des logs sont davantage considérés comme des
outils aux rôles distincts et la plupart des fournisseurs SIEM offrent désormais également des
solutions de gestion des logs. Ils prennent également en charge des cas pratiques d’utilisation plus
étendus pour les outils SIEM, notamment les opérations informatiques, l’analyse des fraudes,
le dépannage des applications mais aussi la gouvernance, les risques et la conformité pour les
objectifs de mesures des risques et de la gouvernance de haut niveau.
Par ailleurs, les processus de gestion et les opérations informatiques commencent à se rapprocher
de la gestion de la sécurité. Même si certains analystes annoncent cette tendance depuis plusieurs
années, celle-ci ne s’était pas encore pleinement matérialisée jusqu’à présent. Toutefois, de
nombreux analystes prédisent que la convergence entre la gestion de la sécurité et la gestion des
opérations informatiques va se poursuivre et que les outils de sécurité seront davantage liés aux
outils d’exploitation informatique, comme les outils de gestion des systèmes et des réseaux.
Exemple de scénario de gestion des logs et des outils SIEM
Cette étude de cas décrit le déploiement d’une solution de gestion des logs et des outils SIEM
afin de garantir la conformité aux conditions de la norme PCI-DSS à l’échelle d’une vaste chaîne
de commerces de détail. Le détaillant a décidé de déployer une solution commerciale de gestion
des logs lorsque son expert PCI lui a signalé que ce serait nécessaire pour passer une évaluation.
Un fournisseur de solutions de gestion des logs a ensuite conseillé au détaillant d’opter pour
une solution SIEM en parallèle. Alors qu’il ne s’occupait auparavant pas du tout de ses logs
directement, le détaillant exécute désormais un système de gestion des logs avancé et assure une
corrélation en temps réel.
Toutefois, de nombreux analystes prédisent que la convergence entre la gestion de la sécurité et la gestion des opérations informatiques va se poursuivre et que les outils de sécurité seront davantage liés aux outils d’exploitation informatique, comme les outils de gestion des systèmes et des réseaux.
9www.netiq.com
Ce projet a été mis sur pied en quelques mois grâce à une approche par étapes. L’équipe
informatique du détaillant s’est basée sur une évaluation des risques afin de mettre en oeuvre la
solution de l’extérieur vers l’intérieur de l’entreprise. Elle a commencé par les pare-feux réseau
périmétriques (DMZ). Puis, elle a intégré des logs supplémentaires dans un système de gestion
des logs tout en définissant des règles de corrélation et en exécutant des rapports provenant d’un
package de conformité à la norme PCI-DSS du fournisseur. Au fur et à mesure que l’équipe a
appris à réagir aux alertes, ses processus ont gagné en maturité et l’entreprise a pu commencer à
utiliser davantage de fonctions SIEM.
Le projet est donc globalement considéré comme une mise en oeuvre réussie des conditions
de consignation de la norme PCI. L’entreprise a réussi l’évaluation PCI haut la main et a été
félicitée pour son approche exhaustive de la consignation et du monitoring de la sécurité. En
outre, l’équipe en charge de la sécurité a démontré que sa mise en oeuvre d’une solution SIEM
PCI garantit la conformité de l’entreprise à des conditions de conformité supplémentaires. En
effet, la norme PCI-DSS couvre essentiellement les mêmes domaines en matière de gouvernance
informatique mais entre plus dans les détails. Parallèlement, les outils de gestion des logs ont
soutenu les fonctions d’exploitation et l’efficacité informatique globale tandis que les outils SIEM
ont fourni à l’entreprise la base dont elle avait besoin pour développer ses fonctions de réponse et
de détection en temps réel.
Architecture des outils SIEM et de la gestion des logs
Étant donné les différences entre ces technologies, de nombreuses entreprises ont déployé
en parallèle un système de gestion des logs et des outils SIEM ou envisagent d’améliorer
un déploiement existant de l’une de ces technologies en y intégrant l’autre. Quelles sont les
architectures courantes réunissant la gestion des logs et des outils SIEM ?
Nous allons qualifier le scénario le plus courant de « protection SIEM ». Parmi les entreprises
qui ont déployé des solutions SIEM héritées, beaucoup ont essayé d’envoyer une trop grande
quantité de données vers leurs outils SIEM, ce qui a entraîné une surcharge et parfois une perte
de fonctions et de données essentielles. Pour résoudre ce problème, elles ont acheté une solution
de gestion des logs et l’ont déployé en amont de leur solution SIEM.
_______________________________________________________________
De nombreuses entreprises ont déployé en parallèle un système de gestion des logs et des outils SIEM ou envisagent d’améliorer un déploiement existant de l’une de ces technologies en y intégrant l’autre.
10
Livre blancLe guide complet de la gestion des logs et événements
_______________________________________________________________
Il n’est pas rare d’envoyer uniquement un événement sur dix provenant de la protection des logs à un outil SIEM sous-jacent. Parallèlement, tous les événements reçus sont archivés par l’outil de gestion des logs.
Fig. 2
Selon un autre scénario émergeant, la gestion des logs est déployée en premier afin de créer une plate-forme de consignation d’entreprise . Ensuite, une solution SIEM est ajoutée en tant qu’application de cette plate-forme . Ce scénario, que l’on peut appeler « ajout de solution SIEM », représente jusqu’à 50 % des déploiements SIEM actuels . Par exemple, une entreprise opte pour un outil de gestion des logs . Puis, elle comprend petit à petit qu’elle a besoin de processus de corrélation, de visualisation, de monitoring et de flux de travail, entre autres, mais aussi qu’elle est davantage capable de les gérer . Un tel scénario s’avère le plus logique pour la plupart des entreprises, comme nous vous l’expliquons plus bas .
_______________________________________________________________
SIEM
Gestion des logs
Fig. 1
Dans cette situation, un outil de gestion des logs de nature bien plus évolutive est déployé en amont de la solution SIEM afin de filtrer et de protéger un outil SIEM moins évolutif des flux de logs extrêmes . Il n’est pas rare d’envoyer uniquement un événement sur dix provenant de la protection des logs à un outil SIEM sous-jacent . Parallèlement, tous les événements reçus sont archivés par l’outil de gestion des logs . Par exemple, si le volume total des logs équivaut à 40 000 messages de logs par seconde, l’outil SIEM recevra uniquement 4 000 messages par seconde .
SIEM
Gestion des logs
11www.netiq.com
Il est nécessaire d’améliorer sa capacité de réponse avant d’être confronté à une situation nécessitant une réaction plus rapide qu’à l’accoutumée. En effet, il est bien plus facile de se préparer à fournir une réponse que d’assurer un monitoring.
Dans la situation suivante, une solution de gestion des logs et des outils SIEM sont déployés en
parallèle et simultanément. Il s’agit d’un « scénario émergent » : de plus en plus d’entreprises se
procurent ces deux solutions en même temps, souvent auprès du même fournisseur. Ainsi, si une
société comprend qu’elle a besoin d’un processus de corrélation, elle doit recueillir et sauvegarder
l’ensemble des logs mais aussi pouvoir effectuer des analyses de données brutes et des recherches
efficaces.
_______________________________________________________________
_______________________________________________________________
Le scénario suivant consiste à déployer des outils SIEM accompagnés d’un système de gestion
des logs qui sert de solution d’archivage des logs traités et autres. Ce scénario se met en place
lorsqu’une entreprise achète une importante solution SIEM à des fins de monitoring de la sécurité
et comprend en l’utilisant qu’elle ne répond pas à tous ses besoins. Elle décide donc de déployer
un outil de gestion des logs afin d’y envoyer l’ensemble des logs et d’analyser les logs bruts rejetés
par l’outil SIEM. Il s’agit, notamment, des logs que l’outil ne sait pas analyser, normaliser ou
classer. De là découle un cas pratique d’utilisation plus étendu, allant du monitoring de la sécurité
à la réponse aux incidents en passant par la conformité à la norme PCI-DSS.
_______________________________________________________________
Ainsi, si une société comprend qu’elle a besoin d’un processus de corrélation, elle doit recueillir et sauvegarder l’ensemble des logs, mais aussi pouvoir effectuer des analyses de données brutes et des recherches efficaces.
Gestion des logsSIEM
Fig. 3
12
Livre blancLe guide complet de la gestion des logs et événements
_______________________________________________________________
Par ailleurs, les cas pratiques d’utilisation des solutions de gestion des logs uniquement sont
multiples et continuent de s’accroître tandis que les scénarios de déploiements des outils SIEM
seuls se font plus rares et sont susceptibles de continuer à diminuer.
Gestion des logs ou outils SIEM : quelle technologie déployer en priorité ? Heureusement, la réponse à cette question est très simple. Si vous possédez des logs, vous avez
besoin d’une solution de gestion des logs. Ceci s’applique aussi bien aux entreprises dotées d’un
seul serveur qu’aux entreprises qui en possèdent 100 000. Même si la technologie déployée pour
gérer les logs sera bien entendu différente, ces sociétés ont besoin d’une solution de gestion des
logs dès lors qu’elles possèdent des logs. Par exemple, si elles doivent réviser des logs provenant
d’une seule machine, les outils intégrés au système d’exploitation sont généralement suffisants.
Cependant, si leur volume quotidien de logs s’élève à 100 Go (une situation tout à fait réaliste),
des outils sophistiqués et, par conséquent, coûteux sont nécessaires.
Dans un rapport de 2009 intitulé « How to Implement SIEM Technology » (Comment mettre
en oeuvre la technologie SIEM), Gartner recommande vivement de « déployer les fonctions de
gestion des logs avant de tenter un déploiement à grande échelle de la gestion des événements
en temps réel ». En outre, lorsque la technologie SIEM se fonde sur un besoin de conformité, le
déploiement doit s’effectuer dans le même ordre : « les premières étapes d’un déploiement SIEM
principalement orienté vers la norme PCI consistent à déployer des fonctions de gestion des logs
pour les systèmes concernés par l’évaluation PCI ». Bref, les entreprises doivent améliorer leur
capacité de réponse avant d’être confrontées à une situation nécessitant une réaction plus rapide
qu’à l’accoutumée.
Si vous possédez des logs, vous avez besoin d’une solution de gestion des logs. Ceci s’applique aussi bien aux entreprises dotées d’un seul serveur qu’aux entreprises qui en possèdent 100 000.
Dans un rapport de 2009 intitulé « How to Implement SIEM Technology » (Comment mettre en oeuvre la technologie SIEM), Gartner recommande vivement de « déployer les fonctions de gestion des logs avant de tenter un déploiement à grande échelle de la gestion des événements en temps réel ».
Gestion des logs
SIEM
Fig. 4
13www.netiq.com
Qu’en est-il des entreprises ayant déjà déployé des outils SIEM hérités ? Nous leur conseillons
d’envisager le déploiement d’une solution de gestion des logs le plus rapidement possible.
Lorsqu’elles seront capables de traiter un vaste éventail de logs, leurs fonctions d’enquête seront
optimisées, ce qui garantira leur conformité aux conditions des réglementations en vigueur.
Toutes les entreprises doivent-elles passer d’une solution de gestion des logs aux outils SIEM ? Une entreprise a déployé un outil de gestion des logs et a commencé à l’utiliser de manière
efficace afin de garantir sa sécurité et sa conformité mais aussi à des fins d’exploitation. Que se
passe-t-il ensuite ? La progression naturelle et logique consiste à déployer un outil SIEM afin de
gérer les événements en quasi temps réel.
Ce livre blanc est le premier document qui présente les critères requis afin d’effectuer un tel
développement. Si les entreprises effectuent cette transition trop tôt, elles perdront leur temps
et leur énergie et n’amélioreront pas l’efficacité de leurs opérations de sécurité. En revanche, en
attendant trop longtemps, elles ne parviendront jamais à développer les fonctions nécessaires
pour assurer leur sécurité.
Les critères requis sont les suivants :
Réponse. Tout d’abord, l’entreprise doit être capable de répondre à des alertes dès leur signalement.
Monitoring. L’entreprise doit posséder ou commencer à développer une fonction de monitoring de la sécurité en mettant en place un centre d’opérations de sécurité ou, tout au moins, une équipe chargée du monitoring périodique.
Personnalisation et réglage. L’entreprise doit accepter d’assumer la responsabilité du réglage et de la personnalisation des outils SIEM déployés. Les déploiements de solutions SIEM prêts à l’emploi sont rarement couronnés de succès ou réussissent peu souvent à atteindre leur plein potentiel.
Définissons ces critères plus en détail.
Tout d’abord, l’entreprise doit être capable de répondre à des alertes dès leur signalement. De
nombreux fournisseurs assurent que la sécurité des entreprises modernes doit fonctionner en
temps réel à l’instar de leurs activités. Or, il semble que peu de sociétés soient capables d’atteindre
cet objectif à l’heure actuelle. Avant de déployer une solution SIEM, demandez-vous si votre
sécurité fonctionne en temps réel ou non. Vous estimez peut-être que c’est le cas la plupart du
temps ou que vous atteignez quasiment cet objectif. Les systèmes de détection des intrusions
sur le réseau repèrent les attaques menées hors ligne en quelques microsecondes ; les pare-
feux bloquent les connexions en cause et les antivirus s’efforcent d’identifier les virus dès leur
apparition.
Avant de déployer une solution SIEM, demandez-vous si votre sécurité fonctionne en temps réel ou non.
14
Livre blancLe guide complet de la gestion des logs et événements
C’est pourquoi peu d’entreprises acceptent d’acheter un système de détection des intrusions
sur le réseau (Network Intrusion Detection System ou NIDS) qui les avertira d’une attaque sur
trois uniquement. Cependant, ces mêmes entreprises demandent à leurs analystes de sécurité
de vérifier les alarmes IDS tous les matins. S’ils identifient qu’un système a été gravement
compromis, la capacité du système NDIS à répondre en quelques millisecondes ne sera d’aucune
aide au contraire de la capacité du personnel à réagir en quelques heures. Ainsi, il est toujours
acceptable d’enquêter sur une alerte menant à l’identification d’un système gravement compromis
le lendemain de son signalement.
Par ailleurs, si un fichier infecté par un virus entre dans le système et si le logiciel peut le nettoyer
en temps réel, le problème est alors résolu. Cependant, si le logiciel antivirus détecte le code
malveillant mais ne peut ni le supprimer ni le mettre en quarantaine automatiquement et émet
à la place une alerte (comme avec certaines portes dérobées ou certains chevaux de Troie), la
responsabilité incombe aux analystes, qui auront probablement déjà perdu plusieurs heures.
Face aux menaces sophistiquées actuelles, un tel retard peut engendrer de graves violations, dont
l’élimination pourrait prendre plusieurs mois. Par conséquent, les règles de corrélation avec état
et d’alerte avancée garantiront des réponses en moins d’une seconde. Toutefois, vous devez être
prêt à réagir.
Si une entreprise ne possède pas de SOC ni aucune fonction de monitoring de la sécurité ou du
fonctionnement accompagnés d’accords de niveau de service, bon nombre des fonctions SIEM ne
seront pas pleinement utilisées. Au cours de la transition d’une utilisation purement réactive des
logs au monitoring de la sécurité généralisé, la première étape consiste couramment à utiliser un
monitoring périodique à retardement, ce qui implique d’examiner les rapports de logs tous les
matins. Pour ce faire, il est nécessaire de faire appel à un outil de gestion des logs ou à un outil
SIEM.
Le dernier critère requis pour la transition concerne la fonction de personnalisation et de réglage.
L’entreprise doit accepter d’assumer la responsabilité du réglage et de la personnalisation de
l’outil SIEM déployé. Ainsi, ses puissantes fonctions personnalisables l’aideront à résoudre le
problème auquel elle est confrontée. Par ailleurs, l’entreprise peut faire appel à un cabinet de
consulting pour effectuer le réglage requis. Chaque entreprise est unique. Afin d’être aussi efficace
que possible, la solution SIEM doit prendre en compte les processus métiers uniques existants.
Pour ce faire, il peut être nécessaire de créer des alertes, de définir des règles de corrélation ou de
personnaliser des rapports afin de connaître la situation de l’entreprise en matière de conformité
ou de sécurité. Les entreprises qui optent pour des déploiements prêts à l’emploi en espérant
bénéficier d’une solution SIEM capable de remplacer leur analyste sont souvent déçues.
Si une entreprise ne possède pas de SOC ni aucune fonction de monitoring de la sécurité ou du fonctionnement accompagnés d’accords de niveau de service, bon nombre des fonctions SIEM ne seront pas pleinement utilisées.
15www.netiq.com
Par conséquent, les sociétés qui n’envisagent pas d’abandonner immédiatement leur processus
de gestion des logs orienté vers la conformité ou autre devraient tout de même choisir un outil de
consignation afin d’être en mesure d’opter pour une solution SIEM ultérieurement. Même si les
entreprises ne souhaitent pas, de prime abord, envisager d’autres domaines que la conformité,
de nombreux déploiements de solutions de gestion des logs et d’outils SIEM sont basés sur des
modèles communément qualifiés de conformité renforcée. Ainsi, la société achète un outil dans
un cadre réglementaire spécifique et l’utilise ensuite pour relever de nombreux autres défis
informatiques ou sécuritaires.
Toutefois, certains outils de gestion des logs ne permettent pas une telle migration vers une
solution SIEM. En effet, les outils simples qui vous permettent uniquement de recueillir des logs
bruts et d’y effectuer des recherches peuvent s’avérer extrêmement utiles. Cependant, ils ne vous
permettront pas de bénéficier facilement d’une normalisation complète, d’une catégorisation
et d’autres enrichissements de données de consignation orientés vers la sécurité. Si votre outil
recueille et conserve des archives de logs bruts mais ne peut pas les associer à une solution SIEM
capable d’utiliser de telles données afin de garantir une analyse et un monitoring de la sécurité,
il vous permettra généralement pas de migrer vers un système de monitoring. L’entreprise devra
alors acheter d’autres outils quand elle sera prête à garantir un monitoring en temps réel.
Étant donné que l’utilisation efficace d’une solution SIEM engendre une diminution des menaces
directes grâce à son analyse avancée orientée vers la sécurité (uniquement si l’entreprise est prête
à déployer un outil SIEM), le modèle de conformité renforcée s’avère pertinent. Concrètement,
il permet à l’entreprise de se rapprocher du principe d’écran unique en matière de gestion de la
sécurité.
Après la gestion des logs et des outils SIEM : la courbe de maturité Une entreprise a déployé une solution de gestion des logs et des outils SIEM, qui l’aident à
garantir sa conformité et lui assurent des avantages en termes de sécurité. Quelle est l’étape
suivante ? La courbe de maturité illustre toutes les situations, de l’ignorance totale des logs au
monitoring de la sécurité en quasi temps réel, en passant par la collecte et la conservation des
logs, les enquêtes occasionnelles et l’examen périodique des logs.
La tendance représentée ci-dessous montre l’évolution d’une entreprise ignorante, puis réactive
à retardement, réactive rapidement et enfin proactive et consciente des événements survenant
au sein de son environnement informatique. Les entreprises qui tentent de passer de l’ignorance
complète à la proactivité en une seule étape y parviennent rarement, voire jamais.
_______________________________________________________________
La courbe de maturité illustre toutes les situations, de l’ignorance totale des logs au monitoring de la sécurité en quasi temps réel, en passant par la collecte et la conservation des logs, les enquêtes occasionnelles et l’examen périodique des logs.
16
Livre blancLe guide complet de la gestion des logs et événements
_______________________________________________________________
Quelle est l’étape suivante dans le cadre de cette transition ? Tout d’abord, les entreprises doivent
améliorer en permanence la portée et la précision de leur déploiement SIEM en l’intégrant à
davantage de systèmes en vue d’optimiser l’utilisation de ses fonctions d’analyse. Ainsi, les outils
SIEM peuvent accomplir leur mission principale, à savoir le monitoring de la sécurité, et résoudre
les nouveaux problèmes, notamment les fraudes, les menaces internes, le monitoring des
applications et le monitoring général de l’activité des utilisateurs. Les outils SIEM commencent à
obtenir davantage d’informations et à passer du réseau aux applications, d’un nombre limité de
sources de données à un déploiement à l’échelle de l’entreprise. Simultanément, une organisation
de sécurité se met en place et développe de meilleures procédures de fonctionnement qui
garantissent une plus grande souplesse à l’entreprise. Au fur et à mesure de l’élargissement du
déploiement, il est essentiel de ne pas oublier qu’une approche par étapes est la seule façon de
réussir.
Quels systèmes pourraient améliorer la mission de la solution SIEM et lui permettre de
résoudre d’autres problèmes ? Un des exemples les plus intéressants implique l’utilisation
d’informations provenant de systèmes de gestion des identités, comme NetIQ Identity Manager.
Les informations disponibles au sein de ce système comprennent l’identité des utilisateurs (nom,
profession, rôle, affiliation à une business unit) mais aussi les droits d’accès à divers systèmes et
applications. Il est indispensable de connaître les utilisateurs et de savoir quelles actions ils sont
autorisés à entreprendre afin d’assurer un monitoring de la sécurité des activités internes. Par
exemple, cela permet de créer une identité unifiée pour chaque utilisateur, puis de l’utiliser afin de
Les entreprises doivent améliorer en permanence la portée et la précision de leur déploiement SIEM en l’intégrant à davantage de systèmes en vue d’optimiser l’utilisation de ses fonctions d’analyse.
Fig. 5
Ignorance des logs : les logs ne sont ni recueillis ni examinés.
Collecte des logs : les logs sont recueillis et stockés mais jamais examinés.
Enquête sur les logs : les logs sont recueillis et examinés en cas d’incident
Création de rapports sur les logs : les logs sont recueillis et les rapports sont examinés tous les mois.
Examen des logs : les logs sont recueillis et examinés tous les jours (monitoring différé).
Monitoring des logs : les informations de sécurité font l’objet d’un monitoring en quasi temps réel.
17www.netiq.com
surveiller les actions de cette personne sur plusieurs systèmes, même en cas de noms d’utilisateur
et de comptes multiples.
En outre, l’intégration d’un système de gestion des identités permet à un produit SIEM de
différencier les connexions officielles autorisées des tentatives de connexion non autorisées via
une porte dérobée. En outre, une telle intégration permet de mettre en place le monitoring de la
séparation des tâches (separation-of-duty ou SoD) en indiquant à la solution SIEM les rôles non
autorisés à effectuer des actions spécifiques.
_______________________________________________________________
_______________________________________________________________
Un système de gestion des ressources contiendra également des informations détaillées
similaires sur l’ensemble des ressources informatiques détenues par l’entreprise. Tout comme
pour les utilisateurs, la société peut alors extraire les rôles professionnels des ressources,
l’importance commerciale, la pertinence en termes de conformité, les emplacements et noms
des administrateurs mais aussi d’autres informations sur les fonctions des ressources et les
personnes en charge. De telles données optimisent de manière significative le calcul des risques
et les fonctions de hiérarchisation des événements de la solution SIEM. Il ne faut pas oublier
que, même si de nombreux fournisseurs affirment garantir l’intégration des identités, la plupart
d’entre eux se contentent d’effectuer une simple recherche LDAP (Lightweight Directory Access
Protocol). Ces systèmes ne bénéficient donc pas de toutes les données riches qu’un système de
gestion des identités pourrait fournir afin d’aider une solution SIEM à déterminer si les activités
sont malveillantes ou pertinentes en termes de réglementation.
Il ne faut pas oublier que, même si de nombreux fournisseurs affirment garantir l’intégration des identités, la plupart d’entre eux se contentent d’effectuer une simple recherche LDAP (Lightweight Directory Access Protocol). Ces systèmes ne bénéficient donc pas de toutes les données riches qu’un système de gestion des identités pourrait fournir afin d’aider une solution SIEM à déterminer si les activités sont malveillantes ou pertinentes en termes de réglementation.
Logs : activités, actions, événements
Gestion des événements et des informations de sécurité
Données d’analyse de vulnérabilité
Gestion des identités et des accès
Utilisateurs : identités, rôles, droits
Fig. 6
18
Livre blancLe guide complet de la gestion des logs et événements
Il est possible de bénéficier de niveaux supplémentaires d’intégration et, ainsi, de plus
d’informations, en intégrant au produit SIEM des bases de données de gestion de la configuration
(CMDB). Grâce à de telles intégrations, un produit SIEM peut corréler les modifications détectées
sur divers systèmes et applications avec des changements autorisés et approuvés.
Erreurs Lors de la planification et de la mise en oeuvre de la collecte de logs et d’une infrastructure
d’analyse (que ce soit pour une solution de gestion des logs ou des outils SIEM), les entreprises
apprennent souvent qu’elles n’exploitent pas le plein potentiel de tels systèmes. Elles remarquent
parfois même une perte d’efficacité. Cela est souvent dû aux erreurs de mise en oeuvre courantes
suivantes.
Nous commencerons par l’erreur évidente, mais malheureusement bien trop fréquente, qu’est
l’absence totale de consignation, même à l’ère de la loi Sarbanes-Oxley (SOX) et de la norme
PCI DSS. Cette erreur détruit toute possibilité de bénéficier d’une solution de gestion des logs ou
d’outils SIEM.
Une autre version de cette erreur consiste à n’assurer aucune consignation et à ne pas le découvrir
avant qu’il ne soit trop tard.
Comment une entreprise peut-il être trop tard ? Si une entreprise ne dispose d’aucun log, elle peut
connaître une perte de revenus. Selon les conditions de consignation de la norme PCI-DSS, les
violations peuvent entraîner une annulation de vos privilèges de traitement des cartes de crédit
par Visa ou MasterCard et, par conséquent, vous exposer à la faillite. La réputation de l’entreprise
peut également être entachée : des numéros de certaines cartes de crédit contenus dans vos bases
de données sont volés, mais les médias signalent le vol de l’ensemble des cartes de crédits, soit
40 millions, annonce que vous ne pouvez démentir. Enfin, l’entreprise peut même perdre sa liberté
(lire les différentes histoires terrifiantes diffusées par les médias au sujet de la loi SOX).
Une fois la solution de gestion des logs et les outils SIEM mis en oeuvre, votre entreprise peut progresser sur l’échelle de maturité afin de bénéficier d’une visibilité complète sur le réseau et les applications, d’un monitoring des activités des utilisateurs et de l’intégration à différents systèmes.
Même les entreprises bien préparées commettent cette erreur. Prenons un exemple récent. La
consignation est-elle activée sur votre serveur Web ? Bien entendu : cette option est installée
par défaut sur les serveurs Web les plus populaires, à savoir Apache et Microsoft IIS. Le système
d’exploitation de votre serveur consigne-t-il les messages ?
Selon les conditions de consignation de la norme PCI-DSS, les violations peuvent entraîner une annulation de vos privilèges de traitement des cartes de crédit par Visa ou MasterCard et, par conséquent, vous exposer à la faillite.
19www.netiq.com
Bien entendu : personne n’a jamais supprimé le contenu du dossier /var/log/messages. Et qu’en
est-il de votre base de données ? L’option par défaut d’Oracle n’effectue aucune consignation des
audits d’accès aux données. Microsoft SQL est-elle une meilleure solution ? Malheureusement, la
réponse est non. Vous devez plonger au coeur du système avant même de commencer à générer
un suivi d’audit de niveau modéré.
Par conséquent, afin d’éviter de commettre cette erreur, il est souvent nécessaire de ne pas
s’arrêter aux paramètres par défaut afin de s’assurer que la consignation est activée au niveau des
logiciels et du matériel. Dans le cas d’Oracle, par exemple, cela peut se résumer à s’assurer que la
variable « audit trail » (suivi d’audit) est configurée sur « db ». Pour d’autres systèmes, la tâche
peut s’avérer plus compliquée.
L’absence d’examen des logs est la deuxième erreur. S’il est important de s’assurer de
l’existence de logs, de les recueillir et de les stocker, cela ne suffit pas. L’objectif pour les
entreprises est de connaître les activités au sein de leur environnement et d’être capables de réagir
mais aussi de prédire les futurs événements. Comme nous l’avons décrit précédemment, il s’agit
seulement d’une étape, pas de l’objectif final. Si votre entreprise vient de commencer à recueillir
les logs après les avoir ignorés, il est important de savoir que vous devrez les examiner par la
suite. Si vous recueillez les logs mais ne les passez pas en revue, cela consiste à documenter votre
propre négligence, particulièrement si votre stratégie de sécurité informatique exige l’examen des
logs.
Par conséquent, une fois la technologie en place et les logs recueillis, vous devez disposer
d’un processus permanent de monitoring et d’examen des actions et des possibles demandes
d’intervention, le cas échéant. En outre, les logs de monitoring ou d’examen du personnel doivent
contenir suffisamment d’informations afin de déterminer leur signification exacte et les actions
éventuellement requises.
Certaines entreprises se contentent de faire les choses à moitié : elles examinent les logs après
un grave incident, comme un système compromis, une fuite d’informations ou une mystérieuse
panne de serveur, mais elles évitent d’assurer le monitoring et l’examen continus des logs,
souvent en invoquant le manque de ressources. Ainsi, elles se montrent réactives en analysant
les logs, ce qui est essentiel. Toutefois, elles ne comprennent pas l’importance d’être proactives
et de savoir quand un événement négatif va survenir ou quand la situation va s’aggraver. Par
exemple, si vous examinez des logs, vous pouvez apprendre que le basculement a été activé sur un
pare-feu, voire même que la connexion est toujours active. Il est donc probablement nécessaire
d’enquêter sur l’incident. Si vous ne le faites pas et que vous perdez votre connectivité réseau,
vous ne pourrez vous tourner que vers vos précieux logs afin de savoir pourquoi les périphériques
de basculement sont tombés en panne.
L’objectif pour les entreprises est de connaître les activités au sein de leur environnement et d’être capables de réagir mais aussi de prédire les futurs événements.
20
Livre blancLe guide complet de la gestion des logs et événements
Par ailleurs, il est important de souligner que certains types d’entreprises doivent examiner les
fichiers logs et les suivis d’audit, en raison de pressions réglementaires. Comme nous l’avons
mentionné, les réglementations de la loi HIPAA obligent les sociétés médicales à établir un
programme d’analyse et d’enregistrement des audits. La norme de sécurité des données PCI-DSS
contient des dispositions relatives à la collecte des logs mais aussi à leur examen périodique et à
leur monitoring, ce qui indique que la collecte ne se suffit pas à elle-même.
La troisième erreur courante est le stockage des logs pendant un délai trop court. Il est possible de
conserver des événements normalisés pendant 30 jours dans le système de stockage des logs de
fonctionnement d’un système SIEM. En revanche, un système de gestion des logs est requis pour
une conservation à long terme Ainsi, les équipes en charge des opérations informatiques ou de la
sécurité pensent disposer des logs nécessaires pour le monitoring, l’investigation ou le dépannage.
Lorsqu’un incident survient, elles réalisent avec horreur que leurs logs sont tous perdus à cause
d’une stratégie de conservation trop réductrice. Trop souvent, notamment en cas d’attaques
internes, l’incident est identifié après un long délai, pouvant aller jusqu’à plusieurs mois après le
crime ou l’utilisation abusive. Vous avez peut-être réalisé des économies en termes de matériel
de stockage, mais vous pourriez subir des pertes dix fois supérieures à cause de sanctions
réglementaires.
S’il est essentiel pour une entreprise de restreindre ses coûts, la solution consiste parfois à diviser la
conversation en deux parties : le stockage en ligne à court terme plus onéreux et le stockage hors ligne
à long terme, bien moins cher. Un bon outil de gestion des logs permet aux entreprises d’effectuer des
recherches dans les deux zones de stockage de manière transparente, sans déplacer aucune donnée.
Une approche à trois niveaux, également courante et plus appropriée, résout certains problèmes de
limitations rencontrés avec la technique précédente. Dans ce cas, un stockage quasi en ligne, où les
logs sont toujours accessibles et peuvent faire l’objet de recherches, est ajouté au stockage en ligne
à court terme. Les archives de logs les plus anciennes et les moins pertinentes sont transférées au
troisième niveau, par exemple des bandes ou des DVD, où elles peuvent être stockées à moindres frais.
Toutefois, il n’est pas possible d’accéder uniquement aux logs requis. Par exemple, une institution
financière stockait des logs en ligne pendant 90 jours, puis dans le stockage quasi en ligne du système
de gestion des logs pendant deux ans, où il était possible d’effectuer des recherches, et enfin sur des
bandes pendant sept ans au maximum, parfois plus dans certains cas.
La quatrième erreur concerne la hiérarchisation des archives des logs. Même si les entreprises
savent hiérarchiser leurs données afin de mieux organiser leurs efforts d’analyse des logs,
une erreur courante à l’heure actuelle consiste à hiérarchiser les archives de logs avant leur
collecte. En réalité, même certains documents relatifs aux meilleures pratiques recommandent
de recueillir uniquement les données les plus importantes. Mais, quelles sont-elles ? Il s’agit là
d’un manquement des documents d’aide précédemment cités : ils ne définissent pas la notion
d’informations importantes de manière utile. Il existe plusieurs approches à ce problème, mais
elles peuvent mener à des défaillances évidentes en matière de positionnement sur la sécurité
voire saper vos efforts de conformité aux réglementations.
Trop souvent, notamment en cas d’attaques internes, l’incident est identifié après un long délai, pouvant aller jusqu’à plusieurs mois après le crime ou l’utilisation abusive.
21www.netiq.com
Par exemple, de nombreuses entreprises affirmeraient que les logs de prévention et de détection
d’intrus sur le réseau sont intrinsèquement plus importants que les logs du concentrateur du
réseau privé virtuel (VPN), par exemple. Cela est peut-être vrai dans le monde réel où les menaces
externes dominent complètement les réseaux et où l’ensemble des employés et des partenaires
sont dignes de confiance. Les logs du VPN mais aussi ceux des postes de travail et des serveurs
sont les emplacements où vous seriez le plus susceptible de devoir mener une enquête interne
en cas de fuite d’informations ou d’infection d’un logiciel malveillant. Par conséquent, les
affirmations similaires sur la grande importance d’autres types de logs peuvent être tout autant
remises en question. Cela nous amène à réaliser que, malheureusement, vous avez besoin de
recueillir la totalité ou la plupart des archives de logs générées. Mais, êtes-vous vraiment en
mesure de le faire ? Avant de répondre à cette question, essayez de savoir si vous pouvez identifier
les logs les plus importants avant même de les consulter. Il vous semblera alors possible de
résoudre ce problème. En réalité, il existe des solutions économiques pour obtenir ce résultat.
Afin d’éviter de commettre cette erreur, il faut déployer une solution de gestion des logs avant
de mettre en place la technologie SIEM, comme nous l’avons expliqué précédemment. Ainsi,
l’entreprise est assurée que tous les logs requis sont disponibles pour être analysés, même si un
pourcentage seulement est visible à l’aide d’un moteur de corrélation SIEM.
La dernière erreur est d’ignorer les logs provenant des applications pour se concentrer
uniquement sur les périphériques réseaux internes et périmétriques, voire sur les serveurs, sans
aller plus haut dans la pile afin d’examiner la consignation des applications.
Les applications d’entreprise vont des systèmes SAP et PeopleSoft aux petites applications
développées en interne, qui gèrent néanmoins des processus fondamentaux dans de nombreuses
entreprises. Il ne faut pas non plus oublier les applications héritées, exécutées sur des mainframes
et des systèmes de milieu de gamme, qui sont souvent en charge du fonctionnement des
processus métiers essentiels. La disponibilité et la qualité des logs diffèrent énormément d’une
application à l’autre : ils peuvent être inexistants (c’est le cas pour de nombreuses applications
développées en interne) ou extrêmement détaillés et volumineux (c’est le cas pour de nombreuses
applications de mainframe). Le manque de normes de consignation courantes voire même de
conseils en consignation destinés aux développeurs de logiciels génère divers défis concernant
les logs d’application. Heureusement, de futurs projets, comme l’initiative CEE (Common Event
Expression) de MITRE, résoudront ce problème.
Malgré les défis, vous devez vous assurer que les logs d’application sont recueillis et disponibles
pour l’analyse mais aussi pour la conservation à long terme. Pour ce faire, vous devez configurer
votre logiciel de gestion des logs afin de les recueillir et établir une stratégie d’examen des logs
qui vous permettra de passer en revue les logs en cas d’incidents, mais aussi de manière proactive
et périodique. Il est donc conseillé de faire appel à des fournisseurs qui facilitent la configuration
Vous devez vous assurer que les logs d’application sont recueillis et disponibles pour l’analyse mais aussi pour la conservation à long terme. Pour ce faire, vous devez configurer votre logiciel de gestion des logs afin de les recueillir et établir une stratégie d’examen des logs qui vous permettra de passer en revue les logs en cas d’incidents, mais aussi de manière proactive et périodique.
22
Livre blancLe guide complet de la gestion des logs et événements
de leurs systèmes afin de collecter des logs provenant d’applications personnalisées, étant donné
qu’ils sont souvent les plus importants. Vous pouvez configurer ultérieurement vos outils SIEM
afin d’analyser les logs à des fins de sécurité, ainsi que les logs de réseau et autres.
Conclusions
L’un des conclusions essentielles à tirer de ce livre blanc est de se souvenir que toutes les
entreprises possèdent des logs. Par conséquent, elles doivent toutes les gérer. Dans sa forme la
plus vaste, la gestion des logs consiste simplement à traiter les logs. Si vous possédez des logs,
vous devez les gérer, ne serait-ce que pour vous conformer aux nombreuses conditions des
réglementations en vigueur actuellement.
En outre, il est important de ne pas oublier que les logs sont utilisés dans un très grand nombre
de situations, de la réponse aux incidents traditionnels à des cas hautement ésotériques. Les logs
sont généralement utilisés bien après l’événement et sa consignation dans les logs. En effet, il est
bien plus facile de se préparer à fournir une réponse que d’assurer un monitoring.
Avant d’être prête à passer aux outils SIEM, votre entreprise va peut-être devoir réapprendre
les principes de la consignation. Pour effectuer une telle transition, vous devez être capable de
répondre aux alertes mais aussi de personnaliser et régler vos produits.
Une fois la solution de gestion des logs et les outils SIEM mis en oeuvre, votre entreprise peut
progresser sur l’échelle de maturité afin de bénéficier d’une visibilité complète sur le réseau et
les applications, d’un monitoring des activités des utilisateurs et de l’intégration à différents
systèmes.
À propos de l’auteur
Le Dr Anton Chuvakin (www.chuvakin.org) est un expert en sécurité réputé dans le domaine
de la gestion des logs et de la conformité à la norme PCI-DSS. Il a écrit deux livres intitulés
« Security Warrior » (Le guerrier de la sécurité) et « PCI Compliance » (Conformité à la norme
PCI) et a contribué à l’élaboration de plusieurs ouvrages, dont « Know Your Enemy II » (Bien
connaître son ennemi II) et « Information Security Management Handbook » (Guide de la
gestion de la sécurité des informations). M. Chuvakin a publié des dizaines d’articles sur la
gestion des logs, la corrélation, l’analyse des données, la norme PCI-DSS et la gestion de la
sécurité (rendez-vous sur le site www.info-secure.org pour en obtenir la liste). Son blog
www.securitywarrior.org est l’un des plus populaires du secteur. En outre, M. Chuvakin
Avant d’être prête à passer aux outils SIEM, votre entreprise va peut-être devoir réapprendre les principes de la consignation. Pour effectuer une telle transition, vous devez être capable de répondre aux alertes mais aussi de personnaliser et régler vos produits.
23www.netiq.com
enseigne et participe à de nombreuses conférences sur la sécurité dans le monde entier. Il a
récemment prononcé des discours aux États-Unis, au Royaume-Uni, à Singapour, en Espagne
et en Russie, entre autres. Il travaille actuellement sur les normes de sécurité émergeantes et est
membre du conseil consultatif de plusieurs startups spécialisées en sécurité.
Actuellement, M. Chuvakin développe son activité de consulting en sécurité, www.
securitywarriorconsulting.com, en se consacrant particulièrement à la consignation et à la
conformité à la norme PCI-DSS pour les fournisseurs de solutions de sécurité et les entreprises
figurant au classement Fortune 500. M. Chuvakin était auparavant directeur des solutions de
conformité à la norme PCI chez Qualys. Auparavant, il a travaillé pour le compte de Log Logic
en tant que promoteur de la consignation. Dans le cadre de ce rôle, il avait pour tâche d’éduquer
les entreprises sur l’importance de la consignation à des fins de sécurité, de conformité et
d’exploitation. Avant de rejoindre Log Logic, M. Chuvakin était responsable de la gestion de
produits stratégiques pour un fournisseur de solutions de sécurité. M. Chuvakin a obtenu son
doctorat de l’université de Stony Brook.
À propos de NetIQ
NetIQ est une société informatique dont les efforts sont constamment axés sur la réussite de
ses clients. Les clients et partenaires choisissent NetIQ pour relever les défis de la protection
économique des informations et de la simplification de la complexité opérationnelle informatique.
Notre portefeuille de solutions de gestion automatisées et évolutives englobe la sécurité et
la conformité, les identités et les accès, et les performances et la disponibilité. De plus, nous
proposons une approche pratique et ciblée de la résolution des défis informatiques. Nos clients en
tirent des avantages stratégiques, leurs activités s’améliorent de façon démontrable et ils réalisent
des économies par rapport aux autres approches existantes.
Pour en savoir plus, consultez le site : www.netiq.com
Les clients et partenaires choisissent NetIQ pour relever les défis de la protection économique des informations et de la simplification de la complexité opérationnelle informatique.
562-FR1003-002 | Q | 06/16 | © 2016 NetIQ Corporation et ses filiales . Tous droits réservés . NetIQ, le logo NetIQ et Sentinel sont des marques commerciales ou déposées de NetIQ Corporation aux États-Unis . Tous les autres noms de produits et d’entreprises peuvent être des marques commerciales appartenant à leur propriétaire respectif .
www.netiq.com
NetIQFranceTel: +33 (0) 1 55 70 30 13
Siège social au Royaume-UniRoyaume-UniTel: +44 (0) 1635 565200
contact-fr@netiq .comwww .netiq .com/communitieswww .netiq .com
Pour obtenir la liste complète de nos bureaux d’Amérique du Nord, d’Europe, du Moyen-Orient, d’Afrique, d’Asie-Pacifique et d’Amérique latine, visitez la page : www .netiq .com/contacts .
www.netiq.com
Recommended