idnits 2.17.1
draft-ietf-mile-implementreport-01.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 (November 20, 2014) is 3444 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC5901' is defined on line 497, but no explicit
reference was found in the text
== Unused Reference: 'RFC5941' is defined on line 500, but no explicit
reference was found in the text
== Unused Reference: 'RFC6545' is defined on line 503, but no explicit
reference was found in the text
== Unused Reference: 'RFC6546' is defined on line 506, 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: May 24, 2015 UTokyo
6 November 20, 2014
8 MILE Implementation Report
9 draft-ietf-mile-implementreport-01
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 May 24, 2015.
35 Copyright Notice
37 Copyright (c) 2014 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 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 4
61 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 4
62 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 5
63 4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 6
64 4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 7
65 5. Vendors with Planned Support . . . . . . . . . . . . . . . . 7
66 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 7
67 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 7
68 6.1. Collaborative Incident Management System . . . . . . . . 7
69 6.2. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
70 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 9
71 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 9
72 7.2. Usability . . . . . . . . . . . . . . . . . . . . . . . . 10
73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
76 11. Informative References . . . . . . . . . . . . . . . . . . . 11
77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
79 1. Introduction
81 This document is a collection of implementation reports from vendors
82 and researchers who have implemented one or more of the standards
83 published from the INCH and MILE working groups. The standards
84 include:
86 o Incident Object Description Exchange Format (IODEF) v1, RFC5070,
88 o Incident Object Description Exchange Format (IODEF) v2,
89 RFC5070-bis,
91 o Extensions to the IODEF-Document Class for Reporting Phishing,
92 RFC5901
94 o Sharing Transaction Fraud Data, RFC5941
96 o IODEF-extension for Structured Cybersecurity Information, RFCXXXX
97 o Real-time Inter-network Defense (RID), RFC6545
99 o Transport of Real-time Inter-network Defense (RID) Messages over
100 HTTP/TLS, RFC6546.
102 The implementation reports included in this document have been
103 provided by the team or product responsible for the implementations
104 of the mentioned RFCs. Additional submissions are welcome and should
105 be sent to the draft editor. A more complete list of
106 implementations, including open source efforts and vendor products,
107 can also be found at the following location:
109 http://siis.realmv6.org/implementations/
111 2. Consortiums and Information Sharing and Analysis Centers (ISACs)
113 2.1. Anti-Phishing Working Group
115 Description of how IODEF is used will be provided in a future
116 revision.
118 2.2. Advanced Cyber Defence Centre (ACDC)
120 Description of how IODEF is used will be provided in a future
121 revision. http://www.botfree.eu/
123 3. Open Source Implementations
125 3.1. EMC/RSA RID Agent
127 The EMC/RSA RID agent is an open source implementation of the
128 Internet Engineering Task Force (IETF) standards for the exchange of
129 incident and indicator data. The code has been released under an MIT
130 license and development will continue with the open source community
131 at the Github site for RSA Intelligence Sharing:
133 https://github.com/RSAIntelShare/RID-Server.git
135 The code implements the RFC6545, Real-time Inter-network Defense
136 (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code
137 supports the evolving RFC5070-bis Incident Object Description
138 Exchange Format (IODEF) data model from the work in the IETF working
139 group Managed Incident Lightweight Exchange (MILE).
141 3.2. NICT IODEF-SCI implementation
143 Japan's National Institute of Information and Communications
144 Technology (NICT) Network Security Research Institute implemented
145 open source tools for exchanging, accumulating, and locating IODEF-
146 SCI documents.
148 Three tools are available in GitHub. They assist the exchange of
149 IODEF-SCI documents between parties. IODEF-SCI is the IETF draft
150 that extends IODEF so that IODEF document can embed structured
151 cybersecurity information (SCI). For instance, it can embed MMDEF,
152 CEE, MAEC in XML and CVE identifiers.
154 The three tools are generator, exchanger, and parser. The generator
155 generates IODEF-SCI document or appends an XML to existing IODEF
156 document. The exchanger sends the IODEF document to its
157 correspondent node. The parser receives, parses, and stores the
158 IODEF-SCI document. It also equips the interface that enable users
159 to locate IODEF-SCI documents it has ever received. The code has
160 been released under an MIT license and development will continue
161 here.
163 Note that users can enjoy this software with their own
164 responsibility.
166 Available Online:
168 https://github.com/TakeshiTakahashi/IODEF-SCI
170 4. Vendor Implementations
172 4.1. Deep Secure
174 Deep-Secure Guards are built to protect a trusted domain from:
176 o releasing sensitive data that does not meet the organisational
177 security policy
179 o applications receiving badly constructed or malicious data which
180 could exploit a vulnerability (known or unknown)
182 Deep-Secure Guards support HTTPS and XMPP (optimised server to server
183 protocol) transports. The Deep-Secure Guards support transfer of XML
184 based business content by creating a schema to translate the known
185 good content to and from the intermediate format. This means that
186 the Deep-Secure Guards can be used to protect:
188 o IODEF/RID using the HTTPS transport binding (RFC 6546)
189 o IODEF/RID using an XMPP binding
191 o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02)
193 o STIX/TAXII using the HTTPS transport binding
195 Deep-Secure Guards also support the SMTP transport and perform deep
196 content inspection of content including XML attachments. The Mail
197 Guard supports S/MIME and Deep Secure are working on support for the
198 upcoming PLASMA standard which enables information centric policy
199 enforcement of data.
201 4.2. IncMan Suite, DFLabs
203 The Incident Object Description Exchange Format, documented in the
204 RFC 5070, defines a data representation that provides a framework for
205 sharing information commonly exchanged by Computer Security Incident
206 Response Teams (CSIRTs) about computer security incidents. IncMan
207 Suite implements the IODEF standard for exchanging details about
208 incidents, either for exporting and importing activities. This has
209 been introduced to enhance the capabilities of the various CSIRT, to
210 facilitate collaboration and sharing of useful experiences, conveying
211 awareness on specific cases.
213 The IODEF implementation is specified as an XML schema, therefore all
214 data are stored in an xml file: in this file all data of an incident
215 are organized in a hierarchical structure to describe the various
216 objects and their relationships.
218 IncMan Suite relies on IODEF as a transport format, composed by
219 various classes for describing the entities which are part of the
220 incident description: for instance the various relevant timestamps
221 (detect time , start time, end time, report time), the techniques
222 used by the intruders to perpetrate the incident, the impact of the
223 incident, either technical and non-technical (time and monetary) and
224 obviously all systems involved in the incident.
226 4.2.1. Exporting Incidents
228 Each incident defined in IncMan Suite can be exported via a User
229 Interface feature and it will populate an xml document. Due to the
230 nature of the data processed, the IODEF extraction might be
231 considered privacy sensitive by the parties exchanging the
232 information or by those described by it. For this reason, specific
233 care needs to be taken in ensuring the distribution to an appropriate
234 audience or third party, either during the document exchange and
235 subsequent processing.
237 The xml document generated will include description and details of
238 the incident along with all the systems involved and the related
239 information. At this stage it can be distributed for import into a
240 remote system.
242 4.2.2. Importing Incidents
244 IncMan Suite provides a functionality to import incidents stored in
245 files and transported via IODEF-compliant xml documents. The
246 importing process comprises of two steps: firstly, the file is
247 inspected to validate if well formed, then all data are uploaded
248 inside the system.
250 If an incident is already existing in the system with the same
251 incident id, the new one being imported will be created under a new
252 id. This approach prevents from accidentally overwriting existing
253 info or merging inconsistent data.
255 IncMan Suite includes also a feature to upload incidents from emails.
257 The incident, described in xml format, can be stored directly into
258 the body of the email message or transported as an attachment of the
259 email. At regular intervals, customizable by the user, IncMan Suite
260 monitors for incoming emails, filtered by a configurable white-list
261 and black-list mechanism on the sender's email account, then a parser
262 processes the received email and a new incident is created
263 automatically, after having validated the email body or the
264 attachment to ensure it is a well formed format.
266 4.3. Surevine Proof of Concept
268 XMPP is enhanced and extended through the XMPP Extension Protocols
269 (or XEPs). XEP-0268 (http://xmpp.org/extensions/xep-0268.html)
270 describes incident management (using IODEF) of the XMPP network
271 itself, effectively supporting self-healing the XMPP network. In
272 order to more generically cover incident management of a network and
273 over a network, XEP-0268 requires some updates. We are working on
274 these changes together with a new XEP that supports "social
275 networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP-
276 0060). This now allows nodes to publish any type of content and
277 subscribe to and therefore receive the content. XEP-0268 will be
278 used to describe IODEF content. We now have an alpha version of the
279 server-side software and client-side software required to demonstrate
280 the "social networking" capability and are currently enhancing this
281 to support Cyber Incident management in real-time.
283 4.4. MANTIS Cyber-Intelligence Management Framework
285 MANTIS provides an example implementation of a framework for managing
286 cyber threat intelligence expressed in standards such as STIX, CybOX,
287 IODEF, etc. The aims of providing such an example implementation
288 are:
290 o To aide discussions about emerging standards such as STIX, CybOX
291 et al. with respect to questions regarding tooling: how would a
292 certain aspect be implemented, how do changes affect an
293 implementation? Such discussions become much easier and have a
294 better basis if they can be lead in the context of example tooling
295 that is known to the community.
297 o To lower the entrance barrier for organizations and teams (esp.
298 CERT teams) in using emerging standards for cyber-threat
299 intelligence management and exchange.
301 o To provide a platform on the basis of which research and
302 community-driven development in the area of cyber-threat
303 intelligence management can occur.
305 5. Vendors with Planned Support
307 5.1. Threat Central, HP
309 HP has developed HP Threat Central, a security intelligence platform
310 that enables automated, real-time collaboration between organizations
311 to combat today's increasingly sophisticated cyber attacks. One way
312 automated sharing of threat indicators is achieved is through close
313 integration with the HP ArcSight SIEM for automated upload and
314 consumption of information from the Threat Central Server. In
315 addition HP Threat Central supports open standards for sharing threat
316 information so that participants who do not use HP Security Products
317 can participate in the sharing ecosystem. General availability of
318 Threat Central will be in 2014. It is planned that future versions
319 also support IODEF for the automated upload and download of threat
320 information.
322 6. Other Implementations
324 6.1. Collaborative Incident Management System
326 Collaborative Incident Management System (CIMS) is a proof-of-concept
327 system for collaborative incident handling and for the sharing of
328 cyber defence situational awareness information between the
329 participants, developed for the Cyber Coalition 2013 (CC13) exercise
330 organized by NATO. CIMS was implemented based on Request Tracker
331 (RT), an open source software widely used for handling incident
332 response by many CERTs and CSIRTs.
334 One of the functionality implemented in CIMS was the ability to
335 import and export IODEF messages in the body of emails. The intent
336 was to verify the suitability of IODEF to achieve the objective of
337 collaborative incident handling. The customized version of RT could
338 be configured to send an email message containing an IODEF message
339 whenever an incident ticket was created, modified or deleted. These
340 IODEF messages would then be imported into other incident handling
341 systems in order to allow participating CSIRTs to use their usual
342 means for incident handling, while still interacting with those using
343 the proof-of-concept CIMS. Having an IODEF message generated for
344 every change made to the incident information in RT (and for the
345 system to allow incoming IODEF email messages to be associated to an
346 existing incident) would in some way allow all participating CSIRTs
347 to actually work on a "common incident ticket", at least at the
348 conceptual level. Of particular importance was the ability for users
349 to exchange information between each other concerning actions taken
350 in the handling of a particular incident, thus creating a sort of
351 common action log, as well as requesting/tasking others to provide
352 information or perform specified action and correlating received
353 responses to the original request or tasking. As well, a specific
354 "profile" was developed to identify a subset of the IODEF classes
355 that would be used during the exercise, in an attempt to channel all
356 users into a common usage pattern of the otherwise flexible IODEF
357 standard.
359 6.2. n6
361 n6 is a platform for processing security-related information,
362 developed by NASK, CERT Polska. Its API provides a common and
363 unified way of representing data across the different sources that
364 participate in knowledge management.
366 n6 exposes a REST-ful API over HTTPS with mandatory authentication
367 via TLS client certificates, to ensure confidential and trustworthy
368 communications. Moreover, it uses an event-based data model for
369 representation of all types of security information.
371 Each event is represented as a JSON object with a set of mandatory
372 and optional attributes. It also supports alternative output data
373 formats for keeping compatibility with existing systems - IODEF and
374 CSV - although they lack some of the attributes that may be present
375 in the native JSON format.
377 7. Implementation Guide
379 The section aims at sharing the tips for development of IODEF-capable
380 systems.
382 7.1. Code Generators
384 For implementing IODEF-capable systems, it is feasible to employ code
385 generators for XML Schema Document (XSD). The generators are used to
386 save development costs since they automatically create useful
387 libraries for accessing XML attributes, composing messages, and/or
388 validating XML objects. The IODEF XSD was defined in section 8 of
389 RFC 5070, and is availabe at http://www.iana.org/assignments/xml-
390 registry/schema/iodef-1.0.xsd.
392 However, there still remains some problem. Due to the complexity of
393 IODEF XSD, some code generators could not generate from the XSD file.
394 The tested code generators were as follows.
396 o XML::Pastor [XSD:Perl] (Perl)
398 o RXSD [XSD:Ruby] (Ruby)
400 o PyXB [XSD:Python] (Python)
402 o JAXB [XSD:Java] (Java)
404 o CodeSynthesis XSD [XSD:Cxx] (C++)
406 o Xsd.exe [XSD:CS] (C#)
408 For instance, we have used XML::Pastor, but it could not properly
409 understand its schema due to the complexity of IODEF XSD. The same
410 applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and Xsd.exe
411 were able to understand the schema.
413 There is no recommended workaround, however, a double conversion of
414 XSD file is one option to go through the situation; it means XSD is
415 serialized to XML, and it is again converted to XSD. The resultant
416 XSD was process-able by the all tools above.
418 It should be noted that IODEF uses '-' (hyphen) symbols in its
419 classes or attributes, listed as follows.
421 o IODEF-Document Class; it is the top level class in the IODEF data
422 model described in section 3.1 of [RFC5070].
424 o The vlan-name and vlan-num Attribute; according to section 3.16.2
425 of [RFC5070], they are the name and number of Virtual LAN and are
426 the attributes for Address class.
428 o Extending the Enumerated Values of Attribute; according to section
429 5.1 of [RFC5070], it is a extension techniques to add new
430 enumerated values to an attribute, and has a prefix of "ext-",
431 e.g., ext-value, ext-category, ext-type, and so on.
433 According to the language specification, many programing language
434 prohibit to contain '-' symbols in the name of class. The code
435 generators must replace or remove '-' when building the librarlies.
436 They should have the name space to restore '-' when outputting the
437 XML along with IODEF XSD.
439 7.2. Usability
441 Here notes some tips to avoid problems.
443 o IODEF has category attribute for NodeRole class. Though various
444 categories are described, they are not enough. For example, in
445 the case of web mail servers, you should choose either "www" or
446 "mail". One suggestion is selecting "mail" as the category
447 attribute and adding "www" for another attirbute.
449 o The numbering of Incident ID needs to be considered. Otherwise,
450 information, such as the number of incidents within certain period
451 could be observed by document receivers. For instance, we could
452 randomize the assignment of the numbers.
454 8. Acknowledgements
456 The MILE Implementation report has been compiled through the
457 submissions of implementers of INCH and MILE working group standards.
458 A special note of thanks to the following contributors:
460 John Atherton, Surevine
462 Humphrey Browning, Deep-Secure
464 Dario Forte, DFLabs
466 Tomas Sander, HP
468 Ulrich Seldeslachts, ACDC
470 Takeshi Takahashi, National Institute of Information and
471 Communications Technology Network Security Research Institute
472 Kathleen Moriarty, EMC
474 Bernd Grobauer, Siemens
476 Dandurand Luc, NATO
478 Pawel Pawlinski, NASK
480 9. IANA Considerations
482 This memo includes no request to IANA.
484 10. Security Considerations
486 This draft provides a summary of implementation reports from
487 researchers and vendors who have implemented RFCs and drafts from the
488 MILE and INCH working groups. There are no security considerations
489 added in this draft because of the nature of the document.
491 11. Informative References
493 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
494 Object Description Exchange Format", RFC 5070, December
495 2007.
497 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
498 Class for Reporting Phishing", RFC 5901, July 2010.
500 [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
501 "Sharing Transaction Fraud Data", RFC 5941, August 2010.
503 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC
504 6545, April 2012.
506 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
507 Defense (RID) Messages over HTTP/TLS", RFC 6546, April
508 2012.
510 [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
511 .
513 [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++",
514 .
516 [XSD:Java]
517 Project Kenai, "JAXB Reference Implementation",
518 .
520 [XSD:Perl]
521 Ulsoy, A., "XML::Pastor",
522 .
524 [XSD:Python]
525 Bigot, P., "PyXB: Python XML Schema Bindings",
526 .
528 [XSD:Ruby]
529 Morsi, M., "RXSD - XSD / Ruby Translator",
530 .
532 Authors' Addresses
534 Chris Inacio
535 Carnegie Mellon University
536 4500 5th Ave., SEI 4108
537 Pittsburgh, PA 15213
538 US
540 Email: inacio@andrew.cmu.edu
542 Daisuke Miyamoto
543 The Univerisity of Tokyo
544 2-11-16 Yayoi, Bunkyo
545 Tokyo 113-8658
546 JP
548 Email: daisu-mi@nc.u-tokyo.ac.jp