Cybersécurité, les standards au service de l’efficacité

En effet, le thème des formats d’échange d’informations de sécurité constitue un enjeu essentiel dans le domaine de la cybersécurité. Administration (ANSSI, Direction Générale des Entreprises…), industriels (développeurs, utilisateurs), CERT, etc., ils étaient nombreux à souhaiter s’informer.

C’est donc devant un auditoire conséquent que Gilles LEHAMNN (CS), Hervé DEBAR (Telecom Sud Paris) et Guillaume HIET (Centrale Supélec) ont présenté les tenants et aboutissants d’un projet qui vise, sous l’égide de la DGA, à promouvoir et optimiser les formats IDMEF et IODEF.

Pourquoi des formats standards ?

Alors que d’une part les cybercriminels s’organisent et se coordonnent, et que d’autre part les attaques hier unitaires deviennent nationales, force est de constater que les acteurs concernés peinent à s’entendre.

La coordination des forces de cyberdéfense est pourtant un facteur potentiel d’efficacité (donc de réduction de coût). En outre, comme chacun sait, la détection d’intrusion est l’un des piliers de la cyberdéfense. L’objectif de la détection d’intrusion est en effet d’alerter l’exploitant le plus tôt possible avant l’attaque.

Par ailleurs, les contraintes réglementaires incitant à agir en ce sens sont multiples. La Loi de Programmation Militaire (LPM 2014-2019) définit plus de deux cents Opérateurs d’Importance Vitale sur le territoire français. La directive européenne Network and Information Security (NIS) s’applique quant à elle, à l’échelle continentale.

Les obligations induites concernent chaque fois la détection et la gestion des risques, la notification des incidents, et les mesures de sécurité et d’audit. Au sein d’une même entité ou entre plusieurs entités, il faut transmettre les informations en cas d’incident. Mais certains éléments restent flous : le contenu de cette transmission et le moyen de transmission.  C’est l’objet du projet SECEF.

Quelques définitions

Précisons quelques définitions pour bien cadrer la problématique. Une Alerte est  un événement considéré comme notable ou suspicieux. Par exemple une tentative d’authentification échouée sur un serveur, même si cela dépend fortement de la stratégie de surveillance mise en place.

Un Incident est une alerte ou un ensemble d’alertes pouvant caractériser une attaque. Par exemple, tel serveur a subi un scan de port, suivi de plusieurs tentatives de connexions échouées ainsi qu’une modification d’un fichier « sensible ».

Un SIM (Security Information Management) permet l’indexation et l’archivage de l’ensemble des données brutes (Log Management).

Un SEM (Security Event Management) opère en temps réel pour gérer les événements de sécurité (alertes) via des activités de Sélection, Normalisation (Contextualisation), Corrélation, Agrégation, Indexation.

Un SIEM (Security Information & Event Management) est  la vision et la gestion unifiées de la sécurité.

(((IMG7921)))

Ces définitions nous aident à répondre à une première question : pourquoi faut-il utiliser un format de « détection d’intrusion» standardisé ?

Chaque sonde produit des « alertes » qu’il faut ensuite transporter et centraliser, puis stocker, archiver et indexer, avant de les comparer et corréler entre elles (au sein d’un même outil mais aussi entre outils) pour enfin les analyser (analyse de tendance et analyse comportementale). S’en suit éventuellement une transmission pour nouvelle consolidation à un niveau plus central par exemple. Pour tout cela il est indispensable d’utiliser un format commun.

De la même façon, il faut un format de description d’incident car chaque centre de sécurité identifie des « incidents » importants qui doivent être centralisés, stockés/archivés/indexés dans un format adéquat, puis comparés et analysés avant une éventuelle transmission.

Les premiers résultats du projet

Les formats IDMEF (RFC 4765) et IODEF (RFC 5070) sont tous les deux définis à l’IETF. Les deux formats utilisent des objets communs, sont complémentaires, et couvrent l’ensemble de la problématique détection et incident.

Les travaux du projet SECEF consistent en plusieurs points :
•    Analyse comparative des formats d’alertes et Etude des formats « incidents »
•    Promotion / Communication (avec rédaction de tutoriaux)
•    Nouvelles sondes IDMEF, Implémentation IODEF
•    Amélioration format IDMEF
•    Rapprochement ISI/ETSI
•    Mise à disposition bibliothèques IDMEF / IODEF

La conférence a tout d’abord présenté l’historique et le contexte de la problématique avant d’offrir un panorama des formats d’incidents.

Il existe une forte demande de mécanismes d’échange d’information. Par les régulateurs notamment, mais aussi pour le passage à l’échelle ainsi que pour l’amélioration de la détection et de la remédiation. Ces mécanismes fonctionnent aujourd’hui autour de communautés de confiance (CERTs, Points focaux).

Utiliser un format standard permettrait de :
•    Limiter le travail de normalisation du manager
•    Faciliter l’interopérabilité des outils
•    Faciliter la spécification de règles de corrélation « génériques »

IDMEF du côté technique

Le consortium SECEF a étudié les formats propriétaires, CEF (HP ArcSight), LEEF (IBM QRADAR), SDEE (CISCO), et les standards IDMEF (IETF), CEE (MITRE + CEE board), CIM (DMTF), XDAS/CADF (The Open Group, Novell, DMTF).

A propos d’IDMEF, il a été indiqué que ce format est décrit par la RFC 4765 (requirements présents dans la RFC 4766).

C’est un format bien documenté (138 pages de RFC) mais qui impose beaucoup de lecture pour créer une alerte simple. Le style textuel de la RFC n’aide pas à « visualiser » le schéma, il manque une définition claire de la stratégie de « peuplement » pour différents use-cases (SECEF a comblé cela par la création de tutoriels IDMEF)…

IDMEF est un format a priori indépendant du transport et de l’encodage. La RFC décrit des exemples s’appuyant sur XML et fournit une DTD. Notons également que le groupe de travail originel devait définir un transport de référence (IDXP) pour ce format dédié aux alertes et orienté détection d’intrusion.

Format très riche, IDMEF propose description des sondes (analyzer), sources, destinations, marqueurs temporels, processus, utilisateurs, fichiers, services, etc. Le schéma est très structuré, avec  33 classes et 108 attributs (beaucoup d’attributs sont des classes, beaucoup sont des listes). Parmi ses autres caractéristiques, on recense la combinaison multiplicité + champs « type », l’identifiant unique des attributs, l’utilisation de dictionnaires (non systématique) ou encore la présence du champ « additionnal data ». C’est un format extensible.

En conclusion

Pour conclure, la conférence a pris l’exemple du cas de la messagerie électronique. A l’origine, plusieurs éditeurs (Microsoft, Novell, Lotus, etc.) proposaient plusieurs formats sans connexion ni collaboration possible. Heureusement, SMTP, format pivot standard, a permis la coexistence de plusieurs éditeurs et la construction d’un monde connecté.

L’essentiel est donc là. Il est impératif que les développeurs et les utilisateurs agissent de concert avec les Autorités afin de s’entendre sur des formats communs et ainsi pouvoir améliorer la sécurité de tous grâce à des processus d’échanges interopérables.

Le consortium livre les clés pour mieux comprendre et apprendre à l’adresse www.secef.net. La présentation et la vidéo y seront prochainement mises en ligne.

Pour approfondir la question technique, le site indépendant secef.net a été créé et permet de réunir la communauté. Si le projet n’est pour l’heure qu’à mi-parcours, c’est également là l’occasion d’expérimenter IDMEF/IODEF grâce aux librairies en téléchargement ou bientôt disponibles.

Enfin, pour continuer stratégiquement, une invitation a été faite à chacun, maître d’ouvrage, responsable sécurité, groupe d’utilisateurs, etc., de mener des discussions communes et de s’accorder sur des solutions mettant en œuvre les formats IDMEF et IODEF.