Gestion des événements de sécurité : la prévention avant la catastrophe

Exemple : le Groupe Eiffage, qui a automatisé la génération d’alertes de sécurité avec un système de corrélation de logs. « L’objectif, en 2008, était avant tout une mise en conformité des procédures du groupe, en particulier pour les transactions financières avec les fournisseurs et les établissements bancaires », se souvient Fabrice Pizzi, RSSI du groupe. Il s’agit aussi, en traçant toutes les actions, par exemple dans les bases de données ou les fichiers sensibles, de prévenir d’éventuelles fraudes internes, dès lors que des flux financiers sont concernés ou de la part d’experts techniques ou de « super-administrateurs » susceptibles d’accéder à l’ensemble des applications.

Pris isolément, des logs sont inexploitables en termes de sécurité. Mais c’est leur corrélation qui permet de mettre en évidence d’éventuelles anomalies. Ce qui n’est possible qu’avec l’élaboration de règles de traitement afin d’automatiser ces corrélations et de déclencher des alertes de sécurité pertinentes. Et pour définir les règles, il importe de se tourner vers les responsables métiers : « Ce sont les seuls qui sont en mesure de définir les comportements incohérents au regard de leur activité », précise Fabrice Pizzi.

« Dès qu’une anomalie est détectée, nous en sommes avertis, poursuit le RSSI d’Eiffage, qui a retenu la solution de Loglogic (Tibco). L’analyse des différentes solutions du marché nous a révélé une forte volatilité des fournisseurs, qui disparaissent ou se font racheter, et nous souhaitons privilégier la stabilité dans la roadmap des produits et une continuité dans la stratégie. »

Fabrice Pizzi suggère de privilégier quatre critères pour choisir une solution : la capacité à gérer des volumes importants de données, celle de traiter des tickets d’incidents, la possibilité de générer un reporting fin sous forme de tableau de bord et le fait de nécessiter le minimum d’expertise pour administrer la solution. De son côté, Thierry Chiofalo, administrateur du Clusif, souligne que « le produit qui fait tout parfaitement n’existe pas mais, avec la corrélation « in the box », on voit arriver sur le marché des produits réellement pertinents car proposant des schémas de corrélation directement applicables ».

Thierry Chiofalo met pour sa part en exergue les fonctionnalités suivantes pour sélectionner une solution : des capacités d’intégration (reconnaissance automatique des terminaux par exemple, une exploitation simplifiée, des fonctions d’archivage, de recherche simple et rapide, d’alertes, de reporting et de tableaux de bord. Et si possible, des analyses de corrélation permettant de produire des alertes intelligentes.

Faut-il plus de transparence ?

Si, pour Fabrice Pizzi, une solution de SIEM « est importante pour montrer à une direction générale et aux métiers le retour sur investissement de la sécurité », il reste des limites. « L’architecture n’est pas complexe, mais les limites tiennent à la définition des règles que l’on souhaite appliquer, à la difficulté de tout surveiller et à la détection des signaux faibles », résume Fabrice Pizzi. Par ailleurs, ajoute ce dernier, « le vrai retour sur investissement du SIEM réside dans la gestion des logs dans les applications, mais la maturité sur ce sujet reste encore insuffisante ». Plus largement, surgissent des difficultés organisationnelles et culturelles : « Les outils de SIEM introduisent par définition davantage de transparence dans l’organisation, ce qui n’est pas toujours très bien vécu, même si les entreprises ont énormément à gagner à déployer ce type de solution », remarque Gérard Gaudin.

Ce dernier suggère de privilégier une approche de type « top-down », pour un meilleur ciblage de la détection, et pas seulement de type « bottom-up », approche la plus répandue. Le club R2GS a élaboré une grille de 95 indicateurs, à partir de données recueillies dans les entreprises de quatre pays (France, États-Unis, Allemagne, Royaume-Uni) : « L’objectif est de s’étalonner par rapport à d’autres organisations et, ainsi, de mieux cibler la détection », précise Gérard Gaudin. Une démarche de mise en œuvre d’une solution de SIEM repose sur quatre étapes : l’étude d’opportunité, la faisabilité et l’appel d’offres, la conception et le déploiement, et la mise en œuvre des services.

L’étude d’opportunité : vérifier le besoin de traçabilité

L’étude d’opportunité répond à trois objectifs principaux. D’abord, un besoin de traçabilité et de conservation des données, en fonction de plusieurs éléments : les principes définis par la politique de sécurité, des contraintes réglementaires (dispositions Cnil, charte interne, traçabilité des messages imposée dans certains secteurs économiques par exemple…), ou les spécificités du contrôle interne et de l’audit (qui fait quoi, quand et pour quel motif…).

Ensuite, l’étude d’opportunité répond à un objectif de mesure de la sécurité, avec la nécessité du reporting, de la détection et de la notification des incidents, de l’analyse des comportements et de mesure des écarts. Enfin, le troisième objectif concerne le traitement des incidents (supervision et administration, diagnostic en temps réel, suspension de comptes, actions correctives…). Au-delà d’une simple détection, l’objectif est de disposer d’un véritable reporting, ce qui présente l’avantage essentiel de pouvoir mesurer les écarts.

La faisabilité et l’appel d’offres

Pour préparer un appel d’offres vers les prestataires de services et éditeurs de logiciels, plusieurs éléments doivent être pris en compte, en particulier les trois suivants : l’hébergement de la solution et des données, l’administration, les fonctionnalités et les services attendus. La solution retenue peut en effet être hébergée, notamment pour la supervision, l’administration, l’exploitation et le support.

En termes d’administration, la solution doit proposer la gestion de plusieurs profils d’utilisateurs (avec des vues partielles ou complètes). Pour les volumes, la solution doit être capable de gérer si possible plusieurs millions de logs par jour, avec un stockage en ligne d’un historique (trois mois et douze mois hors ligne, par exemple). Le prestataire doit assurer au moins les missions suivantes : l’exploitation de la solution, le suivi du fonctionnement, la gestion des correctifs, l’édition des rapports d’intervention, la confidentialité, l’intégrité et la sauvegarde des données, la mise à disposition des données…

Du côté des services attendus, la solution retenue doit être capable d’analyser des événements 24 heures sur 24 et 7 jours sur 7. Cette analyse comprend trois volets essentiels :

• le contrôle et l’analyse périodiques des événements enregistrés dans les journaux d’activité ;
• un échéancier préétabli (quotidien, hebdomadaire…), la rédaction de rapports synthétiques et des préconisations ;
• la surveillance, la surveillance des événements et la qualification des alertes. Il s’agit, d’une part, de pratiquer une analyse à distance, de façon récurrente, des alertes, selon les procédures définies conjointement avec l’entreprise, en phase d’initialisation des services, et, d’autre part de déclencher des actions à entreprendre, par exemple la notification ou le déclenchement à distance des procédures adaptées en cas d’activité suspecte, de tentative d’attaque ou d’attaque avérée. L’appel d’offres doit être géré avec des critères pondérés, par exemple ceux conseillés par Gartner (voir tableau ci-dessous).

La conception et le déploiement

La conception de la solution suppose que l’entreprise fournisse à son prestataire les informations techniques sur les équipements à surveiller, configure les équipements pour intégrer la solution et garantisse la disponibilité des équipes techniques internes. De son côté, le prestataire doit fournir les documentations de configuration, accompagner et assurer l’intégration des plates-formes de gestion des événements. L’entreprise et le prestataire doivent également, de manière coordonnée, se mettre d’accord sur le périmètre technique et fonctionnel de la surveillance, notamment pour la définition des comportements à surveiller, les indicateurs de sécurité et les types d’incidents à prendre en compte, la quantification des informations à consolider, ainsi que les éléments qui figureront dans le tableau de bord (identification des acteurs, nature des informations à restituer, modèles de données).

En interne, un partage des responsabilités se révèle indispensable. Ainsi, le RSSI doit être habilité à effectuer les audits utiles et pouvoir analyser les résultats de la « journalisation », des alertes, des audits, des statistiques et des rapports. De même, chaque famille de composants doit être suivie par un responsable de l’exploitation des données dont le rôle est de surveiller en temps réel l’activité et de recevoir les alertes/rapports d’incidents.

La mise en œuvre des services : anticiper les difficultés

• La mise en œuvre d’une solution de gestion des logs suppose d’anticiper un certain nombre de contraintes qui peuvent se transformer en difficultés. On peut notamment retenir les éléments suivants :
• la difficulté de rapatrier des logs pour des équipements anciens, pour des équipements dont le firmware conditionne le format des logs ou pour des équipements non supportés nativement par la solution retenue ;
• la nécessité de prévoir des capacités de stockage nécessaires pour gérer/conserver les historiques de logs ;
• la charge liée aux « revues de logs » : les premières sont généralement fastidieuses, du fait des volumes à traiter.
• la charge de travail pour repenser et améliorer les processus, le niveau de détail des rapports et des indicateurs, ainsi que la forme de présentation des informations ;
• la corrélation automatique entre des événements est difficilement automatisable de façon exhaustive, l’expertise humaine (donc coûteuse de façon directe ou indirecte) reste nécessaire.

Solutions de SIEM : les fonctionnalités à privilégier et les pondérations à appliquer
Principales fonctionnalités	Pondération
Surveillance en temps réel	15 %
Intégration des nouveaux risques (Threat Intelligence)	10 %
Profilage des comportements	7 %
Surveillance des utilisateurs et des données	8 %
Surveillance des applications	6 %
Fonctionnalités décisionnelles	8 %
Management des logs	26 %
Simplicité du déploiement et de l’administration	20 %
Total	100 %
Source : Gartner.

---

Solutions de SIEM : les fonctionnalités à privilégier et les pondérations à appliquer

• Une architecture modulaire
• Une collecte des données en temps réel
• Une taxonomie et une normalisation des événements
• Un monitoring en temps réel pour établir les corrélations
• Une analyse des comportements normaux/anormaux
• Une intégration des nouveaux risques
• Des capacités décisionnelles (tableaux de bord ou requêtes à la demande)
• Un reporting et un archivage des logs
• Un worklow pour le management des incidents
• Un monitoring de l’activité des utilisateurs et des accès aux données
• Une simplicité dans le déploiement

Source : Gartner.

---

Un guide de bonnes pratiques

L’Anssi (Agence nationale de la sécurité des systèmes d’information) vient de publier un document de synthèse sur « l’hygiène informatique ». Ce guide présente les 40 règles incontournables. « Elles ne prétendent pas avoir un caractère d’exhaustivité. Elles constituent cependant le socle minimum des règles à respecter pour protéger les informations d’une entreprise », est-il précisé dans ce document, avec un avertissement : « Ne pas les suivre expose l’entreprise à des risques d’incidents majeurs, susceptibles de mettre sa compétitivité, voire sa pérennité, en danger. » Les règles concernent la connaissance du système d’information et de ses utilisateurs, la maîtrise du réseau, la mise à niveau des logiciels, l’authentification des utilisateurs, la sécurisation des terminaux, la protection du réseau interne, l’administration du réseau, les contrôles d’accès, la sécurité physique, la réaction en cas d’incident, la sensibilisation et l’audit de la sécurité.

Pour télécharger le guide de l’Anssi : www.ssi.gouv.fr

---

Les dix bonnes pratiques du RSSI d’Eiffage

1. Prendre son temps pour exprimer les besoins et définir les règles de gestion.
2. Réévaluer les règles régulièrement pour les adapter aux périmètres de l’organisation et du système d’information.
3. Élaborer les processus de gestion des incidents : tout ce qui n’est pas écrit n’existe pas !
4. Informer les utilisateurs, par exemple par une charte.
5. Si des données personnelles sont concernées, effectuer les formalités nécessaires auprès de la Cnil.
6. Prévoir une équipe sécurité, surtout si la surveillance s’effectue 24 heures sur 24
7. En cas de manque de ressources internes, étudier une solution d’infogérance
8. Déterminer ce qui est financièrement et techniquement possible
9. Vérifier la disponibilité d’expertises externes
10. Vérifier la capacité de la solution à gérer des volumes importants de logs.

---

Les quinze points d’attention

1. La nature de ce qui doit être surveillé
2. Le périmètre à couvrir
3. L’évaluation des volumes et leur évolution
4. La lisibilité des informations
5. La catégorisation des événements
6. La surveillance des administrateurs clés
7. La diversité des solutions avec des fonctionnalités redondantes
8. Un tableau de bord simple, pertinent et évolutif
9. La charge de travail
10. La définition des profils d’utilisateurs
11. Le test régulier de la performance des solutions
12. La problématique de stockage et de restitution des informations
13. Les engagements de services
14. Les seuils de déclenchement des alertes
15. La part de l’expertise humaine.