draft-ietf-mile-implementreport-10.txt   rfc8134.txt 
MILE C. Inacio Internet Engineering Task Force (IETF) C. Inacio
Internet-Draft CMU Request for Comments: 8134 CMU
Intended status: Informational D. Miyamoto Category: Informational D. Miyamoto
Expires: May 17, 2017 UTokyo ISSN: 2070-1721 UTokyo
November 13, 2016 May 2017
MILE Implementation Report Management Incident Lightweight Exchange (MILE) Implementation Report
draft-ietf-mile-implementreport-10
Abstract Abstract
This document is a collection of implementation reports from vendors, This document is a collection of implementation reports from vendors,
consortiums, and researchers who have implemented one or more of the consortiums, and researchers who have implemented one or more of the
standards published from the IETF INCident Handling (INCH) and standards published from the IETF INCident Handling (INCH) and
Management Incident Lightweight Exchange (MILE) working groups. Management Incident Lightweight Exchange (MILE) working groups.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on May 17, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8134.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Consortiums and Information Sharing and Analysis Centers 2. Consortiums and Information Sharing and Analysis Centers
(ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3 2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 4
2.2. Advanced Cyber Defence Centre . . . . . . . . . . . . . . 4 2.2. Advanced Cyber Defence Centre . . . . . . . . . . . . . . 4
2.3. Research and Education Networking Information Sharing and 2.3. Research and Education Networking Information Sharing and
Analysis Center . . . . . . . . . . . . . . . . . . . . . 4 Analysis Center . . . . . . . . . . . . . . . . . . . . . 4
3. Open Source Implementations . . . . . . . . . . . . . . . . . 4 3. Open Source Implementations . . . . . . . . . . . . . . . . . 4
3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . 4 3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . 4
3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . 4 3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . 5
3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 6 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 6
4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 6 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 7
4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 8 4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 8
4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 8 4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 8
5. Vendors with Planned Support . . . . . . . . . . . . . . . . 8 5. Vendors with Planned Support . . . . . . . . . . . . . . . . 9
5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 9 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 9
5.2. DAEDALUS, NICT . . . . . . . . . . . . . . . . . . . . . 9 5.2. DAEDALUS, NICT . . . . . . . . . . . . . . . . . . . . . 9
6. Other Implementations . . . . . . . . . . . . . . . . . . . . 9 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 10
6.1. Collaborative Incident Management System . . . . . . . . 9 6.1. Collaborative Incident Management System . . . . . . . . 10
6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 10 6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 10
6.3. US Department of Energy CyberFed . . . . . . . . . . . . 10 6.3. US Department of Energy CyberFed . . . . . . . . . . . . 11
7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 11 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 11
7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 11 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 11
7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 13 7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Informative References . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This draft is a collection of information about Security Incident This document is a collection of information about security incident
reporting protocols, and the implementation of systems that use them reporting protocols and the implementation of systems that use them
to share such information. It is simply a collection of information, to share such information. It is simply a collection of information,
it makes no attempt to compare the various standards or and it makes no attempt to compare the various standards or
implementations. As such, it will be of interest to Network implementations. As such, it will be of interest to network
Operators who wish to collect and share such data. operators who wish to collect and share such data.
Operationally, Operators would need to decide which incident data Operationally, operators would need to decide which incident data
collection group they want to be part of, that choice will strongly collection group they want to be part of, and that choice will
influence their choice of reporting protocol and applications to strongly influence their choice of reporting protocol and
gather and distribute the data. applications used to gather and distribute the data.
This document is a collection of implementation reports from vendors This document is a collection of implementation reports from vendors
and researchers who have implemented one or more of the standards and researchers who have implemented one or more of the standards
published from the INCH and MILE working groups. The standards published from the INCH and MILE working groups. The standards
include: include:
o Incident Object Description Exchange Format (IODEF) v1, RFC5070 o Incident Object Description Exchange Format (IODEF) v1 [RFC5070]
[RFC5070],
o Incident Object Description Exchange Format (IODEF) v2, o Incident Object Description Exchange Format (IODEF) v2 [RFC7970]
RFC5070-bis [RFC5070-bis],
o Extensions to the IODEF-Document Class for Reporting Phishing, o Extensions to the IODEF-Document Class for Reporting Phishing
RFC5901 [RFC5901], [RFC5901]
o Sharing Transaction Fraud Data, RFC5941 [RFC5941], o Sharing Transaction Fraud Data [RFC5941]
o Real-time Inter-network Defense (RID), RFC6545 [RFC6545], o Real-time Inter-network Defense (RID) [RFC6545]
o Transport of Real-time Inter-network Defense (RID) Messages over o Transport of Real-time Inter-network Defense (RID) Messages over
HTTP/TLS, RFC6546 [RFC6546], HTTP/TLS [RFC6546]
o Incident Object Description Exchange Format (IODEF) Extension for o Incident Object Description Exchange Format (IODEF) Extension for
Structured Cybersecurity Information (SCI), RFC7203 [RFC7203]. Structured Cybersecurity Information (SCI) [RFC7203]
The implementation reports included in this document have been The implementation reports included in this document have been
provided by the team or product responsible for the implementations provided by the team or product responsible for the implementations
of the mentioned RFCs. Additional submissions are welcome and should of the mentioned RFCs. A more complete list of implementations,
be sent to the draft editor. A more complete list of including open source efforts and vendor products, can also be found
implementations, including open source efforts and vendor products, at the following location:
can also be found at the following location:
http://siis.realmv6.org/implementations/ <http://siis.realmv6.org/implementations/>
2. Consortiums and Information Sharing and Analysis Centers (ISACs) 2. Consortiums and Information Sharing and Analysis Centers (ISACs)
2.1. Anti-Phishing Working Group 2.1. Anti-Phishing Working Group
The Anti-Phishing Working Group (APWG) is one of the biggest The Anti-Phishing Working Group (APWG) is one of the biggest
coalitions against cybercrime, especially phishing. In order to coalitions against cybercrime, especially phishing. In order to
collect threat information in a structured format, APWG provides a collect threat information in a structured format, APWG provides a
phishing and cybercrime reporting tool which sends threat information phishing and cybercrime reporting tool that sends threat information
to APWG by tailoring information with IODEF format, based on RFC5070 to APWG by tailoring information with the IODEF format, based on RFC
and RFC5901. 5070 [RFC5070] and RFC 5901 [RFC5901].
2.2. Advanced Cyber Defence Centre 2.2. Advanced Cyber Defence Centre
The Advanced Cyber Defense Centre (ACDC), is an European wide The Advanced Cyber Defence Centre (ACDC) is a Europe-wide activity to
activity to fight against botnets. ACDC provides solutions to fight against botnets. ACDC provides solutions to mitigate on-going
mitigate on-going attacks, as well as consolidating information attacks and consolidates information provided by various stakeholders
provided by various stakeholders into a pool of knowledge. Within into a pool of knowledge. Within ACDC, IODEF is one of the supported
ACDC, IODEF is one of the supported schema for exchanging the schemas for exchanging the information.
information.
2.3. Research and Education Networking Information Sharing and Analysis 2.3. Research and Education Networking Information Sharing and Analysis
Center Center
Research and Education Networking Information Sharing and Analysis The Research and Education Networking Information Sharing and
Center (REN-ISAC) is a private community of the research and higher Analysis Center (REN-ISAC) is a private community of researchers and
education members for sharing threat information, and employs IODEF higher-education members that share threat information and employs
formatted-messages to exchange information. IODEF formatted-messages to exchange information.
REN-ISAC also recommends using an IODEF attachment provided with a REN-ISAC also recommends using an IODEF attachment provided with a
notification email for processing rather than relying on parsing of notification email for processing rather than relying on parsing of
the email body text. The tools provided by REN-ISAC is designed to the body text of email. The tools provided by REN-ISAC are designed
handle such email. to handle such email.
http://www.ren-isac.net/notifications/using_iodef.html <http://www.ren-isac.net/notifications/using_iodef.html>
3. Open Source Implementations 3. Open Source Implementations
3.1. EMC/RSA RID Agent 3.1. EMC/RSA RID Agent
The EMC/RSA RID agent is an open source implementation of the IETF The EMC/RSA RID agent is an open source implementation of the IETF
standards for the exchange of incident and indicator data. The code standards for the exchange of incident and indicator data. The code
has been released under a MIT license and development will continue has been released under an MIT license, and development will continue
with the open source community at the Github site for RSA with the open source community at the GitHub site for RSA
Intelligence Sharing: Intelligence Sharing:
https://github.com/RSAIntelShare/RID-Server.git <https://github.com/RSAIntelShare/RID-Server.git>
The code implements the RFC6545, Real-time Inter-network Defense The code implements the Real-time Inter-network Defense (RID)
(RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code described in RFC 6545 [RFC6545] and the Transport of RID over HTTP/
supports the evolving RFC5070-bis Incident Object Description TLS protocol described in [RFC6546]. The code supports the evolving
Exchange Format (IODEF) data model from the work in the IETF working Incident Object Description Exchange Format (IODEF) data model
group Managed Incident Lightweight Exchange (MILE). [RFC7970] from the work in the IETF Managed Incident Lightweight
Exchange (MILE) working group.
3.2. NICT IODEF-SCI implementation 3.2. NICT IODEF-SCI implementation
Japan's National Institute of Information and Communications Japan's National Institute of Information and Communications
Technology (NICT) Network Security Research Institute implemented Technology (NICT) Network Security Research Institute implemented
open source tools for exchanging, accumulating, and locating IODEF- open source tools for exchanging, accumulating, and locating IODEF-
SCI (RFC7203, [RFC7203]documents. SCI [RFC7203] documents.
Three tools are available from GitHub. These tools assist the Three tools are available from GitHub. These tools assist the
exchange of IODEF-SCI documents between parties. IODEF-SCI is exchange of IODEF-SCI documents between parties. IODEF-SCI [RFC7203]
RFC7203 that extends IODEF so that IODEF document can embed extends IODEF so that an IODEF document can embed Structured
structured cybersecurity information (SCI). For instance, it can Cybersecurity Information (SCI). For instance, it can embed Malware
embed MMDEF, CEE, MAEC in XML and CVE identifiers. 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 generator, exchanger, and parser. The generator The three tools are generator, exchanger, and parser. The generator
generates IODEF-SCI documents or appends an XML to an existing IODEF generates IODEF-SCI documents or appends XML to an existing IODEF
document. The exchanger sends the IODEF document to a specified document. The exchanger sends the IODEF document to a specified
correspondent node. The parser receives, parses, and stores the correspondent node. The parser receives, parses, and stores the
IODEF-SCI document. The parser also creates an interface that IODEF-SCI document. The parser also creates an interface that
enables users to locate IODEF-SCI documents which have previously enables users to locate IODEF-SCI documents that have previously been
been received. The code has been released under a MIT license and received. The code has been released under an MIT license and
development will continue on GitHub. development will continue on GitHub.
Note that users can enjoy using this software at their own risk. Note that users can enjoy using this software at their own risk.
Available Online: Available Online:
https://github.com/TakeshiTakahashi/IODEF-SCI <https://github.com/TakeshiTakahashi/IODEF-SCI>
3.3. n6 3.3. n6
n6 is a platform for processing security-related information, n6 is a platform for processing security-related information; it was
developed by NASK (Poland Research and Academic Computer Network), developed by the Poland Research and Academic Computer Network (NASK)
Computer Emergency Response Team (CERT) Polska. The n6 API provides Computer Emergency Response Team (CERT) Polska. The n6 API provides
a common and unified way of representing data across the different a common and unified way of representing data across the different
sources that participate in knowledge management. sources that participate in knowledge management.
n6 exposes a REST-ful API over HTTPS with mandatory authentication n6 exposes a REST-ful (Representational State Transfer) API over
via TLS client certificates, to ensure confidential and trustworthy HTTPS with mandatory authentication via Transport Layer Security
(TLS) client certificates to ensure confidential and trustworthy
communications. Moreover, it uses an event-based data model for communications. Moreover, it uses an event-based data model for
representation of all types of security information. representation of all types of security information.
Each event is represented as a JSON object with a set of mandatory Each event is represented as a JSON object with a set of mandatory
and optional attributes. n6 also supports alternative output data and optional attributes. n6 also supports alternative output data
formats for keeping compatibility with existing systems - IODEF and formats for keeping compatibility with existing systems - IODEF and
CSV - although these formats lack some of the attributes that may be CSV - although these formats lack some of the attributes that may be
present in the native JSON format. present in the native JSON format.
Available Online: Available Online:
https://github.com/CERT-Polska/n6sdk <https://github.com/CERT-Polska/n6sdk>
4. Vendor Implementations 4. Vendor Implementations
4.1. Deep Secure 4.1. Deep Secure
Deep-Secure Guards are built to protect a trusted domain from: Deep-Secure Guards are built to protect a trusted domain from:
o Releasing sensitive data that does not meet the organisational o releasing sensitive data that does not meet the organizational
security policy security policy, and
o Applications receiving badly constructed or malicious data which o applications receiving badly constructed or malicious data that
could exploit a vulnerability (known or unknown) could exploit a vulnerability (known or unknown).
Deep-Secure Guards support HTTPS and XMPP (optimised server to server Deep-Secure Guards support HTTPS and the Extensible Messaging and
protocol) transports. The Deep-Secure Guards support transfer of XML Presence Protocol (XMPP -- optimized server-to-server protocol),
based business content by creating a schema to translate the known transports. The Deep-Secure Guards support transfer of XML-based
good content to and from the intermediate format. This means that business content by creating a schema to translate the known good
the Deep-Secure Guards can be used to protect: content to and from the intermediate format. This means that the
Deep-Secure Guards can be used to protect:
o IODEF/RID using the HTTPS transport binding (RFC6546) o IODEF/RID using the HTTPS transport binding [RFC6546]
o IODEF/RID using an XMPP binding o IODEF/RID using an XMPP binding
o ROLIE using HTTPS transport binding (XEP-0268, [XEP-0268]) o Resource-Oriented Lightweight Indicator Exchange (ROLIE) using
HTTPS transport binding [XEP-0268]
o STIX/TAXII using the HTTPS transport binding o 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 Deep-Secure Guards also support the SMTP transport and perform deep
content inspection of content including XML attachments. The Mail content inspection of content including XML attachments. The Mail
Guard supports S/MIME and Deep Secure is working on support for the Guard supports S/MIME, and Deep Secure is working on support for the
upcoming PLASMA standard which enables an information centric policy upcoming PLASMA standard, which enables an information-centric policy
enforcement of data use. enforcement of data use.
4.2. IncMan Suite, DFLabs 4.2. IncMan Suite, DFLabs
The Incident Object Description Exchange Format, documented in the The Incident Object Description Exchange Format, documented in RFC
RFC5070, defines a data representation that provides a framework for 5070 [RFC5070], defines a data representation that provides a
sharing information commonly exchanged by Computer Security Incident framework for sharing information commonly exchanged by Computer
Response Teams (CSIRTs) about computer security incidents. IncMan Security Incident Response Teams (CSIRTs) about computer security
Suite implements the IODEF standard for exchanging details about incidents. IncMan Suite implements the IODEF standard for exchanging
incidents, either for exporting or importing activities. This has details about incidents, either for exporting or importing
been introduced to enhance the capabilities of the various Computer activities. This has been introduced to enhance the capabilities of
Security Incident Response Teams (CSIRT), to facilitate collaboration the various CSIRTs to facilitate collaboration and sharing of useful
and sharing of useful experiences, sharing awareness on specific experiences (sharing awareness on specific cases).
cases.
The IODEF implementation is specified as an XML schema, therefore all 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 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 incident are organized in a hierarchical structure to describe the
various objects and their relationships. various objects and their relationships.
The IncMan Suite relies on IODEF as a transport format, composed by The IncMan Suite relies on IODEF as a transport format, which is
various classes for describing the entities which are part of the composed by various classes for describing the entities that are part
incident description. For instance the various relevant timestamps of the incident description. For instance, the various relevant
(detection time, start time, end time, and report time), the timestamps (detection time, start time, end time, and report time),
techniques used by the intruders to perpetrate the incident, the the techniques used by the intruders to perpetrate the incident, the
impact of the incident, technical and non-technical (time and impact of the incident, technical and non-technical (time and
monetary) and obviously all systems involved in the incident. monetary), and obviously all systems involved in the incident.
4.2.1. Exporting Incidents 4.2.1. Exporting Incidents
Each incident defined in the IncMan Suite can be exported via a User Each incident defined in the IncMan Suite can be exported via a user
Interface feature and it will create a xml document. Due to the interface feature, and it will create an XML document. Due to the
nature of the data processed, the IODEF extraction might be nature of the data processed, the IODEF extraction might be
considered privacy sensitive by the parties exchanging the considered privacy sensitive by the parties exchanging the
information or by those described by it. For this reason, specific information or by those described by it. For this reason, specific
care needs to be taken in ensuring the distribution to an appropriate care needs to be taken in ensuring the distribution to an appropriate
audience or third party, either during the document exchange and audience or third party, either during the document exchange or the
subsequent processing. subsequent processing.
The xml document generated will include description and details of The XML document generated will include a description and details of
the incident along with all the systems involved and the related the incident along with all the systems involved and the related
information. At this stage it can be distributed for import into a information. At this stage, it can be distributed for import into a
remote system. remote system.
4.2.2. Importing Incidents 4.2.2. Importing Incidents
The IncMan Suite provides the functionality to import incidents The IncMan Suite provides the functionality to import incidents
stored in files and transported via IODEF-compliant xml documents. stored in files and transported via IODEF-compliant XML documents.
The importing process comprises of two steps: first, the file is The importing process is comprised of two steps: first, the file is
inspected to validate if it is well formed, then all data are inspected to validate if it is well formed; second, all data are
uploaded inside the system. uploaded inside the system.
If the incident already exists in the system with the same incident 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 ID, the new one being imported will be created under a new ID. This
approach prevents accidentally overwriting existing info or merging approach prevents accidentally overwriting existing information or
inconsistent data. merging inconsistent data.
The IncMan Suite also includes a feature to upload incidents from The IncMan Suite also includes a feature to upload incidents from
emails. emails.
The incident, described in xml format, can be stored directly into The incident, described in XML format, can be stored directly into
the body of the email message or transported as an attachment of the the body of the email message or transported as an attachment of the
email. At regular intervals, customizable by the user, the IncMan email. At regular intervals that are customizable by the user, the
Suite monitors for incoming emails, filtered by a configurable white- IncMan Suite monitors for incoming emails, which are filtered by a
list and black-list mechanism on the sender's email account, then a configurable white-list and black-list mechanism on the sender's
parser processes the received email and a new incident is created email account. Then, a parser processes the received email and a new
automatically, after having validated the email body or the incident is created automatically after having validated the email
attachment to ensure it is well formed format. body or the attachment to ensure the format is well formed.
4.3. Surevine Proof of Concept 4.3. Surevine Proof of Concept
XMPP is enhanced and extended through the XMPP Extension Protocols XMPP is enhanced and extended through the XMPP Extension Protocols
(or XEPs). XEP-0268 [XEP-0268] describes incident management (using (XEPs). XEP-0268 [XEP-0268] describes incident management (using
IODEF) of the XMPP network itself, effectively supporting self- IODEF) of the XMPP network itself, effectively supporting self-
healing the XMPP network. In order to more generically cover the healing the XMPP network. In order to more generically cover the
incident management of a network over the same network, XEP-0268 incident management of a network over the same network, XEP-0268
requires some updates. We are working on these changes together with requires some updates. We are working on these changes together with
a new XEP that supports "social networking" over XMPP, enhancing the a new XEP that supports "social networking" over XMPP, which enhances
publish-and-subscribe XEP (XEP-0060 [XEP-0060]). This now allows the publish-and-subscribe XEP [XEP-0060]. This now allows nodes to
nodes to publish and subscribe to any type of content and therefore publish and subscribe to any type of content and therefore receive
receive the content. XEP-0060 will be used to describe IODEF the content. XEP-0060 will be used to describe IODEF content. We
content. We now have an alpha version of the server-side software now have an alpha version of the server-side software and client-side
and client-side software required to demonstrate the "social software required to demonstrate the "social networking" capability
networking" capability and are currently enhancing this to support and are currently enhancing this to support cyber incident management
Cyber Incident management in real-time. in real time.
4.4. MANTIS Cyber-Intelligence Management Framework 4.4. MANTIS Cyber-Intelligence Management Framework
MANTIS provides an example implementation of a framework for managing Model-based Analysis of Threat Intelligence Sources (MANTIS) provides
cyber threat intelligence expressed in standards such as STIX, CybOX, an example implementation of a framework for managing cyber threat
IODEF, etc. The aims of providing such an example implementation intelligence expressed in standards such as STIX, Cyber Observable
are: Expression (CybOX), IODEF, etc. The aims of providing such an
example implementation are as follows:
o To facilitate discussions about emerging standards such as STIX, o To facilitate discussions about emerging standards such as STIX,
CybOX et al. with respect to questions regarding tooling: how CybOX, et al., with respect to questions regarding tooling: how
would a certain aspect be implemented, how do changes affect an would a certain aspect be implemented, and how do changes affect
implementation? Such discussions become much easier and have a an implementation? Such discussions become much easier and have a
better basis if they can be lead in the context of example tooling better basis if they can be lead in the context of example tooling
that is known to the community. that is known to the community.
o To lower the barrier of entry for organizations and teams (esp. o To lower the barrier of entry for organizations and teams
CSIRT/CERT teams) in using emerging standards for cyber-threat (especially CSIRT/CERT teams) in using emerging standards for
intelligence management and exchange. cyber-threat-intelligence management and exchange.
o To provide a platform the basis of which research and community- o To provide a platform on the basis of which research and
driven development in the area of cyber-threat intelligence community-driven development in the area of cyber-threat-
management can occur. intelligence management can occur.
5. Vendors with Planned Support 5. Vendors with Planned Support
5.1. Threat Central, HP 5.1. Threat Central, HP
HP has developed HP Threat Central, a security intelligence platform HP has developed HP Threat Central, a security intelligence platform
that enables automated, real-time collaboration between organizations that enables automated, real-time collaboration between organizations
to combat today's increasingly sophisticated cyber attacks. One way to combat today's increasingly sophisticated cyber attacks. One way
automated sharing of threat indicators is achieved is through close automated sharing of threat indicators is achieved is through close
integration with the HP ArcSight SIEM for automated upload and integration with the HP ArcSight Security Information and Event
consumption of information from the Threat Central Server. In Management (SIEM) for automated upload and consumption of information
addition HP Threat Central supports open standards for sharing threat from the Threat Central Server. In addition, HP Threat Central
information so that participants who do not use HP Security Products supports open standards for sharing threat information so that
can participate in the sharing ecosystem. It is planned that future participants who do not use HP Security Products can participate in
versions also support IODEF for the automated upload and download of the sharing ecosystem. It is planned that future versions will also
threat information. support IODEF for the automated upload and download of threat
information.
5.2. DAEDALUS, NICT 5.2. DAEDALUS, NICT
DAEDALUS is a real-time alert system based on a large-scale darknet DAEDALUS is a real-time alert system based on a large-scale darknet
monitoring facility that has been deployed as a part of the nicter monitoring facility that has been deployed as a part of the Network
system of NICT, Japan. DAEDALUS consists of an analysis center Incident analysis Center for Tactical Emergency Response (nicter)
(i.e., nicter) and several cooperative organizations. Each system of NICT, which is based in Japan. DAEDALUS consists of an
organization installs a darknet sensor and establishes a secure analysis center (i.e., nicter) and several cooperative organizations.
channel between it and the analysis center, and continuously forwards Each organization installs a darknet sensor and establishes a secure
darknet traffic toward the center. In addition, each organization channel between it and the analysis center, and it continuously
registers the IP address range of its livenet at the center in forwards darknet traffic toward the center. In addition, each
advance. When these distributed darknet sensors observe malware organization registers the IP address range of its livenet at the
activities from the IP address of a cooperate organization, then the center in advance. When these distributed darknet sensors observe
analysis center sends an alert to the organization. The future malware activities from the IP address of a cooperating organization,
version of DAEDALUS will support IODEF for sending alert messages to then the analysis center sends an alert to the organization. The
the users. future version of DAEDALUS will support IODEF for sending alert
messages to the users.
6. Other Implementations 6. Other Implementations
6.1. Collaborative Incident Management System 6.1. Collaborative Incident Management System
Collaborative Incident Management System (CIMS) is a proof-of-concept A Collaborative Incident Management System (CIMS) is a proof-of-
system for collaborative incident handling and for the sharing of concept system for collaborative incident handling and for the
cyber defence situational awareness information between the sharing of information about cyber defense situational awareness
participants, developed for the Cyber Coalition 2013 (CC13) exercise between the participants; it was developed for the Cyber Coalition
organized by NATO. CIMS was implemented based on Request Tracker 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 (RT), an open source software widely used for handling incident
response by many CERTs and CSIRTs. responses by many CERTs and CSIRTs.
One of the functionality implemented in CIMS was the ability to One of the functionalities implemented in CIMS was the ability to
import and export IODEF messages in the body of emails. The intent import and export IODEF messages in the body of emails. The intent
was to verify the suitability of IODEF to achieve the objective of was to verify the suitability of IODEF to achieve the objective of
collaborative incident handling. The customized version of RT could collaborative incident handling. The customized version of RT could
be configured to send an email message containing an IODEF message be configured to send an email message containing an IODEF message
whenever an incident ticket was created, modified or deleted. These whenever an incident ticket was created, modified, or deleted. These
IODEF messages would then be imported into other incident handling IODEF messages would then be imported into other incident handling
systems in order to allow participating CSIRTs to use their usual systems in order to allow participating CSIRTs to use their usual
means for incident handling, while still interacting with those using means for incident handling while still interacting with those using
the proof-of-concept CIMS. Having an IODEF message generated for the proof-of-concept CIMS. Having an IODEF message generated for
every change made to the incident information in RT (and for the every change made to the incident information in RT (and for the
system to allow incoming IODEF email messages to be associated to an system to allow incoming IODEF email messages to be associated to an
existing incident) would in some way allow all participating CSIRTs existing incident) would in some way allow all participating CSIRTs
to actually work on a "common incident ticket", at least at the to actually work on a "common incident ticket", at least at the
conceptual level. Of particular importance was the ability for users conceptual level. Of particular importance was the ability for users
to exchange information between each other concerning actions taken to exchange information between each other concerning actions taken
in the handling of a particular incident, thus creating a sort of in the handling of a particular incident, thus creating a sort of
common action log, as well as requesting/tasking others to provide common action log as well as requesting/tasking others to provide
information or perform specified action and correlating received information or perform a specified action and correlating received
responses to the original request or tasking. As well, a specific responses to the original request or task. As well, a specific
"profile" was developed to identify a subset of the IODEF classes "profile" was developed to identify a subset of the IODEF classes
that would be used during the exercise, in an attempt to channel all that would be used during the exercise in an attempt to channel all
users into a common usage pattern of the otherwise flexible IODEF users into a common usage pattern of the otherwise flexible IODEF
standard. standard.
6.2. Automated Incident Reporting - AirCERT 6.2. Automated Incident Reporting - AirCERT
AirCERT was implemented by CERT/CC of Carnegie Mellon's Software AirCERT was implemented by the CERT / Coordination Center (CC) of
Engineering Institute CERT division. AirCERT was designed to be an Carnegie Mellon's Software Engineering Institute CERT division.
Internet-scalable distributed system for sharing security event data. AirCERT was designed to be an Internet-scalable distributed system
The AirCERT system was designed to be an automated collector of flow for sharing security event data. The AirCERT system was designed to
and IDS alerts. AirCERT would collect that information into a be an automated collector of flow and Intrusion Detection System
(IDS) alerts. AirCERT would collect that information into a
relational database and be able to share reporting using IODEF and relational database and be able to share reporting using IODEF and
Intrusion Detection Message Exchange Format (RFC4765, [RFC4765]). the Intrusion Detection Message Exchange Format [RFC4765]. AirCERT
AirCERT additionally used SNML [SNML] to exchange information about additionally used SNML [SNML] to exchange information about the
the network. AirCERT was implemented in a combination of C and Perl network. AirCERT was implemented in a combination of C and Perl
modules and included periodic graphing capabilities leveraging modules and included periodic graphing capabilities leveraging the
RRDTool. Round-Robin Database Tool (RRDTool).
AirCERT was intended for large scale distributed deployment and AirCERT was intended for large-scale distributed deployment and,
eventually the ability to sanitize data to be shared across eventually, the ability to sanitize data to be shared across
administrative domains. The architecture was designed to allow administrative domains. The architecture was designed to allow
collection of data at a per site basis and to allow each site to collection of data on a per-site basis and to allow each site to
create data sharing based on its own particular trust relationships. create data sharing based on its own particular trust relationships.
6.3. US Department of Energy CyberFed 6.3. US Department of Energy CyberFed
The CyberFed system was implemented and deployed by Argonne National The CyberFed system was implemented and deployed by Argonne National
Laboratory to automate the detection and response of attack activity Laboratory to automate the detection and response of attack activity
against Department of Energy (DoE) computer networks. CyberFed against Department of Energy (DoE) computer networks. CyberFed
automates the collection of network alerting activity from various automates the collection of network alerting activity from various
perimeter network defenses and logs those events into its database. perimeter network defenses and logs those events into its database.
CyberFed then automatically converts that information into blocking CyberFed then automatically converts that information into blocking
information transmitted to all participants. The original information transmitted to all participants. The original
implementation used IODEF messages wrapped in an XML extension to implementation used IODEF messages wrapped in an XML extension to
manage a large array of indicators. The CyberFed system was not manage a large array of indicators. The CyberFed system was not
designed to describe a particular incident as much as to describe a designed to describe a particular incident as much as to describe a
set of current network blocking indicators that can be generated and set of current network-blocking indicators that can be generated and
deployed machine-to-machine. deployed machine to machine.
CyberFed is primarily implemented in Perl. Included as part of the CyberFed is primarily implemented in Perl. Included as part of the
CyberFed system are scripts which interact with a large number of CyberFed system are scripts that interact with a large number of
firewalls, IDS/IPS devices, DNS systems, and proxies which operate to firewalls, IDS / Intrusion Prevention System (IPS) devices, DNS
implement both the automated collection of events as well as the systems, and proxies that operate to implement both the automated
automated deployment of black listing. collection of events as well as the automated deployment of black
listing.
Currently CyberFed supports multiple exchange formats including IODEF Currently, CyberFed supports multiple exchange formats including
and STIX. OpenIOC is also a potential exchange format that US DoE is IODEF and STIX. Open Indicators of Compromise (OpenIOC) is also a
considering. potential exchange format that the US DoE is considering.
7. Implementation Guide 7. Implementation Guide
The section aims at sharing the tips for development of IODEF-capable The section aims at sharing tips for development of IODEF-capable
systems. systems.
7.1. Code Generators 7.1. Code Generators
For implementing IODEF-capable systems, it is feasible to employ code For implementing IODEF-capable systems, it is feasible to employ code
generators for XML Schema Document (XSD). The generators are used to generators for the XML Schema Definition (XSD). The generators are
save development costs since they automatically create useful used to save development costs since they automatically create useful
libraries for accessing XML attributes, composing messages, and/or libraries for accessing XML attributes, composing messages, and/or
validating XML objects. The IODEF XSD was defined in section 8 of validating XML objects. The IODEF XSD was defined in Section 8 of
RFC5070, and is availabe at http://www.iana.org/assignments/xml- RFC 5070 [RFC5070] and is available from the "ns" registry
registry/schema/iodef-1.0.xsd. <https://www.iana.org/assignments/xml-registry>.
However, there still remains some issues. Due to the complexity of However, some issues remain. Due to the complexity of the IODEF XSD,
IODEF XSD, some code generators could not generate code from the XSD some code generators could not generate code from the XSD file. The
file. The tested code generators were as follows. tested code generators are as follows.
o XML::Pastor [XSD:Perl] (Perl) o XML::Pastor [XSD:Perl] (Perl)
o RXSD [XSD:Ruby] (Ruby) o RXSD [XSD:Ruby] (Ruby)
o PyXB [XSD:Python] (Python) o PyXB [XSD:Python] (Python)
o JAXB [XSD:Java] (Java) o JAXB [XSD:Java] (Java)
o CodeSynthesis XSD [XSD:Cxx] (C++) o CodeSynthesis XSD [XSD:Cxx] (C++)
skipping to change at page 12, line 4 skipping to change at page 12, line 23
o RXSD [XSD:Ruby] (Ruby) o RXSD [XSD:Ruby] (Ruby)
o PyXB [XSD:Python] (Python) o PyXB [XSD:Python] (Python)
o JAXB [XSD:Java] (Java) o JAXB [XSD:Java] (Java)
o CodeSynthesis XSD [XSD:Cxx] (C++) o CodeSynthesis XSD [XSD:Cxx] (C++)
o Xsd.exe [XSD:CS] (C#) o Xsd.exe [XSD:CS] (C#)
For instance, we have tried to use XML::Pastor, but it could not For instance, we have tried to use XML::Pastor, but it could not
properly understand its schema due to the complexity of IODEF XSD. properly understand its schema due to the complexity of IODEF XSD.
The same applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and The same applies to Ruby XSD (RXSD) and Java Architecture for XML
Xsd.exe were able to understand the complex schema. Binding (JAXB). Only Python XML Schema Bindings (PyXB),
CodeSynthesis XSD, and Xsd.exe were able to understand the complex
schema.
Unfortunately, there is no recommended workaround. A possible Unfortunately, there is no recommended workaround. A possible
workaround is a double conversion of XSD file. This entails the XSD workaround is a double conversion of the XSD file. This entails the
being serialized into XML, and afterwards the resulting XML is XSD being serialized into XML; afterwards, the resulting XML is
converted back into an XSD. The resultant XSD was successfully converted back into an XSD. The resultant XSD was successfully
processed by the all tools above. processed by all the tools listed above.
It should be noted that IODEF uses '-' (hyphen) symbols in its It should be noted that IODEF uses '-' (hyphen) symbols in its
classes or attributes, listed as follows. classes or attributes, which are listed as follows:
o IODEF-Document Class; it is the top level class in the IODEF data o IODEF-Document Class: It is the top-level class in the IODEF data
model described in section 3.1 of RFC5070. model described in Section 3.1 of RFC 5070 [RFC5070].
o The vlan-name and vlan-num Attribute; according to section 3.16.2 o The vlan-name and vlan-num Attributes: According to Section 3.16.2
of RFC5070, they are the name and number of Virtual LAN and are of RFC 5070 [RFC5070], they are the name and number of Virtual LAN
the attributes for Address class. and are the attributes for Address class.
o Extending the Enumerated Values of Attribute; according to section o Extending the Enumerated Values of Attribute: According to
5.1 of RFC5070, it is a extension techniques to add new enumerated Section 5.1 of RFC 5070 [RFC5070], this is an extension technique
values to an attribute, and has a prefix of "ext-", e.g., ext- to add new enumerated values to an attribute, and it has a prefix
value, ext-category, ext-type, and so on. of "ext-", e.g., ext-value, ext-category, ext-type, and so on.
According to the language specification, many programing language According to the language specification, many programming languages
prohibit having '-' symbols in the name of class. The code prohibit having '-' symbols in the name of class. The code
generators must replace or remove the '-' when building the generators must replace or remove the '-' when building the
librarlies. They should have the name space restore the '-' when libraries. They should have the name space restore the '-' when
outputting the XML along with IODEF XSD. outputting the XML along with IODEF XSD.
7.2. iodeflib 7.2. iodeflib
iodeflib is an open source implementation written in Python. This iodeflib is an open source implementation written in Python. This
provides simple but powerful APIs to create, parse and edit IODEF provides simple but powerful APIs to create, parse, and edit IODEF
documents. It was designed in order to keep its interface as simple documents. It was designed in order to keep its interface as simple
as possible, whereas generated libraries tend to inherit the as possible, whereas generated libraries tend to inherit the
complexity of IODEF XSD. In addition, the iodeflib interface complexity of IODEF XSD. In addition, the iodeflib interface
includes functions to hide some unnecessarily nested structures of includes functions to hide some unnecessarily nested structures of
the IODEF schema, and adding more convenient shortcuts. the IODEF schema and add more convenient shortcuts.
This tool is available through the following link: This tool is available through the following link:
http://www.decalage.info/python/iodeflib <http://www.decalage.info/python/iodeflib>
7.3. iodefpm 7.3. iodefpm
IODEF.pm is an open source implementation written in Perl. This also IODEF.pm is an open source implementation written in Perl. This also
provides a simple interface for creating and parsing IODEF documents, provides a simple interface for creating and parsing IODEF documents
in order to facilitate the translation of the a key-value based in order to facilitate the translation of the key-value-based format
format to the IODEF representation. The module contains a generic to the IODEF representation. The module contains a generic XML DTD
XML DTD parser and includes a simplified node based representation of parser and includes a simplified node-based representation of the
the IODEF DTD. It can hence easily be upgraded or extended to IODEF DTD. Hence, it can easily be upgraded or extended to support
support new XML nodes or other DTDs. new XML nodes or other DTDs.
This tool is available through the following link: This tool is available through the following link:
http://search.cpan.org/~saxjazman/ <http://search.cpan.org/~saxjazman/>
7.4. Usability 7.4. Usability
Here notes some tips to avoid problems. Some tips to avoid problems are noted here:
o IODEF has a category attribute for NodeRole class. Though various
categories are described, they are not sufficient. For example,
in the case of web mail servers, should the user choose "www" or
"mail". One suggestion is selecting "mail" as the category
attribute and adding "www" for another attirbute.
o The numbering of Incident ID needs to be considered. Otherwise,
information, such as the number of incidents within certain period
could be observed by document receivers. This is easily mitigated
by randomizing the assignment of incident IDs.
8. Acknowledgements
The MILE Implementation report has been compiled through the
submissions of implementers of INCH and MILE working group standards.
A special note of thanks to the following contributors:
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 o IODEF has a category attribute for the NodeRole class. Though
various categories are described, they are not sufficient. For
example, in the case of webmail servers, should the user choose
"www" or "mail"? One suggestion is to select "mail" as the
category attribute and add "www" for another attribute.
Pawel Pawlinski, NASK o The numbering of incident IDs needs to be considered. Otherwise,
information, such as 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.
9. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo does not require any IANA actions.
10. Security Considerations 9. Security Considerations
This draft provides a summary of implementation reports from This document provides a summary of implementation reports from
researchers and vendors who have implemented RFCs and drafts from the researchers and vendors who have implemented RFCs and drafts from the
MILE and INCH working groups. There are no security considerations MILE and INCH working groups. There are no security considerations
added in this draft because of the nature of the document. added because of the nature of the document.
11. Informative References 10. Informative References
[RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion [RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion
Detection Message Exchange Format (IDMEF)", RFC 4765, Detection Message Exchange Format (IDMEF)", RFC 4765,
DOI 10.17487/RFC4765, March 2007, DOI 10.17487/RFC4765, March 2007,
<http://www.rfc-editor.org/info/rfc4765>. <http://www.rfc-editor.org/info/rfc4765>.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
DOI 10.17487/RFC5070, December 2007, DOI 10.17487/RFC5070, December 2007,
<http://www.rfc-editor.org/info/rfc5070>. <http://www.rfc-editor.org/info/rfc5070>.
[RFC5070-bis]
Danyliw, R., "The Incident Object Description Exchange
Format v2", 2016, <https://datatracker.ietf.org/doc/draft-
ietf-mile-rfc5070-bis>.
[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
Class for Reporting Phishing", RFC 5901, Class for Reporting Phishing", RFC 5901,
DOI 10.17487/RFC5901, July 2010, DOI 10.17487/RFC5901, July 2010,
<http://www.rfc-editor.org/info/rfc5901>. <http://www.rfc-editor.org/info/rfc5901>.
[RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj, [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
"Sharing Transaction Fraud Data", RFC 5941, "Sharing Transaction Fraud Data", RFC 5941,
DOI 10.17487/RFC5941, August 2010, DOI 10.17487/RFC5941, August 2010,
<http://www.rfc-editor.org/info/rfc5941>. <http://www.rfc-editor.org/info/rfc5941>.
skipping to change at page 15, line 20 skipping to change at page 15, line 5
Defense (RID) Messages over HTTP/TLS", RFC 6546, Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012, DOI 10.17487/RFC6546, April 2012,
<http://www.rfc-editor.org/info/rfc6546>. <http://www.rfc-editor.org/info/rfc6546>.
[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An [RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
Incident Object Description Exchange Format (IODEF) Incident Object Description Exchange Format (IODEF)
Extension for Structured Cybersecurity Information", Extension for Structured Cybersecurity Information",
RFC 7203, DOI 10.17487/RFC7203, April 2014, RFC 7203, DOI 10.17487/RFC7203, April 2014,
<http://www.rfc-editor.org/info/rfc7203>. <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, [SNML] Trammell, B., Danyliw, R., Levy, S., and A. Kompanek,
"AirCERT: The Definitive Guide", 2005, "AirCERT: The Definitive Guide", 2005,
<http://aircert.sourceforge.net/docs/ <http://aircert.sourceforge.net/docs/
aircert_manual-06_2005.pdf>. aircert_manual-06_2005.pdf>.
[XEP-0060] [XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "XEP-0060:
Millard, P., Saint-Andre, P., and R. Meijer, "XEP-0060: Publish-Subscribe", December 2016,
Publish-Subscribe", 2016,
<http://www.xmpp.org/extensions/xep-0060.html>. <http://www.xmpp.org/extensions/xep-0060.html>.
[XEP-0268] [XEP-0268] Hefczy, A., Jensen, F., Remond, M., Saint-Andre, P., and
Hefczy, A., Jensen, F., Remond, M., Saint-Andre, P., and M. Wild, "XEP-0268: Incident Handling", May 2012,
M. Wild, "XEP-0268: Incident Handling", 2012,
<http://xmpp.org/extensions/xep-0268.html>. <http://xmpp.org/extensions/xep-0268.html>.
[XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)", [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
<http://www.microsoft.com/>. <http://www.microsoft.com/>.
[XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++", [XSD:Cxx] CodeSynthesis, "XSD: XML Data Binding for C++",
<http://www.codesynthesis.com/>. <http://www.codesynthesis.com/>.
[XSD:Java] [XSD:Java] Project Kenai, "Project JAXB", <https://jaxb.java.net/>.
Project Kenai, "JAXB Reference Implementation",
<https://jaxb.java.net/>.
[XSD:Perl] [XSD:Perl] Ulsoy, A., "XML-Pastor-1.0.4",
Ulsoy, A., "XML::Pastor",
<http://search.cpan.org/~aulusoy/XML-Pastor-1.0.4/>. <http://search.cpan.org/~aulusoy/XML-Pastor-1.0.4/>.
[XSD:Python] [XSD:Python]
Bigot, P., "PyXB: Python XML Schema Bindings", Bigot, P., "PyXB 1.2.5: Python XML Schema Bindings",
<https://pypi.python.org/pypi/PyXB>. <https://pypi.python.org/pypi/PyXB>.
[XSD:Ruby] [XSD:Ruby] Morsi, M., "XSD / Ruby Translator",
Morsi, M., "RXSD - XSD / Ruby Translator",
<https://github.com/movitto/RXSD>. <https://github.com/movitto/RXSD>.
Acknowledgements
The MILE implementation report has been compiled through the
submissions of implementers of INCH and MILE working group standards.
A special note of thanks to the following contributors:
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 Authors' Addresses
Chris Inacio Chris Inacio
Carnegie Mellon University Carnegie Mellon University
4500 5th Ave., SEI 4108 4500 5th Ave., SEI 4108
Pittsburgh, PA 15213 Pittsburgh, PA 15213
US United States of America
Email: inacio@andrew.cmu.edu Email: inacio@andrew.cmu.edu
Daisuke Miyamoto Daisuke Miyamoto
The Univerisity of Tokyo The University of Tokyo
2-11-16 Yayoi, Bunkyo 2-11-16 Yayoi, Bunkyo
Tokyo 113-8658 Tokyo 113-8658
JP Japan
Email: daisu-mi@nc.u-tokyo.ac.jp Email: daisu-mi@nc.u-tokyo.ac.jp
 End of changes. 126 change blocks. 
323 lines changed or deleted 328 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/