idnits 2.17.1
draft-ietf-mile-implementreport-00.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 (July 4, 2014) is 3577 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC5901' is defined on line 436, but no explicit
reference was found in the text
== Unused Reference: 'RFC5941' is defined on line 439, but no explicit
reference was found in the text
== Unused Reference: 'RFC6545' is defined on line 442, but no explicit
reference was found in the text
== Unused Reference: 'RFC6546' is defined on line 445, 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: January 5, 2015 UTokyo
6 July 4, 2014
8 MILE Implementation Report
9 draft-ietf-mile-implementreport-00
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 January 5, 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 . . . . . . . . . . . . . . 3
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 . . . . . 6
65 5. Vendors with Planned Support . . . . . . . . . . . . . . . . 7
66 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 7
67 6. Implementation Guide . . . . . . . . . . . . . . . . . . . . 7
68 6.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 7
69 6.2. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9
70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
73 10. Informative References . . . . . . . . . . . . . . . . . . . 10
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
76 1. Introduction
78 This document is a collection of implementation reports from vendors
79 and researchers who have implemented one or more of the standards
80 published from the INCH and MILE working groups. The standards
81 include:
83 o Incident Object Description Exchange Format (IODEF) v1, RFC5070,
85 o Incident Object Description Exchange Format (IODEF) v2,
86 RFC5070-bis,
88 o Extensions to the IODEF-Document Class for Reporting Phishing,
89 RFC5901
91 o Sharing Transaction Fraud Data, RFC5941
93 o IODEF-extension for Structured Cybersecurity Information, RFCXXXX
95 o Real-time Inter-network Defense (RID), RFC6545
96 o Transport of Real-time Inter-network Defense (RID) Messages over
97 HTTP/TLS, RFC6546.
99 The implementation reports included in this document have been
100 provided by the team or product responsible for the implementations
101 of the mentioned RFCs. Additional submissions are welcome and should
102 be sent to the draft editor. A more complete list of
103 implementations, including open source efforts and vendor products,
104 can also be found at the following location:
106 http://siis.realmv6.org/implementations/
108 2. Consortiums and Information Sharing and Analysis Centers (ISACs)
110 2.1. Anti-Phishing Working Group
112 Description of how IODEF is used will be provided in a future
113 revision.
115 2.2. Advanced Cyber Defence Centre (ACDC)
117 Description of how IODEF is used will be provided in a future
118 revision. http://www.botfree.eu/
120 3. Open Source Implementations
122 3.1. EMC/RSA RID Agent
124 The EMC/RSA RID agent is an open source implementation of the
125 Internet Engineering Task Force (IETF) standards for the exchange of
126 incident and indicator data. The code has been released under an MIT
127 license and development will continue with the open source community
128 at the Github site for RSA Intelligence Sharing:
130 https://github.com/RSAIntelShare/RID-Server.git
132 The code implements the RFC6545, Real-time Inter-network Defense
133 (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code
134 supports the evolving RFC5070-bis Incident Object Description
135 Exchange Format (IODEF) data model from the work in the IETF working
136 group Managed Incident Lightweight Exchange (MILE).
138 3.2. NICT IODEF-SCI implementation
140 Japan's National Institute of Information and Communications
141 Technology (NICT) Network Security Research Institute implemented
142 open source tools for exchanging, accumulating, and locating IODEF-
143 SCI documents.
145 Three tools are available in GitHub. They assist the exchange of
146 IODEF-SCI documents between parties. IODEF-SCI is the IETF draft
147 that extends IODEF so that IODEF document can embed structured
148 cybersecurity information (SCI). For instance, it can embed MMDEF,
149 CEE, MAEC in XML and CVE identifiers.
151 The three tools are generator, exchanger, and parser. The generator
152 generates IODEF-SCI document or appends an XML to existing IODEF
153 document. The exchanger sends the IODEF document to its
154 correspondent node. The parser receives, parses, and stores the
155 IODEF-SCI document. It also equips the interface that enable users
156 to locate IODEF-SCI documents it has ever received. The code has
157 been released under an MIT license and development will continue
158 here.
160 Note that users can enjoy this software with their own
161 responsibility.
163 Available Online:
165 https://github.com/TakeshiTakahashi/IODEF-SCI
167 4. Vendor Implementations
169 4.1. Deep Secure
171 Deep-Secure Guards are built to protect a trusted domain from:
173 o releasing sensitive data that does not meet the organisational
174 security policy
176 o applications receiving badly constructed or malicious data which
177 could exploit a vulnerability (known or unknown)
179 Deep-Secure Guards support HTTPS and XMPP (optimised server to server
180 protocol) transports. The Deep-Secure Guards support transfer of XML
181 based business content by creating a schema to translate the known
182 good content to and from the intermediate format. This means that
183 the Deep-Secure Guards can be used to protect:
185 o IODEF/RID using the HTTPS transport binding (RFC 6546)
187 o IODEF/RID using an XMPP binding
189 o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02)
191 o STIX/TAXII using the HTTPS transport binding
192 Deep-Secure Guards also support the SMTP transport and perform deep
193 content inspection of content including XML attachments. The Mail
194 Guard supports S/MIME and Deep Secure are working on support for the
195 upcoming PLASMA standard which enables information centric policy
196 enforcement of data.
198 4.2. IncMan Suite, DFLabs
200 The Incident Object Description Exchange Format, documented in the
201 RFC 5070, defines a data representation that provides a framework for
202 sharing information commonly exchanged by Computer Security Incident
203 Response Teams (CSIRTs) about computer security incidents. IncMan
204 Suite implements the IODEF standard for exchanging details about
205 incidents, either for exporting and importing activities. This has
206 been introduced to enhance the capabilities of the various CSIRT, to
207 facilitate collaboration and sharing of useful experiences, conveying
208 awareness on specific cases.
210 The IODEF implementation is specified as an XML schema, therefore all
211 data are stored in an xml file: in this file all data of an incident
212 are organized in a hierarchical structure to describe the various
213 objects and their relationships.
215 IncMan Suite relies on IODEF as a transport format, composed by
216 various classes for describing the entities which are part of the
217 incident description: for instance the various relevant timestamps
218 (detect time , start time, end time, report time), the techniques
219 used by the intruders to perpetrate the incident, the impact of the
220 incident, either technical and non-technical (time and monetary) and
221 obviously all systems involved in the incident.
223 4.2.1. Exporting Incidents
225 Each incident defined in IncMan Suite can be exported via a User
226 Interface feature and it will populate an xml document. Due to the
227 nature of the data processed, the IODEF extraction might be
228 considered privacy sensitive by the parties exchanging the
229 information or by those described by it. For this reason, specific
230 care needs to be taken in ensuring the distribution to an appropriate
231 audience or third party, either during the document exchange and
232 subsequent processing.
234 The xml document generated will include description and details of
235 the incident along with all the systems involved and the related
236 information. At this stage it can be distributed for import into a
237 remote system.
239 4.2.2. Importing Incidents
241 IncMan Suite provides a functionality to import incidents stored in
242 files and transported via IODEF-compliant xml documents. The
243 importing process comprises of two steps: firstly, the file is
244 inspected to validate if well formed, then all data are uploaded
245 inside the system.
247 If an incident is already existing in the system with the same
248 incident id, the new one being imported will be created under a new
249 id. This approach prevents from accidentally overwriting existing
250 info or merging inconsistent data.
252 IncMan Suite includes also a feature to upload incidents from emails.
254 The incident, described in xml format, can be stored directly into
255 the body of the email message or transported as an attachment of the
256 email. At regular intervals, customizable by the user, IncMan Suite
257 monitors for incoming emails, filtered by a configurable white-list
258 and black-list mechanism on the sender's email account, then a parser
259 processes the received email and a new incident is created
260 automatically, after having validated the email body or the
261 attachment to ensure it is a well formed format.
263 4.3. Surevine Proof of Concept
265 XMPP is enhanced and extended through the XMPP Extension Protocols
266 (or XEPs). XEP-0268 (http://xmpp.org/extensions/xep-0268.html)
267 describes incident management (using IODEF) of the XMPP network
268 itself, effectively supporting self-healing the XMPP network. In
269 order to more generically cover incident management of a network and
270 over a network, XEP-0268 requires some updates. We are working on
271 these changes together with a new XEP that supports "social
272 networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP-
273 0060). This now allows nodes to publish any type of content and
274 subscribe to and therefore receive the content. XEP-0268 will be
275 used to describe IODEF content. We now have an alpha version of the
276 server-side software and client-side software required to demonstrate
277 the "social networking" capability and are currently enhancing this
278 to support Cyber Incident management in real-time.
280 4.4. MANTIS Cyber-Intelligence Management Framework
282 MANTIS provides an example implementation of a framework for managing
283 cyber threat intelligence expressed in standards such as STIX, CybOX,
284 IODEF, etc. The aims of providing such an example implementation
285 are:
287 o To aide discussions about emerging standards such as STIX, CybOX
288 et al. with respect to questions regarding tooling: how would a
289 certain aspect be implemented, how do changes affect an
290 implementation? Such discussions become much easier and have a
291 better basis if they can be lead in the context of example tooling
292 that is known to the community.
294 o To lower the entrance barrier for organizations and teams (esp.
295 CERT teams) in using emerging standards for cyber-threat
296 intelligence management and exchange.
298 o To provide a platform on the basis of which research and
299 community-driven development in the area of cyber-threat
300 intelligence management can occur.
302 5. Vendors with Planned Support
304 5.1. Threat Central, HP
306 HP has developed HP Threat Central, a security intelligence platform
307 that enables automated, real-time collaboration between organizations
308 to combat today's increasingly sophisticated cyber attacks. One way
309 automated sharing of threat indicators is achieved is through close
310 integration with the HP ArcSight SIEM for automated upload and
311 consumption of information from the Threat Central Server. In
312 addition HP Threat Central supports open standards for sharing threat
313 information so that participants who do not use HP Security Products
314 can participate in the sharing ecosystem. General availability of
315 Threat Central will be in 2014. It is planned that future versions
316 also support IODEF for the automated upload and download of threat
317 information.
319 6. Implementation Guide
321 The section aims at sharing the tips for development of IODEF-capable
322 systems.
324 6.1. Code Generators
326 For implementing IODEF-capable systems, it is feasible to employ code
327 generators for XML Schema Document (XSD). The generators are used to
328 save development costs since they automatically create useful
329 libraries for accessing XML attributes, composing messages, and/or
330 validating XML objects. The IODEF XSD was defined in section 8 of
331 RFC 5070, and is availabe at http://www.iana.org/assignments/xml-
332 registry/schema/iodef-1.0.xsd.
334 However, there still remains some problem. Due to the complexity of
335 IODEF XSD, some code generators could not generate from the XSD file.
336 The tested code generators were as follows.
338 o XML::Pastor [XSD:Perl] (Perl)
340 o RXSD [XSD:Ruby] (Ruby)
342 o PyXB [XSD:Python] (Python)
344 o JAXB [XSD:Java] (Java)
346 o CodeSynthesis XSD [XSD:Cxx] (C++)
348 o Xsd.exe [XSD:CS] (C#)
350 For instance, we have used XML::Pastor, but it could not properly
351 understand its schema due to the complexity of IODEF XSD. The same
352 applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and Xsd.exe
353 were able to understand the schema.
355 There is no recommended workaround, however, a double conversion of
356 XSD file is one option to go through the situation; it means XSD is
357 serialized to XML, and it is again converted to XSD. The resultant
358 XSD was process-able by the all tools above.
360 It should be noted that IODEF uses '-' (hyphen) symbols in its
361 classes or attributes, listed as follows.
363 o IODEF-Document Class; it is the top level class in the IODEF data
364 model described in section 3.1 of [RFC5070].
366 o The vlan-name and vlan-num Attribute; according to section 3.16.2
367 of [RFC5070], they are the name and number of Virtual LAN and are
368 the attributes for Address class.
370 o Extending the Enumerated Values of Attribute; according to section
371 5.1 of [RFC5070], it is a extension techniques to add new
372 enumerated values to an attribute, and has a prefix of "ext-",
373 e.g., ext-value, ext-category, ext-type, and so on.
375 According to the language specification, many programing language
376 prohibit to contain '-' symbols in the name of class. The code
377 generators must replace or remove '-' when building the librarlies.
378 They should have the name space to restore '-' when outputting the
379 XML along with IODEF XSD.
381 6.2. Usability
383 Here notes some tips to avoid problems.
385 o IODEF has category attribute for NodeRole class. Though various
386 categories are described, they are not enough. For example, in
387 the case of web mail servers, you should choose either "www" or
388 "mail". One suggestion is selecting "mail" as the category
389 attribute and adding "www" for another attirbute.
391 o The numbering of Incident ID needs to be considered. Otherwise,
392 information, such as the number of incidents within certain period
393 could be observed by document receivers. For instance, we could
394 randomize the assignment of the numbers.
396 7. Acknowledgements
398 The MILE Implementation report has been compiled through the
399 submissions of implementers of INCH and MILE working group standards.
400 A special note of thanks to the following contributors:
402 John Atherton, Surevine
404 Humphrey Browning, Deep-Secure
406 Dario Forte, DFLabs
408 Tomas Sander, HP
410 Ulrich Seldeslachts, ACDC
412 Takeshi Takahashi, National Institute of Information and
413 Communications Technology Network Security Research Institute
415 Kathleen Moriarty, EMC
417 Bernd Grobauer, Siemens
419 8. IANA Considerations
421 This memo includes no request to IANA.
423 9. Security Considerations
425 This draft provides a summary of implementation reports from
426 researchers and vendors who have implemented RFCs and drafts from the
427 MILE and INCH working groups. There are no security considerations
428 added in this draft because of the nature of the document.
430 10. Informative References
432 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
433 Object Description Exchange Format", RFC 5070, December
434 2007.
436 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
437 Class for Reporting Phishing", RFC 5901, July 2010.
439 [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
440 "Sharing Transaction Fraud Data", RFC 5941, August 2010.
442 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC
443 6545, April 2012.
445 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
446 Defense (RID) Messages over HTTP/TLS", RFC 6546, April
447 2012.
449 [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
450 .
452 [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++",
453 .
455 [XSD:Java]
456 Project Kenai, "JAXB Reference Implementation",
457 .
459 [XSD:Perl]
460 Ulsoy, A., "XML::Pastor",
461 .
463 [XSD:Python]
464 Bigot, P., "PyXB: Python XML Schema Bindings",
465 .
467 [XSD:Ruby]
468 Morsi, M., "RXSD - XSD / Ruby Translator",
469 .
471 Authors' Addresses
472 Chris Inacio
473 Carnegie Mellon University
474 4500 5th Ave., SEI 4108
475 Pittsburgh, PA 15213
476 US
478 Email: inacio@andrew.cmu.edu
480 Daisuke Miyamoto
481 The Univerisity of Tokyo
482 2-11-16 Yayoi, Bunkyo
483 Tokyo 113-8658
484 JP
486 Email: daisu-mi@nc.u-tokyo.ac.jp