PARTIE 2 :

ADMINISTRATION ET SUPERVISION DES RESEAUX DOSSIER PROJET MASTER 2 RESEAUX et TELECOMMUNICATIONS Présenté par : Habib BALE Thillo TALL

TABLE DES MATIÈRES

Introduction .........................................................................................................................3 1. LogLogic .........................................................................................................................4

A. Presentation ................................................................................................................4 B. Collecte .......................................................................................................................4 C. Normalisation ..............................................................................................................4 D. Agrégation ..................................................................................................................4 E. Corrélation ..................................................................................................................4 F. Gestion des alertes .....................................................................................................5

2. Prelude ...........................................................................................................................6 A. Présentation ................................................................................................................6 B. Collecte .......................................................................................................................6 C. Normalisation ..............................................................................................................6 D. Agrégation ..................................................................................................................7 E. Corrélation ..................................................................................................................7 F. Gestion des alertes .....................................................................................................7

3. Net Report ......................................................................................................................9 A. Presentation ...............................................................................................................9 B. Net Report Monitoring Center .....................................................................................9 C. Net Report Tool Kit .....................................................................................................9 D. Net Report appliances ................................................................................................9 E. L’offre Net Report en contexte ..................................................................................10 F. Collecte .....................................................................................................................11 G. Filtrage et Enrichissement des données ...................................................................11 H. Base de données ......................................................................................................11 I. Génération de tableaux de bord ................................................................................12 J. Customisation des Rapports ......................................................................................12 K. Corrélation et Alerting ...............................................................................................12

4. Log One de NS One .....................................................................................................14 A. Presentation ..............................................................................................................14 B. Principe de fonctionnement .......................................................................................14 C. Collecte.....................................................................................................................14 D. Rapatriement, filtrage, corrélation et stockage ..........................................................14 E. Elaboration de rapports détaillés ...............................................................................15

5. Cisco Security Mars .....................................................................................................16 A. Presentation ..............................................................................................................16 B. Les appliances CS MARS .........................................................................................16 C. La gestion des problématiques STM .........................................................................18 D. La gestion des alarmes avec CS MARS ...................................................................20 E. Gestion de l'archivage avec CS MARS .....................................................................21 F. Les rapports sous CS MARS .....................................................................................21 G.Quelques considérations d'architecture .....................................................................24

6. Arcsight ESM ................................................................................................................25 A. Presentation: .............................................................................................................25 B. Arcsight manager ......................................................................................................27 C. Collecte.....................................................................................................................27 D. Arcsight Base de Données........................................................................................28 E. Analyse de la securité avec la console arcsight ........................................................28 F. Gestion des alertes ...................................................................................................29 G. Corrélation ................................................................................................................29 H. Automatisation de conformité ....................................................................................30

Conclusion : ......................................................................................................................31

INTRODUCTION Depuis quelques années, les entreprises perçoivent l'intérêt d'exploiter les nombreuses traces, événements et autres données d'audit logicielles, pour obtenir une image plus objective de leur sécurité informatique. A ce besoin, les éditeurs ont répondu par une gamme de produits communément appelés SIEM. Sans entrer dans le débat sémantique consistant à utiliser cette appellation générique ou une typologie plus pointue distinguant les SEM (Security Event Management) qui n'exploitent que des données événementielles (logs), des SIM (Security Information/Incident Management) qui prennent en compte d'autres sources (résultats de scans par l'antivirus, par exemple), le SIEM-type est une couche de collecte filtrant différentes sources pour ne conserver que les événements de sécurité informatique. C'est aussi une couche de stockage souvent centralisé, une couche de valorisation (corrélation, alerte, reporting) permettant d'exploiter les événements de sécurité et une couche de présentation. Les SIEM ont une architecture souvent complexe, une centralisation fréquente des données qui n'est pas toujours compatible avec les contraintes d'utilisation d'une grande entreprise (organisation géographiquement distribuée) et une orientation trop SSI, limitant le ROI « à la source » (filtrage lors de la collecte), même si les SIEM ont trouvé un second souffle bienvenu, avec les grands projets de conformité de type SOX. Ces critiques récurrentes ont conduit à l'émergence des solutions dites de « Log Management » ou Gestion des Logs, conciliant des possibilités de collecte beaucoup plus larges, des capacités de stockage ad hoc et des fonctionnalités basiques de requête et de reporting. Ce nouveau marché s'articule aussi bien autour de pure players - LogLogic étant le plus connu d'entre eux - que d'éditeurs de SIEM ayant senti la tendance et complétant leur offre avec des composants dédiés au log management : ArcSight avec ArcSight Logger et ArcSight Connectors,CS-MARS avec certaines appliances de la série, Log One, etc. Malgré cette effervescence marketing, les différents acteurs du marché semblent converger plus ou moins rapidement vers une architecture générique qui s'appuie sur des appliances plutôt que sur des composants logiciels (simplicité d'installation puis d'administration, réduction des coûts matériels et de fonctionnement). Nous dans les lignes qui suivent allons faire une études comparative des differentes solution SIEM

1. LOGLOGIC

A. PRESENTATION Loglogic, anciennement “Exaprotect” a été créé en 2004 par la société française Exaprotect. Celle-ci a été rachetée en 2009 par l’entreprise américaine LogLogic et est donc devenu « LogLogic » par la même occasion. De plus, LogLogic est une « appliance », c'est-à-dire que le logiciel est indissociable du matériel.

B. COLLECTE Loglogic fonctionne en mode actif, il faut donc déployer des agents sur les équipements à surveiller pour qu’ils réalisent la collecte. Les agents n’ont presque pas de configuration, ils déterminent lors de l’installation le format des logs à collecter et agissent ensuite en autonomie. C'est-à-dire qu’ils collectent les logs, les normalisent, puis les envoient de façon sécurisée au SIEM. Si un agent n’est pas nativement compatible avec un équipement, il faut alors configurer l’agent pour qu’il puisse comprendre ceux-ci à l’aide de règles pour « parser » ceux-ci. L’avantage de Loglogic est sa simplicité de mise en oeuvre. Les agents s’installent facilement et la configuration est simplifiée. La configuration peut de surcroit être réalisée à distance depuis le manager de Loglogic. Les échanges entre les agents et le SIEM sont sécurisés par TLS.

C. NORMALISATION Loglogic utilise le format normalisé IDMEF. Les Logs sont normalisés par les agents avant qu’ils envoient les alertes au manager. Le choix d’un format normalisé (IDMEF) permet que les logs soient « compréhensibles » par le SIEM et facilement traité par celui-ci.

D. AGREGATION

LogLogic possède un moteur d’agrégation paramétrable à l’aide de règles. C’est une étape importante qui détermine comment les évènements seront regroupés avant d’être envoyés au corrélateur. En plus d’être affichés dans la console graphique de LogLogic, les évènements agrégés sont regroupés par critères définis au préalable, ce qui permet une meilleure corrélation car les évènements sont déjà rassemblés pour être corrélés, et peuvent même être fusionnés ou redéfinis.

E. CORRELATION Toutes les alertes reçues par LogLogic sont transmises au moteur d’agrégation, puis au corrélateur et celui-ci les traite en fonction de ses règles de corrélation. Quand une alerte de corrélation est créée, elle est stockée dans la base de données et est affichée dans la console graphique. LogLogic permet de définir des « scénarios » qui sont des regroupements d’alertes de corrélation. Cela ajoute un traitement supplémentaire par le SIEM.

F. GESTION DES ALERTES Loglogic peut réaliser un « reporting » en fonction du type d’alerte détectée. On peut donc décider que pour un type d’attaque détecté on réalise une action particulière. Les actions réalisables par Loglogic sont nombreuses : on peut envoyer un mail, un SMS, envoyer l’incident à un autre serveur, ou même créer un « trap » SNMP… De plus Loglogic réalise automatiquement des rapports dynamiques, qui sont composés de graphiques et de résumes des attaques répertoriées. La réponse se fait à par l’envoi d’incidents IODEF ou Alertes de corrélation IDMEF à un moteur de réaction quelconque. Celui-ci agira en fonction des évènements reçus.

Figure 1 : schéma de fonctionnement d'un SIEM dans LogLogic

2. PRELUDE

A. PRESENTATION Prelude est un SIEM issu d’un projet open source qui fut créé en 1998 par Yoann Vandoorselaere. Ce projet est né de l’idée que le nombre de systèmes de détection d’intrusion augmentait mais qu’il n’existait pas de système pour les faire communiquer entre eux, ce qui diminuait leur efficacité.

B. COLLECTE Prelude fonctionne en mode actif, c’est à dire qu’il utilise des agents qui sont installés sur les systèmes à surveiller et qui vont s’occuper de la phase de collecte. Dans un premier temps, l’agent (appelé Prelude-LML) doit être configuré, Il faut indiquer à celui-ci les formats de logs des logiciels à surveiller pour que celui-ci puisse les prendre en compte. Ensuite, l’agent démarré peut collecter les logs de deux façons différentes : soit il surveille les journaux systèmes de l’hôte sur lequel il est installé, soit il reçoit les journaux venant de différentes machines placées sur le réseau. Ces messages sont sécurisés (en TLS) et possèdent un mécanisme d'autorégulation pour ne pas surcharger le réseau. L’intérêt de cette deuxième méthode est de permettre aux systèmes ne supportant pas l’agent Prelude de pouvoir être surveillés en envoyant leurs logs à un agent distant. Une fois les informations récupérées, l’agent les compare avec ses jeux de règles (basés sur des expressions régulières) et si une condition précise est reconnue, un évènement de sécurité est créé. L’avantage de cette méthode de collecte est la flexibilité par rapport au réseau. Les mécanismes mis en place empêchent la perte de paquet (autorégulation, réémission) et assurent leurs intégrités. Par contre, la confidentialité (chiffrement TLS) n’est pas assurée totalement car seuls les échanges entre l’agent et le manager sont sécurisés, contrairement aux échanges entre l’agent et les systèmes distants, qui lui envoient leurs logs. Un autre avantage est le mode « sonde » : ce mode permet qu’un agent soit directement « patché » au code source d’un logiciel de sécurité (ils sont alors indissociables).

C. NORMALISATION Prelude a participé au projet “Intrusion Detection Message Exchange Format” (IDMEF). C’est donc evidement ce format qui fut choisit pour le SIEM. La normalisation est réalisée par l’agent Prelude-LML qui formate les évènements avant de les envoyer au manager. L’IDMEF est un format de message pour les évènements de sécurité et les alertes de corrélation. Il sert donc uniquement à « mettre en forme » ceux-ci. Les évènements et alertes sont donc décrits par ce format de manière à être traité plus facilement par le SIEM. L’atout principal de faire normaliser les logs par l’agent est d’alléger le traitement réalisé par le manager. De plus, le choix d’un format normalisé permet une compréhension simplifiée et une plus grande adaptabilité.

D. AGREGATION Prelude ne fait pas d’agrégation car il n’y a aucun traitement sur les évènements, cependant il possède un système pour améliorer le traitement des informations par les utilisateurs.

E. CORRELATION Tous les évènements envoyés au manager sont stockés puis transmis au moteur de corrélation appelé Prelude-Correlator. Ce moteur se base sur des règles (écrites en langage python) pour analyser les évènements de sécurité et ainsi créer des « alertes de corrélation ». Ces alertes sont alors renvoyées au manager qui les stocke. Le système de corrélation est encore instable, on pourra mettre en avant que l’écriture des règles est complexe, car elle demande une bonne compréhension du langage python, de la norme IDMEF, du réseau surveillé et des attaques surveillées.

F. GESTION DES ALERTES Prelude peut réaliser le « reporting » de trois façons :

Lorsque que des évènements sont détectés, il affiche les alarmes via sa console graphique Prewikka.

Il peut aussi prendre la décision de transmettre l’alerte à un autre manager Prelude (dans le cas d’un fonctionnement hiérarchique).

Il peut également, grâce à un « plugin », envoyer des mails d’alerte contenant l’alerte détectée. Prelude possède des ajouts transmettant les alertes à des moteurs de réaction.

Figure 1 : Schéma du fonctionnement du SIEM Prelude

3. NET REPORT

A. PRESENTATION La société Net Report a été crée en 2001 dans le but de fournir une solution globale à l’exploitation des évènements logs et pour donner une lisibilité aux évènements. En 2003, Net Report a fusionné avec la société DataSet. DataSet est spécialisée dans les solutions de Business Intelligence depuis plus de 10 ans. En 2004, Net Report fournit : Des solutions complète d’exploitation des logs : produits Net Report. Outils d’analyse de logs et gestion proactive des évènements de sécurité. Il offre deux offres pour les entreprises :

Net Report Log Analyser Net Report Monitoring Center Net Report Tool Kit Net Report appliance

Net Report Log Analyser permet de centraliser et stocker l’ensemble de vos logs en un point central, c’est l’outil indispensable pour l’analyse de l’activité de vos équipements Firewalls, IPS, UTM, Proxy, Web, Domains Windows, Serveur de Messagerie et Serveur Anti-Virus... Avec plus d’une centaine de tableaux de bord.

B. NET REPORT MONITORING CENTER Net Report Monitoring Center répond à l’ensemble des problématiques d’exploitation des logs. Centralisant l’ensemble des évènements en un point central. Net Report analyse en temps réel l’activité de votre infrastructure sécurité et réseaux. Véritable solution de Business Intellignce, elle génère des alertes, offre un reporting avancé grâce à des tableaux de bords décisionnels, ainsi que des outils d’investigation évolués (cubes OLAP) afin de vous apporter une vision complète de vos évènements en temps réel.

C. NET REPORT TOOL KIT Analyse des volumes importants de données sous plusieurs angles sur de multiples sources de données, créez des requêtes ad hoc et des rapports personnalisés avec la charte graphique de l’entreprise.

D. NET REPORT APPLIANCES Les Appliances Net Report offrent une souplesse de configuration dans un châssis 2U et sont destinés aux sociétés qui souhaitent une capacité de traitement maximum dans un espace minimum.

E. L’OFFRE NET REPORT EN CONTEXTE Le diagramme ci-dessous illustre les parties propres à chacun de nos 3 produits :– Net Report Log Analyser, Net Report Monitoring Center* et Net Report Tool Kit dans une architecture :

F. COLLECTE La collecte se fait :

A partir de périphériques hétérogènes Net Report supporte les principales catégories d’équipements du marché : Firewall, Proxy, Serveurs, IPS (Intrusion Prevention System), IDS (Intrusion Detection System), Serveur E-mail, Serveur d’Authentification, Passerelle Anti-Virus, Serveur Web.

A partir de différents format de logs / média Les données peuvent être collectées soit en Syslog*, à partir de fichier Flat File ou à travers certains protocoles propriétaires tels que CheckPoint LEA, Windows WMI ou Radius. Les logs en fonction des médias peuvent être collectées en temps réel ou en temps différé.

* Net Report est lui-même serveur Syslog

Centralisation en 1 point unique Toutes les données sont centralisées dans une base de données pour la génération des tableaux de bords et pour l’investigation.

Format de logs archivables Net Report archive tous les fichiers de logs au format, syslog, fichiers à plat ou API propriétaires.

Valeur légales Les logs sont stockés dans leur format natif afin d’être présentés si nécessaire comme preuve lors d’une enquête ou commission rogatoire.

Intégrité, Compression et Chiffrement Les fichiers de logs sont signés, compressés et chiffrés de manière journalière (par type de périphérique et/ou date).

Archivage

Les données sont collectées et stockées en format brut à travers le module Net Report Log Archive afin d’assurer l’intégrité des données dans le temps. Les fichiers de données brutes sont signés, compressés et chiffrés avant d’être archivés.

G. FILTRAGE ET ENRICHISSEMENT DES DONNEES Le moteur Net Report ULA (Universal Log Analyser) analyse, normalise, filtre les données en temps réél. Les données peuvent être enrichies en temps réel par des informations contenues dans des sources externes (RDNS, Annuaire LDAP, Table SQL, dictionnaires) afin d’en améliorer la lisibilité. Chaque moteur Net Report permet d’insérer dans la base de données plusieurs dizaines de millions d’évènements par jour.

H. BASE DE DONNEES Net Report agrège, consolide et purge les données dans la base de données de manière automatique. Ces actions planifiées permettent de réduire de manière considérable le volume dans les bases de données (Coefficient de 25 pour les équipements de type proxy ou Firewalls)

I. GENERATION DE TABLEAUX DE BORD La génération des tableaux de bord peut être automatisée et planifiée dans le temps (tâche journalière, hebdomadaire ou mensuelle) Les tableaux de bord peuvent également être générés en temps réel. Des fonctions avancées de Drill-Drown permettent une navigation intuitive et offrent la possibilité d’aller rapidement aux informations de détails.

J. CUSTOMISATION DES RAPPORTS Notre tool kit (rapports) vous permet de créer vos rapports spécifiques et de personnaliser le look & feel de vos tableaux de bord.

K. CORRELATION ET ALERTING Des fonctions avancées de corrélation et d’alerting vous permettent de détecter en temps réel les attaques et d’identifier les vulnérabilités. Net Report remonte en temps réel les alertes à vos équipes techniques via e-mail, Trap SNMP ou sur notre propre console (Q2 2006) dans le but d’isoler et de résoudre rapidement les problèmes potentiels. La Console d’alerte permet de plus de gérer le niveau des alertes, de les filtrer ou de les acquitter. Net Report fournit plus d’une centaine d’alertes et d’exemples de corrélation par défaut. Il offre des simples et multi-équipements par défaut. Les alertes sont envoyées sur une console d’alerte web ou par email, par Trap SNMP et/ou par Syslog. La Console web vous permet de facilement gérer les alertes en temps réel. Les administrateurs peuvent facilement utiliser la fonction avancée pour créer des alertes et des actions personnalisées. Net Report corrèle les évènements d’une gamme importante d’équipements réseaux pour faciliter la prise des décisions et garantir un niveau élevé de sécurité. Net Report offre un moyen simple de définir certaines constantes d’évènements, de règles et des actions liées afin de simplifier le monitoring des évènements réseaux. Net Report offre quatre moyens de corréler des évènements de sécurité des équipements divers pour identifier des incidents de sécurité et le déclenchement des alertes :

Déclencher une alerte quand les modèles / les conditions / les relations prédéfinis sont atteints / satisfaits.

Déclencher une alerte quand un seuil est atteint avec un timeout de session prédéfini (Compteur de mémoire).

Déclencher une alerte si une des actions ci-dessus est identifiée, et corrélée avec des données dans la base de données, ou dans un dictionnaire.

Déclencher une alerte quand le résultat d’une requête dans la base de données atteint certains des critères définies dans la règle. Cette requête peut être planifier. Ce moyen facilite l’analyse sur les périodes étendues, par exemple pour les scans de ports.

Les avantages de la corrélation des évènements sont nombreux. La corrélation vous permet d’augmenter l’efficacité de votre équipe informatique, elle vous permet d’optimiser votre « Business Continuity » et d’empêcher la perte du revenu à cause de « downtime ». Net Report collecte, archive et analyse des volumes de données importantes. Ces données doivent être analysées en temps réel et elles sont utiles dans plusieurs scenarios de sécurité.

Figure 1 : schéma de fonctionnement du SIEM Net Report

4. LOG ONE DE NS ONE

A. PRESENTATION Net Secure devenue NS One est un acteur spécialisé offrant une solution de sécurité globale personnalisable répondant à l´ensemble des besoins de sécurité applicative des entreprises mais également une solution de supervision globale de la sécurité. NS One propose pour renforcer ce positionnement sur le marché et conforter la volonté de l´éditeur de devenir en 2008 l´un des acteurs majeurs de la sécurité applicative, NS One marque clairement sa volonté de changement en proposnt LOG One, une solution de supervision et d´interprétation des logs générés par l´ensemble des équipements installés sur le réseau de l´entreprise. LOG One centralise, analyse et corrèle les logs des équipements de sécurité, de réseau et des serveurs. Les évènements collectés sont corrélés en temps réel pour produire des alarmes pertinentes et enregistrées en parallèle pour une analyse ultérieure. Un système expert étudie en permanence l´historique des évènements collectés pour compléter l´analyse en temps réel par des rapports. La solution couvre le cycle méthodologique complet de la gestion d´incident : prévenir, dé-tecter, confiner, enquêter, corriger et documenter. LOG One génère des alertes, définit des tableaux de bord paramétrables et génère automatiquement des rapports utilisés pour la mise en œuvre des procédures récurrentes du suivi et du contrôle de la politique de sécurité.

B. PRINCIPE DE FONCTIONNEMENT La centralisation des logs a pour objectif de pouvoir disposer d’une vue unifiée de toutes les sources d’évènements pertinentes pour la gestion de la sécurité. La nature des évènements collectés, la façon de les collecter et de les centraliser ayant une influence capitale sur les fonctionnalités qui peuvent être offertes.

C. COLLECTE La solution Log One est basée sur un système d’agents non intrusifs, distants et locaux, installés sur des boîtiers dédiés et placés près des équipements de sécurité ou directement sur les serveurs. Ils sont ensuite envoyés à un collecteur universel d’évènements qui les rapatrie sous les formats standards (LEA, File, OCBC, Syslog...).

D. RAPATRIEMENT, FILTRAGE, CORRELATION ET STOCKAGE Les logs sont collectés par des agents non intrusifs distants et locaux, installés sur des boîtiers dédiés près des équipements de sécurité ou directement sur les serveurs. La normalisation, le rapatriement, le filtrage, la corrélation et le stockage sont ensuite réalisés par Log Manager. Le filtrage défini par l’administrateur élimine tous les événements considérés comme inutiles. La corrélation d’événements de plusieurs équipements permet le déclenchement d’alarmes et d’actions paramétrables. La génération automatique de rapports d’analyse et leur transmission par e-mail ou encore l’émission d’alertes SNMP à destination des plates-formes d’administration et de supervision facilitent une exploitation 24/24 H.

La solution LOG One embarque le module Manager. Il assure :

Le filtrage de tous les évènements considérés comme inutiles. La corrélation d’évènements de plusieurs équipements pour permettre le

déclenchement d’alarmes et d’actions paramétrables. La génération automatique de rapports d’analyse et la transmission par e-mail. L’émission d’alertes SNMP à destination des plateformes d’administration et

de supervision. La réalisation d’analyses approfondies à travers un éditeur de requêtes

paramétrable.

E. ELABORATION DE RAPPORTS DETAILLES Afin de simplifier la mise en oeuvre d’une procédure de surveillance régulière et d’alertes, LOG One permet d’établir des rapports définis, automatiquement diffusés aux administrateurs de sécurité lorsque des alarmes sont déclenchées par des comportements interdits ou par des attaques.

Figure 1 : schéma de fonctionnement du SIEM Log One

5. CISCO SECURITY MARS

A. PRESENTATION Cisco Security Monitoring, Analysis and Response System (Cisco Security MARS) est un dispositif hautes performances évolutif d'administration et de surveillance, qui facilite la prise de décision en matière de sécurité.

CS MARS se positionne donc clairement comme une solution de type SIEM avec pour ambition d'apporter cette réponse non seulement aux infrastructures Cisco mais aussi dans des réseaux hétérogènes. Attention cependant, il est important de se souvenir que le travail qu'il faudra fournir pour paramétrer CS MARS sera beaucoup plus important que sur une solution 100% Cisco. Cette remarque restera par ailleurs valable pour les produits Cisco trop récents pour que des scénarios aient été déjà intégrés (exemple le CUCM). Ce point est traité dans un des der-niers paragraphes du document.

B. LES APPLIANCES CS MARS CS MARS est livré sous forme d'appliance. Il arrive donc sous forme d'un produit pré packagé ayant une plateforme physique définie avec un OS et un produit livré par l'éditeur et non modifiable. Les utilisateurs n'auront en aucun cas accès aux fonctions sous sous-jacentes de l'OS. L'interface de gestion des appliances est accessible au travers des protocoles sécurisés HTTPS (TCP 443) et SSH (TCP 22). Ces protocoles sont sécurisés et offrent les fonctions d'authentification, de chiffrement et d'autorisation. HTTP et Telnet sont désactivés de façon permanente. L'OS des serveurs est basé sur un linux renforcé. On trouvera par ailleurs une base Oracle et un serveur web de la famille Apache pour archiver les données et offrir une interface graphique (technologies web). Ces différents éléments sont mis à jour à chaque nouvelle version ou patch. Les différents modèles d'appliances sont décrits dans le tableau de la Figure 2. Dans l'absolu, il sera préférable de placer le CS MARS derrière des firewalls et IPS ainsi que dans une zone réservée à l'administration pour lui éviter d'être la cible d'attaques externes auquel il peut être sensible comme tout serveur. N'oublions pas qu'une fois configurée, cette application contiendra de nombreuses informations sensibles sur le réseau qu'elle aide à protéger.

Figure 1 : Les différents modèles d'appliance

C. LA GESTION DES PROBLEMATIQUES STM La gestion des problèmes de sécurité détectés ou STM. Le STM permettra d'automatiser le travail portant sur les problématiques sécurité bien identifiées pour permettre aux équipes de se focaliser sur les nouvelles menaces et les réponses à trouver. Les solutions STM se doivent d'être temps réels et de proposer des contre mesures de façon pro actives de manière à défendre le réseau en lui apportant les contre mesures nécessaires au moment les plus opportun. Les technologies STM commencent au même en collectant les informations des différents équipements. Les algorithmes de corrélation détectent alors des points chauds ou une attaque se déroule sur le réseau. La réponse apportée se porte alors non seulement sur les équipements directement attaqués, mais aussi sur l'ensemble des éléments périphériques pouvant permettre de bloquer l'attaque en amont. La plus value des technologies STM se résume essentiellement au travers des points suivants :

Une connaissance approfondie de la topologie du réseau et de son adressage permettant de réduire le volume important de log générer aux éléments clés permettant de cibler un incident,

Apport d'une interface graphique permettant d'identifier tous les éléments du réseau et leurs configurations mais aussi les emplacements d'incidents ou d'attaques,

L'intégration de scénario permettant des audits amont de la solution permet de réduire le nombre de faux positifs et d'améliorer le paramétrage de la solution pour gagner en efficacité,

L'apport d'une réponse en temps réel permettant de bloquer une attaque.

Remarque : CS MARS possède plusieurs méthodes d'apprentissage pour connaître la topologie d'un réseau:

Découverte du réseau (SNMP, Telnet, SSH). Il faut deux heures pour environ 300 périphériques,

Intégration de fichiers de topologie externes (support HP OV ou Cisco works), Interprétation des logs,

Entrées manuelles.

Figure 3. La gestion d'un événement au sein de CS MARS

D. LA GESTION DES ALARMES AVEC CS MARS Par alarme, on parle du cycle d'action déclenché par une remontée d'incident. On prendra par exemple le blocage d'un paquet suspect par un IPS et la trap SNMP qui est déclenchée suite à cette action au système de supervision. La liste ci-dessous donnera une indication sur les protocoles supportés pour assurer les remontées d'alarmes. Avec un CS MARS, au lieu d'avoir une simple remontée d'alarme, une corrélation d'évènement (mécanisme sommairement présenté en Figure 3) sera réalisée en amont de l'alarme envoyée à l'administrateur permettant ainsi de réduire les faux positifs, de qualifier très précisément le problème et de se concentrer directement sur les points essentiels, des actions correctives pouvant déjà être enclenchées en fonction du paramétrage. La Figure 4 présente un rapport remontant un premier niveau d'information suite à des évènements anormaux détectés par CS MARS. Protocoles utilisées pour les remontées d'alarmes : Syslog, SNMP, RDEP, OPSEC-LEA (Clear and encrypted), POP, SDEE, HTTPS, HTTP, JDBC, RPC, SQLNet. La gestion de ces alarmes pourra se faire au travers de différentes méthodes suivantes : SNMP, Mail, Syslog, Messages texte, SMS, Signal sonore. La gestion des incidents détectés se ferra soit de façon pro active soit sous réserve de validation par un administrateur au travers d'éléments comme ceux-ci :

Envoi de TCP reset, Fermeture de ports, Mise en place d'access-list, Isolation de VLAN, Politique de sécurité plus globale pour le réseau, ...

Ces modifications porteront en premier lieu sur les équipements impactés. Les modifications concernant un écosystème élargi (voir le diagramme de l'attaque en Figure 3) seront soumises comme des alternatives complémentaires et nécessiteront une approbation. On se reportera à la Figure 5 comme exemple concret. La connexion aux équipements devant être modifiés se fera au travers de SNMP, telnet ou SSH. C'est cette possibilité de provoquer une réaction temps réel et adaptée à l'incident qui place le produit CS MARS comme un brique importante du concept de Self Defending Network (réseau se défendant seul) poussée en avant par Cisco.

Figure 2 : Premier niveau d'information d'une alerte

E. GESTION DE L'ARCHIVAGE AVEC CS MARS CS MARS est basé sur une base Oracle. Celle-ci est bien sur correctement configurée pour l'ensemble des opération du produit et ne demandera pas de compétence particulière pour l'administrée. Par conséquent, l'ensemble des systèmes de connexion traditionnels de ce produit ont été désactivés et seules les opérations réalisées par l'interface d'administration ou les services de CS MARS seront autorisées. La structure de la base n'est pas publi-quement divulguée par Cisco. On notera que le produit possède des mécanismes d'export et de sauvegarde de la base vers des NAS permettant éventuellement de restaurer le système avec une perte minimum de données si un problème devait survenir sur le système.

F. LES RAPPORTS SOUS CS MARS Pour un outil de type STM, les problématiques de création de rapports et de requêtes sont un point absolument essentiel à regarder. En effet, si ces éléments ne sont pas bien traités, le produit perdra beaucoup de sa valeur car l'essentiel de l'information ne parviendra pas aux administrateurs en temps et heure. CS MARS intègre un choix important de rapport déjà construits qui permettront de traiter la plupart des cas rencontrés classiquement dans la vie d'un réseau. Ces derniers permettent

de partir d'informations globales et de relativement haut niveau pour arriver aux éléments très détailler (voir Figure 5). CS MARS propose désormais des rapports prenant en compte les spécificités des référentiels SOX, PCI et GLBA. Il est indéniable que l'intégration de rapports concernant ces référentiels devrait fortement facilité le travail des administrateurs devant montrer les conformités. Les personnes souhaitant plus de détails pourront se connecter à l'url suivante : https://cisco.hosted.jiveso ftware.com/docs/DOC-2302 (l'enregistrement est gratuit). Les méthodologies d'audit COBIT sont elles aussi intégrées. Il est intéressant de constater que même si l'accès à la base de donnée n'est pas accessible, un moteur de création de requêtes existe, permettant ainsi de modifier ou de créer des rapports prenant en compte les particularités d'un environnement donné. Le moteur chargé d'exécuter les différentes requêtes et de générer les rapports pourra être paramétré pour travailler en temps réel ou différé si l'on souhaite éviter d'accaparer trop de ressources pour cette tache à certaines périodes. Intégration d'un périphérique tierce. Pour intégrer un périphérique inconnu dans CS MARS, il sera nécessaire de créer un parser personnalisé. Ceci sera réalisé en trois grandes étapes (Figure 6) :

Définition du nouveau type de périphérique – les noms, modèles et version sont renseignés pour une bonne identification par le système,

Création des modèles nécessaires au parser – il s’agit ici d’indiquer quel est le format des messages qui seront reçu par CS MARS et comment chacun d’entre eux devront être interprétés,

Définition des règles – cette étape est optionnelle si l’on souhaite simplement intégrer les messages de l’équipement dans certains rapports. Par contre, s’il est destiné à être intégré dans la gestion d’incidents, il est absolument nécessaire d’effectuer cette étape avec sérieux et minutie. C’est d’elle que viendra la pertinence des réactions de CS MARS pour le périphérique,

Figure 5. Exemple de rapports

Figure 6. Intégration d’un périphérique tierce

G. QUELQUES CONSIDERATIONS D'ARCHITECTURE La façon la plus simple de travailler avec la solution CS MARS est de déployer un seul contrôleur, soit une seule appliance collectant l'ensemble des logs générés par les péri-phériques réseaux ou les serveurs et assurant l'analyse des données.

La seconde possibilité nécessite l'utilisation de deux briques appelées contrôleur global et local. Dans ce cas, des contrôleurs locaux sont placés sur différents sites. Les périphériques intégrés pour travailler avec CS MARS envoient les logs vers ces derniers. Les périphériques supervisés ne pourront jamais envoyer directement des données au contrôleur global. La supervision de la solution complète est effectuée depuis le contrôleur global. Chaque contrôleur local n'ayant qu'une vision limitée à son périmètre. L'utilisation du modèle utilisant deux types de contrôleur devra prendre en compte les éléments suivants :

Le volume de log total généré par les périphériques supervisés ne peut être absorbé par un seul serveur (20 000 logs/s et 600 000 netflows/s). Le listing 3 donnera quelques chiffres indicatifs permettant de calculer le volume généré par un réseau. Il est couramment considéré que si 60% de la capacité d'EPS du serveur est atteinte, il devient nécessaire d'envisager une mise à jour pour assurer le bon fonctionnement,

L'architecture réseau comprend des sites distants reliés à l'aide de liens WAN. Dans ce cas, le contrôleur global demande uniquement les informations nécessaires au contrôleur local et évite ainsi de saturer le lien WAN,

La société est composée de nombreux départements ou filiales avec des besoins spécifiques. Les contrôleurs locaux permettront à chaque département de répondre à ses propres exigences tandis que le contrôleur global amènera une vision globale et pourra être placé dans un SOC.

Il sera absolument nécessaire par ailleurs de calculer l'espace disque nécessité pour archiver l'ensemble des logs qui seront générés par l'installation supervisée. On pourra considérer que la taille moyenne d'un log sera de 300 octets. La formule suivante permettra alors un premier calcul : Nbre de jour archivés = Taille réservée à l'archivage / (Taille du log (donc ici 300 en moyenne) * EPS * 86,400).

Figure 7. Synoptique d'architecture avec les deux types de contrôleurs

6. ARCSIGHT ESM

A. PRESENTATION: ArcSight, une société HP, a été fondée en 2000 et est une société technologique qui fournit des informations de sécurité et de gestion des événements (SIEM) des solutions. ArcSight est en pole position du Quadrant magique de Gartner concernant les principaux éditeurs de solutions SIEM pour Mai 2010 ArcSight Enterprise Security Manager (ESM): moteur d'analyse de base pour gérer les menaces et les risques au sein de la plate-forme ArcSight constituée de : * ArcSight Logger: stockage des journaux de la plateforme et la solution de recherche * ArcSight Express: la corrélation et la gestion des logs * ArcSight IdentityView: suivi des activités des utilisateurs * Connecteurs ArcSight: la collecte des données provenant de diverses sources de données * Applications vérificateur ArcSight: surveillance continue des contrôles automatisés La plate-forme ArcSight supporte également la virtualisation, les environnements informatiques mobiles et de nuages ArcSight ESM assure l’analyse et la corrélation de l’ensemble des événements survenant dans l’entreprise – connexions, déconnexions, accès aux fichiers, requêtes de bases de données, etc. – et, ainsi, une définition précise des priorités de contrôle des risques de sécurité et des violations de conformité. ArcSight ESM constitue une application unique en matière de maîtrise du type d’utilisateurs du réseau, des données qu’ils voient, des actions dans lesquelles ils sont engagés avec quelles données et de compréhension de la manière dont cela affecte le risque d’affaires.

AVANTAGES DE CETTE SOLUTION:

La plate-forme ArcSight SIEM est un ensemble intégré de produits pour collecter, analyser et gérer les informations relatives aux événements d'entreprise. Ces produits peuvent être achetés et déployés séparément ou ensemble, selon la taille des entreprises et des besoins. Elles comprennent des logiciels et appareils pour: • Collection événement • Gestion des journaux •Automatisation Conformité • Surveillance d'identité Offrant des avantages tels que :

• performance, paramétrage, fiabilité • adapté aux besoins des grandes entreprises • procédures et les priorités de l’organisation • créée une liaison entre les exigences techniques de sécurité et l’objectif commercial • possibilités complètes d’application et fonctions add-on • non seulement les informations sur la sécurité sont regroupées, mais elles sont

également présentées par rapport à leur influence sur les processus commerciaux

• corrélation tridimensionnelle : informations de sécurité des différents produits, informations de vulnérabilité, caractéristiques d’actifs

• identification automatique des modèles • enregistrement des données à 100% et optimisation de l’enregistrement • incident Management intégré et contre-mesures automatiques contre les attaques

identifiées • peut-être installé sur tous les systèmes d’exploitation courants • permet le temps réel et l’analyse légale des informations • accès à base de rôles • fonctions d’analyse hautement développées • l’efficacité et la performance du département sécurité sont renforcées

ArcSight SIEM plateforme

B. ARCSIGHT MANAGER Le gestionnaire ArcSight est le cœur de l'ESM ArcSight. Le gestionnaire ArcSight est un système basé sur le serveur qui fournit une gestion des données, la logique de corrélation et les moniteurs d'affichage d'informations et de contrôles. Il constitue la base de différencier clairement les troubles de workflows. Cela permet à la détection des problèmes et le temps de résolution requise peut être réduite de manière drastique. FONCTIONNALITES CLES * Composante centrale de la corrélation en temps réel, l'analyse et le workflow * Encapsulé application Java, fonctionnant sur différents systèmes d'exploitation * Rédaction du flux de données d'événements provenant du connecteur ArcSight ArcSight Smart dans la base de données * Pré-filtres, règles, moniteurs de données, des tableaux de bord et des rapports

C. COLLECTE ArcSight Smart Connector collecter des événements du journal à partir de différentes sources et de les passer à travers l'utilisation de l'infrastructure réseau existante pour le gestionnaire ArcSight. Une grande organisation a environ plusieurs centaines de différents Logdatenquellen qui surveille, doivent être consolidés et fusionnés. ArcSight connecteurs intelligents sont capables de collecter des milliers d'événements par seconde et l'envoyer au gestionnaire ArcSight. Pour l'analyse, l'affichage, l'analyse et de reporting de ArcSight Manager stocke les événements reçus dans la base de données ArcSight. Connecteurs ArcSight isole votre sécurité et analyse de la conformité de vos choix technologiques. En recueillant les journaux dans des formats de périphérique natif, puis normaliser ces données dans un format commun, connecteurs ArcSight produit une structure unique pour la recherche, la corrélation et de reporting sur les informations de l'événement. En conséquence, la plate-forme d'analyse est à l'épreuve des nouvelles technologies réseau. Swap sur un seul fournisseur de pare-feu pour une autre, et tous les rapports de conformité, de corrélation et continuera à travailler comme défini. Les connecteurs sont disponibles en tant que logiciel installable, les appareils du centre de données, ou des appareils branch-office/store petits. Connecteurs ArcSight découple la capacité d'une organisation pour analyser les risques de vulérabilité des périphériques réseau. FONCTIONNALITES CLES * Analyse et la normalisation des événements du journal * Les collecteurs de données pour divers Logdatenquellen * Filtrage et agrégation d'événements Catégorisation * des événements dans un générique (fabricant indépendant) de format

D. ARCSIGHT BASE DE DONNEES La base de données est une base de données ArcSight relationnelle Oracle optimisée pour le stockage de tous les événements du journal. Une indexation efficace et efficiente des données fournit un accès rapide à des événements historiques dans l'analyse des journaux de sécurité, ou lors de la génération de rapports. Outre le stockage des événements du journal est stocké dans la base de données et la configuration de l'ESM ArcSight ArcSight - tels que Les utilisateurs, groupes, les paramètres d'autorisations, règles, filtres, tableaux de bord, la modélisation des réseaux, rapports, etc FONCTIONNALITES CLES * Référentiel central pour tous les événements du journal normalisé * Stockage efficace par compression, partitionnement et l'archivage * Base de données relationnelle basée sur Oracle 10g * Fournir des données en fonction du volume DB-volume et de données dans la plage allant jusqu'à plusieurs mois

E. ANALYSE DE LA SECURITE AVEC LA CONSOLE ARCSIGHT La console ArcSight fournit l'interface globale pour tous les utilisateurs d'ArcSight ESM alors que l'utilisation de la zone de la console ArcSight comprend l'exploitation d'une exploitation COS (Centre d'Opération de Sécurité) qui se concentre sur le suivi des indicateurs d'alerte et le signalement des incidents est, ainsi que les Création de contenu ArcSight (telles que le filtrage, les règles de corrélation, tableaux de bord, rapports, etc) pour l'analyse de la sécurité en aval. La console ArcSight est également l'outil central pour gérer et administrer le dar ESM ArcSight. FONCTIONNALITES CLES * une interface basée sur Java, conçu pour Operation Center de sécurité * Fournit des outils pour la définition des filtres, règles, rapports, affiche, alarmes, etc.. * Permet de contrôler l'accès basé sur les rôles, à partir d'un tableau de bord simple de créer des règles de corrélation complexes

F. GESTION DES ALERTES ArcSight produit de log management, ArcSight Logger, est un appareil autonome pour stocker, gérer et rapports contre les données du journal d'entreprise. Un seul appareil peut effectivement stocker jusqu'à 35 To de données journal, sans besoin de réglage ou d'optimisation. ArcSight Logger offre de recherche et de reporting, ainsi que d'alerte par e-mail, SNMP ou d'une console Web. Contrairement aux autres produits de gestion des logs, ArcSight Logger fournit drill-down à partir des alertes et des rapports sur les événements source derrière l'alerte ou de rapport. En conséquence, même les clients qui n'ont besoin que simple bénéfice d'alerte et de reporting de «Forensics à la voléesont servis.

G. CORRELATION

Corrélation avancée ESM utilise une variété de techniques sophistiquées pour passer au crible millions des événements pour trouver les incidents qui peuvent avoir un impact véritable sur l’entreprise. Corrélation effective est très importante; résultats de corrélation pauvres soit manquée menaces ou de trop nombreux faux positifs et donc, gaspillage de temps et d'argent. ArcSight ESM fournit "Forensics sur le Fly "en temps réel par l'intermédiaire de corrélation sur plusieurs systèmes et des millions d'événements, avec drill down à partir d'un complexe d'alerte aux événements qui il a causé.

Réponse automatique

Lorsque ArcSight ESM détecte un problème potentiel via la corrélation des événements, le moteur de réponse guidée facultative, Threat Response ArcSight Manager (TRM) peut fournir aux administrateurs pilotées par les processus des conseils pour endiguer le problème. Par exemple, si ArcSight ESM détecte un employé potentiellement accéder à des enregistrements dans un de manière non autorisée, ArcSight TRM peut déterminer quels actifs Annuaire en compte pour désactiver, ce qui la session VPN à débrancher, etc et ensuite un guide de l'administrateur à travers les mesures appropriées. ESM est disponible comme logiciel configurable ou comme un appareil (ArcSight ESM E7100), et peut être déployé sur ses propres ou avec ArcSight Logger et connecteurs ArcSight. En utilisant ESM et ArcSight Logger ensemble, les clients peuvent trouver des anomalies en temps réel, puis les comparer aux données historiques pour plus de contexte. ArcSight ESM rend les organisations plus efficaces et plus sécurisés par filtrer le «bruit» et en se concentrant sur les incidents les plus importants.

H. AUTOMATISATION DE CONFORMITE ArcSight conformité Forfaits Insight est un moyen idéal pour lancer un projet de conformité ou d'automatiser le suivi du manuel existant contrôles de conformité. Installable sur le dessus de la plate-forme ArcSight SIEM, Ces modules fournissent de pré-emballés règles, rapports, tableaux de bord et alertes mappés à des réglementations spécifiques. Grâce à l'automatisation et la meilleure pratiques, ArcSight conformité Forfaits Insight peut réduire considérablement le coût et les efforts de conformité.

Figure 1 : Scema de fonctionnement du package ArcSight ESM

CONCLUSION : L’objectif de ce rapport était d’apporter des réponses quant au fonctionnement des SIEM dans le cadre d’une gestion centralisée. Pour cela, nous avons commencé par expliquer le contexte : l’intérêt de l’utilisation de cette méthode centralisé. Nous avons ensuite étudié le fonctionnement théorique de cette méthode, ainsi que deux implémentations concrètes. Notre étude nous a aussi permis d’étudier les principaux avantages de la gestion centralisée :

la simplicité de configuration du manager la visibilité globale du réseau par le manager la cohérence des alertes et des décisions menées

Cependant cette technique possède aussi des faiblesses. Par exemple la centralisation peut amener rapidement un problème de disponibilité du service si le manager est défaillant. Nous pouvons conclure que les SIEM en gestion centralisée permettent une réelle sécurisation du système, mais que l’on doit s’assurer de leur disponibilité, et qu’il semble malvenu d’utiliser les envois non sécurisés de logs. Les SIEM étudiés ont chacun leurs particularités. Prelude que nous avons jugé utile de faire l’étude vient du monde open-source, ce qui lui permet une très large compatibilité avec d’autres logiciels et équipements. Les autres produits tel que LogLogic, ArcSight, CS-MARS …sont des produits issus de l’industrie et possède un système de traitement des alertes très performant. Le « reporting » est presque identique, puisque Prelude en version professionnelle a de nombreux ajouts. Les SIEM sont de plus très évolutifs car leurs auteurs permettent aux diverses entreprises de demander des améliorations et modifications sur-mesure, moyennant finance évidemment. Une théorie des SIEM existe donc, ainsi que des standards. Les développeurs de logiciels de SIEM ont un panel de caractéristiques possibles à exploiter et ceux-ci choisissent ce qui les intéresse en fonction de leur politique technique, organisationnelle et commerciale. Nous pouvons donc trouver une multitude de SIEM sur le marché avec aussi bien des ressemblances que des divergences qui font les faiblesses et forces de chacun. Nous conclurons sur l’intérêt de l’utilisation d’un système tel que le SIEM pour une entreprise. En effet, la possibilité de pouvoir récupérer et agréger la totalité des logs du réseau permet d’avoir à la fois une vision complète, mais aussi une compréhension affinée des évènements qui se passent sur celui-ci. La combinaison de ces deux éléments (vison + compréhension) fait des SIEM un élément nécessaire en terme de sécurité informatique et est donc indispensable pour les entreprises.