draft-ietf-mile-implementreport-09.txt   draft-ietf-mile-implementreport-10.txt 
MILE C. Inacio MILE C. Inacio
Internet-Draft CMU Internet-Draft CMU
Intended status: Informational D. Miyamoto Intended status: Informational D. Miyamoto
Expires: December 9, 2016 UTokyo Expires: May 17, 2017 UTokyo
June 7, 2016 November 13, 2016
MILE Implementation Report MILE Implementation Report
draft-ietf-mile-implementreport-09 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2016. This Internet-Draft will expire on May 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Consortiums and Information Sharing and Analysis Centers 2. Consortiums and Information Sharing and Analysis Centers
(ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3 2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3
2.2. Advanced Cyber Defence Centre . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . 4
3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 5 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 6
4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 6 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 6
4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 8
5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 8 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 9
5.2. DAEDALUS, NICT . . . . . . . . . . . . . . . . . . . . . 8 5.2. DAEDALUS, NICT . . . . . . . . . . . . . . . . . . . . . 9
6. Other Implementations . . . . . . . . . . . . . . . . . . . . 9 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 9
6.1. Collaborative Incident Management System . . . . . . . . 9 6.1. Collaborative Incident Management System . . . . . . . . 9
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 . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . 14 11. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This draft is a collection of information about Security Incident
reporting protocols, and the implementation of systems that use them
to share such information. It is simply a collection of information,
it makes no attempt to compare the various standards or
implementations. As such, it will be of interest to Network
Operators who wish to collect and share such data.
Operationally, Operators would need to decide which incident data
collection group they want to be part of, that choice will strongly
influence their choice of reporting protocol and applications 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], [RFC5070],
o Incident Object Description Exchange Format (IODEF) v2, o Incident Object Description Exchange Format (IODEF) v2,
RFC5070-bis, 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 [RFC5901],
o Sharing Transaction Fraud Data, RFC5941 [RFC5941], o Sharing Transaction Fraud Data, RFC5941 [RFC5941],
o Real-time Inter-network Defense (RID), RFC6545 [RFC6545], o Real-time Inter-network Defense (RID), RFC6545 [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 [RFC6546],
o Incident Object Description Exchange Format (IODEF) Extension for o Incident Object Description Exchange Format (IODEF) Extension for
Structured Cybersecurity Information, RFC7203 [RFC7203]. Structured Cybersecurity Information (SCI), RFC7203 [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. Additional submissions are welcome and should
be sent to the draft editor. A more complete list of be sent to the draft editor. A more complete list of
implementations, including open source efforts and vendor products, implementations, including open source efforts and vendor products,
can also be found 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
Anti-Phishing Working Group (APWG) is one of the biggest coalition The Anti-Phishing Working Group (APWG) is one of the biggest
against cybercrime, especially phishing. In order to collect threat coalitions against cybercrime, especially phishing. In order to
information in a structured format, APWG provides a phishing and collect threat information in a structured format, APWG provides a
cybercrime reporting tool which sends threat information to APWG by phishing and cybercrime reporting tool which sends threat information
tailoring information with IODEF format, based on RFC5070 and to APWG by tailoring information with IODEF format, based on RFC5070
RFC5901. and RFC5901.
2.2. Advanced Cyber Defence Centre 2.2. Advanced Cyber Defence Centre
The Advanced Cyber Defense Centre (ACDC), is EU-wide activity to The Advanced Cyber Defense Centre (ACDC), is an European wide
fight against botnets. ACDC provides a solutions to mitigate on- activity to fight against botnets. ACDC provides solutions to
going attacks, as well as consolidating information provided by mitigate on-going attacks, as well as consolidating information
various stakeholders into a pool of knowledge. Within ACDC, IODEF is provided by various stakeholders into a pool of knowledge. Within
one of the supported schema for exchanging the information. ACDC, IODEF is one of the supported schema for exchanging the
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 Research and Education Networking Information Sharing and Analysis
Center (REN-ISAC) is a private community of the research and higher Center (REN-ISAC) is a private community of the research and higher
education members for sharing threat information, and employs IODEF education members for sharing threat information, and employs IODEF
formatted-message to exchange information. formatted-messages to exchange information.
REN-ISAC also recommends to use 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 interface provided by REN-ISAC are designed the email body text. The tools provided by REN-ISAC is designed to
to handle such email. 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 an MIT license and development will continue has been released under a 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 RFC6545, Real-time Inter-network Defense
(RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code
supports the evolving RFC5070-bis Incident Object Description supports the evolving RFC5070-bis Incident Object Description
Exchange Format (IODEF) data model from the work in the IETF working Exchange Format (IODEF) data model from the work in the IETF working
group Managed Incident Lightweight Exchange (MILE). group Managed Incident Lightweight Exchange (MILE).
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 documents. SCI (RFC7203, [RFC7203]documents.
Three tools are available in GitHub. They assist the exchange of Three tools are available from GitHub. These tools assist the
IODEF-SCI documents between parties. IODEF-SCI is the IETF draft exchange of IODEF-SCI documents between parties. IODEF-SCI is
that extends IODEF so that IODEF document can embed structured RFC7203 that extends IODEF so that IODEF document can embed
cybersecurity information (SCI). For instance, it can embed MMDEF, structured cybersecurity information (SCI). For instance, it can
CEE, MAEC in XML and CVE identifiers. embed MMDEF, CEE, MAEC in XML and 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 document or appends an XML to existing IODEF generates IODEF-SCI documents or appends an XML to an existing IODEF
document. The exchanger sends the IODEF document to its 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. It also equips the interface that enable users IODEF-SCI document. The parser also creates an interface that
to locate IODEF-SCI documents it has ever received. The code has enables users to locate IODEF-SCI documents which have previously
been released under an MIT license and development will continue been received. The code has been released under a MIT license and
here. development will continue on GitHub.
Note that users can enjoy this software with their own Note that users can enjoy using this software at their own risk.
responsibility.
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,
developed by NASK, CERT Polska. Its API provides a common and developed by NASK (Poland Research and Academic Computer Network),
unified way of representing data across the different sources that Computer Emergency Response Team (CERT) Polska. The n6 API provides
participate in knowledge management. a common and unified way of representing data across the different
sources that participate in knowledge management.
n6 exposes a REST-ful API over HTTPS with mandatory authentication n6 exposes a REST-ful API over HTTPS with mandatory authentication
via TLS client certificates, to ensure confidential and trustworthy via 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. It 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 they lack some of the attributes that may be present CSV - although these formats lack some of the attributes that may be
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 organisational
security policy security policy
o applications receiving badly constructed or malicious data which o Applications receiving badly constructed or malicious data which
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 XMPP (optimised server to server
protocol) transports. The Deep-Secure Guards support transfer of XML protocol) transports. The Deep-Secure Guards support transfer of XML
based business content by creating a schema to translate the known based business content by creating a schema to translate the known
good content to and from the intermediate format. This means that good content to and from the intermediate format. This means that
the Deep-Secure Guards can be used to protect: 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 (draft-field-mile-rolie-02) o ROLIE using HTTPS transport binding (XEP-0268, [XEP-0268])
o STIX/TAXII using the HTTPS transport binding o STIX/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 are working on support for the Guard supports S/MIME and Deep Secure is working on support for the
upcoming PLASMA standard which enables information centric policy upcoming PLASMA standard which enables an information centric policy
enforcement of data. 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 the
RFC5070, defines a data representation that provides a framework for RFC5070, defines a data representation that provides a framework for
sharing information commonly exchanged by Computer Security Incident sharing information commonly exchanged by Computer Security Incident
Response Teams (CSIRTs) about computer security incidents. IncMan Response Teams (CSIRTs) about computer security incidents. IncMan
Suite implements the IODEF standard for exchanging details about Suite implements the IODEF standard for exchanging details about
incidents, either for exporting and importing activities. This has incidents, either for exporting or importing activities. This has
been introduced to enhance the capabilities of the various CSIRT, to been introduced to enhance the capabilities of the various Computer
facilitate collaboration and sharing of useful experiences, conveying Security Incident Response Teams (CSIRT), to facilitate collaboration
awareness on specific cases. and sharing of useful experiences, sharing awareness on specific
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 data of an incident data are stored in an xml file; in this file all the data of an
are organized in a hierarchical structure to describe the various incident are organized in a hierarchical structure to describe the
objects and their relationships. various objects and their relationships.
IncMan Suite relies on IODEF as a transport format, composed by The IncMan Suite relies on IODEF as a transport format, composed by
various classes for describing the entities which are part of the various classes for describing the entities which are part of the
incident description: for instance the various relevant timestamps incident description. For instance the various relevant timestamps
(detect time , start time, end time, report time), the techniques (detection time, start time, end time, and report time), the
used by the intruders to perpetrate the incident, the impact of the techniques used by the intruders to perpetrate the incident, the
incident, either technical and non-technical (time and monetary) and impact of the incident, technical and non-technical (time 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 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 populate an xml document. Due to the Interface feature and it will create a 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 and
subsequent processing. subsequent processing.
The xml document generated will include description and details of The xml document generated will include 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
IncMan Suite provides a functionality to import incidents stored in The IncMan Suite provides the functionality to import incidents
files and transported via IODEF-compliant xml documents. The stored in files and transported via IODEF-compliant xml documents.
importing process comprises of two steps: firstly, the file is The importing process comprises of two steps: first, the file is
inspected to validate if well formed, then all data are uploaded inspected to validate if it is well formed, then all data are
inside the system. uploaded inside the system.
If an incident is already existing in the system with the same If the incident already exists in the system with the same incident
incident id, the new one being imported will be created under a new id, the new one being imported will be created under a new id. This
id. This approach prevents from accidentally overwriting existing approach prevents accidentally overwriting existing info or merging
info or merging inconsistent data. inconsistent data.
IncMan Suite includes also a feature to upload incidents from emails. The IncMan Suite also includes a feature to upload incidents from
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, IncMan Suite email. At regular intervals, customizable by the user, the IncMan
monitors for incoming emails, filtered by a configurable white-list Suite monitors for incoming emails, filtered by a configurable white-
and black-list mechanism on the sender's email account, then a parser list and black-list mechanism on the sender's email account, then a
processes the received email and a new incident is created parser processes the received email and a new incident is created
automatically, after having validated the email body or the automatically, after having validated the email body or the
attachment to ensure it is a well formed format. attachment to ensure it is well formed format.
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 (http://xmpp.org/extensions/xep-0268.html) (or XEPs). XEP-0268 [XEP-0268] describes incident management (using
describes incident management (using IODEF) of the XMPP network IODEF) of the XMPP network itself, effectively supporting self-
itself, effectively supporting self-healing the XMPP network. In healing the XMPP network. In order to more generically cover the
order to more generically cover incident management of a network and incident management of a network over the same network, XEP-0268
over a network, XEP-0268 requires some updates. We are working on requires some updates. We are working on these changes together with
these changes together with a new XEP that supports "social a new XEP that supports "social networking" over XMPP, enhancing the
networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP- publish-and-subscribe XEP (XEP-0060 [XEP-0060]). This now allows
0060). This now allows nodes to publish any type of content and nodes to publish and subscribe to any type of content and therefore
subscribe to and therefore receive the content. XEP-0268 will be receive the content. XEP-0060 will be used to describe IODEF
used to describe IODEF content. We now have an alpha version of the content. We now have an alpha version of the server-side software
server-side software and client-side software required to demonstrate and client-side software required to demonstrate the "social
the "social networking" capability and are currently enhancing this networking" capability and are currently enhancing this to support
to support Cyber Incident management in real-time. Cyber Incident management 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 MANTIS provides an example implementation of a framework for managing
cyber threat intelligence expressed in standards such as STIX, CybOX, cyber threat intelligence expressed in standards such as STIX, CybOX,
IODEF, etc. The aims of providing such an example implementation IODEF, etc. The aims of providing such an example implementation
are: are:
o To aide discussions about emerging standards such as STIX, CybOX o To facilitate discussions about emerging standards such as STIX,
et al. with respect to questions regarding tooling: how would a CybOX et al. with respect to questions regarding tooling: how
certain aspect be implemented, how do changes affect an would a certain aspect be implemented, how do changes affect an
implementation? Such discussions become much easier and have a 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 entrance barrier for organizations and teams (esp. o To lower the barrier of entry for organizations and teams (esp.
CERT teams) in using emerging standards for cyber-threat CSIRT/CERT teams) in using emerging standards for cyber-threat
intelligence management and exchange. intelligence management and exchange.
o To provide a platform on the basis of which research and o To provide a platform the basis of which research and community-
community-driven development in the area of cyber-threat driven development in the area of cyber-threat intelligence
intelligence management can occur. 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 SIEM for automated upload and
consumption of information from the Threat Central Server. In consumption of information from the Threat Central Server. In
addition HP Threat Central supports open standards for sharing threat addition HP Threat Central supports open standards for sharing threat
information so that participants who do not use HP Security Products information so that participants who do not use HP Security Products
skipping to change at page 8, line 39 skipping to change at page 9, line 14
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 SIEM for automated upload and
consumption of information from the Threat Central Server. In consumption of information from the Threat Central Server. In
addition HP Threat Central supports open standards for sharing threat addition HP Threat Central supports open standards for sharing threat
information so that participants who do not use HP Security Products information so that participants who do not use HP Security Products
can participate in the sharing ecosystem. General availability of can participate in the sharing ecosystem. It is planned that future
Threat Central will be in 2014. It is planned that future versions versions also support IODEF for the automated upload and download of
also support IODEF for the automated upload and download of threat threat information.
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 nicter
system of NICT, Japan. DAEDALUS consists of an analysis center system of NICT, Japan. DAEDALUS consists of an analysis center
(i.e., nicter) and several cooperate organizations. Each (i.e., nicter) and several cooperative organizations. Each
organization installs a darknet sensor and establishes a secure organization installs a darknet sensor and establishes a secure
channel between it and the analysis center, and continuously forwards channel between it and the analysis center, and continuously forwards
darknet traffic toward the center. In addition, each organization darknet traffic toward the center. In addition, each organization
registers the IP address range of its livenet at the center in registers the IP address range of its livenet at the center in
advance. When these distributed darknet sensors observe malware advance. When these distributed darknet sensors observe malware
activities from the IP address of a cooperate organization, then the activities from the IP address of a cooperate organization, then the
analysis center sends an alert to the organization. The future analysis center sends an alert to the organization. The future
version of DAEDALUS will support IODEF for sending alert messages to version of DAEDALUS will support IODEF for sending alert messages to
the users. the users.
skipping to change at page 10, line 14 skipping to change at page 10, line 32
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 CERT/CC of Carnegie Mellon's Software
Engineering Institute CERT division. AirCERT was designed to be an Engineering Institute CERT division. AirCERT was designed to be an
Internet-scalable distributed system for sharing security event data. Internet-scalable distributed system for sharing security event data.
The AirCERT system was designed to be an automated collector of flow The AirCERT system was designed to be an automated collector of flow
and IDS alerts. AirCERT would collect that information into a and 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]). Intrusion Detection Message Exchange Format (RFC4765, [RFC4765]).
AirCERT additionally used Simple Network Markup Language [SNML] to AirCERT additionally used SNML [SNML] to exchange information about
exchange information about the network. AirCERT was implemented in a the network. AirCERT was implemented in a combination of C and Perl
combination of C and perl modules and included periodic graphing modules and included periodic graphing capabilities leveraging
capabilities leveraging RRDTool. 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 at 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
skipping to change at page 10, line 44 skipping to change at page 11, line 14
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 which interact with a large number of
firewalls, IDS/IPS devices, DNS systems, and proxies which operate to firewalls, IDS/IPS devices, DNS systems, and proxies which operate to
implement both the automated collection of events as well as the implement both the automated collection of events as well as the
automated deployment of blacking. automated deployment of black listing.
Currently CyberFed supports multiple exchange formats including IODEF Currently CyberFed supports multiple exchange formats including IODEF
and STIX. OpenIOC is also a potential exchange format that DoE is and STIX. OpenIOC is also a potential exchange format that US DoE is
considering. considering.
7. Implementation Guide 7. Implementation Guide
The section aims at sharing the tips for development of IODEF-capable The section aims at sharing the 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 XML Schema Document (XSD). The generators are used to
save development costs since they automatically create useful 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- RFC5070, and is availabe at http://www.iana.org/assignments/xml-
registry/schema/iodef-1.0.xsd. registry/schema/iodef-1.0.xsd.
However, there still remains some problem. Due to the complexity of However, there still remains some issues. Due to the complexity of
IODEF XSD, some code generators could not generate from the XSD file. IODEF XSD, some code generators could not generate code from the XSD
The tested code generators were as follows. file. The tested code generators were 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++)
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
properly understand its schema due to the complexity of IODEF XSD.
The same applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and
Xsd.exe were able to understand the complex schema.
For instance, we have used XML::Pastor, but it could not properly Unfortunately, there is no recommended workaround. A possible
understand its schema due to the complexity of IODEF XSD. The same workaround is a double conversion of XSD file. This entails the XSD
applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and Xsd.exe being serialized into XML, and afterwards the resulting XML is
were able to understand the schema. converted back into an XSD. The resultant XSD was successfully
processed by the all tools above.
There is no recommended workaround, however, a double conversion of
XSD file is one option to go through the situation; it means XSD is
serialized to XML, and it is again converted to XSD. The resultant
XSD was process-able by the all tools 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, 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 RFC5070.
o The vlan-name and vlan-num Attribute; according to section 3.16.2 o The vlan-name and vlan-num Attribute; according to section 3.16.2
of RFC5070, they are the name and number of Virtual LAN and are of RFC5070, they are the name and number of Virtual LAN and are
the attributes for Address class. the attributes for Address class.
o Extending the Enumerated Values of Attribute; according to section o Extending the Enumerated Values of Attribute; according to section
5.1 of RFC5070, it is a extension techniques to add new enumerated 5.1 of RFC5070, it is a extension techniques to add new enumerated
values to an attribute, and has a prefix of "ext-", e.g., ext- values to an attribute, and has a prefix of "ext-", e.g., ext-
value, ext-category, ext-type, and so on. value, ext-category, ext-type, and so on.
According to the language specification, many programing language According to the language specification, many programing language
prohibit to contain '-' symbols in the name of class. The code prohibit having '-' symbols in the name of class. The code
generators must replace or remove '-' when building the librarlies. generators must replace or remove the '-' when building the
They should have the name space to restore '-' when outputting the librarlies. They should have the name space restore the '-' when
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 a 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. As well as the interface, iodeflib involves complexity of IODEF XSD. In addition, the iodeflib interface
functions of hiding some unnecessarily nested structures of the IODEF includes functions to hide some unnecessarily nested structures of
schema, and adding more convenient shortcuts. the IODEF schema, and adding 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 a key-value based
skipping to change at page 13, line 5 skipping to change at page 13, line 23
support new XML nodes or other DTDs. support 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. Here notes some tips to avoid problems.
o IODEF has category attribute for NodeRole class. Though various o IODEF has a category attribute for NodeRole class. Though various
categories are described, they are not enough. For example, in categories are described, they are not sufficient. For example,
the case of web mail servers, you should choose either "www" or in the case of web mail servers, should the user choose "www" or
"mail". One suggestion is selecting "mail" as the category "mail". One suggestion is selecting "mail" as the category
attribute and adding "www" for another attirbute. attribute and adding "www" for another attirbute.
o The numbering of Incident ID needs to be considered. Otherwise, o The numbering of Incident ID needs to be considered. Otherwise,
information, such as the number of incidents within certain period information, such as the number of incidents within certain period
could be observed by document receivers. For instance, we could could be observed by document receivers. This is easily mitigated
randomize the assignment of the numbers. by randomizing the assignment of incident IDs.
8. Acknowledgements 8. Acknowledgements
The MILE Implementation report has been compiled through the The MILE Implementation report has been compiled through the
submissions of implementers of INCH and MILE working group standards. submissions of implementers of INCH and MILE working group standards.
A special note of thanks to the following contributors: A special note of thanks to the following contributors:
John Atherton, Surevine John Atherton, Surevine
Humphrey Browning, Deep-Secure Humphrey Browning, Deep-Secure
skipping to change at page 14, line 17 skipping to change at page 14, line 35
[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 14, line 47 skipping to change at page 15, line 25
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>.
[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]
Millard, P., Saint-Andre, P., and R. Meijer, "XEP-0060:
Publish-Subscribe", 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", 2012,
<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, "JAXB Reference Implementation", Project Kenai, "JAXB Reference Implementation",
<https://jaxb.java.net/>. <https://jaxb.java.net/>.
 End of changes. 63 change blocks. 
148 lines changed or deleted 177 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/