idnits 2.17.1 draft-ietf-mile-implementreport-09.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 (June 7, 2016) is 2880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5070 (Obsoleted by RFC 7970) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: December 9, 2016 UTokyo 6 June 7, 2016 8 MILE Implementation Report 9 draft-ietf-mile-implementreport-09 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 December 9, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 . . . . . . . . . . . . . . 3 57 2.3. Research and Education Networking Information Sharing and 58 Analysis Center . . . . . . . . . . . . . . . . . . . . . 3 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 5.2. DAEDALUS, NICT . . . . . . . . . . . . . . . . . . . . . 8 71 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Collaborative Incident Management System . . . . . . . . 9 73 6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 10 74 6.3. US Department of Energy CyberFed . . . . . . . . . . . . 10 75 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 94 [RFC5070], 96 o Incident Object Description Exchange Format (IODEF) v2, 97 RFC5070-bis, 99 o Extensions to the IODEF-Document Class for Reporting Phishing, 100 RFC5901 [RFC5901], 102 o Sharing Transaction Fraud Data, RFC5941 [RFC5941], 104 o Real-time Inter-network Defense (RID), RFC6545 [RFC6545], 106 o Transport of Real-time Inter-network Defense (RID) Messages over 107 HTTP/TLS, RFC6546 [RFC6546], 109 o Incident Object Description Exchange Format (IODEF) Extension for 110 Structured Cybersecurity Information, RFC7203 [RFC7203]. 112 The implementation reports included in this document have been 113 provided by the team or product responsible for the implementations 114 of the mentioned RFCs. Additional submissions are welcome and should 115 be sent to the draft editor. A more complete list of 116 implementations, including open source efforts and vendor products, 117 can also be found at the following location: 119 http://siis.realmv6.org/implementations/ 121 2. Consortiums and Information Sharing and Analysis Centers (ISACs) 123 2.1. Anti-Phishing Working Group 125 Anti-Phishing Working Group (APWG) is one of the biggest coalition 126 against cybercrime, especially phishing. In order to collect threat 127 information in a structured format, APWG provides a phishing and 128 cybercrime reporting tool which sends threat information to APWG by 129 tailoring information with IODEF format, based on RFC5070 and 130 RFC5901. 132 2.2. Advanced Cyber Defence Centre 134 The Advanced Cyber Defense Centre (ACDC), is EU-wide activity to 135 fight against botnets. ACDC provides a solutions to mitigate on- 136 going attacks, as well as consolidating information provided by 137 various stakeholders into a pool of knowledge. Within ACDC, IODEF is 138 one of the supported schema for exchanging the information. 140 2.3. Research and Education Networking Information Sharing and Analysis 141 Center 143 Research and Education Networking Information Sharing and Analysis 144 Center (REN-ISAC) is a private community of the research and higher 145 education members for sharing threat information, and employs IODEF 146 formatted-message to exchange information. 148 REN-ISAC also recommends to use an IODEF attachment provided with a 149 notification email for processing rather than relying on parsing of 150 the email body text. The interface provided by REN-ISAC are designed 151 to handle such email. 153 http://www.ren-isac.net/notifications/using_iodef.html 155 3. Open Source Implementations 157 3.1. EMC/RSA RID Agent 159 The EMC/RSA RID agent is an open source implementation of the IETF 160 standards for the exchange of incident and indicator data. The code 161 has been released under an MIT license and development will continue 162 with the open source community at the Github site for RSA 163 Intelligence Sharing: 165 https://github.com/RSAIntelShare/RID-Server.git 167 The code implements the RFC6545, Real-time Inter-network Defense 168 (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code 169 supports the evolving RFC5070-bis Incident Object Description 170 Exchange Format (IODEF) data model from the work in the IETF working 171 group Managed Incident Lightweight Exchange (MILE). 173 3.2. NICT IODEF-SCI implementation 175 Japan's National Institute of Information and Communications 176 Technology (NICT) Network Security Research Institute implemented 177 open source tools for exchanging, accumulating, and locating IODEF- 178 SCI documents. 180 Three tools are available in GitHub. They assist the exchange of 181 IODEF-SCI documents between parties. IODEF-SCI is the IETF draft 182 that extends IODEF so that IODEF document can embed structured 183 cybersecurity information (SCI). For instance, it can embed MMDEF, 184 CEE, MAEC in XML and CVE identifiers. 186 The three tools are generator, exchanger, and parser. The generator 187 generates IODEF-SCI document or appends an XML to existing IODEF 188 document. The exchanger sends the IODEF document to its 189 correspondent node. The parser receives, parses, and stores the 190 IODEF-SCI document. It also equips the interface that enable users 191 to locate IODEF-SCI documents it has ever received. The code has 192 been released under an MIT license and development will continue 193 here. 195 Note that users can enjoy this software with their own 196 responsibility. 198 Available Online: 200 https://github.com/TakeshiTakahashi/IODEF-SCI 202 3.3. n6 204 n6 is a platform for processing security-related information, 205 developed by NASK, CERT Polska. Its API provides a common and 206 unified way of representing data across the different sources that 207 participate in knowledge management. 209 n6 exposes a REST-ful API over HTTPS with mandatory authentication 210 via TLS client certificates, to ensure confidential and trustworthy 211 communications. Moreover, it uses an event-based data model for 212 representation of all types of security information. 214 Each event is represented as a JSON object with a set of mandatory 215 and optional attributes. It also supports alternative output data 216 formats for keeping compatibility with existing systems - IODEF and 217 CSV - although they lack some of the attributes that may be present 218 in the native JSON format. 220 Available Online: 222 https://github.com/CERT-Polska/n6sdk 224 4. Vendor Implementations 226 4.1. Deep Secure 228 Deep-Secure Guards are built to protect a trusted domain from: 230 o releasing sensitive data that does not meet the organisational 231 security policy 233 o applications receiving badly constructed or malicious data which 234 could exploit a vulnerability (known or unknown) 236 Deep-Secure Guards support HTTPS and XMPP (optimised server to server 237 protocol) transports. The Deep-Secure Guards support transfer of XML 238 based business content by creating a schema to translate the known 239 good content to and from the intermediate format. This means that 240 the Deep-Secure Guards can be used to protect: 242 o IODEF/RID using the HTTPS transport binding (RFC6546) 243 o IODEF/RID using an XMPP binding 245 o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02) 247 o STIX/TAXII using the HTTPS transport binding 249 Deep-Secure Guards also support the SMTP transport and perform deep 250 content inspection of content including XML attachments. The Mail 251 Guard supports S/MIME and Deep Secure are working on support for the 252 upcoming PLASMA standard which enables information centric policy 253 enforcement of data. 255 4.2. IncMan Suite, DFLabs 257 The Incident Object Description Exchange Format, documented in the 258 RFC5070, defines a data representation that provides a framework for 259 sharing information commonly exchanged by Computer Security Incident 260 Response Teams (CSIRTs) about computer security incidents. IncMan 261 Suite implements the IODEF standard for exchanging details about 262 incidents, either for exporting and importing activities. This has 263 been introduced to enhance the capabilities of the various CSIRT, to 264 facilitate collaboration and sharing of useful experiences, conveying 265 awareness on specific cases. 267 The IODEF implementation is specified as an XML schema, therefore all 268 data are stored in an xml file: in this file all data of an incident 269 are organized in a hierarchical structure to describe the various 270 objects and their relationships. 272 IncMan Suite relies on IODEF as a transport format, composed by 273 various classes for describing the entities which are part of the 274 incident description: for instance the various relevant timestamps 275 (detect time , start time, end time, report time), the techniques 276 used by the intruders to perpetrate the incident, the impact of the 277 incident, either technical and non-technical (time and monetary) and 278 obviously all systems involved in the incident. 280 4.2.1. Exporting Incidents 282 Each incident defined in IncMan Suite can be exported via a User 283 Interface feature and it will populate an xml document. Due to the 284 nature of the data processed, the IODEF extraction might be 285 considered privacy sensitive by the parties exchanging the 286 information or by those described by it. For this reason, specific 287 care needs to be taken in ensuring the distribution to an appropriate 288 audience or third party, either during the document exchange and 289 subsequent processing. 291 The xml document generated will include description and details of 292 the incident along with all the systems involved and the related 293 information. At this stage it can be distributed for import into a 294 remote system. 296 4.2.2. Importing Incidents 298 IncMan Suite provides a functionality to import incidents stored in 299 files and transported via IODEF-compliant xml documents. The 300 importing process comprises of two steps: firstly, the file is 301 inspected to validate if well formed, then all data are uploaded 302 inside the system. 304 If an incident is already existing in the system with the same 305 incident id, the new one being imported will be created under a new 306 id. This approach prevents from accidentally overwriting existing 307 info or merging inconsistent data. 309 IncMan Suite includes also a feature to upload incidents from emails. 311 The incident, described in xml format, can be stored directly into 312 the body of the email message or transported as an attachment of the 313 email. At regular intervals, customizable by the user, IncMan Suite 314 monitors for incoming emails, filtered by a configurable white-list 315 and black-list mechanism on the sender's email account, then a parser 316 processes the received email and a new incident is created 317 automatically, after having validated the email body or the 318 attachment to ensure it is a well formed format. 320 4.3. Surevine Proof of Concept 322 XMPP is enhanced and extended through the XMPP Extension Protocols 323 (or XEPs). XEP-0268 (http://xmpp.org/extensions/xep-0268.html) 324 describes incident management (using IODEF) of the XMPP network 325 itself, effectively supporting self-healing the XMPP network. In 326 order to more generically cover incident management of a network and 327 over a network, XEP-0268 requires some updates. We are working on 328 these changes together with a new XEP that supports "social 329 networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP- 330 0060). This now allows nodes to publish any type of content and 331 subscribe to and therefore receive the content. XEP-0268 will be 332 used to describe IODEF content. We now have an alpha version of the 333 server-side software and client-side software required to demonstrate 334 the "social networking" capability and are currently enhancing this 335 to support Cyber Incident management in real-time. 337 4.4. MANTIS Cyber-Intelligence Management Framework 339 MANTIS provides an example implementation of a framework for managing 340 cyber threat intelligence expressed in standards such as STIX, CybOX, 341 IODEF, etc. The aims of providing such an example implementation 342 are: 344 o To aide discussions about emerging standards such as STIX, CybOX 345 et al. with respect to questions regarding tooling: how would a 346 certain aspect be implemented, how do changes affect an 347 implementation? Such discussions become much easier and have a 348 better basis if they can be lead in the context of example tooling 349 that is known to the community. 351 o To lower the entrance barrier for organizations and teams (esp. 352 CERT teams) in using emerging standards for cyber-threat 353 intelligence management and exchange. 355 o To provide a platform on the basis of which research and 356 community-driven development in the area of cyber-threat 357 intelligence management can occur. 359 5. Vendors with Planned Support 361 5.1. Threat Central, HP 363 HP has developed HP Threat Central, a security intelligence platform 364 that enables automated, real-time collaboration between organizations 365 to combat today's increasingly sophisticated cyber attacks. One way 366 automated sharing of threat indicators is achieved is through close 367 integration with the HP ArcSight SIEM for automated upload and 368 consumption of information from the Threat Central Server. In 369 addition HP Threat Central supports open standards for sharing threat 370 information so that participants who do not use HP Security Products 371 can participate in the sharing ecosystem. General availability of 372 Threat Central will be in 2014. It is planned that future versions 373 also support IODEF for the automated upload and download of threat 374 information. 376 5.2. DAEDALUS, NICT 378 DAEDALUS is a real-time alert system based on a large-scale darknet 379 monitoring facility that has been deployed as a part of the nicter 380 system of NICT, Japan. DAEDALUS consists of an analysis center 381 (i.e., nicter) and several cooperate organizations. Each 382 organization installs a darknet sensor and establishes a secure 383 channel between it and the analysis center, and continuously forwards 384 darknet traffic toward the center. In addition, each organization 385 registers the IP address range of its livenet at the center in 386 advance. When these distributed darknet sensors observe malware 387 activities from the IP address of a cooperate organization, then the 388 analysis center sends an alert to the organization. The future 389 version of DAEDALUS will support IODEF for sending alert messages to 390 the users. 392 6. Other Implementations 394 6.1. Collaborative Incident Management System 396 Collaborative Incident Management System (CIMS) is a proof-of-concept 397 system for collaborative incident handling and for the sharing of 398 cyber defence situational awareness information between the 399 participants, developed for the Cyber Coalition 2013 (CC13) exercise 400 organized by NATO. CIMS was implemented based on Request Tracker 401 (RT), an open source software widely used for handling incident 402 response by many CERTs and CSIRTs. 404 One of the functionality implemented in CIMS was the ability to 405 import and export IODEF messages in the body of emails. The intent 406 was to verify the suitability of IODEF to achieve the objective of 407 collaborative incident handling. The customized version of RT could 408 be configured to send an email message containing an IODEF message 409 whenever an incident ticket was created, modified or deleted. These 410 IODEF messages would then be imported into other incident handling 411 systems in order to allow participating CSIRTs to use their usual 412 means for incident handling, while still interacting with those using 413 the proof-of-concept CIMS. Having an IODEF message generated for 414 every change made to the incident information in RT (and for the 415 system to allow incoming IODEF email messages to be associated to an 416 existing incident) would in some way allow all participating CSIRTs 417 to actually work on a "common incident ticket", at least at the 418 conceptual level. Of particular importance was the ability for users 419 to exchange information between each other concerning actions taken 420 in the handling of a particular incident, thus creating a sort of 421 common action log, as well as requesting/tasking others to provide 422 information or perform specified action and correlating received 423 responses to the original request or tasking. As well, a specific 424 "profile" was developed to identify a subset of the IODEF classes 425 that would be used during the exercise, in an attempt to channel all 426 users into a common usage pattern of the otherwise flexible IODEF 427 standard. 429 6.2. Automated Incident Reporting - AirCERT 431 AirCERT was implemented by CERT/CC of Carnegie Mellon's Software 432 Engineering Institute CERT division. AirCERT was designed to be an 433 Internet-scalable distributed system for sharing security event data. 434 The AirCERT system was designed to be an automated collector of flow 435 and IDS alerts. AirCERT would collect that information into a 436 relational database and be able to share reporting using IODEF and 437 Intrusion Detection Message Exchange Format (RFC4765, [RFC4765]). 438 AirCERT additionally used Simple Network Markup Language [SNML] to 439 exchange information about the network. AirCERT was implemented in a 440 combination of C and perl modules and included periodic graphing 441 capabilities leveraging RRDTool. 443 AirCERT was intended for large scale distributed deployment and 444 eventually the ability to sanitize data to be shared across 445 administrative domains. The architecture was designed to allow 446 collection of data at a per site basis and to allow each site to 447 create data sharing based on its own particular trust relationships. 449 6.3. US Department of Energy CyberFed 451 The CyberFed system was implemented and deployed by Argonne National 452 Laboratory to automate the detection and response of attack activity 453 against Department of Energy (DoE) computer networks. CyberFed 454 automates the collection of network alerting activity from various 455 perimeter network defenses and logs those events into its database. 456 CyberFed then automatically converts that information into blocking 457 information transmitted to all participants. The original 458 implementation used IODEF messages wrapped in an XML extension to 459 manage a large array of indicators. The CyberFed system was not 460 designed to describe a particular incident as much as to describe a 461 set of current network blocking indicators that can be generated and 462 deployed machine-to-machine. 464 CyberFed is primarily implemented in Perl. Included as part of the 465 CyberFed system are scripts which interact with a large number of 466 firewalls, IDS/IPS devices, DNS systems, and proxies which operate to 467 implement both the automated collection of events as well as the 468 automated deployment of blacking. 470 Currently CyberFed supports multiple exchange formats including IODEF 471 and STIX. OpenIOC is also a potential exchange format that DoE is 472 considering. 474 7. Implementation Guide 476 The section aims at sharing the tips for development of IODEF-capable 477 systems. 479 7.1. Code Generators 481 For implementing IODEF-capable systems, it is feasible to employ code 482 generators for XML Schema Document (XSD). The generators are used to 483 save development costs since they automatically create useful 484 libraries for accessing XML attributes, composing messages, and/or 485 validating XML objects. The IODEF XSD was defined in section 8 of 486 RFC5070, and is availabe at http://www.iana.org/assignments/xml- 487 registry/schema/iodef-1.0.xsd. 489 However, there still remains some problem. Due to the complexity of 490 IODEF XSD, some code generators could not generate from the XSD file. 491 The tested code generators were as follows. 493 o XML::Pastor [XSD:Perl] (Perl) 495 o RXSD [XSD:Ruby] (Ruby) 497 o PyXB [XSD:Python] (Python) 499 o JAXB [XSD:Java] (Java) 501 o CodeSynthesis XSD [XSD:Cxx] (C++) 503 o Xsd.exe [XSD:CS] (C#) 505 For instance, we have used XML::Pastor, but it could not properly 506 understand its schema due to the complexity of IODEF XSD. The same 507 applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and Xsd.exe 508 were able to understand the schema. 510 There is no recommended workaround, however, a double conversion of 511 XSD file is one option to go through the situation; it means XSD is 512 serialized to XML, and it is again converted to XSD. The resultant 513 XSD was process-able by the all tools above. 515 It should be noted that IODEF uses '-' (hyphen) symbols in its 516 classes or attributes, listed as follows. 518 o IODEF-Document Class; it is the top level class in the IODEF data 519 model described in section 3.1 of RFC5070. 521 o The vlan-name and vlan-num Attribute; according to section 3.16.2 522 of RFC5070, they are the name and number of Virtual LAN and are 523 the attributes for Address class. 525 o Extending the Enumerated Values of Attribute; according to section 526 5.1 of RFC5070, it is a extension techniques to add new enumerated 527 values to an attribute, and has a prefix of "ext-", e.g., ext- 528 value, ext-category, ext-type, and so on. 530 According to the language specification, many programing language 531 prohibit to contain '-' symbols in the name of class. The code 532 generators must replace or remove '-' when building the librarlies. 533 They should have the name space to restore '-' when outputting the 534 XML along with IODEF XSD. 536 7.2. iodeflib 538 iodeflib is an open source implementation written in Python. This 539 provides a simple but powerful APIs to create, parse and edit IODEF 540 documents. It was designed in order to keep its interface as simple 541 as possible, whereas generated libraries tend to inherit the 542 complexity of IODEF XSD. As well as the interface, iodeflib involves 543 functions of hiding some unnecessarily nested structures of the IODEF 544 schema, and adding more convenient shortcuts. 546 This tool is available through the following link: 548 http://www.decalage.info/python/iodeflib 550 7.3. iodefpm 552 IODEF.pm is an open source implementation written in Perl. This also 553 provides a simple interface for creating and parsing IODEF documents, 554 in order to facilitate the translation of the a key-value based 555 format to the IODEF representation. The module contains a generic 556 XML DTD parser and includes a simplified node based representation of 557 the IODEF DTD. It can hence easily be upgraded or extended to 558 support new XML nodes or other DTDs. 560 This tool is available through the following link: 562 http://search.cpan.org/~saxjazman/ 564 7.4. Usability 566 Here notes some tips to avoid problems. 568 o IODEF has category attribute for NodeRole class. Though various 569 categories are described, they are not enough. For example, in 570 the case of web mail servers, you should choose either "www" or 571 "mail". One suggestion is selecting "mail" as the category 572 attribute and adding "www" for another attirbute. 574 o The numbering of Incident ID needs to be considered. Otherwise, 575 information, such as the number of incidents within certain period 576 could be observed by document receivers. For instance, we could 577 randomize the assignment of the numbers. 579 8. Acknowledgements 581 The MILE Implementation report has been compiled through the 582 submissions of implementers of INCH and MILE working group standards. 583 A special note of thanks to the following contributors: 585 John Atherton, Surevine 587 Humphrey Browning, Deep-Secure 589 Dario Forte, DFLabs 591 Tomas Sander, HP 593 Ulrich Seldeslachts, ACDC 595 Takeshi Takahashi, National Institute of Information and 596 Communications Technology Network Security Research Institute 598 Kathleen Moriarty, EMC 600 Bernd Grobauer, Siemens 602 Dandurand Luc, NATO 604 Pawel Pawlinski, NASK 606 9. IANA Considerations 608 This memo includes no request to IANA. 610 10. Security Considerations 612 This draft provides a summary of implementation reports from 613 researchers and vendors who have implemented RFCs and drafts from the 614 MILE and INCH working groups. There are no security considerations 615 added in this draft because of the nature of the document. 617 11. Informative References 619 [RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion 620 Detection Message Exchange Format (IDMEF)", RFC 4765, 621 DOI 10.17487/RFC4765, March 2007, 622 . 624 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 625 Object Description Exchange Format", RFC 5070, 626 DOI 10.17487/RFC5070, December 2007, 627 . 629 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document 630 Class for Reporting Phishing", RFC 5901, 631 DOI 10.17487/RFC5901, July 2010, 632 . 634 [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj, 635 "Sharing Transaction Fraud Data", RFC 5941, 636 DOI 10.17487/RFC5941, August 2010, 637 . 639 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 640 RFC 6545, DOI 10.17487/RFC6545, April 2012, 641 . 643 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 644 Defense (RID) Messages over HTTP/TLS", RFC 6546, 645 DOI 10.17487/RFC6546, April 2012, 646 . 648 [RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An 649 Incident Object Description Exchange Format (IODEF) 650 Extension for Structured Cybersecurity Information", 651 RFC 7203, DOI 10.17487/RFC7203, April 2014, 652 . 654 [SNML] Trammell, B., Danyliw, R., Levy, S., and A. Kompanek, 655 "AirCERT: The Definitive Guide", 2005, 656 . 659 [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)", 660 . 662 [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++", 663 . 665 [XSD:Java] 666 Project Kenai, "JAXB Reference Implementation", 667 . 669 [XSD:Perl] 670 Ulsoy, A., "XML::Pastor", 671 . 673 [XSD:Python] 674 Bigot, P., "PyXB: Python XML Schema Bindings", 675 . 677 [XSD:Ruby] 678 Morsi, M., "RXSD - XSD / Ruby Translator", 679 . 681 Authors' Addresses 683 Chris Inacio 684 Carnegie Mellon University 685 4500 5th Ave., SEI 4108 686 Pittsburgh, PA 15213 687 US 689 Email: inacio@andrew.cmu.edu 691 Daisuke Miyamoto 692 The Univerisity of Tokyo 693 2-11-16 Yayoi, Bunkyo 694 Tokyo 113-8658 695 JP 697 Email: daisu-mi@nc.u-tokyo.ac.jp