Etude comparative des formats d’alertes

Conference Paper (PDF Available) · November 2015with 338 Reads
Conference: C&ESAR (Computer & Electronics Security Applications Rendez-vous) 2015
Cite this publication
Figures - uploaded by Guillaume Hiet
Author content
All content in this area was uploaded by Guillaume Hiet
Content may be subject to copyright.
Etude comparative des formats d’alertes
Guillaume Hiet1, Hervé Debar2, Selim Menouar3, and Vérène Houdebine3
1CentraleSupélec, Cesson-Sévigné, France,
guillaume.hiet@centralesupelec.fr
2Télécom SudParis, Evry, France,
herve.debar@telecom-sudparis.eu
3CS, Le Plessis Robinson, France,
prenom.nom@c-s.fr
Résumé Une des approches contribuant à la résilience des systèmes
informatiques consiste à surveiller en continu leur fonctionnement afin de
détecter les comportements indésirables (attaques, intrusions). L’objectif
final est de ramener le système dans un état sain, éventuellement dans
un mode dégradé, en exécutant des contre-mesures adéquates. Il est pour
cela nécessaire de déployer différents composants qui doivent échanger
de l’information sous forme d’alertes : sondes de détection, manager,
base de données, interface de visualisation, etc. Dans ce contexte, la
définition d’un format standard et ouvert pour les échanges d’alertes
apparaît crucial. Ce format doit offrir une structuration et une richesse
sémantique qui facilitent le classement et la contextualisation des alertes.
Ces aspects sont essentiels pour optimiser le traitement automatiques des
alertes (par exemple, la corrélation). L’utilisation d’un format standard
facilite non seulement l’inter-opérabilité mais il permet également aux
exploitants de capitaliser leurs efforts. Nous présentons dans cet article
les résultats d’une étude comparative des formats d’alerte existants et
nous proposons des pistes d’amélioration issues de ce retour d’expérience.
Cette étude a été réalisée dans le cadre du projet RAPID SECEF qui
s’intéresse notamment à proposer des améliorations au format IDMEF [1]
pour l’adapter au contexte actuel et faciliter son adoption.
Keywords: supervision de sécurité, format d’alertes, IDMEF
1 Introduction
La supervision de sécurité est une approche de cyber-sécurité réactive qui
participe à la Lutte Informatique Défensive. Elle consiste en premier lieu à dé-
tecter les attaques ou intrusions et à émettre le cas échéant des alertes (ou
événements de sécurité). Une deuxième étape consiste à gérer automatiquement
ces différentes alertes (processus de collecte, de stockage et de corrélation). Ces
informations sont ensuite présentées aux personnes en charge de la sécurité du SI
sous différentes formes (évolutions au fil de l’eau, rapports d’incident, tableaux
de bord, résultats de recherches, etc.). L’objectif final est d’apporter une infor-
mation la plus pertinente possible pour que les opérateurs de sécurité puissent
mettre en œuvre des contre-mesures. Cette approche contribue à la résilience des
Figure 1. Architecture de supervision de sécurité
systèmes informatiques, comme le souligne la grille d’analyse de la résilience [2]
proposée par le Professeur Erik Hollnagel. Celle-ci s’appuie sur quatre caracté-
ristiques d’un système pour évaluer sa capacité de résilience. L’une d’entre-elles
réside justement dans la capacité du système à surveiller les évolutions de son
comportement et de son environnement.
Comme l’illustre la figure 1, la mise en œuvre d’une architecture de super-
vision de sécurité nécessite de déployer différents composants hétérogènes qui
doivent communiquer entre eux au sein d’un Security Operationnal Center. Ty-
piquement, les SOC sont constitués de différentes sondes qui doivent remonter
l’information concernant les événements qu’elles ont détectés à des managers
(Security Information and Event Manager). En pratique, les composants du
SOC proviennent de différents éditeurs.
Dans ce contexte, la définition d’un format standard d’échange des alertes
apparaît crucial. Plusieurs formats, plus ou moins spécifiques au domaine, ont été
proposés par le passé mais force est de constater qu’aujourd’hui, aucun d’eux
n’a été adopté massivement par les différents éditeurs. Généralement, chaque
éditeur de sonde utilise un format propriétaire pour décrire les alertes émises
par ses sondes. Il est donc nécessaire que le manager connaisse ces différents
formats qu’il doit analyser et traduire dans un format interne, ce dernier étant
lui aussi généralement propriétaire. Cette étape de normalisation est primordiale.
En effet, il est nécessaire que les alertes soient exprimées dans un format commun
afin de pouvoir leur appliquer facilement par la suite des traitements automatisés
(corrélation, requête, etc.).
Cette situation (normalisation par le manager), n’est pas optimale. En effet,
l’intégration repose alors en grande partie sur les capacités de l’éditeur du mana-
ger à normaliser de manière pertinente un grand nombre de formats d’alertes 4.
Pour les formats non reconnus nativement, l’utilisateur doit, si le produit retenu
le lui permet, développer lui-même le traducteur, ce qui peut s’avérer complexe
et difficile à maintenir dans le temps. Les éditeurs de managers et les utilisateurs
finaux sont alors fortement dépendants des éditeurs de sondes, notamment en
cas de modification du format utilisé par ces derniers.
A l’inverse, l’utilisation d’un format standard commun aux différents ac-
teurs du domaine permettrait de s’affranchir de cette dépendance et faciliterait
l’inter-opérabilité. En outre, l’utilisation par les managers d’un format standard,
au lieu des multiples formats propriétaires, permettrait aux utilisateurs finaux
(opérateur de sécurité, administrateur, etc.) de capitaliser leurs efforts lors du
développement des traitements automatisés, tels que la corrélation. Actuelle-
ment, le développement de ces traitements nécessite d’acquérir une compétence
spécifique à un produit, notamment en termes de format. Enfin, l’utilisation d’un
format standard permet de développer des traitements automatiques qui soient
génériques et ne dépendent pas du format propre à chaque sonde.
L’objectif du projet SECEF 5est de promouvoir IDMEF, l’un des rares for-
mats standards dédiés au domaine. Pour cela, le projet s’attelle à différentes
tâches dont :
l’étude comparative des différents formats plus ou moins spécifiques au
domaine qui ont été proposés jusqu’à maintenant afin notamment de dé-
gager les bonnes pratiques ;
— la proposition d’évolutions du format IDMEF, prenant notamment en
compte les résultats issus de l’étape précédente, afin d’adapter le standard
existant au contexte actuel;
la rédaction de documentation et de tutoriaux permettant de faciliter le
travail des développeurs désireux d’adopter IDMEF ;
— le développement et la mise à disposition de bibliothèques permettant
d’échanger et de manipuler des alertes au format IDMEF.
Nous proposons dans cet article de présenter les travaux relatifs aux deux pre-
mières tâches de ce projet : l’étude comparative des formats d’alertes et les pistes
d’amélioration envisagées.
Dans un premier temps, nous rappelons en section 2 le périmètre de l’étude
et la démarche retenue. Puis nous présentons la comparaison des formats en
section 3 ainsi que les pistes d’amélioration en section 4. La section 5 conclut
cet article.
4. Il s’agit d’ailleurs d’un argument commercial avancé par bon nombre d’éditeurs
5. SECEF/COSCOM est un projet financé par la DGA via le dispositif RAPID :
http://www.secef.net
Figure 2. Format de messages
2 Périmètre de l’étude et démarche
Nous présentons par la suite les concepts relatifs à la définition d’un format
de message. Nous présentons également la démarche que nous avons suivie.
2.1 Format d’alerte
Les informations remontées par les sondes vers les managers le sont sous forme
de messages. Il convient donc de définir le format de ces messages. L’étude des
différents formats existants fait apparaître qu’il existe en fait différents niveaux
de définition pour un format donné, ce qui est illustré par la figure 2.
Classiquement, les message sont décrits par un ensemble d’attributs (ou de
champs) auxquels sont associées des valeurs. Le format des messages à propre-
ment parler comprend :
le schéma, c’est-à-dire la structure des messages et la définition des dif-
férents attributs standards, ainsi que la sémantique de ces attributs;
— le typage, c’est-à-dire le format des valeurs que peuvent prendre ces
différents attributs.
Selon les formats, le typage peut-être plus ou moins précis (par exemple
« chaîne de caractères » vs. « date au format ISO 8601 »). Le typage décrit
l’ensemble des valeurs possibles pour un attribut donné. Pour certains attributs,
ce typage peut prendre la forme d’une énumération ou d’un dictionnaire.
L’usage de dictionnaire apparaît comme une nécessité afin de pouvoir compa-
rer et traiter automatiquement (notamment durant la phase de corrélation) les
valeurs de certains champs issus d’alertes produites par des sondes développées
par différents éditeurs. Toutefois, la définition de ces dictionnaires, c’est-à-dire
d’une énumération de valeurs non ambiguës qui couvre les besoins de chacun
tout en permettant de distinguer les différents cas, s’avère en pratique souvent
difficile. Il s’agit donc d’un point important dans la définition et la comparaison
des formats.
Le format des messages est une spécification abstraite. L’encodage (ou for-
mat de sérialisation) détermine la manière dont les messages, c’est-à-dire les
champs et les valeurs associées, vont être codés. Il est possible d’utiliser un
format d’encodage ad-hoc mais il paraît préférable d’utiliser des formats gé-
nériques pré-existants (par exemple JSON ou XML). Cela permet notamment,
en termes d’implémentation, de faciliter les développements (ré-utilisation de
bibliothèques existantes) ainsi que de favoriser la robustesse (ré-utilisation de
parseurs robustes) et l’interopérabilité.
Classiquement, on peut distinguer les encodages textuels reposant sur AS-
CII ou UTF (par exemple, JSON et XML) des encodages binaires (par exemple
BER, CER, BSON, binary XML, etc.). Les premiers ont l’avantage d’être direc-
tement interprétables par un humain (ce qui peut être utile notamment lorsque
les messages sont stockés directement dans des fichiers). Ils sont dans notre cas
particulièrement adaptés car l’information à transporter est principalement de
nature textuelle. Le transport d’information binaire (par exemple, capture ré-
seau au format PCAP,) nécessite un encodage particulier, par exemple Base64
ou Uuencoding. Les encodages binaires permettent un encodage plus compact
et donc d’optimiser les performances.
Le protocole de transport permet d’échanger les messages en utilisant une
pile protocolaire standard (TCP/IP, étant donné le cas d’usage). Comme pour
l’encodage, l’intérêt est d’utiliser des protocoles génériques existants (HTTP,
SYSLOG, AMQP, etc.). Le protocole de transport et l’encodage sont en géné-
ral plus ou moins couplés. Par exemple, l’utilisation de HTTP comme protocole
de transport tend à favoriser l’utilisation d’encodage textuel (JSON, XML).
Certains protocoles, par exemple AMQP, imposent un encodage particulier. A
l’inverse, il est parfois envisageable d’utiliser différents encodages pour un même
protocole (JSON ou XML sur HTTP) ou un même encodage sur différents pro-
tocoles (par exemple JSON sur HTTP ou SYSLOG).
Classiquement, le transport et l’encodage assurent un certain nombre de fonc-
tionnalités essentielles pour le bon acheminement des messages. Ils doivent no-
tamment fournir des fonctions de sécurité (authentification des émetteurs et
des récepteurs, signature et chiffrement des messages), de haute-disponibilité
(ré-émission des messages, mécanismes de redondance) et d’optimisation de la
bande-passante (compression, gestion de la congestion, etc.). Ces fonctionnali-
tés sont particulièrement importantes dans le contexte de l’échange d’alertes de
sécurité. Toutefois, elles sont a priori indépendantes du format des messages à
proprement parler car elles sont liées au type d’encodage et de transport utilisés.
La présente étude se focalise essentiellement sur le format de messages (c’est-
à-dire le schéma et le typage). En effet, les besoins finaux (standardisation en vue
de faciliter le traitement automatique des données) imposent prioritairement que
le schéma et le typage soient standards. Ces derniers devraient être en grande
partie agnostiques de l’encodage et du protocole de transport utilisés, le choix
de ceux-ci relevant de l’implémentation.
This research hasn't been cited in any other publications.
  • Standards and tools for exchange and processing of actionable information
    • P Pawliński
    • P Jaroszewski
    • J Urbanowicz
    • P Jacewicz
    • P Zielony
    • P Kijewski
    • K Gorzelak
    Pawliński, P., Jaroszewski, P., Urbanowicz, J., Jacewicz, P., Zielony, P., Kijewski, P., Gorzelak, K. : Standards and tools for exchange and processing of actionable information. Tech. Rep. TP-04-14-999-EN-N, ENISA (November 2014), https://www.enisa.europa.eu/activities/cert/support/actionableinformation/standards-and-tools-for-exchange-and-processing-ofactionable-information
  • The Intrusion Detection Message Exchange Format (IDMEF)
    • H Debar
    • D Curry
    • B Feinstein
    Debar, H., Curry, D., Feinstein, B. : The Intrusion Detection Message Exchange Format (IDMEF). RFC 4765 (Experimental) (March 2007), http://www.ietf.org/ rfc/rfc4765.txt
  • Article
    Resilience engineering has since 2004 attracted widespread interest from industry as well as academia. Practitioners from various fields, such as aviation and air traffic management, patient safety, off-shore exploration and production, have quickly realised the potential of resilience engineering and have became early adopters. The continued development of resilience engineering has focused on four abilities that are essential for resilience. These are the ability a) to respond to what happens, b) to monitor critical developments, c) to anticipate future threats and opportunities, and d) to learn from past experience - successes as well as failures. Working with the four abilities provides a structured way of analysing problems and issues, as well as of proposing practical solutions (concepts, tools, and methods). This book is divided into four main sections which describe issues relating to each of the four abilities. The chapters in each section emphasise practical ways of engineering resilience and feature case studies and real applications. The text is written to be easily accessible for readers who are more interested in solutions than in research, but will also be of interest to the latter group.