draft-ietf-mile-implementreport-05.txt   draft-ietf-mile-implementreport-06.txt 
MILE C. Inacio MILE C. Inacio
Internet-Draft CMU Internet-Draft CMU
Intended status: Informational D. Miyamoto Intended status: Informational D. Miyamoto
Expires: January 6, 2016 UTokyo Expires: April 20, 2016 UTokyo
July 5, 2015 October 18, 2015
MILE Implementation Report MILE Implementation Report
draft-ietf-mile-implementreport-05 draft-ietf-mile-implementreport-06
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 January 6, 2016. This Internet-Draft will expire on April 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . 5
4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 9 6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 10
6.3. US Department of Energy CyberFed . . . . . . . . . . . . 10 6.3. US Department of Energy CyberFed . . . . . . . . . . . . 10
6.4. TrendMicro Sharing System . . . . . . . . . . . . . . . . 10 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 11
7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 10 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 11
7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 10
7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Informative References . . . . . . . . . . . . . . . . . . . 13 11. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
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,
skipping to change at page 4, line 13 skipping to change at page 4, line 13
one of the supported schema for exchanging the information. 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 fro sharing threat information, and employs IODEF education members fro sharing threat information, and employs IODEF
formatted-message to exchange information. formatted-message to exchange information.
REN-ISAC also recommends to ues of the IODEF attachment provided with REN-ISAC also recommends to use of the IODEF attachment provided with
the notification email be processed rather than relying on parsing of the notification email be processed rather than relying on parsing of
the email body text. The interface provided by REN-ISAC are designed the email body text. The interface provided by REN-ISAC are designed
for dealing with such email. for dealing with 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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
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. General availability of
Threat Central will be in 2014. It is planned that future versions Threat Central will be in 2014. It is planned that future versions
also support IODEF for the automated upload and download of threat also support IODEF for the automated upload and download of threat
information. information.
5.2. DAEDALUS, NICT
DAEDALUS is a real-time alert system based on a large-scale darknet
monitoring facility that has been deployed as a part of the nicter
system of NICT, Japan. DAEDALUS consists of an analysis center
(i.e., nicter) and several cooperate organizations. Each
organization installs a darknet sensor and establishes a secure
channel between it and the analysis center, and continuously forwards
darknet traffic toward the center. In addition, each organization
registers the IP address range of its livenet at the center in
advance. When these distributed darknet sensors observe malware
activities from the IP address of a cooperate organization, then the
analysis center sends an alert to the organization. The future
version of DAEDALUS will support IODEF for sending alert messages to
the users.
6. Other Implementations 6. Other Implementations
6.1. Collaborative Incident Management System 6.1. Collaborative Incident Management System
Collaborative Incident Management System (CIMS) is a proof-of-concept Collaborative Incident Management System (CIMS) is a proof-of-concept
system for collaborative incident handling and for the sharing of system for collaborative incident handling and for the sharing of
cyber defence situational awareness information between the cyber defence situational awareness information between the
participants, developed for the Cyber Coalition 2013 (CC13) exercise participants, developed for the Cyber Coalition 2013 (CC13) exercise
organized by NATO. CIMS was implemented based on Request Tracker organized by 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
skipping to change at page 9, line 45 skipping to change at page 10, line 12
information or perform specified action and correlating received information or perform specified action and correlating received
responses to the original request or tasking. As well, a specific responses to the original request or tasking. 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 CERT/CC of Carnegie Mellon's Software
Engineering Institute CERT divison. 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
IDMEF. AirCERT additionally used SNML to exchange information about IDMEF. AirCERT additionally used SNML to exchange information about
the network. AirCERT was implemented in a combination of C and perl the 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
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 desgined 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
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 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 blacking.
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 DoE is
considering. considering.
6.4. TrendMicro Sharing System
More information to come.
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
skipping to change at page 13, line 46 skipping to change at page 14, line 8
10. Security Considerations 10. Security Considerations
This draft provides a summary of implementation reports from This draft 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 in this draft because of the nature of the document.
11. Informative References 11. Informative References
[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, December Object Description Exchange Format", RFC 5070,
2007. DOI 10.17487/RFC5070, December 2007,
<http://www.rfc-editor.org/info/rfc5070>.
[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, July 2010. Class for Reporting Phishing", RFC 5901,
DOI 10.17487/RFC5901, July 2010,
<http://www.rfc-editor.org/info/rfc5901>.
[RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj, [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
"Sharing Transaction Fraud Data", RFC 5941, August 2010. "Sharing Transaction Fraud Data", RFC 5941,
DOI 10.17487/RFC5941, August 2010,
<http://www.rfc-editor.org/info/rfc5941>.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
6545, April 2012. RFC 6545, DOI 10.17487/RFC6545, April 2012,
<http://www.rfc-editor.org/info/rfc6545>.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546, April Defense (RID) Messages over HTTP/TLS", RFC 6546,
2012. DOI 10.17487/RFC6546, April 2012,
<http://www.rfc-editor.org/info/rfc6546>.
[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. 18 change blocks. 
26 lines changed or deleted 45 lines changed or added

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