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