Initiale releaseHEADmaster

1 files changed, 172 insertions, 0 deletions

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)