[SIM] MISSION: Watch everything!

Dans de nombreuses tâches de sécurité, il faut faire appel aux logs. Mais il s'agit certainement de l'une des tâches des plus difficiles car deux problématiques essentielles se posent : où chercher ? et comment ne pas manquer l'information utile parmi tous les logs fournis par l'ensemble du réseau (serveurs et équipements réseau) ? La solution existe depuis un moment maintenant et son nom de code est SIM pour Security Information Management. A travers l'exemple Open Source nommé OSSIM, nous verrons les caractéristiques et les réponses techniques apportées par ce type d'outils.

Identification :

• Définition ;
  

Un SIM est un moteur de corrélation dont la puissance peut être évaluée par le nombre de logs qu'il peut traiter à la seconde et les types d'information qu'il est capable de comprendre. A l'issue de cela, un SIM corrèle les logs selon des règles pré-établies afin de remonter des alertes en (quasi) temps réel.

• Caractéristiques basiques ;

S'il existe de nombreux SIMs sous forme d'appliance, OSSIM est entièrement software. Il a plusieurs but principaux qui sont de superviser et de piloter la sécurité d'un (sous-)réseau dans sa globalité. En effet, il prendra en compte aussi bien les serveurs (quelque soit l'OS) que les équipements réseau (pare-feu, routeurs, etc...). Pour cela, notre SIM utilise une architecture client / serveur. Nous aurons d'une part la partie serveur sur lequel tournera un service pour l'affichage de la console de pilotage et d'autre part, les clients qui sont en réalité ni plus ni moins des agents. Ces derniers auront simplement pour rôle de collecter des informations et de les renvoyer vers le serveur. Comme nous l'avons compris, OSSIM est une solution Open Source par sa conception mais aussi par les modules (appelés sensors) utilisés. En effet, pour collecter les informations nécessaires, notre corrélateur se base sur les outils les plus connus de la communauté Open Source utilisés en tant que "sensor". On parle alors de SNORT/ACID, NESSUS, NMAP, NTOP, p0f, TCPTrack, Syslog, PADS et NAGIOS.

• Caractéristiques avancées :

A - La corrélation

La corrélation se fait à partir de toutes les informations récoltées par les agents, chacun devant être disposés sur des noeuds stratégiques du réseau à superviser. Ensuite, les informations sont traitées en les confrontant. Premier avantage, on réduit le nombre de faux-positifs qu'un sensor à lui-seul fournirait (ex : SNORT). La corrélation peut être détaillée en trois étapes :

1. Cohérence des données - OSSIM commene par examiner la cohérence des données collectées pour en déterminer la pertinence. Grâce à un inventaire de matériel et de logiciels présents sur le réseau, nous saurons que tel serveur utilise IIS par exemple. Si une alerte à propos de cette même machine concerne Apache, le score de pertinence sera très faible.
2. Correspondance des données - OSSIM a aussi à sa disposition une table de correspondance alertes-versions et alertes-vulnérabilités fournies par SNORT et NESSUS. Ainsi, supposons qu'une alerte remonté par SNORT correspond à une vulnérabilité connue après un scan de NESSUS, le score de pertinence sera cette fois élevé.
3. Les directives logiques - Pour terminer, notre solution fonctionne aussi avec des directives ou règles qui permettent de corréler des anomalies, des alertes et des états (fournis via les moniteurs).

B - La prioritisation ;

Pour qu'une solution de sécurité soit efficace, il faut que celle-ci s'adapte au mieux aux particularités et aux exigences de l'environnement où nous désirons la déployer. OSSIM est capable de répondre aux questions suivantes :
1. Qu'est-ce qui est important pour la sécurité ?
2. Quelles sont les adresses sources que l'on redoute avant tout ?
3. Quelles sont les adresses de destination les plus critiques ?

Par exemple, nous admettons qu'une attaque provenant d'Internet et ayant pour cible une adresse interne de notre réseau est prioritaire, d'autant plus s'il s'agit d'un serveur financier plutôt qu'un serveur d'impression. Alors, nous pourrons via notre SIM donné un score de priorité entre 0 (priorité minimale) et 5 (priorité maximale) pour chaque équipement réseau.

C - L'évaluation des risques ;

Grâce à la combinaison de plusieurs éléments, OSSIM est capable d'évaluer le risque d'une attaque en cours. Il se base sur :

1. L'algorithme CALM (Compromise et Attack Level Monitor).
2. Les directives (pré-établies ou écrites).
3. Des seuils de tolérance.

Ce système de points fait l'objet d'un calcul qui permet d'évaluer le niveau de l'alarme :

niveau_alerte = (importance_machine * prioritisation * risque) / 10

Le tableau de bord d'OSSIM :

A travers un exemple concret d'attaque et d'investigation, voyons le tableau de bord fourni par la solution. Celui-ci est founi via un portail WEB. A noter que des fonds d'écran sont disponibles sur le site d'OSSIM.

• Le panneau de contrôle général ; Fournit les informations globales (niveau de sécurité actuel de l'ensemble du réseau, alerte la plus grave pour le réseau, les sous-réseaux, les serveurs). Aussi, on y trouve un graphe avec le nombre de machines éventuellement attaquées et attaquantes (après compromission).

• Le riskmeter. Si le premier panneau montre un problème (ex : nombre de machine attaquées en augmentation), nous nous dirigeons vers le riskmeter qui est un graphe en barre dont la valeur augmente dans le même temps qu'une attaque s'intensifie. par exemple, lors d'un scan massif, au fur et à mesure des scans, nous verrons la barre correspondant à la machine cible avancer en temps réel. Quelque chose se prépare !
  
• Le tableau d'alerte. Ici sont regroupées les alertes remontées par SNORT et visualisées avec l'interface ACID ou BASE (au choix). Chaque alerte peut correspondre à une phase de l'attaque.
  
• Le tableau d'alarme. L'ensemble des alertes relevées en 3 peuvent constituer une alarme après corrélation. Dans ce nouveau tableau, nous voyons les attaques repérées (ex : la propagation d'un vers) et le niveau de l'alarme (de 0 à 10).

• La gestion d'incident. Il est donc temps d'agir alors, on utilise l'outil de ticketing qui permettra d'alerter les personnes concernées de l'attaque en cours. La réactivité est de mise dans ce genre de situation.
  
• Les statistiques. Une fois l'incident repéré et traité, il ne faut pas que cela se reproduise. Grâce aux panneaux fournis par NTOP entre autres, nous pourrons trouver des indices par rapport à l'origine de l'attaque. Aussi des tableaux comme le top 20 des attaques nous permettront de concentrer nos efforts sur les points les plus critiques de notre S.I.
  

Les résultats fournis par OSSIM :

Un tel outil n'a de sens que s'il est en mesure de fournir différents résultats qui nous aideront à gérer les incidents, à fournir les informations nécessaires en cas de forensics, à dessiner les graphes qui vont bien pour évaluer la sécurité de son S.I et en trouver les points faibles (dans le but d'y remédier bien sûr).

C'est donc sous forme de mails, ticketing, graphes, tableaux et rapports (PDF, HTML, ...) que nous aurons à disposition toutes les informations nécessaires.
Les informations obtenues, étant de différentes natures, pourront soit être utiles à un Administrateur Sécurité (rapport technique, relevé d'incident,...) soit à un RSSI (statistiques, top20, synthèses).

D'autres information dans l'article d'Hakin9, numéro 10/2007.