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