RFC 8134

Management Incident Lightweight Exchange (MILE) Implementation Report

📅 published May 2017, from ietf

Management Incident Lightweight Exchange (MILE) Implementation Report 🦋

Okay bestie, this is RFC 8134 from the IETF (Internet Engineering Task Force) 💖 It's written by C. Inacio from CMU and D. Miyamoto from UTokyo, and it's dated May 2017. The category is Informational, so it's not a standards-track spec, and the ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates. Basically it's a scrapbook of who actually built stuff with the INCH and MILE standards 📚✨

Abstract ✨

Okay so this doc is a collection of implementation reports 🍓 Vendors, consortiums, and researchers wrote in about the standards they've built from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups. It's giving "look what we made" energy, and I'm obsessed 💅

Status of This Memo 📜

Real talk, this is not an Internet Standards Track specification. It's published just for info 🌸

It's a product of the IETF and represents what the IETF community agreed on. It got public review, and the IESG (Internet Engineering Steering Group) approved it for publication. Not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🧐

For the latest status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc8134 🦋

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. Please actually read those, because they spell out your rights and restrictions 🫶 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🔥

Table of Contents 🎀

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Consortiums and Information Sharing and Analysis Centers
    (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Anti-Phishing Working Group . . . . . . . . . . . . . . .   4
  2.2.  Advanced Cyber Defence Centre . . . . . . . . . . . . . .   4
  2.3.  Research and Education Networking Information Sharing and
        Analysis Center . . . . . . . . . . . . . . . . . . . . .   4
3.  Open Source Implementations . . . . . . . . . . . . . . . . .   4
  3.1.  EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . .   4
  3.2.  NICT IODEF-SCI implementation . . . . . . . . . . . . . .   5
  3.3.  n6  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.  Vendor Implementations  . . . . . . . . . . . . . . . . . . .   6
  4.1.  Deep Secure . . . . . . . . . . . . . . . . . . . . . . .   6
  4.2.  IncMan Suite, DFLabs  . . . . . . . . . . . . . . . . . .   7
  4.3.  Surevine Proof of Concept . . . . . . . . . . . . . . . .   8
  4.4.  MANTIS Cyber-Intelligence Management Framework  . . . . .   8
5.  Vendors with Planned Support  . . . . . . . . . . . . . . . .   9
  5.1.  Threat Central, HP  . . . . . . . . . . . . . . . . . . .   9
  5.2.  DAEDALUS, NICT  . . . . . . . . . . . . . . . . . . . . .   9
6.  Other Implementations . . . . . . . . . . . . . . . . . . . .  10
  6.1.  Collaborative Incident Management System  . . . . . . . .  10
  6.2.  Automated Incident Reporting - AirCERT  . . . . . . . . .  10
  6.3.  US Department of Energy CyberFed  . . . . . . . . . . . .  11
7.  Implementation Guide  . . . . . . . . . . . . . . . . . . . .  11
  7.1.  Code Generators . . . . . . . . . . . . . . . . . . . . .  11
  7.2.  iodeflib  . . . . . . . . . . . . . . . . . . . . . . . .  13
  7.3.  iodefpm . . . . . . . . . . . . . . . . . . . . . . . . .  13
  7.4.  Usability . . . . . . . . . . . . . . . . . . . . . . . .  13
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
10. Informative References  . . . . . . . . . . . . . . . . . . .  14
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1. Introduction 🌸

Okay so this doc is a collection of info about security incident reporting protocols and the systems that use them to share that info 💅 It's just a collection, so it doesn't try to compare the standards or the implementations. It's super useful for network operators who want to collect and share this data ✨

Operationally, operators have to pick which incident data collection group they want to be part of 🫶 That choice really shapes which reporting protocol they use and which apps they use to gather and distribute the data 🔥

This doc is a collection of implementation reports from vendors and researchers who built one or more of the standards from the INCH and MILE working groups 🦋 The standards are:

  • Incident Object Description Exchange Format (IODEF) v1 [RFC5070]
  • Incident Object Description Exchange Format (IODEF) v2 [RFC7970]
  • Extensions to the IODEF-Document Class for Reporting Phishing [RFC5901]
  • Sharing Transaction Fraud Data [RFC5941]
  • Real-time Inter-network Defense (RID) [RFC6545]
  • Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS [RFC6546]
  • Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information (SCI) [RFC7203]

The implementation reports in here came from the team or product behind each implementation of those RFCs 💖 If you want a bigger list, including open source projects and vendor products, check out this spot: <http://siis.realmv6.org/implementations/> 🧚

2. Consortiums and Information Sharing and Analysis Centers (ISACs) 👑

2.1. Anti-Phishing Working Group

The Anti-Phishing Working Group (APWG) is one of the biggest coalitions fighting cybercrime, especially phishing 🎀 To collect threat info in a structured way, APWG runs a phishing and cybercrime reporting tool. It sends threat info to APWG in the IODEF format, based on RFC 5070 [RFC5070] and RFC 5901 [RFC5901] 💅

2.2. Advanced Cyber Defence Centre

The Advanced Cyber Defence Centre (ACDC) is a Europe-wide effort to fight botnets 🤖 ACDC helps mitigate ongoing attacks and pulls info from lots of stakeholders into one pool of knowledge 🌈 IODEF is one of the schemas ACDC supports for swapping info, so it's a big deal 😭

2.3. Research and Education Networking Information Sharing and Analysis Center

The Research and Education Networking Information Sharing and Analysis Center (REN-ISAC) is a private community of researchers and higher-education members 🎓 They share threat info and use IODEF-formatted messages to do it 🔥

REN-ISAC also recommends using an IODEF attachment that comes with a notification email, instead of parsing the body text of the email 🙈 Their tools are built to handle that kind of email ✨

<http://www.ren-isac.net/notifications/using_iodef.html>

3. Open Source Implementations 🧚

3.1. EMC/RSA RID Agent

The EMC/RSA RID agent is an open source implementation of the IETF standards for exchanging incident and indicator data 💜 The code is released under an MIT license, and development keeps going with the open source community on the GitHub site for RSA Intelligence Sharing:

<https://github.com/RSAIntelShare/RID-Server.git>

The code implements Real-time Inter-network Defense (RID), described in RFC 6545 [RFC6545], and the Transport of RID over HTTP/TLS protocol described in [RFC6546] 🦋 It also supports the evolving Incident Object Description Exchange Format (IODEF) data model [RFC7970] from the IETF Managed Incident Lightweight Exchange (MILE) working group 🌸

3.2. NICT IODEF-SCI implementation

Japan's National Institute of Information and Communications Technology (NICT) Network Security Research Institute built open source tools for exchanging, storing, and finding IODEF-SCI [RFC7203] documents 🍓

There are three tools on GitHub, and they help parties exchange IODEF-SCI documents 💖 IODEF-SCI [RFC7203] extends IODEF so an IODEF document can embed Structured Cybersecurity Information (SCI) ✨ For example, it can embed Malware Metadata Exchange Format (MMDEF), Common Event Expression (CEE), Malware Attribute Enumeration and Characterization (MAEC) in XML, and Common Vulnerabilities and Exposures (CVE) identifiers 🔥

The three tools are the generator, the exchanger, and the parser 🎀 The generator makes IODEF-SCI documents or adds XML to an existing IODEF document 🛠️ The exchanger sends the IODEF document to a specified correspondent node 📨 The parser receives, parses, and stores the IODEF-SCI document 🫶 It also creates an interface so users can find IODEF-SCI documents they've received before 👀 The code is released under an MIT license, and development keeps going on GitHub 💅

Note that users can enjoy using this software at their own risk. ⚠️

Available Online:

<https://github.com/TakeshiTakahashi/IODEF-SCI>

3.3. n6

n6 is a platform for processing security-related information 🌈 It was developed by the Poland Research and Academic Computer Network (NASK) Computer Emergency Response Team (CERT) Polska 🇵🇱 The n6 API gives a common, unified way to represent data from all the different sources that take part in knowledge management 🧠

n6 exposes a REST-ful (Representational State Transfer) API over HTTPS, with mandatory authentication through Transport Layer Security (TLS) client certificates to keep communications confidential and trustworthy 🔐 It also uses an event-based data model to represent all types of security information ✨

Each event is represented as a JSON object with a set of mandatory and optional attributes 💜 n6 also supports alternative output formats for compatibility with existing systems, namely IODEF and CSV 🍓 These formats do lack some of the attributes that may be present in the native JSON format, so keep that in mind 👀

Available Online:

<https://github.com/CERT-Polska/n6sdk>

4. Vendor Implementations 👑

Okay the vendor section is so juicy, and it's coming up in part 2 🫶💖

4.1. Deep Secure 🛡️

okay so Deep-Secure Guards are built to protect a trusted domain from:

  • releasing sensitive data that does not meet the organizational security policy, and
  • applications receiving badly constructed or malicious data that could exploit a vulnerability (known or unknown).

Deep-Secure Guards support HTTPS and the Extensible Messaging and Presence Protocol (XMPP -- optimized server-to-server protocol), transports. They support transfer of XML-based business content by creating a schema to translate the known good content to and from the intermediate format. ✨ This means the Deep-Secure Guards can be used to protect:

  • IODEF/RID using the HTTPS transport binding [RFC6546]
  • IODEF/RID using an XMPP binding
  • Resource-Oriented Lightweight Indicator Exchange (ROLIE) using HTTPS transport binding [XEP-0268]
  • Structured Threat Information Expression (STIX) / Trusted Automated Exchange of Indicator Information (TAXII) using the HTTPS transport binding

Deep-Secure Guards also support the SMTP transport and perform deep content inspection of content including XML attachments. 🎀 The Mail Guard supports S/MIME, and Deep Secure is working on support for the upcoming PLASMA standard, which enables an information-centric policy enforcement of data use. main character energy, honestly 💅

4.2. IncMan Suite, DFLabs 🔥

The Incident Object Description Exchange Format, documented in RFC 5070 [RFC5070], defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. IncMan Suite implements the IODEF standard for exchanging details about incidents, either for exporting or importing activities. 🦋 This has been introduced to enhance the capabilities of the various CSIRTs to facilitate collaboration and sharing of useful experiences (sharing awareness on specific cases).

The IODEF implementation is specified as an XML schema, therefore all data are stored in an XML file. In this file, all the data of an incident are organized in a hierarchical structure to describe the various objects and their relationships. 🧚

The IncMan Suite relies on IODEF as a transport format, which is composed by various classes for describing the entities that are part of the incident description. For instance, the various relevant timestamps (detection time, start time, end time, and report time), the techniques used by the intruders to perpetrate the incident, the impact of the incident, technical and non-technical (time and monetary), and obviously all systems involved in the incident. 💀

4.2.1. Exporting Incidents 📤

Each incident defined in the IncMan Suite can be exported via a user interface feature, and it will create an XML document. Due to the nature of the data processed, the IODEF extraction might be considered privacy sensitive by the parties exchanging the information or by those described by it. 🙈 For this reason, specific care needs to be taken in ensuring the distribution to an appropriate audience or third party, either during the document exchange or the subsequent processing.

The XML document generated will include a description and details of the incident along with all the systems involved and the related information. At this stage, it can be distributed for import into a remote system. 🌸

4.2.2. Importing Incidents 📥

The IncMan Suite provides the functionality to import incidents stored in files and transported via IODEF-compliant XML documents. The importing process is comprised of two steps: first, the file is inspected to validate if it is well formed; second, all data are uploaded inside the system.

If the incident already exists in the system with the same incident ID, the new one being imported will be created under a new ID. This approach prevents accidentally overwriting existing information or merging inconsistent data. 🫶

The IncMan Suite also includes a feature to upload incidents from emails. ✉️

The incident, described in XML format, can be stored directly into the body of the email message or transported as an attachment of the email. At regular intervals that are customizable by the user, the IncMan Suite monitors for incoming emails, which are filtered by a configurable white-list and black-list mechanism on the sender's email account. Then, a parser processes the received email and a new incident is created automatically after having validated the email body or the attachment to ensure the format is well formed. the way that this is so organised 😭

4.3. Surevine Proof of Concept 🌈

XMPP is enhanced and extended through the XMPP Extension Protocols (XEPs). XEP-0268 [XEP-0268] describes incident management (using IODEF) of the XMPP network itself, effectively supporting self-healing the XMPP network. In order to more generically cover the incident management of a network over the same network, XEP-0268 requires some updates. We are working on these changes together with a new XEP that supports "social networking" over XMPP, which enhances the publish-and-subscribe XEP [XEP-0060]. This now allows nodes to publish and subscribe to any type of content and therefore receive the content. XEP-0060 will be used to describe IODEF content.

We now have an alpha version of the server-side software and client-side software required to demonstrate the "social networking" capability and are currently enhancing this to support cyber incident management in real time. ⭐

4.4. MANTIS Cyber-Intelligence Management Framework 🧠

Model-based Analysis of Threat Intelligence Sources (MANTIS) provides an example implementation of a framework for managing cyber threat intelligence expressed in standards such as STIX, Cyber Observable Expression (CybOX), IODEF, etc. The aims of providing such an example implementation are as follows:

  • To facilitate discussions about emerging standards such as STIX, CybOX, et al., with respect to questions regarding tooling: how would a certain aspect be implemented, and how do changes affect an implementation? Such discussions become much easier and have a better basis if they can be lead in the context of example tooling that is known to the community. 💭
  • To lower the barrier of entry for organizations and teams (especially CSIRT/CERT teams) in using emerging standards for cyber-threat-intelligence management and exchange. 🍓
  • To provide a platform on the basis of which research and community-driven development in the area of cyber-threat-intelligence management can occur. 👑

5. Vendors with Planned Support 🚀

5.1. Threat Central, HP 💜

HP has developed HP Threat Central, a security intelligence platform that enables automated, real-time collaboration between organizations to combat today's increasingly sophisticated cyber attacks. One way automated sharing of threat indicators is achieved is through close integration with the HP ArcSight Security Information and Event Management (SIEM) for automated upload and consumption of information from the Threat Central Server. In addition, HP Threat Central supports open standards for sharing threat information so that participants who do not use HP Security Products can participate in the sharing ecosystem. It is planned that future versions will also support IODEF for the automated upload and download of threat information. 🙌

5.2. DAEDALUS, NICT 🛰️

DAEDALUS is a real-time alert system based on a large-scale darknet monitoring facility that has been deployed as a part of the Network Incident analysis Center for Tactical Emergency Response (nicter) system of NICT, which is based in Japan. DAEDALUS consists of an analysis center (i.e., nicter) and several cooperative organizations. Each organization installs a darknet sensor and establishes a secure channel between it and the analysis center, and it continuously forwards darknet traffic toward the center. In addition, each organization registers the IP address range of its livenet at the center in advance. When these distributed darknet sensors observe malware activities from the IP address of a cooperating organization, then the analysis center sends an alert to the organization. The future version of DAEDALUS will support IODEF for sending alert messages to the users. 🔔

6. Other Implementations ✨

6.1. Collaborative Incident Management System 🤝

A Collaborative Incident Management System (CIMS) is a proof-of-concept system for collaborative incident handling and for the sharing of information about cyber defense situational awareness between the participants; it was developed for the Cyber Coalition 2013 (CC13) exercise organized by the North Atlantic Treaty Organization (NATO). CIMS was implemented based on Request Tracker (RT), an open source software widely used for handling incident responses by many CERTs and CSIRTs.

One of the functionalities implemented in CIMS was the ability to import and export IODEF messages in the body of emails. The intent was to verify the suitability of IODEF to achieve the objective of collaborative incident handling. The customized version of RT could be configured to send an email message containing an IODEF message whenever an incident ticket was created, modified, or deleted. These IODEF messages would then be imported into other incident handling systems in order to allow participating CSIRTs to use their usual means for incident handling while still interacting with those using the proof-of-concept CIMS. Having an IODEF message generated for every change made to the incident information in RT (and for the system to allow incoming IODEF email messages to be associated to an existing incident) would in some way allow all participating CSIRTs to actually work on a "common incident ticket", at least at the conceptual level. this is such a big brain idea 🧚💖

Of particular importance was the ability for users to exchange information between each other concerning actions taken in the handling of a particular incident, thus creating a sort of common action log as well as requesting/tasking others to provide information or perform a specified action and correlating received responses to the original request or task. As well, a specific "profile" was developed to identify a subset of the IODEF classes that would be used during the exercise in an attempt to channel all users into a common usage pattern of the otherwise flexible IODEF standard. 🎀

6.2. Automated Incident Reporting - AirCERT 🦋

AirCERT ✨ was built by the CERT / Coordination Center (CC) of Carnegie Mellon's Software Engineering Institute CERT division. The goal was an Internet-scalable distributed system for sharing security event data, and honestly it's giving big-brain architecture 🧠. It was designed to be an automated collector of flow and Intrusion Detection System (IDS) alerts. AirCERT gathered all that info into a relational database and could share reports using IODEF and the Intrusion Detection Message Exchange Format [RFC4765]. It also used SNML [SNML] to exchange information about the network. The whole thing was written in a mix of C and Perl modules, and it had periodic graphing capabilities that leveraged the Round-Robin Database Tool (RRDTool) 📊💖.

AirCERT was meant for large-scale distributed deployment, and eventually it was supposed to be able to sanitize data before sharing it across administrative domains 🫶. The architecture let data be collected on a per-site basis, and each site could set up its own data sharing based on its own trust relationships. Main character energy for real 👑.

6.3. US Department of Energy CyberFed 🌈

The CyberFed system was implemented and deployed by Argonne National Laboratory to automate the detection and response of attack activity against Department of Energy (DoE) computer networks 💅. It automates the collection of network alerting activity from various perimeter network defenses and logs those events into its database. Then CyberFed automatically turns that information into blocking information and sends it out to all participants. The original implementation used IODEF messages wrapped in an XML extension to manage a large array of indicators. Lowkey genius. CyberFed wasn't really built to describe one particular incident. It was built to describe a set of current network-blocking indicators that can be generated and deployed machine to machine 🤖✨.

CyberFed is mostly implemented in Perl 🐪. It also includes scripts that interact with a large number of firewalls, IDS / Intrusion Prevention System (IPS) devices, DNS systems, and proxies, which handle both the automated collection of events and the automated deployment of black listing 🙈.

Right now, CyberFed supports multiple exchange formats, including IODEF and STIX. Open Indicators of Compromise (OpenIOC) is also a potential exchange format that the US DoE is considering 🍓.

7. Implementation Guide 🧚

This section is all about sharing tips for developing IODEF-capable systems 💜.

7.1. Code Generators

For implementing IODEF-capable systems, it's feasible to use code generators for the XML Schema Definition (XSD) 💅. These generators save development costs because they automatically create useful libraries for accessing XML attributes, composing messages, and/or validating XML objects. The IODEF XSD was defined in Section 8 of RFC 5070 [RFC5070] and is available from the "ns" registry <https://www.iana.org/assignments/xml-registry>.

Okay but there are still some issues 😭. Because the IODEF XSD is so complex, some code generators could not generate code from it at all. These are the code generators that were tested:

  • XML::Pastor [XSD:Perl] (Perl)
  • RXSD [XSD:Ruby] (Ruby)
  • PyXB [XSD:Python] (Python)
  • JAXB [XSD:Java] (Java)
  • CodeSynthesis XSD [XSD:Cxx] (C++)
  • Xsd.exe [XSD:CS] (C#)

For example, we tried XML::Pastor, but it couldn't properly understand the schema because the IODEF XSD is so complicated. The same thing happened with Ruby XSD (RXSD) and Java Architecture for XML Binding (JAXB). Only Python XML Schema Bindings (PyXB), CodeSynthesis XSD, and Xsd.exe were able to understand the complex schema 🥹.

There's no recommended workaround, unfortunately 💀. One possible workaround is a double conversion of the XSD file. The XSD gets serialized into XML first, and then that resulting XML is converted back into an XSD. The resulting XSD was processed successfully by all of the tools listed above ✨.

It's worth noting that IODEF uses '-' (hyphen) symbols in its classes or attributes, and those are listed here:

  • IODEF-Document Class: This is the top-level class in the IODEF data model described in Section 3.1 of RFC 5070 [RFC5070].
  • The vlan-name and vlan-num Attributes: According to Section 3.16.2 of RFC 5070 [RFC5070], these are the name and number of a Virtual LAN, and they are the attributes for the Address class.
  • Extending the Enumerated Values of Attribute: According to Section 5.1 of RFC 5070 [RFC5070], this is an extension technique for adding new enumerated values to an attribute. It uses an ext- prefix, for example ext-value, ext-category, ext-type, and so on 🎀.

Many programming languages prohibit '-' symbols in class names, which is a real vibe check 🙅‍♀️. Code generators need to replace or remove the '-' when building the libraries. They should have the namespace restore the '-' when outputting the XML along with the IODEF XSD 🦋.

7.2. iodeflib

iodeflib is an open source implementation written in Python 🐍💖. It gives you simple but powerful APIs to create, parse, and edit IODEF documents. It was designed to keep the interface as simple as possible, since generated libraries tend to inherit all the complexity of the IODEF XSD. The iodeflib interface also has functions that hide some unnecessarily nested structures of the IODEF schema and add more convenient shortcuts 🌸.

This tool is available through the following link:

<http://www.decalage.info/python/iodeflib>

7.3. iodefpm

IODEF.pm is an open source implementation written in Perl 🐪. It also gives you a simple interface for creating and parsing IODEF documents, which helps when translating the key-value-based format into the IODEF representation. The module includes a generic XML DTD parser and a simplified node-based representation of the IODEF DTD. Because of that, it can be easily upgraded or extended to support new XML nodes or other DTDs 🧠✨.

This tool is available through the following link:

<http://search.cpan.org/~saxjazman/>

7.4. Usability

Here are some tips to help you avoid problems 🫶:

  • IODEF has a category attribute for the NodeRole class. Even though there are various categories described, they aren't sufficient. For example, for webmail servers, should the user choose "www" or "mail"? One suggestion is to select "mail" as the category attribute and add "www" as another attribute 📧.
  • The numbering of incident IDs needs to be thought through 👀. Otherwise, information like the number of incidents within a certain period could be observed by document receivers. This is easily mitigated by randomizing the assignment of incident IDs 🎲💅.

8. IANA Considerations 🌷

This memo does not require any IANA actions 🙌.

9. Security Considerations 🔥

This document provides a summary of implementation reports from researchers and vendors who have implemented RFCs and drafts from the MILE and INCH working groups. There are no security considerations added because of the nature of the document 🛡️. (Tbh, that's the only thing that's low-key a relief 😌.)

10. Informative References 📚

[RFC4765]  Debar, H., Curry, D., and B. Feinstein, "The Intrusion
           Detection Message Exchange Format (IDMEF)", RFC 4765,
           DOI 10.17487/RFC4765, March 2007,
           <http://www.rfc-editor.org/info/rfc4765>.

[RFC5070]  Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
           Object Description Exchange Format", RFC 5070,
           DOI 10.17487/RFC5070, December 2007,
           <http://www.rfc-editor.org/info/rfc5070>.

[RFC5901]  Cain, P. and D. Jevans, "Extensions to the IODEF-Document
           Class for Reporting Phishing", RFC 5901,
           DOI 10.17487/RFC5901, July 2010,
           <http://www.rfc-editor.org/info/rfc5901>.

[RFC5941]  M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
           "Sharing Transaction Fraud Data", RFC 5941,
           DOI 10.17487/RFC5941, August 2010,
           <http://www.rfc-editor.org/info/rfc5941>.

[RFC6545]  Moriarty, K., "Real-time Inter-network Defense (RID)",
           RFC 6545, DOI 10.17487/RFC6545, April 2012,
           <http://www.rfc-editor.org/info/rfc6545>.

[RFC6546]  Trammell, B., "Transport of Real-time Inter-network
           Defense (RID) Messages over HTTP/TLS", RFC 6546,
           DOI 10.17487/RFC6546, April 2012,
           <http://www.rfc-editor.org/info/rfc6546>.

[RFC7203]  Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
           Incident Object Description Exchange Format (IODEF)
           Extension for Structured Cybersecurity Information",
           RFC 7203, DOI 10.17487/RFC7203, April 2014,
           <http://www.rfc-editor.org/info/rfc7203>.

[RFC7970]  Danyliw, R., "The Incident Object Description Exchange
           Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
           November 2016, <http://www.rfc-editor.org/info/rfc7970>.

[SNML]     Trammell, B., Danyliw, R., Levy, S., and A. Kompanek,
           "AirCERT: The Definitive Guide", 2005,
           <http://aircert.sourceforge.net/docs/
           aircert_manual-06_2005.pdf>.

[XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "XEP-0060:
           Publish-Subscribe", December 2016,
           <http://www.xmpp.org/extensions/xep-0060.html>.

[XEP-0268] Hefczy, A., Jensen, F., Remond, M., Saint-Andre, P., and
           M. Wild, "XEP-0268: Incident Handling", May 2012,
           <http://xmpp.org/extensions/xep-0268.html>.

[XSD:CS]   Microsoft, "XML Schema Definition Tool (Xsd.exe)",
           <http://www.microsoft.com/>.

[XSD:Cxx]  CodeSynthesis, "XSD: XML Data Binding for C++",
           <http://www.codesynthesis.com/>.

[XSD:Java] Project Kenai, "Project JAXB", <https://jaxb.java.net/>.

[XSD:Perl] Ulsoy, A., "XML-Pastor-1.0.4",
           <http://search.cpan.org/~aulusoy/XML-Pastor-1.0.4/>.

[XSD:Python]
           Bigot, P., "PyXB 1.2.5: Python XML Schema Bindings",
           <https://pypi.python.org/pypi/PyXB>.

[XSD:Ruby] Morsi, M., "XSD / Ruby Translator",
           <https://github.com/movitto/RXSD>.

Acknowledgements 💜

The MILE implementation report was compiled from submissions by implementers of INCH and MILE working group standards 🫶. Special thanks to the following contributors, who are absolutely iconic 👑:

  • John Atherton, Surevine
  • Humphrey Browning, Deep-Secure
  • Dario Forte, DFLabs
  • Tomas Sander, HP
  • Ulrich Seldeslachts, ACDC
  • Takeshi Takahashi, National Institute of Information and Communications Technology Network Security Research Institute
  • Kathleen Moriarty, EMC
  • Bernd Grobauer, Siemens
  • Dandurand Luc, NATO
  • Pawel Pawlinski, NASK

Authors' Addresses 🎀

Chris Inacio
Carnegie Mellon University
4500 5th Ave., SEI 4108
Pittsburgh, PA  15213
United States of America

Email: inacio@andrew.cmu.edu


Daisuke Miyamoto
The University of Tokyo
2-11-16 Yayoi, Bunkyo
Tokyo  113-8658
Japan

Email: daisu-mi@nc.u-tokyo.ac.jp
📦 where this page comes from