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