idnits 2.17.1
draft-ietf-mile-implementreport-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 4, 2015) is 3211 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC5901' is defined on line 612, but no explicit
reference was found in the text
== Unused Reference: 'RFC5941' is defined on line 615, but no explicit
reference was found in the text
== Unused Reference: 'RFC6545' is defined on line 618, but no explicit
reference was found in the text
== Unused Reference: 'RFC6546' is defined on line 621, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 5070
(Obsoleted by RFC 7970)
Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MILE C. Inacio
3 Internet-Draft CMU
4 Intended status: Informational D. Miyamoto
5 Expires: January 5, 2016 UTokyo
6 July 4, 2015
8 MILE Implementation Report
9 draft-ietf-mile-implementreport-04
11 Abstract
13 This document is a collection of implementation reports from vendors,
14 consortiums, and researchers who have implemented one or more of the
15 standards published from the IETF INCident Handling (INCH) and
16 Management Incident Lightweight Exchange (MILE) working groups.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on January 5, 2016.
35 Copyright Notice
37 Copyright (c) 2015 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 2. Consortiums and Information Sharing and Analysis Centers
54 (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3
56 2.2. Advanced Cyber Defence Centre (ACDC) . . . . . . . . . . 3
57 2.3. Research and Education Networkig Information Sharing and
58 Analyssi Center (REN-ISAC) . . . . . . . . . . . . . . . 4
59 3. Open Source Implementations . . . . . . . . . . . . . . . . . 4
60 3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . 4
61 3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . 4
62 3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
63 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 5
64 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5
65 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 6
66 4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 7
67 4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 8
68 5. Vendors with Planned Support . . . . . . . . . . . . . . . . 8
69 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 8
70 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 9
71 6.1. Collaborative Incident Management System . . . . . . . . 9
72 6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 9
73 6.3. US Department of Energy CyberFed . . . . . . . . . . . . 10
74 6.4. TrendMicro Sharing System . . . . . . . . . . . . . . . . 10
75 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 10
76 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 10
77 7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 12
78 7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 12
79 7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 12
80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
83 11. Informative References . . . . . . . . . . . . . . . . . . . 13
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
86 1. Introduction
88 This document is a collection of implementation reports from vendors
89 and researchers who have implemented one or more of the standards
90 published from the INCH and MILE working groups. The standards
91 include:
93 o Incident Object Description Exchange Format (IODEF) v1, RFC5070,
95 o Incident Object Description Exchange Format (IODEF) v2,
96 RFC5070-bis,
98 o Extensions to the IODEF-Document Class for Reporting Phishing,
99 RFC5901
101 o Sharing Transaction Fraud Data, RFC5941
103 o IODEF-extension for Structured Cybersecurity Information, RFCXXXX
105 o Real-time Inter-network Defense (RID), RFC6545
107 o Transport of Real-time Inter-network Defense (RID) Messages over
108 HTTP/TLS, RFC6546.
110 o Incident Object Description Exchange Format (IODEF) Extension for
111 Structured Cybersecurity Information, RFC7203
113 The implementation reports included in this document have been
114 provided by the team or product responsible for the implementations
115 of the mentioned RFCs. Additional submissions are welcome and should
116 be sent to the draft editor. A more complete list of
117 implementations, including open source efforts and vendor products,
118 can also be found at the following location:
120 http://siis.realmv6.org/implementations/
122 2. Consortiums and Information Sharing and Analysis Centers (ISACs)
124 2.1. Anti-Phishing Working Group
126 Anti-Phishing Working Group (APWG) is one of the biggest coalition
127 against cybercrime, especially phishing. In order to collect threat
128 information in a structured format, APWG provides a phishing and
129 cybercrime reporting tool which sends threat information to APWG by
130 tailoring information with IODEF format, based on RFC5070 and
131 RFC5901.
133 2.2. Advanced Cyber Defence Centre (ACDC)
135 The Advanced Cyber Defense Centre (ACDC), is EU-wide activity to
136 fight against botnets. ACDC provides a solutions to mitigate on-
137 going attacks, as well as consolidating information provided by
138 various stakeholders into a pool of knowledge. Within ACDC, IODEF is
139 one of the supported schema for exchanging the information.
141 2.3. Research and Education Networkig Information Sharing and Analyssi
142 Center (REN-ISAC)
144 Research and Education Networking Information Sharing and Analysis
145 Center (REN-ISAC) is a private community of the research and higher
146 education members fro sharing threat information, and employs IODEF
147 formatted-message to exchange information.
149 REN-ISAC also recommends to ues of the IODEF attachment provided with
150 the notification email be processed rather than relying on parsing of
151 the email body text. The interface provided by REN-ISAC are designed
152 for dealing with such email.
154 http://www.ren-isac.net/notifications/using_iodef.html
156 3. Open Source Implementations
158 3.1. EMC/RSA RID Agent
160 The EMC/RSA RID agent is an open source implementation of the
161 Internet Engineering Task Force (IETF) standards for the exchange of
162 incident and indicator data. The code has been released under an MIT
163 license and development will continue with the open source community
164 at the Github site for RSA Intelligence Sharing:
166 https://github.com/RSAIntelShare/RID-Server.git
168 The code implements the RFC6545, Real-time Inter-network Defense
169 (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code
170 supports the evolving RFC5070-bis Incident Object Description
171 Exchange Format (IODEF) data model from the work in the IETF working
172 group Managed Incident Lightweight Exchange (MILE).
174 3.2. NICT IODEF-SCI implementation
176 Japan's National Institute of Information and Communications
177 Technology (NICT) Network Security Research Institute implemented
178 open source tools for exchanging, accumulating, and locating IODEF-
179 SCI documents.
181 Three tools are available in GitHub. They assist the exchange of
182 IODEF-SCI documents between parties. IODEF-SCI is the IETF draft
183 that extends IODEF so that IODEF document can embed structured
184 cybersecurity information (SCI). For instance, it can embed MMDEF,
185 CEE, MAEC in XML and CVE identifiers.
187 The three tools are generator, exchanger, and parser. The generator
188 generates IODEF-SCI document or appends an XML to existing IODEF
189 document. The exchanger sends the IODEF document to its
190 correspondent node. The parser receives, parses, and stores the
191 IODEF-SCI document. It also equips the interface that enable users
192 to locate IODEF-SCI documents it has ever received. The code has
193 been released under an MIT license and development will continue
194 here.
196 Note that users can enjoy this software with their own
197 responsibility.
199 Available Online:
201 https://github.com/TakeshiTakahashi/IODEF-SCI
203 3.3. n6
205 n6 is a platform for processing security-related information,
206 developed by NASK, CERT Polska. Its API provides a common and
207 unified way of representing data across the different sources that
208 participate in knowledge management.
210 n6 exposes a REST-ful API over HTTPS with mandatory authentication
211 via TLS client certificates, to ensure confidential and trustworthy
212 communications. Moreover, it uses an event-based data model for
213 representation of all types of security information.
215 Each event is represented as a JSON object with a set of mandatory
216 and optional attributes. It also supports alternative output data
217 formats for keeping compatibility with existing systems - IODEF and
218 CSV - although they lack some of the attributes that may be present
219 in the native JSON format.
221 Available Online:
223 https://github.com/CERT-Polska/n6sdk
225 4. Vendor Implementations
227 4.1. Deep Secure
229 Deep-Secure Guards are built to protect a trusted domain from:
231 o releasing sensitive data that does not meet the organisational
232 security policy
234 o applications receiving badly constructed or malicious data which
235 could exploit a vulnerability (known or unknown)
237 Deep-Secure Guards support HTTPS and XMPP (optimised server to server
238 protocol) transports. The Deep-Secure Guards support transfer of XML
239 based business content by creating a schema to translate the known
240 good content to and from the intermediate format. This means that
241 the Deep-Secure Guards can be used to protect:
243 o IODEF/RID using the HTTPS transport binding (RFC 6546)
245 o IODEF/RID using an XMPP binding
247 o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02)
249 o STIX/TAXII using the HTTPS transport binding
251 Deep-Secure Guards also support the SMTP transport and perform deep
252 content inspection of content including XML attachments. The Mail
253 Guard supports S/MIME and Deep Secure are working on support for the
254 upcoming PLASMA standard which enables information centric policy
255 enforcement of data.
257 4.2. IncMan Suite, DFLabs
259 The Incident Object Description Exchange Format, documented in the
260 RFC 5070, defines a data representation that provides a framework for
261 sharing information commonly exchanged by Computer Security Incident
262 Response Teams (CSIRTs) about computer security incidents. IncMan
263 Suite implements the IODEF standard for exchanging details about
264 incidents, either for exporting and importing activities. This has
265 been introduced to enhance the capabilities of the various CSIRT, to
266 facilitate collaboration and sharing of useful experiences, conveying
267 awareness on specific cases.
269 The IODEF implementation is specified as an XML schema, therefore all
270 data are stored in an xml file: in this file all data of an incident
271 are organized in a hierarchical structure to describe the various
272 objects and their relationships.
274 IncMan Suite relies on IODEF as a transport format, composed by
275 various classes for describing the entities which are part of the
276 incident description: for instance the various relevant timestamps
277 (detect time , start time, end time, report time), the techniques
278 used by the intruders to perpetrate the incident, the impact of the
279 incident, either technical and non-technical (time and monetary) and
280 obviously all systems involved in the incident.
282 4.2.1. Exporting Incidents
284 Each incident defined in IncMan Suite can be exported via a User
285 Interface feature and it will populate an xml document. Due to the
286 nature of the data processed, the IODEF extraction might be
287 considered privacy sensitive by the parties exchanging the
288 information or by those described by it. For this reason, specific
289 care needs to be taken in ensuring the distribution to an appropriate
290 audience or third party, either during the document exchange and
291 subsequent processing.
293 The xml document generated will include description and details of
294 the incident along with all the systems involved and the related
295 information. At this stage it can be distributed for import into a
296 remote system.
298 4.2.2. Importing Incidents
300 IncMan Suite provides a functionality to import incidents stored in
301 files and transported via IODEF-compliant xml documents. The
302 importing process comprises of two steps: firstly, the file is
303 inspected to validate if well formed, then all data are uploaded
304 inside the system.
306 If an incident is already existing in the system with the same
307 incident id, the new one being imported will be created under a new
308 id. This approach prevents from accidentally overwriting existing
309 info or merging inconsistent data.
311 IncMan Suite includes also a feature to upload incidents from emails.
313 The incident, described in xml format, can be stored directly into
314 the body of the email message or transported as an attachment of the
315 email. At regular intervals, customizable by the user, IncMan Suite
316 monitors for incoming emails, filtered by a configurable white-list
317 and black-list mechanism on the sender's email account, then a parser
318 processes the received email and a new incident is created
319 automatically, after having validated the email body or the
320 attachment to ensure it is a well formed format.
322 4.3. Surevine Proof of Concept
324 XMPP is enhanced and extended through the XMPP Extension Protocols
325 (or XEPs). XEP-0268 (http://xmpp.org/extensions/xep-0268.html)
326 describes incident management (using IODEF) of the XMPP network
327 itself, effectively supporting self-healing the XMPP network. In
328 order to more generically cover incident management of a network and
329 over a network, XEP-0268 requires some updates. We are working on
330 these changes together with a new XEP that supports "social
331 networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP-
332 0060). This now allows nodes to publish any type of content and
333 subscribe to and therefore receive the content. XEP-0268 will be
334 used to describe IODEF content. We now have an alpha version of the
335 server-side software and client-side software required to demonstrate
336 the "social networking" capability and are currently enhancing this
337 to support Cyber Incident management in real-time.
339 4.4. MANTIS Cyber-Intelligence Management Framework
341 MANTIS provides an example implementation of a framework for managing
342 cyber threat intelligence expressed in standards such as STIX, CybOX,
343 IODEF, etc. The aims of providing such an example implementation
344 are:
346 o To aide discussions about emerging standards such as STIX, CybOX
347 et al. with respect to questions regarding tooling: how would a
348 certain aspect be implemented, how do changes affect an
349 implementation? Such discussions become much easier and have a
350 better basis if they can be lead in the context of example tooling
351 that is known to the community.
353 o To lower the entrance barrier for organizations and teams (esp.
354 CERT teams) in using emerging standards for cyber-threat
355 intelligence management and exchange.
357 o To provide a platform on the basis of which research and
358 community-driven development in the area of cyber-threat
359 intelligence management can occur.
361 5. Vendors with Planned Support
363 5.1. Threat Central, HP
365 HP has developed HP Threat Central, a security intelligence platform
366 that enables automated, real-time collaboration between organizations
367 to combat today's increasingly sophisticated cyber attacks. One way
368 automated sharing of threat indicators is achieved is through close
369 integration with the HP ArcSight SIEM for automated upload and
370 consumption of information from the Threat Central Server. In
371 addition HP Threat Central supports open standards for sharing threat
372 information so that participants who do not use HP Security Products
373 can participate in the sharing ecosystem. General availability of
374 Threat Central will be in 2014. It is planned that future versions
375 also support IODEF for the automated upload and download of threat
376 information.
378 6. Other Implementations
380 6.1. Collaborative Incident Management System
382 Collaborative Incident Management System (CIMS) is a proof-of-concept
383 system for collaborative incident handling and for the sharing of
384 cyber defence situational awareness information between the
385 participants, developed for the Cyber Coalition 2013 (CC13) exercise
386 organized by NATO. CIMS was implemented based on Request Tracker
387 (RT), an open source software widely used for handling incident
388 response by many CERTs and CSIRTs.
390 One of the functionality implemented in CIMS was the ability to
391 import and export IODEF messages in the body of emails. The intent
392 was to verify the suitability of IODEF to achieve the objective of
393 collaborative incident handling. The customized version of RT could
394 be configured to send an email message containing an IODEF message
395 whenever an incident ticket was created, modified or deleted. These
396 IODEF messages would then be imported into other incident handling
397 systems in order to allow participating CSIRTs to use their usual
398 means for incident handling, while still interacting with those using
399 the proof-of-concept CIMS. Having an IODEF message generated for
400 every change made to the incident information in RT (and for the
401 system to allow incoming IODEF email messages to be associated to an
402 existing incident) would in some way allow all participating CSIRTs
403 to actually work on a "common incident ticket", at least at the
404 conceptual level. Of particular importance was the ability for users
405 to exchange information between each other concerning actions taken
406 in the handling of a particular incident, thus creating a sort of
407 common action log, as well as requesting/tasking others to provide
408 information or perform specified action and correlating received
409 responses to the original request or tasking. As well, a specific
410 "profile" was developed to identify a subset of the IODEF classes
411 that would be used during the exercise, in an attempt to channel all
412 users into a common usage pattern of the otherwise flexible IODEF
413 standard.
415 6.2. Automated Incident Reporting - AirCERT
417 AirCERT was implemented by CERT/CC of Carnegie Mellon's Software
418 Engineering Institute CERT divison. AirCERT was designed to be an
419 Internet-scalable distributed system for sharing security event data.
420 The AirCERT system was designed to be an automated collector of flow
421 and IDS alerts. AirCERT would collect that information into a
422 relational database and be able to share reporting using IODEF and
423 IDMEF. AirCERT additionally used SNML to exchange information about
424 the network. AirCERT was implemented in a combination of C and perl
425 modules and included periodic graphing capabilities leveraging
426 RRDTool.
428 AirCERT was intended for large scale distributed deployment and
429 eventually the ability to sanitize data to be shared across
430 administrative domains. The architecture was desgined to allow
431 collection of data at a per site basis and to allow each site to
432 create data sharing based on its own particular trust relationships.
434 6.3. US Department of Energy CyberFed
436 The CyberFed system was implemented and deployed by Argonne National
437 Laboratory to automate the detection and response of attack activity
438 against Department of Energy (DoE) computer networks. CyberFed
439 automates the collection of network alerting activity from various
440 perimeter network defenses and logs those events into its database.
441 CyberFed then automatically converts that information into blocking
442 information transmitted to all participants. The original
443 implementation used IODef messages wrapped in an XML extension to
444 manage a large array of indicators. The CyberFed system was not
445 designed to describe a particular incident as much as to describe a
446 set of current network blocking indicators that can be generated and
447 deployed machine-to-machine.
449 CyberFed is primarily implemented in Perl. Included as part of the
450 CyberFed system are scripts which interact with a large number of
451 firewalls, IDS/IPS devices, DNS systems, and proxies which operate to
452 implement both the automated collection of events as well as the
453 automated deployment of blacking.
455 Currently CyberFed supports multiple exchange formats including IODef
456 and STIX. OpenIOC is also a potential exchange format that DoE is
457 considering.
459 6.4. TrendMicro Sharing System
461 More information to come.
463 7. Implementation Guide
465 The section aims at sharing the tips for development of IODEF-capable
466 systems.
468 7.1. Code Generators
470 For implementing IODEF-capable systems, it is feasible to employ code
471 generators for XML Schema Document (XSD). The generators are used to
472 save development costs since they automatically create useful
473 libraries for accessing XML attributes, composing messages, and/or
474 validating XML objects. The IODEF XSD was defined in section 8 of
475 RFC 5070, and is availabe at http://www.iana.org/assignments/xml-
476 registry/schema/iodef-1.0.xsd.
478 However, there still remains some problem. Due to the complexity of
479 IODEF XSD, some code generators could not generate from the XSD file.
480 The tested code generators were as follows.
482 o XML::Pastor [XSD:Perl] (Perl)
484 o RXSD [XSD:Ruby] (Ruby)
486 o PyXB [XSD:Python] (Python)
488 o JAXB [XSD:Java] (Java)
490 o CodeSynthesis XSD [XSD:Cxx] (C++)
492 o Xsd.exe [XSD:CS] (C#)
494 For instance, we have used XML::Pastor, but it could not properly
495 understand its schema due to the complexity of IODEF XSD. The same
496 applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and Xsd.exe
497 were able to understand the schema.
499 There is no recommended workaround, however, a double conversion of
500 XSD file is one option to go through the situation; it means XSD is
501 serialized to XML, and it is again converted to XSD. The resultant
502 XSD was process-able by the all tools above.
504 It should be noted that IODEF uses '-' (hyphen) symbols in its
505 classes or attributes, listed as follows.
507 o IODEF-Document Class; it is the top level class in the IODEF data
508 model described in section 3.1 of [RFC5070].
510 o The vlan-name and vlan-num Attribute; according to section 3.16.2
511 of [RFC5070], they are the name and number of Virtual LAN and are
512 the attributes for Address class.
514 o Extending the Enumerated Values of Attribute; according to section
515 5.1 of [RFC5070], it is a extension techniques to add new
516 enumerated values to an attribute, and has a prefix of "ext-",
517 e.g., ext-value, ext-category, ext-type, and so on.
519 According to the language specification, many programing language
520 prohibit to contain '-' symbols in the name of class. The code
521 generators must replace or remove '-' when building the librarlies.
522 They should have the name space to restore '-' when outputting the
523 XML along with IODEF XSD.
525 7.2. iodeflib
527 iodeflib is an open source implementation written in Python. This
528 provides a simple but powerful APIs to create, parse and edit IODEF
529 documents. It was designed in order to keep its interface as simple
530 as possible, whereas generated libraries tend to inherit the
531 complexity of IODEF XSD. As well as the interface, iodeflib involves
532 functions of hiding some unnecessarily nested structures of the IODEF
533 schema, and adding more convenient shortcuts.
535 This tool is available through the following link:
537 http://www.decalage.info/python/iodeflib
539 7.3. iodefpm
541 IODEF.pm is an open source implementation written in Perl. This also
542 provides a simple interface for creating and parsing IODEF documents,
543 in order to facilitate the translation of the a key-value based
544 format to the IODEF representation. The module contains a generic
545 XML DTD parser and includes a simplified node based representation of
546 the IODEF DTD. It can hence easily be upgraded or extended to
547 support new XML nodes or other DTDs.
549 This tool is available through the following link:
551 http://search.cpan.org/~saxjazman/
553 7.4. Usability
555 Here notes some tips to avoid problems.
557 o IODEF has category attribute for NodeRole class. Though various
558 categories are described, they are not enough. For example, in
559 the case of web mail servers, you should choose either "www" or
560 "mail". One suggestion is selecting "mail" as the category
561 attribute and adding "www" for another attirbute.
563 o The numbering of Incident ID needs to be considered. Otherwise,
564 information, such as the number of incidents within certain period
565 could be observed by document receivers. For instance, we could
566 randomize the assignment of the numbers.
568 8. Acknowledgements
570 The MILE Implementation report has been compiled through the
571 submissions of implementers of INCH and MILE working group standards.
572 A special note of thanks to the following contributors:
574 John Atherton, Surevine
576 Humphrey Browning, Deep-Secure
578 Dario Forte, DFLabs
580 Tomas Sander, HP
582 Ulrich Seldeslachts, ACDC
584 Takeshi Takahashi, National Institute of Information and
585 Communications Technology Network Security Research Institute
587 Kathleen Moriarty, EMC
589 Bernd Grobauer, Siemens
591 Dandurand Luc, NATO
593 Pawel Pawlinski, NASK
595 9. IANA Considerations
597 This memo includes no request to IANA.
599 10. Security Considerations
601 This draft provides a summary of implementation reports from
602 researchers and vendors who have implemented RFCs and drafts from the
603 MILE and INCH working groups. There are no security considerations
604 added in this draft because of the nature of the document.
606 11. Informative References
608 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
609 Object Description Exchange Format", RFC 5070, December
610 2007.
612 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
613 Class for Reporting Phishing", RFC 5901, July 2010.
615 [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
616 "Sharing Transaction Fraud Data", RFC 5941, August 2010.
618 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC
619 6545, April 2012.
621 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
622 Defense (RID) Messages over HTTP/TLS", RFC 6546, April
623 2012.
625 [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
626 .
628 [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++",
629 .
631 [XSD:Java]
632 Project Kenai, "JAXB Reference Implementation",
633 .
635 [XSD:Perl]
636 Ulsoy, A., "XML::Pastor",
637 .
639 [XSD:Python]
640 Bigot, P., "PyXB: Python XML Schema Bindings",
641 .
643 [XSD:Ruby]
644 Morsi, M., "RXSD - XSD / Ruby Translator",
645 .
647 Authors' Addresses
649 Chris Inacio
650 Carnegie Mellon University
651 4500 5th Ave., SEI 4108
652 Pittsburgh, PA 15213
653 US
655 Email: inacio@andrew.cmu.edu
656 Daisuke Miyamoto
657 The Univerisity of Tokyo
658 2-11-16 Yayoi, Bunkyo
659 Tokyo 113-8658
660 JP
662 Email: daisu-mi@nc.u-tokyo.ac.jp