En introduction, Gilles Lehmann a expliqué que le marché de la cybercriminalité est en plein développement du fait de la facilité de réaliser des attaques. On est passé d’attaques qui ciblaient des entreprises de façon unitaire à des attaques multiples visant même des Etats. Ainsi, les risques augmentent, c’est pour cela qu’il faut mettre en place des formats de défense standardisés afin de mutualiser les efforts de protection. Par ailleurs, des contraintes réglementaires deviennent prééminentes avec par exemple la LPM qui ciblent les OIV, les directives européennes comme la NIS Network and Information Security. Le seul frein aujourd’hui est le périmètre concerné qui va induire des coûts supplémentaires pour les entreprises concernées. Sans compter bien sûr, les législations autour de la protection des données personnelles où en cas de pertes, il faudra envoyer des notifications… mais qu’elles vont être les canaux utilisés, les personnes concernées ?

De ce fait la détection d’intrusion devient une obligation. Il est rappelé que chaque attaque suit le même schéma en 5 points : le recueil d’information, la pénétration, la persistance dans le SI, la propagation et la paralysie du système.

Pour détecter une intrusion il faut pouvoir être informé d’événements comme des scans de ports, une reconnaissance applicative, une tentative de connexion... L’objectif de la détection d’intrusion est d’alerter l’exploitant le plus tôt avant l’attaque. Pour cela, il faut collecter des traces, caractériser un incident... Pour cela, les outils, de détection d’intrusion existent comme les sondes de tout type NIDS, HIDS, modules d’analyses, antivirus, WAF... Les informations sont alors envoyées dans un SIEM incluant un SIM (Security Information Management) et d’un SEM (Security Event Management) . Le premier permet d’indexer les données collectées et le second de gérer en temps réel les événements de sécurité. L’ensemble des deux permet de collecter et d’analyser les logs et s’appelle donc un SIEM. 

Au niveau pragmatique, à chaque alerte, une corrélation est réalisée afin de qualifier chacune d’entre elles. En fait, chaque sonde produit une alerte qui est par la suite transportée et centralisée. Puis, elle est stockée, archivée et indexée. Par la suite, elle est comparée, corrélée avec d’autres. L’étape suivante est celle de l’analyse à la fois pour vérifier si on est face à une tendance et faire des statistiques. Le même processus doit être fait pour les incidents déduits des alertes. Des corrélations doivent être faites en temps réel et sur le long terme. Pour réaliser toutes ces étapes, il est donc indispensable d’utiliser un format de description d’incident commun.

Des formats standards sont indispensables, mais lesquels choisir ?

Gilles Lehmann a par la suite décrit les deux formats choisit par CS.

Le format IDMEF : RFC4765
C’est un format technique qui permet de faire de la remonté d’information via des outils de détection d’intrusion. Ce format permet une contextualisation des alertes en entrant dans le détail.

Le format IODEF : RFC5070
C’est un format d’échange d’informations entre SOC qui remplace les formulaires adressés aujourd’hui. IODEF se présente de la même manière que le format précédent.

Dans, les faits, tout commence par des données brutes qui vont être analysées dans IDMEF. Puis lorsqu’un incident est qualifié l’information est envoyée dans IODEF. Ces deux formats sont définis à l’IETF. Ils utilisent des objets communs, sont complémentaires et couvrent l’ensemble de la problématique détection et incident.

Puis, il a rapidement présenté PRELUDE, l’outil SIEM proposé par CS qui s’appuie sur les deux formats standards pour l’envoi d’alertes et l’analyse.

Le projet SECEF

Par la suite Gilles Lehmann a présenté le projet SECEF. Au départ, tout est partie de la longue expérience de CS dans les standards IETF. Il était convaincu de l’urgence, pour la communauté cyber et en particulier les OIV, d’utiliser un standard. Le projet a obtenu un financement RAPID. (Régime d’Appui PME pour l’Innovation Duale). L’objectif de ce projet est la promotion et l’amélioration des formats IDMEF et IODEF. Il est mené par le consortium CS, Telecom Sud Paris et Centrale Supelec pour une durée de deux ans. Aujourd’hui le projet est à mi-chemin. Ainsi, de nouvelles sondes IDMEF ont été créées. Des tutoriaux ont été rédigés. Une étude des formats "incidents" a été réalisée.

Hervé Debar a présenté le contexte et dressé un historique des standards. En fait plusieurs standards existent qui sont plutôt propriétaires. Ainsi, HP (Arcsight),IBM... ont leur format, l’objectif étant de pouvoir exporter les alertes dans ces formats. Il a rappelé que la création du domaine dit « de la détection d’intrusion » date de 1980 avec James Anderson, puis en1985 avec Denning. Par la suite, la DARPA (Defense Advanced Research Projects Agency) a souhaité homogénéiser l’évaluation des logiciels de détection d’intrusion développés par les chercheurs qu’elle finançait. Ainsi, un groupe a été lancé aussi via l’IETF. Dans les années 2000, les premiers SIEM sont apparus avec ISS Proventia et IBM Tivoli RISK Manager.

En fait aujourd’hui, deux standards émergent : un américain avec l’IDWG et l’IDMEF pour les alertes. Pour les incidents l’IODEF/MILE est le standard européen et Cybox, STIX et TAXII, le standard américain.

Actuellement, l’IODEF est en version 2 qui intègre le phishing, les politiques de sécurité, le contrôle du Darknet... Les protocoles de transport pour la version 2 sont RID et ROILE mais peut-être mis dans des mails, ou par tout autre protocole y compris le téléphone. Les CERT se sont investis dans ce projet. Quant aux standards américains Cybox, STIX et TAXII, ils ont été développés pour permettre l’échange automatisé d’informations sur les cyber-attaques entre organisations et produits.

Quant aux IOC (Indicator of Compromise) initialisé par la société Mandiant, ils permettent de décrire des indicateurs de compromission. Une version Open source est disponible OpenIOC.

En conclusion il a rappelé que les efforts se portent sur les mécanismes d’échange d’informations afin d’améliorer la détection et la remédiation. Ces mécanismes fonctionnent entre les CERT. Par contre l’impact sur les techniques de détection et de corrélation reste à déterminer. Enfin, il a rappelé que même si IDMEF est dit complexe il permet de lever des ambiguïtés et d’assurer au récepteur le niveau minimal d’interaction lui permettant d’évaluer le risque.

Panorama détaillé des formats d’alertes

Guillaume Hiet a dressé un panorama détaillé des formats d’alertes en expliquant champs par champs les informations nécessaires à l’exploitation des alertes. Bien sûr, ces formats nécessitent de l’encodage. Pour lui, il faudrait définir un format d’encodage et de transport qui soient agnostiques. Il faudrait limiter le travail de normalisation du manager, faciliter l’interopérabilité des outils et faciliter la spécification de règles de corrélation "générique". Il y a de nombreux formats propriétaires comme ceux de HP appelé CEF, LEEF par IBM et SDEE élaboré par CISCO. De plus, il existe des formats standards l’IDMEF portés par l’IETF, le CEE porte par le MITRE et le CEE Board, le format CIM du DMTF et XDAS/CADF porté par The Open Group, Novell et le DMTF.

Une comparaison a été réalisée afin de pouvoir effectuer des traductions mais aussi pouvoir améliorer le format IDMEF. Il a été regardé les références et la documentation, le transport et l’encodage, le pouvoir d’expressivité et la richesse, la structuration et enfin comment est gérée l’extensibilité.

En comparant ces différents formats, il apparaît qu’IDMEF est très bien documenté avec138 pages de RFC, le style contextuel de la RFC n’aide pas à visualiser le schéma. Par contre, il manque une définition claire de la stratégie de peuplement pour différents user-cases. Il est vraiment orienté détection d’intrusion. C’est un format très riche qui décrit en 33 classes et 108 à 160 attributs les informations.
CEF est documentée, mais a une description plus succincte. Elle utilise un transport et un encodage Syslog. Elle est très orienté événements de sécurité. Elle est peu structurée, il n’y a pas de dictionnaire mais peu de champs le nécessite. Donc est un frein au traitement automatique.

LEEF est documenté, a un transport et un encodage Syslog. Le format est peu riche et il n’a pas d’extensibilité possible.

Le format CIM est pour sa part très bien documenté et est bien structuré. Il couvre un domaine plus large car il est utilisé pour décrire un SI. En fait, une sous partie décrit les alertes, est expérimentale depuis un certain temps et serait peu utilisé. Pour la partie sécurité, le format est peu riche. Par exemple elle ne décrit pas la sonde, les fichiers, les processus...le schéma est moyennement structuré avec 49 attributs. Enfin, l’extensibilité est gérée par héritages.

CEE avait pour objectif d’avoir un format commun pour l’échange de logs ce qui était trop ambitieux. Le projet est arrêté par contre sur le site du MITRE il y a une documentation très légère avec des schémas. De nombreux champs sont ambigus ou redondants. Par contre l’encodage est bien abouti. Il est orienté gestion de logs. Le format est assez riche mais souvent très ambigus avec un schéma moyennement structuré. Il y avait la possibilité de créer des profils additionnels.

Pour XDAS/CADF une documentation est en ligne avec une version propriétaire NetIQ/Novell. La documentation est toutefois succincte. Le transport et l’encodage sont libres. Ce format est orienté gestion des événements/audit et Cloud.
En conclusion, pour lui le format IDMEF est le plus complet avec 259 champs normalise contre 84 pour CEF à 35 pour CEE, XDAS. De même au niveau de la richesse relative le meilleur des formats ne couvre que 31% de celle d’IDMEF.

Il est nécessaire d’avoir un format de communication universel

En conclusion de cette journée, pour Gilles Lehmann il est nécessaire d’avoir un format de communication universel comme on l’a fait pour la messagerie avec le SMTP. Il y a un aspect économique qui plaide en faveur d’un format unique. Pour lui, IDMEF grâce aux passerelles faciles conçues, peut devenir un format complémentaire aux formats propriétaires. Il en est de même avec IODEF.
Au final, aujourd’hui tout est une question de volonté.

Pour en savoir plus www.secef.net