Pour rendre plus facilement analysables les innombrables rapports
d'incidents de sécurité qui circulent sur Internet tous les jours, ce
RFC spécifie un
format standard XML, nommé IODEF, pour
décrire ces incidents. Ici, il s'agit de la version
2 de ce format IODEF, la version 1 était dans le .
Tous les jours, des organisations comme les
CERT et
CSIRT, mais aussi les OIV, envoient et reçoivent des rapports
détaillés concernant une attaque sur un réseau informatique ou un
serveur. Ces rapports sont longs et détaillés mais, la plupart du
temps, ce n'est pas une attaque isolée qui est intéressante, c'est
l'image qui apparait lorsqu'on synthétise tous les rapports, et qu'on
voit alors les tendances, par exemple l'arrivée d'un nouveau
ver ou bien une attaque concertée contre un
pays donné. D'où l'importance de pouvoir analyser automatiquement ces
rapports, ce qui impose un modèle de données et un format standard, ce
que fournit ce RFC.
Le modèle de données est proche des modèles
objet, par
exemple dans la descriptions des classes d'objets
manipulés (comme la classe Incident en section 3.2, avec la
cardinalité des attributs). Ces classes sont
composés avec des données élémentaires (booléens, entiers, dates)
décrites dans la section 2. Par exemple, parmi les attributs de la
classe Incident, on trouve l'heure de début et de
fin de l'incident, l'heure de détection, etc. Le schéma XML complet, écrit en W3C Schema,
figure dans la section 8.
On trouve énormément de choses dans ce schéma (le RFC fait plus de
160 pages), pour traiter tous les cas prévus. Par exemple, on peut
exprimer une liste de ports comprenant à la fois des ports
individuels et des intervalles :
22,53,80,1024-2047. De nombreuses classes
existent pour utiliser ces informations élémentaires. Ainsi, la classe
Discovery, une nouveauté de la version 2, permet
d'indiquer comment l'incident a été découvert (avec un attribut
source qui a vingt valeurs possibles, comme
av - antivirus,
os-log - journal,
passive-dns - un système comme DNSdb, etc). Et
BusinessImpact permet de décrire les conséquences
de l'incident sur l'activité (breach-privacy,
loss-of-service,
theft-financial, etc). Ça peut même se quantifier
financièrement avec la classe MonetaryImpact. Si
on met les incidents de sécurité dans une base de données (ça
s'appelle un SIEM, comme Prelude), on peut donc imaginer de regarder
d'abord les incidents qui ont coûté le plus cher...
Voici un exemple d'un rapport d'incident, tiré du RFC (section 7), et qui
décrit et qui décrit les systèmes de C&C
(quatre serveurs)
d'une campagne donnée (dans le ,
l'exemple était une simple reconnaissance avec
nmap...). Cet exemple a l'avantage d'illustrer
la classe IndicatorData, une nouveauté de la
version 2 :
897923
TA-12-AGGRESSIVE-BUTTERFLY
Aggressive ButterflyC-2015-59405Orange Giraffe2015-10-02T11:18:00-05:00Summarizes the Indicators of Compromise
for the Orange Giraffe campaign of the Aggressive
Butterfly crime gang.
CSIRT for example.comcontact@csirt.example.com
G90823490
C2 domains2014-12-02T11:18:00-05:00
kj290023j09r34.example.com
09ijk23jfj0k8.example.net
klknjwfjiowjefr923.example.org
oimireik79msd.example.org
]]>
Le RFC note sagement que le partage d'informations n'est pas
uniquement une question technique, mais qu'elle dépend aussi des
procédures bureaucratiques de chaque organisation, des contraintes légales, de la
confiance (ou de l'absence de confiance, souvent justifiée) et enfin de la simple bonne
ou mauvaise volonté. (Mon opinion personnelle est que, en France, le
partage d'informations précises sur les incidents de sécurité est très insuffisant.)
Les changements depuis la version 1 (celle du ) sont listés dans la section 1.4. Beaucoup de détails,
beaucoup d'ajouts,
parmi lesquels je note :
Meilleure internationalisation (voir à
ce sujet la section 6 du RFC), comme le fait que la classe
Contact permette désormais d'indiquer une
adresse postale en un jeu de caractères quelconque,Nouvelles classes (comme IndicatorData ou
Discovery cités
plus haut, ou comme DomainData, pour des
informations sur un nom de domaine), et nouveaux attributs dans les classes
existantes (par exemple, Incident y gagne
observable-id, un identificateur qui peut être
utilisé dans des références croisées).
Si l'ajout de nouvelles classes ne rendent pas les anciennes
descriptions IODEF incorrectes, en revanche, certains changements cassent la compatibilité et un fichier
IODEF version 1 parfait ne sera pas forcément légal pour la version
2 (cf. section 4.4). Par exemple, la sous-classe
NodeRole (qui permet de décrire si on est attaqué
par
une caméra de vidéosurveillance
ou bien par un routeur) a changé
de classe parente.
Et les mises en œuvre d'IODEF ? Un résumé de l'état de ces mises
en œuvre figure dans
l'Internet-Draftdraft-ietf-mile-implementreport,
et qui référence une liste des programmes
IODEF (j'ai aussi trouvé celle-ci). Parmi d'autres, on peut noter la bibliothèque de
Prelude (et qui a une version pour l'IODEF v2 de
notre RFC), un
module Perl, un autre en
PHP, et un troisième
en Python. On trouve aussi des
moyens de connecter IODEF à des logiciels existants par exemple au
logiciel de suivi de tâcheMantis, avec ce connecteur.
Pour des articles ou présentations sur IODEF, vous pouvez voir la
Rump (session rapide) de Thomas Andrejak au
SSTIC 2016 (vidéo en
ligne).
Notez en France l'existence du projet SECEF (SECurity
Exchange Format) qui a pour objectif de promouvoir
et de faciliter l’usage des deux formats de fichier
IDMEF () et
IODEF. Vous pouvez consulter leur
Wiki, et leur
tutoriel IODEF. Il y a aussi un article
de synthèse sur SECEF, et un compte-rendu
d'une de leurs réunions (mais vite fait et avec des
erreurs). Enfin, le donne quelques
conseils sur la mise en œuvre d'IODEF.