idnits 2.17.1
draft-ietf-mile-implementreport-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (May 1, 2015) is 3283 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC5901' is defined on line 535, but no explicit
reference was found in the text
== Unused Reference: 'RFC5941' is defined on line 538, but no explicit
reference was found in the text
== Unused Reference: 'RFC6545' is defined on line 541, but no explicit
reference was found in the text
== Unused Reference: 'RFC6546' is defined on line 544, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 5070
(Obsoleted by RFC 7970)
Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MILE C. Inacio
3 Internet-Draft CMU
4 Intended status: Informational D. Miyamoto
5 Expires: November 2, 2015 UTokyo
6 May 1, 2015
8 MILE Implementation Report
9 draft-ietf-mile-implementreport-02
11 Abstract
13 This document is a collection of implementation reports from vendors,
14 consortiums, and researchers who have implemented one or more of the
15 standards published from the IETF INCident Handling (INCH) and
16 Management Incident Lightweight Exchange (MILE) working groups.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on November 2, 2015.
35 Copyright Notice
37 Copyright (c) 2015 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 2. Consortiums and Information Sharing and Analysis Centers
54 (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3
56 2.2. Advanced Cyber Defence Centre (ACDC) . . . . . . . . . . 3
57 3. Open Source Implementations . . . . . . . . . . . . . . . . . 3
58 3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . 3
59 3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . 4
60 3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 5
62 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5
63 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 5
64 4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 7
65 4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 7
66 5. Vendors with Planned Support . . . . . . . . . . . . . . . . 7
67 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 8
68 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 8
69 6.1. Collaborative Incident Management System . . . . . . . . 8
70 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 9
71 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 9
72 7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 10
73 7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 10
74 7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 11
75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
78 11. Informative References . . . . . . . . . . . . . . . . . . . 12
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
81 1. Introduction
83 This document is a collection of implementation reports from vendors
84 and researchers who have implemented one or more of the standards
85 published from the INCH and MILE working groups. The standards
86 include:
88 o Incident Object Description Exchange Format (IODEF) v1, RFC5070,
90 o Incident Object Description Exchange Format (IODEF) v2,
91 RFC5070-bis,
93 o Extensions to the IODEF-Document Class for Reporting Phishing,
94 RFC5901
96 o Sharing Transaction Fraud Data, RFC5941
97 o IODEF-extension for Structured Cybersecurity Information, RFCXXXX
99 o Real-time Inter-network Defense (RID), RFC6545
101 o Transport of Real-time Inter-network Defense (RID) Messages over
102 HTTP/TLS, RFC6546.
104 o Incident Object Description Exchange Format (IODEF) Extension for
105 Structured Cybersecurity Information, RFC7203
107 The implementation reports included in this document have been
108 provided by the team or product responsible for the implementations
109 of the mentioned RFCs. Additional submissions are welcome and should
110 be sent to the draft editor. A more complete list of
111 implementations, including open source efforts and vendor products,
112 can also be found at the following location:
114 http://siis.realmv6.org/implementations/
116 2. Consortiums and Information Sharing and Analysis Centers (ISACs)
118 2.1. Anti-Phishing Working Group
120 Description of how IODEF is used will be provided in a future
121 revision.
123 2.2. Advanced Cyber Defence Centre (ACDC)
125 Description of how IODEF is used will be provided in a future
126 revision. http://www.botfree.eu/
128 3. Open Source Implementations
130 3.1. EMC/RSA RID Agent
132 The EMC/RSA RID agent is an open source implementation of the
133 Internet Engineering Task Force (IETF) standards for the exchange of
134 incident and indicator data. The code has been released under an MIT
135 license and development will continue with the open source community
136 at the Github site for RSA Intelligence Sharing:
138 https://github.com/RSAIntelShare/RID-Server.git
140 The code implements the RFC6545, Real-time Inter-network Defense
141 (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code
142 supports the evolving RFC5070-bis Incident Object Description
143 Exchange Format (IODEF) data model from the work in the IETF working
144 group Managed Incident Lightweight Exchange (MILE).
146 3.2. NICT IODEF-SCI implementation
148 Japan's National Institute of Information and Communications
149 Technology (NICT) Network Security Research Institute implemented
150 open source tools for exchanging, accumulating, and locating IODEF-
151 SCI documents.
153 Three tools are available in GitHub. They assist the exchange of
154 IODEF-SCI documents between parties. IODEF-SCI is the IETF draft
155 that extends IODEF so that IODEF document can embed structured
156 cybersecurity information (SCI). For instance, it can embed MMDEF,
157 CEE, MAEC in XML and CVE identifiers.
159 The three tools are generator, exchanger, and parser. The generator
160 generates IODEF-SCI document or appends an XML to existing IODEF
161 document. The exchanger sends the IODEF document to its
162 correspondent node. The parser receives, parses, and stores the
163 IODEF-SCI document. It also equips the interface that enable users
164 to locate IODEF-SCI documents it has ever received. The code has
165 been released under an MIT license and development will continue
166 here.
168 Note that users can enjoy this software with their own
169 responsibility.
171 Available Online:
173 https://github.com/TakeshiTakahashi/IODEF-SCI
175 3.3. n6
177 n6 is a platform for processing security-related information,
178 developed by NASK, CERT Polska. Its API provides a common and
179 unified way of representing data across the different sources that
180 participate in knowledge management.
182 n6 exposes a REST-ful API over HTTPS with mandatory authentication
183 via TLS client certificates, to ensure confidential and trustworthy
184 communications. Moreover, it uses an event-based data model for
185 representation of all types of security information.
187 Each event is represented as a JSON object with a set of mandatory
188 and optional attributes. It also supports alternative output data
189 formats for keeping compatibility with existing systems - IODEF and
190 CSV - although they lack some of the attributes that may be present
191 in the native JSON format.
193 Available Online:
195 https://github.com/CERT-Polska/n6sdk
197 4. Vendor Implementations
199 4.1. Deep Secure
201 Deep-Secure Guards are built to protect a trusted domain from:
203 o releasing sensitive data that does not meet the organisational
204 security policy
206 o applications receiving badly constructed or malicious data which
207 could exploit a vulnerability (known or unknown)
209 Deep-Secure Guards support HTTPS and XMPP (optimised server to server
210 protocol) transports. The Deep-Secure Guards support transfer of XML
211 based business content by creating a schema to translate the known
212 good content to and from the intermediate format. This means that
213 the Deep-Secure Guards can be used to protect:
215 o IODEF/RID using the HTTPS transport binding (RFC 6546)
217 o IODEF/RID using an XMPP binding
219 o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02)
221 o STIX/TAXII using the HTTPS transport binding
223 Deep-Secure Guards also support the SMTP transport and perform deep
224 content inspection of content including XML attachments. The Mail
225 Guard supports S/MIME and Deep Secure are working on support for the
226 upcoming PLASMA standard which enables information centric policy
227 enforcement of data.
229 4.2. IncMan Suite, DFLabs
231 The Incident Object Description Exchange Format, documented in the
232 RFC 5070, defines a data representation that provides a framework for
233 sharing information commonly exchanged by Computer Security Incident
234 Response Teams (CSIRTs) about computer security incidents. IncMan
235 Suite implements the IODEF standard for exchanging details about
236 incidents, either for exporting and importing activities. This has
237 been introduced to enhance the capabilities of the various CSIRT, to
238 facilitate collaboration and sharing of useful experiences, conveying
239 awareness on specific cases.
241 The IODEF implementation is specified as an XML schema, therefore all
242 data are stored in an xml file: in this file all data of an incident
243 are organized in a hierarchical structure to describe the various
244 objects and their relationships.
246 IncMan Suite relies on IODEF as a transport format, composed by
247 various classes for describing the entities which are part of the
248 incident description: for instance the various relevant timestamps
249 (detect time , start time, end time, report time), the techniques
250 used by the intruders to perpetrate the incident, the impact of the
251 incident, either technical and non-technical (time and monetary) and
252 obviously all systems involved in the incident.
254 4.2.1. Exporting Incidents
256 Each incident defined in IncMan Suite can be exported via a User
257 Interface feature and it will populate an xml document. Due to the
258 nature of the data processed, the IODEF extraction might be
259 considered privacy sensitive by the parties exchanging the
260 information or by those described by it. For this reason, specific
261 care needs to be taken in ensuring the distribution to an appropriate
262 audience or third party, either during the document exchange and
263 subsequent processing.
265 The xml document generated will include description and details of
266 the incident along with all the systems involved and the related
267 information. At this stage it can be distributed for import into a
268 remote system.
270 4.2.2. Importing Incidents
272 IncMan Suite provides a functionality to import incidents stored in
273 files and transported via IODEF-compliant xml documents. The
274 importing process comprises of two steps: firstly, the file is
275 inspected to validate if well formed, then all data are uploaded
276 inside the system.
278 If an incident is already existing in the system with the same
279 incident id, the new one being imported will be created under a new
280 id. This approach prevents from accidentally overwriting existing
281 info or merging inconsistent data.
283 IncMan Suite includes also a feature to upload incidents from emails.
285 The incident, described in xml format, can be stored directly into
286 the body of the email message or transported as an attachment of the
287 email. At regular intervals, customizable by the user, IncMan Suite
288 monitors for incoming emails, filtered by a configurable white-list
289 and black-list mechanism on the sender's email account, then a parser
290 processes the received email and a new incident is created
291 automatically, after having validated the email body or the
292 attachment to ensure it is a well formed format.
294 4.3. Surevine Proof of Concept
296 XMPP is enhanced and extended through the XMPP Extension Protocols
297 (or XEPs). XEP-0268 (http://xmpp.org/extensions/xep-0268.html)
298 describes incident management (using IODEF) of the XMPP network
299 itself, effectively supporting self-healing the XMPP network. In
300 order to more generically cover incident management of a network and
301 over a network, XEP-0268 requires some updates. We are working on
302 these changes together with a new XEP that supports "social
303 networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP-
304 0060). This now allows nodes to publish any type of content and
305 subscribe to and therefore receive the content. XEP-0268 will be
306 used to describe IODEF content. We now have an alpha version of the
307 server-side software and client-side software required to demonstrate
308 the "social networking" capability and are currently enhancing this
309 to support Cyber Incident management in real-time.
311 4.4. MANTIS Cyber-Intelligence Management Framework
313 MANTIS provides an example implementation of a framework for managing
314 cyber threat intelligence expressed in standards such as STIX, CybOX,
315 IODEF, etc. The aims of providing such an example implementation
316 are:
318 o To aide discussions about emerging standards such as STIX, CybOX
319 et al. with respect to questions regarding tooling: how would a
320 certain aspect be implemented, how do changes affect an
321 implementation? Such discussions become much easier and have a
322 better basis if they can be lead in the context of example tooling
323 that is known to the community.
325 o To lower the entrance barrier for organizations and teams (esp.
326 CERT teams) in using emerging standards for cyber-threat
327 intelligence management and exchange.
329 o To provide a platform on the basis of which research and
330 community-driven development in the area of cyber-threat
331 intelligence management can occur.
333 5. Vendors with Planned Support
334 5.1. Threat Central, HP
336 HP has developed HP Threat Central, a security intelligence platform
337 that enables automated, real-time collaboration between organizations
338 to combat today's increasingly sophisticated cyber attacks. One way
339 automated sharing of threat indicators is achieved is through close
340 integration with the HP ArcSight SIEM for automated upload and
341 consumption of information from the Threat Central Server. In
342 addition HP Threat Central supports open standards for sharing threat
343 information so that participants who do not use HP Security Products
344 can participate in the sharing ecosystem. General availability of
345 Threat Central will be in 2014. It is planned that future versions
346 also support IODEF for the automated upload and download of threat
347 information.
349 6. Other Implementations
351 6.1. Collaborative Incident Management System
353 Collaborative Incident Management System (CIMS) is a proof-of-concept
354 system for collaborative incident handling and for the sharing of
355 cyber defence situational awareness information between the
356 participants, developed for the Cyber Coalition 2013 (CC13) exercise
357 organized by NATO. CIMS was implemented based on Request Tracker
358 (RT), an open source software widely used for handling incident
359 response by many CERTs and CSIRTs.
361 One of the functionality implemented in CIMS was the ability to
362 import and export IODEF messages in the body of emails. The intent
363 was to verify the suitability of IODEF to achieve the objective of
364 collaborative incident handling. The customized version of RT could
365 be configured to send an email message containing an IODEF message
366 whenever an incident ticket was created, modified or deleted. These
367 IODEF messages would then be imported into other incident handling
368 systems in order to allow participating CSIRTs to use their usual
369 means for incident handling, while still interacting with those using
370 the proof-of-concept CIMS. Having an IODEF message generated for
371 every change made to the incident information in RT (and for the
372 system to allow incoming IODEF email messages to be associated to an
373 existing incident) would in some way allow all participating CSIRTs
374 to actually work on a "common incident ticket", at least at the
375 conceptual level. Of particular importance was the ability for users
376 to exchange information between each other concerning actions taken
377 in the handling of a particular incident, thus creating a sort of
378 common action log, as well as requesting/tasking others to provide
379 information or perform specified action and correlating received
380 responses to the original request or tasking. As well, a specific
381 "profile" was developed to identify a subset of the IODEF classes
382 that would be used during the exercise, in an attempt to channel all
383 users into a common usage pattern of the otherwise flexible IODEF
384 standard.
386 7. Implementation Guide
388 The section aims at sharing the tips for development of IODEF-capable
389 systems.
391 7.1. Code Generators
393 For implementing IODEF-capable systems, it is feasible to employ code
394 generators for XML Schema Document (XSD). The generators are used to
395 save development costs since they automatically create useful
396 libraries for accessing XML attributes, composing messages, and/or
397 validating XML objects. The XSD of IODEFv1 was defined in section 8
398 of RFC 5070, and is availabe at http://www.iana.org/assignments/xml-
399 registry/schema/iodef-1.0.xsd.
401 However, there still remained some problems. Due to the complexity
402 of IODEF XSD, some code generators could not generate from the XSD
403 file. The tested code generators were as follows.
405 o XML::Pastor [XSD:Perl] (Perl)
407 o RXSD [XSD:Ruby] (Ruby)
409 o PyXB [XSD:Python] (Python)
411 o JAXB [XSD:Java] (Java)
413 o CodeSynthesis XSD [XSD:Cxx] (C++)
415 o Xsd.exe [XSD:CS] (C#)
417 For instance, we have used XML::Pastor, but it could not properly
418 understand its schema due to the complexity of IODEF XSD. The same
419 applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and Xsd.exe
420 were able to understand the schema.
422 There is no recommended workaround, however, a double conversion of
423 XSD file is one option to go through the situation; it means XSD is
424 serialized to XML, and it is again converted to XSD. The resultant
425 XSD was process-able by the all tools above.
427 It should be noted that IODEF uses '-' (hyphen) symbols in its
428 classes or attributes, listed as follows.
430 o IODEF-Document Class; it is the top level class in the IODEF data
431 model described in section 3.1 of [RFC5070].
433 o The vlan-name and vlan-num Attribute; according to section 3.16.2
434 of [RFC5070], they are the name and number of Virtual LAN and are
435 the attributes for Address class.
437 o Extending the Enumerated Values of Attribute; according to section
438 5.1 of [RFC5070], it is a extension techniques to add new
439 enumerated values to an attribute, and has a prefix of "ext-",
440 e.g., ext-value, ext-category, ext-type, and so on.
442 According to the language specification, many programing language
443 prohibit to contain '-' symbols in the name of class. The code
444 generators must replace or remove '-' when building the librarlies.
445 They should have the name space to restore '-' when outputting the
446 XML along with IODEF XSD.
448 7.2. iodeflib
450 iodeflib is an open source implementation written in Python. This
451 provides a simple but powerful APIs to create, parse and edit IODEF
452 documents. It was designed in order to keep its interface as simple
453 as possible, whereas generated libraries tend to inherit the
454 complexity of IODEF XSD. As well as the interface, iodeflib involves
455 functions of hiding some unnecessarily nested structures of the IODEF
456 schema, and adding more convenient shortcuts.
458 This tool is available through the following link:
460 http://www.decalage.info/python/iodeflib
462 7.3. iodefpm
464 IODEF.pm is an open source implementation written in Perl. This also
465 provides a simple interface for creating and parsing IODEF documents,
466 in order to facilitate the translation of the a key-value based
467 format to the IODEF representation. The module contains a generic
468 XML DTD parser and includes a simplified node based representation of
469 the IODEF DTD. It can hence easily be upgraded or extended to
470 support new XML nodes or other DTDs.
472 This tool is available through the following link:
474 http://search.cpan.org/~saxjazman/
476 7.4. Usability
478 Here notes some tips to avoid problems.
480 o IODEF has category attribute for NodeRole class. Though various
481 categories are described, they are not enough. For example, in
482 the case of web mail servers, you should choose either "www" or
483 "mail". One suggestion is selecting "mail" as the category
484 attribute and adding "www" for another attirbute.
486 o The numbering of Incident ID needs to be considered. Otherwise,
487 information, such as the number of incidents within certain period
488 could be observed by document receivers. For instance, we could
489 randomize the assignment of the numbers.
491 8. Acknowledgements
493 The MILE Implementation report has been compiled through the
494 submissions of implementers of INCH and MILE working group standards.
495 A special note of thanks to the following contributors:
497 John Atherton, Surevine
499 Humphrey Browning, Deep-Secure
501 Dario Forte, DFLabs
503 Tomas Sander, HP
505 Ulrich Seldeslachts, ACDC
507 Takeshi Takahashi, National Institute of Information and
508 Communications Technology Network Security Research Institute
510 Kathleen Moriarty, EMC
512 Bernd Grobauer, Siemens
514 Dandurand Luc, NATO
516 Pawel Pawlinski, NASK
518 9. IANA Considerations
520 This memo includes no request to IANA.
522 10. Security Considerations
524 This draft provides a summary of implementation reports from
525 researchers and vendors who have implemented RFCs and drafts from the
526 MILE and INCH working groups. There are no security considerations
527 added in this draft because of the nature of the document.
529 11. Informative References
531 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
532 Object Description Exchange Format", RFC 5070, December
533 2007.
535 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
536 Class for Reporting Phishing", RFC 5901, July 2010.
538 [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
539 "Sharing Transaction Fraud Data", RFC 5941, August 2010.
541 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC
542 6545, April 2012.
544 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
545 Defense (RID) Messages over HTTP/TLS", RFC 6546, April
546 2012.
548 [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
549 .
551 [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++",
552 .
554 [XSD:Java]
555 Project Kenai, "JAXB Reference Implementation",
556 .
558 [XSD:Perl]
559 Ulsoy, A., "XML::Pastor",
560 .
562 [XSD:Python]
563 Bigot, P., "PyXB: Python XML Schema Bindings",
564 .
566 [XSD:Ruby]
567 Morsi, M., "RXSD - XSD / Ruby Translator",
568 .
570 Authors' Addresses
572 Chris Inacio
573 Carnegie Mellon University
574 4500 5th Ave., SEI 4108
575 Pittsburgh, PA 15213
576 US
578 Email: inacio@andrew.cmu.edu
580 Daisuke Miyamoto
581 The Univerisity of Tokyo
582 2-11-16 Yayoi, Bunkyo
583 Tokyo 113-8658
584 JP
586 Email: daisu-mi@nc.u-tokyo.ac.jp