1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
Titre: RFC 7970: The Incident Object Description Exchange Format Version 2
Auteur:
Date: Thu 01 Dec 2016 01:00:00 +0100
Lien: https://www.bortzmeyer.org/7970.html
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 RFC 5070.
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[1], 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[2]), 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 RFC 5070, l'exemple était une simple reconnaissance avec
nmap...). Cet exemple a l'avantage d'illustrer la classe IndicatorData, une
nouveauté de la version 2 :
<>?xml version="1.0" encoding="UTF-8"?>
<>!-- A list of C2 domains associated with a campaign -->
<>IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/
iodef-2.0.xsd">
<>Incident purpose="watch" restriction="green">
<>IncidentID name="csirt.example.com">897923<>/IncidentID>
<>RelatedActivity>
<>ThreatActor>
<>ThreatActorID>
TA-12-AGGRESSIVE-BUTTERFLY
<>/ThreatActorID>
<>Description>Aggressive Butterfly<>/Description>
<>/ThreatActor>
<>Campaign>
<>CampaignID>C-2015-59405<>/CampaignID>
<>Description>Orange Giraffe<>/Description>
<>/Campaign>
<>/RelatedActivity>
<>GenerationTime>2015-10-02T11:18:00-05:00<>/GenerationTime>
<>Description>Summarizes the Indicators of Compromise
for the Orange Giraffe campaign of the Aggressive
Butterfly crime gang.
<>/Description>
<>Assessment>
<>BusinessImpact type="breach-proprietary"/>
<>/Assessment>
<>Contact type="organization" role="creator">
<>ContactName>CSIRT for example.com<>/ContactName>
<>Email>
<>EmailTo>contact@csirt.example.com<>/EmailTo>
<>/Email>
<>/Contact>
<>IndicatorData>
<>Indicator>
<>IndicatorID name="csirt.example.com" version="1">
G90823490
<>/IndicatorID>
<>Description>C2 domains<>/Description>
<>StartTime>2014-12-02T11:18:00-05:00<>/StartTime>
<>Observable>
<>BulkObservable type="fqdn">
<>BulkObservableList>
kj290023j09r34.example.com
09ijk23jfj0k8.example.net
klknjwfjiowjefr923.example.org
oimireik79msd.example.org
<>/BulkObservableList>
<>/BulkObservable>
<>/Observable>
<>/Indicator>
<>/IndicatorData>
<>/Incident>
<>/IODEF-Document>
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 RFC 5070) 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[3]ou bien par un routeur[4]
) 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[5], et qui
référence une liste des programmes IODEF[6] (j'ai aussi trouvé celle-ci[7]).
Parmi d'autres, on peut noter la bibliothèque de Prelude[8] (et qui a une
version pour l'IODEF v2 de notre RFC[9]), un module[10] Perl, un autre[11] en
PHP, et un troisième[12] en Python. On trouve aussi des moyens de connecter
IODEF à des logiciels existants par exemple au logiciel de suivi de tâche
Mantis, avec ce connecteur[13].
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[14]).
Notez en France l'existence du projet SECEF[15] (SECurity Exchange Format) qui
a pour objectif de promouvoir et de faciliter l’usage des deux formats de
fichier IDMEF (RFC 4765) et IODEF. Vous pouvez consulter leur Wiki[16], et leur
tutoriel IODEF[17]. Il y a aussi un article de synthèse sur SECEF[18], et un
compte-rendu d'une de leurs réunions[19] (mais vite fait et avec des erreurs).
Liens:
[1]: http://www.bortzmeyer.org/dnsdb.html (lien)
[2]: https://www.prelude-siem.org/ (lien)
[3]: http://www.nextinpact.com/news/101871-dyn-on-fait-point-sur-attaque-ddos-qui-a-impactee-nombreux-sites.htm (lien)
[4]: http://arstechnica.com/security/2016/11/notorious-iot-botnets-weaponize-new-flaw-found-in-millions-of-home-routers/ (lien)
[5]: https://datatracker.ietf.org/doc/draft-ietf-mile-implementreport/ (lien)
[6]: http://siis.realmv6.org/implementations/ (lien)
[7]: http://www.ecsirt.net/service/products.html (lien)
[8]: https://github.com/Prelude-SIEM/libiodef (lien)
[9]: https://github.com/IDMEF-IODEF/libiodefv2 (lien)
[10]: http://search.cpan.org/~saxjazman/XML-IODEF-0.11/lib/XML/IODEF.pm (lien)
[11]: https://github.com/marknl/iodef (lien)
[12]: http://www.decalage.info/python/iodeflib (lien)
[13]: https://github.com/siemens/django-mantis-iodef-importer (lien)
[14]: http://static.sstic.org/rumps2016/SSTIC_2016-06-02_P12_RUMPS_14.mp4 (lien)
[15]: http://www.secef.net/ (lien)
[16]: http://redmine.secef.net/projects/secef/wiki (lien)
[17]: http://redmine.secef.net/projects/secef/wiki/How_to_use_IODEF (lien)
[18]: http://www.silicon.fr/oiv-france-pousse-normalisation-incidents-securite-160969.html (lien)
[19]: http://www.globalsecuritymag.fr/SECEF-Day-2016-l-IDMEF-IODEF,20160921,65464.html (lien)
|
