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