From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- ...bject_Description_Exchange_Format_Version_2.txt | 172 +++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 RFC_7970_The_Incident_Object_Description_Exchange_Format_Version_2.txt (limited to 'RFC_7970_The_Incident_Object_Description_Exchange_Format_Version_2.txt') diff --git a/RFC_7970_The_Incident_Object_Description_Exchange_Format_Version_2.txt b/RFC_7970_The_Incident_Object_Description_Exchange_Format_Version_2.txt new file mode 100644 index 0000000..e8f9aa9 --- /dev/null +++ b/RFC_7970_The_Incident_Object_Description_Exchange_Format_Version_2.txt @@ -0,0 +1,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) -- cgit v1.2.1