Date de publication du RFC : Avril 2014
Auteur(s) du RFC : T. Takahashi (NICT), K. Landfield (McAfee), T. Millar (USCERT), Y. Kadobayashi (NAIST)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF mile
Première rédaction de cet article le 22 avril 2014
Le format IODEF permet l'échange de données structurées (et donc analysables par un programme) sur des incidents de sécurité. Ce nouvel RFC étend le format IODEF avec des informations utiles pour le monde de la « cybersécurité ».
Le RFC commence par prétendre que le nombre d'incidents de cybersécurité augmente tous les jours (alors qu'on n'en sait rien). Ce qui est sûr, c'est que la quantité d'informations échangées sur ces incidents augmente et qu'il existe une quantité impressionnante de formats structurés et de référentiels (quelques exemples au hasard, pris dans ceux cités par le RFC : CVSS, OVAL, SCAP, XCCDF...). Notre RFC en ajoute donc un, sous forme, non pas d'un format nouveau mais d'une extension de IODEF, un format fondé sur XML et qui avait été normalisé dans le RFC 5070 (remplacé depuis par le RFC 7970). Signe des temps : un des auteurs du RFC travaille au ministère de l'intérieur états-unien...
La section 3 du RFC rappelle ses buts, et l'importance de ne pas
repartir de zéro, d'agréger les formats cités plus haut au lieu
d'essayer de les remplacer. Les extensions IODEF elles-mêmes
figurent en section 4. En gros, il s'agit de permettre d'incorporer
dans IODEF des descriptions issues de normes extérieures déjà
existantes. Un nouveau registre IANA
stocke les spécifications ainsi incorporées. Pour l'instant, le
registre n'en compte qu'une seule,
urn:ietf:params:xml:ns:mile:mmdef:1.2
qui est
fondée sur la
norme IEEE MMDEF, qui permet de décrire des
logiciels malveillants.
Chacune de ces entrées dans le nouveau registre dérivera d'une
classe (notre RFC utilise le vocabulaire de la
programmation objet, et le langage
UML pour la modélisation) parmi les huit : AttackPattern
,
Platform
, Vulnerability
,
Scoring
, Weakness
,
EventReport
, Verification
et
Remediation
. Ainsi, MMDEF, la première entrée,
hérite de AttackPattern
. Chacune de ces classes
est décrite en détail en section 4.5
Et voici, tiré du RFC, un exemple de rapport IODEF incorporant des
éléments MMDEF, décrivant un
malware de nom
eicar_com.zip
(un fichier de test connu) :
<?xml version="1.0" encoding="UTF-8"?> <IODEF-Document version="1.00" lang="en" xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef-sci="urn:ietf:params:xml:ns:iodef-sci-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Incident purpose="reporting"> <IncidentID name="iodef-sci.example.com">189493</IncidentID> <ReportTime>2013-06-18T23:19:24+00:00</ReportTime> <Description>a candidate security incident</Description> <Assessment> <Impact completion="failed" type="admin" /> </Assessment> <Method> <Description>A candidate attack event</Description> <AdditionalData dtype="xml"> <iodef-sci:AttackPattern SpecID="http://xml/metadataSharing.xsd"> <iodef-sci:RawData dtype="xml"> <malwareMetaData xmlns="http://xml/metadataSharing.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xml/metadataSharing.xsd file:metadataSharing.xsd" version="1.200000" id="10000"> <company>N/A</company> <author>MMDEF Generation Script</author> <comment>Test MMDEF v1.2 file generated using genMMDEF </comment> <timestamp>2013-03-23T15:12:50.726000</timestamp> <objects> <file id="6ce6f415d8475545be5ba114f208b0ff"> <md5>6ce6f415d8475545be5ba114f208b0ff</md5> <sha1>da39a3ee5e6b4b0d3255bfef95601890afd80709</sha1> <sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca4 95991b7852b855</sha256> <sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83 f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b9 31bd47417a81a538327af927da3e</sha512> <size>184</size> <filename>eicar_com.zip</filename> <MIMEType>application/zip</MIMEType> </file> <file id="44d88612fea8a8f36de82e1278abb02f"> <md5>44d88612fea8a8f36de82e1278abb02f</md5> <sha1>3395856ce81f2b7382dee72602f798b642f14140</sha1> <sha256>275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4 538aabf651fd0f</sha256> <sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e565e 68847223b8e6b85cb48f3afad842726d99239c9e36505c64b0 dc9a061d9e507d833277ada336ab</sha512> <size>68</size> <crc32>1750191932</crc32> <filename>eicar.com</filename> <filenameWithinInstaller>eicar.com </filenameWithinInstaller> </file> </objects> <relationships> <relationship type="createdBy" id="1"> <source> <ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]</ref> </source> <target> <ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]</ref> </target> <timestamp>2013-03-23T15:12:50.744000</timestamp> </relationship> </relationships> </malwareMetaData> </iodef-sci:RawData> </iodef-sci:AttackPattern> </AdditionalData> </Method> <Contact role="creator" type="organization"> <ContactName>iodef-sci.example.com</ContactName> <RegistryHandle registry="arin">iodef-sci.example-com </RegistryHandle> <Email>contact@csirt.example.com</Email> </Contact> <EventData> <Flow> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.200</Address> <Counter type="event">57</Counter> </Node> </System> <System category="target"> <Node> <Address category="ipv4-net">192.0.2.16/28</Address> </Node> <Service ip_protocol="4"> <Port>80</Port> </Service> </System> </Flow> <Expectation action="block-host" /> <Expectation action="other" /> </EventData> </Incident> </IODEF-Document>
On notera que bien des discussions préalables au RFC portaient sur cette plaie de l'appropriation intellectuelle, plusieurs des schémas référencés ayant des noms qui sont des marques déposées.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)