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