Du bon usage des logs de sécurité

Connaitre l’état de la sécurité d’un système d’information requiert bien souvent la mise en place d’un outil de gestion de ses évènements. Depuis les règles de collecte des évènements de sécurité jusqu’à la mise en place d’un indicateur hebdomadaire de niveau de la sécurité, voici une méthode pour monter un tableau de bord qui pourra s’appliquer à une nouvelle infrastructure ou une infrastructure existante.

Appelé SIEM pour « Security Information and Event Management », SEIM (« Security Event Information Management »), SEM (« Security Event Management ») ou simplement SIM (« Security Information Management »), cet outil a pour ambition de traiter les nombreux évènements générés par les composants d’un système d’information. Il doit aussi assurer les principales fonctions de traitement suivantes :

• collecte des évènements
• agrégation des évènements
• corrélation des évènements
• reporting des évènements
• archivage des évènements

Les évènements (logs ou alertes) de sécurité sont en effet parmi les seules informations qui permettent à la fois de mesurer le niveau de sécurité, de détecter d’éventuelles menaces et d’enclencher les éventuelles actions à entreprendre, le tout en temps réel ou pas.

Ne pas établir un niveau de sécurité, ne pas analyser les évènements de sécurité, leur évolution et leurs caractéristiques, revient à ne pas maîtriser son infrastructure réseau

Mise en place d’un tableau de bord

Outre les besoins de contrôle de conformité, de rétention légale ou d’analyse post-mortem, la supervision à des fins de détection d’une menace passe par les modules suivants :

• analyse des évènements,
• corrélation des évènements
• alertes en temps réel et/ou rapports programmés

Nous excluons ici toutes les fonctions complémentaires que pourrait apporter un outil d’analyse de logs, comme les fonctions d’inventaire de parc, de gestion de tickets d’incident ou autre rétention d’information à des fins d’archivage règlementaire.

Un SIEM n’est pas autonome

Malgré tous les efforts marketing des éditeurs, il est important de savoir qu’un SIEM ne fonctionne pas tout seul. Les mécanismes d’extraction syntaxique d’informations à partir d’un événement collecté ne s’avèrent pertinents que s’ils se basent sur des grammaires déjà connues.

Les agents de collectes proposés par les SIEM ne s’appuient effectivement que sur une partie des informations qu’ils ont jugées intéressantes d’un point de vue de la sécurité.

Selon qu’il s’agisse d’évènements issues d’un équipement passif avec peu de fonctionnalités comme un boitier VPN ou d’un équipement très utilisé avec des fonctionnalités avancées comme un serveur proxy, le nombre d’événements de sécurité intéressants à collecter ne sera pas le même :

• d’une part, les agents de collecte ne connaissent pas les particularités de votre réseau pour y trouver des informations pertinentes,
• d’autre part, ils ne connaissent pas non plus tous les équipements et la manière dont ces derniers organisent l’information dans leurs logs (par exemple, équipement Huawei).

Exhaustivité de l’analyse

Il est donc nécessaire de mettre tout d’abord en œuvre une méthode d’analyse structurée, de la définition des informations à collecter jusqu’à l’élaboration des tableaux de bord finaux, en passant par la mise en place, nous le verrons, de niveaux de référence.

À titre d’exemple encore, pour un routeur Cisco dont la fonction est de simplement aiguiller le trafic, il y aura peu d’événements à collecter. À l’inverse, une passerelle Internet, proposant de multiples fonctions comme un pare-feu, un composant de filtrage d’URL ou un antivirus, produira en comparaison une multitude de fichiers de journalisation et donc d’évènements à collecter.

De plus, les équipements évoluent constamment ainsi que les logs générés. Il est donc nécessaire d’analyser cette évolution des logs afin d’accroitre les évènements considérés comme pertinents pour la sécurité (cas de journaux Windows ou de sondes IDS).

Inventaire des sources

La première étape consiste à lister l’ensemble des équipements qui constitue les sources des évènements ou logs. Sources qui seront de plus en plus nombreuses, car selon le SANS Institute, une nouvelle génération de SIEM, appelés « SIEM v2 » se concentre sur la collecte la plus vaste possible d’informations, ne se basant plus uniquement sur des informations issues des syslogs, mais aussi netflow ou SNMP par exemple.

Cette volonté d’étendre à l’infini la collecte d’informations est sans doute tout autant liée à la baisse des coûts de stockage et de temps-machine (CPU) qu’à l’optimisation du fonctionnement des bases de données et autres moteurs internes des SIEM.

Nous commencerons donc ici notre projet avec un nouvel équipement de sécurité à introduire dans l’infrastructure de notre système d’information.

Préparation de l’analyse

La collecte des données événementielles brutes s’effectue soit par une extraction directe de logs provenant de l’équipement, soit par la réception de ces logs par un agent déjà configuré sur notre environnement.

Le volume de données sera sans doute proportionnel au nombre de fonctionnalités qui sont déployées sur l’équipement. Cependant, par expérience, pour qu’une analyse soit pertinente, il faudra collecter au moins 10.000 évènements chaque jour.

Munis de ces évènements, il vous sera à présent utile de disposer :

• de la documentation du fournisseur ou éditeur de l’équipement fournissant les logs
• d’un éditeur de texte permettant de manipuler des chaines via des expressions régulières (ex : « EditPad Lite 7 »)
• d’un tableur bureautique (ex : Microsoft Excel)

Analyse syntaxique par élimination

Les logs ou évènements doivent à présent être analysés manuellement. Pour cela, nous allons devoir les classer par catégories :

• les logs non nécessaires ou incomplets,
• les logs relatifs à l’administration de l’équipement,
• les logs relatifs à la disponibilité de l’équipement,
• les logs relatifs aux services assurés par l’équipement (ex : journaux de connexions dans le cas d’un serveur proxy).

On peut utiliser la documentation de l’équipement, l’information de catégorisation (facility level) pour définir le modèle de reconnaissance (appelés aussi « patterns ») qui va différencier ses logs des autres.

Exemples de chaine de caractère : « %ADMIN% », « %PROXY% » ou encore « %AAA% »).

Les évènements à rejeter et à conserver

Un certain nombre d’évènements sont à rejeter, car ils sont :

• sans lien avec des informations propres à la sécurité,
• insuffisamment explicites,
• non utilisables par des mécanismes de corrélation,
• non utiles pour l’élaboration des rapports finaux.

Exemples de logs non suffisants :

Exemples de patterns de logs à conserver :

• les évènements ayant en commun la chaine de caractère <AAA> (Authentication, Authorization, Accounting),
• les évènements de connexion/déconnexion ayant en commun la chaine de caractère <NAT> (Network Address Translation).

Création d’un dictionnaire d’évènements

Pour chaque évènement que nous décidons de conserver ou rejeter, il nous faut à présent créer une expression régulière qui va correspondre à tous les événements de ce type, et enregistrer cette expression dans un document de travail avec notre tableur.

Pour le moment, notre document de travail liste les types d’évènements, la décision associée de conserver ou rejeter, et leur associe une étiquette (par exemple, « REJECT001 » pour le 1^er type de logs à rejeter).

Pour les évènements conservés, il sera nécessaire de fournir plus d’informations :

• nom de l’élément : il doit être le plus explicite possible en indiquant si possible le type de log concerné (exemple: « CISCO-CUST_1001_BAD-AUTH »),
• pattern de correspondance (.*Login/sAccepted\s :% 1.*),
• numéro d’alarme unique (tel qu’associé dans le SIEM),
• sévérité de l’alarme (telle qu’associée dans le SIEM. Elles sont en général basées sur la sévérité mentionnée dans le syslog),
• données récupérées par le pattern (exemple : « user=$1|srcip=$2|srcport=$3|destip=$4|destport=$5 »),
• action à entreprendre (par exemple, générer un email),
• commentaires (indications pour les futures règles de corrélation).

L’utilisation d’une convention de nommage s’avère très puissante. Par exemple : « DEVICETYPE_ALARMTYPE_ALARMID_DETAILS ».

Implémentation des collecteurs

En vertu du principe des vases communicants, toutes ces règles de syntaxe doivent être appliquées dans l’agent de collecte du SIEM en plus des règles existantes.

Au final, notre agent de collecte va utiliser au moins quatre groupes de règles :

• les règles « custom reject »,
• les règles fournies par le SIEM,
• les règles « custom »,
• les règles « catch all rules » (tout ce qui n’est pas parsé).

Tableaux de bord

Une fois les évènements collectés et analysés, il reste à les intégrer dans un tableau de bord. Celui-ci sera fonction d’un périmètre souhaité. Par exemple :

• un tableau de bord pare-feu du réseau interne pour les évènements de sécurité associés (leurs logs vont être regroupés ensemble puisqu’ils font face aux mêmes niveaux de menace),
• un tableau de bord « Authentication, Authorization, Accounting » pourra être construit à partir de l’association de l’ensemble des évènements de type « AAA », quels que soient les équipements sources.

Figure 3 : Exemple de tableau de bord : flux IP de l’entreprise

Intégration et surveillance

Au final, l’intégration passe par la création de règles d’analyse syntaxique dans les agents de collecte, la définition des alarmes (avec leurs sévérités, les actions à prendre,...) et la création ou la mise à jour de rapports programmés. Ce travail est accompli pour chaque nouvel équipement ou chaque nouvelle alarme créée.

Il est également important de mettre en œuvre une procédure d’analyses régulières de chaque rapport par les équipes du SOC (Security Operations Center) :

• analyses quantitatives (nombres d’événements),
• analyses qualitatives (sévérités des événements).

Mis à part les alarmes générées en temps réel, cette revue hebdomadaire permettra dans un premier temps de supprimer les « bruits » jusqu’à atteindre un niveau de stabilité qui permette de détecter des évènements de sécurité peu verbeux.

Chaque évènement non classifié devra également être analysé pour classement éventuel dans les catégories « à rejeter » ou « à conserver ». Ces analyses peuvent être aussi longues que le réseau est complexe.

Figure 4 : Flux et consolidations des alertes produites par le SIEM

Le SIEM valorise tous les équipements de sécurité

De nombreux projets de SIEM sont rapidement abandonnés après leur lancement en raison du modèle de coût (CAPEX/OPEX) juge trop élevé. Néanmoins, il permet d’identifier des problèmes de sécurité invisibles jusque-là et d’exploiter les équipements à leur juste valeur. Le choix d’un produit SIEM doit être guidé par ses besoins spécifiques : création de ses propres règles d’analyse syntaxique, de ses propres alarmes et de ses propres rapports. Et tous les produits ne l’offrent pas, ou alors il faut payer des services de consultation.

Cyrille Aubergier

crédit photo : vector flat secure icon - www.fotolia.com