idnits 2.17.1 draft-moriarty-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 (February 11, 2014) is 3720 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5070' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC5901' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC5941' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC6545' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC6546' is defined on line 337, 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 (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MILE K. Moriarty, Ed. 2 Internet-Draft EMC Corporation 3 Intended status: Informational February 11, 2014 4 Expires: August 15, 2014 6 MILE Implementation Report 7 draft-moriarty-mile-implementreport-00 9 Abstract 11 This document is a collection of implementation reports from vendors, 12 consortiums, and researchers who have implemented one or more of the 13 standards published from the IETF INCident Handling (INCH) and 14 Management Incident Lightweight Exchange (MILE) working groups. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 15, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Consortiums and Information Sharing and Analysis Centers 52 (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . . 3 54 2.2. Advanced Cyber Defence Centre (ACDC) . . . . . . . . . . . 3 55 3. Open Source Implementations . . . . . . . . . . . . . . . . . . 4 56 3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . . 4 58 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . . 5 61 4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . . 7 62 5. Vendors with Planned Support . . . . . . . . . . . . . . . . . 7 63 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document is a collection of implementation reports from vendors 73 and researchers who have implemented one or more of the standards 74 published from the INCH and MILE working groups. The standards 75 include: 77 o Incident Object Description Exchange Format (IODEF) v1, RFC5070, 79 o Incident Object Description Exchange Format (IODEF) v2, RFC5070- 80 bis, 82 o Extensions to the IODEF-Document Class for Reporting Phishing, 83 RFC5901 85 o Sharing Transaction Fraud Data, RFC5941 87 o IODEF-extension for Structured Cybersecurity Information, RFCXXXX 89 o Real-time Inter-network Defense (RID), RFC6545 91 o Transport of Real-time Inter-network Defense (RID) Messages over 92 HTTP/TLS, RFC6546. 94 The implementation reports included in this document have been 95 provided by the team or product responsible for the implementations 96 of the mentioned RFCs. Additional submissions are welcome and should 97 be sent to the draft editor. A more complete list of 98 implementations, including open source efforts and vendor products, 99 can also be found at the following location: 101 http://siis.realmv6.org/implementations/ 103 2. Consortiums and Information Sharing and Analysis Centers (ISACs) 105 2.1. Anti-Phishing Working Group 107 Description of how IODEF is used will be provided in a future 108 revision. 110 2.2. Advanced Cyber Defence Centre (ACDC) 112 Description of how IODEF is used will be provided in a future 113 revision. http://www.botfree.eu/ 115 3. Open Source Implementations 117 3.1. EMC/RSA RID Agent 119 The EMC/RSA RID agent is an open source implementation of the 120 Internet Engineering Task Force (IETF) standards for the exchange of 121 incident and indicator data. The code has been released under an MIT 122 license and development will continue with the open source community 123 at the Github site for RSA Intelligence Sharing: 125 https://github.com/RSAIntelShare/RID-Server.git 127 The code implements the RFC6545, Real-time Inter-network Defense 128 (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code 129 supports the evolving RFC5070-bis Incident Object Description 130 Exchange Format (IODEF) data model from the work in the IETF working 131 group Managed Incident Lightweight Exchange (MILE). 133 3.2. NICT IODEF-SCI implementation 135 Japan's National Institute of Information and Communications 136 Technology (NICT) Network Security Research Institute implemented 137 open source tools for exchanging, accumulating, and locating IODEF- 138 SCI documents. 140 Three tools are available in GitHub. They assist the exchange of 141 IODEF-SCI documents between parties. IODEF-SCI is the IETF draft 142 that extends IODEF so that IODEF document can embed structured 143 cybersecurity information (SCI). For instance, it can embed MMDEF, 144 CEE, MAEC in XML and CVE identifiers. 146 The three tools are generator, exchanger, and parser. The generator 147 generates IODEF-SCI document or appends an XML to existing IODEF 148 document. The exchanger sends the IODEF document to its 149 correspondent node. The parser receives, parses, and stores the 150 IODEF-SCI document. It also equips the interface that enable users 151 to locate IODEF-SCI documents it has ever received. The code has 152 been released under an MIT license and development will continue 153 here. 155 Note that users can enjoy this software with their own 156 responsibility. 158 Available Online: 160 https://github.com/TakeshiTakahashi/IODEF-SCI 162 4. Vendor Implementations 164 4.1. Deep Secure 166 Deep-Secure Guards are built to protect a trusted domain from: 168 o releasing sensitive data that does not meet the organisational 169 security policy 171 o applications receiving badly constructed or malicious data which 172 could exploit a vulnerability (known or unknown) 174 Deep-Secure Guards support HTTPS and XMPP (optimised server to server 175 protocol) transports. The Deep-Secure Guards support transfer of XML 176 based business content by creating a schema to translate the known 177 good content to and from the intermediate format. This means that 178 the Deep-Secure Guards can be used to protect: 180 o IODEF/RID using the HTTPS transport binding (RFC 6546) 182 o IODEF/RID using an XMPP binding 184 o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02) 186 o STIX/TAXII using the HTTPS transport binding 188 Deep-Secure Guards also support the SMTP transport and perform deep 189 content inspection of content including XML attachments. The Mail 190 Guard supports S/MIME and Deep Secure are working on support for the 191 upcoming PLASMA standard which enables information centric policy 192 enforcement of data. 194 4.2. IncMan Suite, DFLabs 196 The Incident Object Description Exchange Format, documented in the 197 RFC 5070, defines a data representation that provides a framework for 198 sharing information commonly exchanged by Computer Security Incident 199 Response Teams (CSIRTs) about computer security incidents. IncMan 200 Suite implements the IODEF standard for exchanging details about 201 incidents, either for exporting and importing activities. This has 202 been introduced to enhance the capabilities of the various CSIRT, to 203 facilitate collaboration and sharing of useful experiences, conveying 204 awareness on specific cases. 206 The IODEF implementation is specified as an XML schema, therefore all 207 data are stored in an xml file: in this file all data of an incident 208 are organized in a hierarchical structure to describe the various 209 objects and their relationships. 211 IncMan Suite relies on IODEF as a transport format, composed by 212 various classes for describing the entities which are part of the 213 incident description: for instance the various relevant timestamps 214 (detect time , start time, end time, report time), the techniques 215 used by the intruders to perpetrate the incident, the impact of the 216 incident, either technical and non-technical (time and monetary) and 217 obviously all systems involved in the incident. 219 4.2.1. Exporting Incidents 221 Each incident defined in IncMan Suite can be exported via a User 222 Interface feature and it will populate an xml document. Due to the 223 nature of the data processed, the IODEF extraction might be 224 considered privacy sensitive by the parties exchanging the 225 information or by those described by it. For this reason, specific 226 care needs to be taken in ensuring the distribution to an appropriate 227 audience or third party, either during the document exchange and 228 subsequent processing. 230 The xml document generated will include description and details of 231 the incident along with all the systems involved and the related 232 information. At this stage it can be distributed for import into a 233 remote system. 235 4.2.2. Importing Incidents 237 IncMan Suite provides a functionality to import incidents stored in 238 files and transported via IODEF-compliant xml documents. The 239 importing process comprises of two steps: firstly, the file is 240 inspected to validate if well formed, then all data are uploaded 241 inside the system. 243 If an incident is already existing in the system with the same 244 incident id, the new one being imported will be created under a new 245 id. This approach prevents from accidentally overwriting existing 246 info or merging inconsistent data. 248 IncMan Suite includes also a feature to upload incidents from emails. 250 The incident, described in xml format, can be stored directly into 251 the body of the email message or transported as an attachment of the 252 email. At regular intervals, customizable by the user, IncMan Suite 253 monitors for incoming emails, filtered by a configurable white-list 254 and black-list mechanism on the sender's email account, then a parser 255 processes the received email and a new incident is created 256 automatically, after having validated the email body or the 257 attachment to ensure it is a well formed format. 259 4.3. Surevine Proof of Concept 261 XMPP is enhanced and extended through the XMPP Extension Protocols 262 (or XEPs). XEP-0268 (http://xmpp.org/extensions/xep-0268.html) 263 describes incident management (using IODEF) of the XMPP network 264 itself, effectively supporting self-healing the XMPP network. In 265 order to more generically cover incident management of a network and 266 over a network, XEP-0268 requires some updates. We are working on 267 these changes together with a new XEP that supports "social 268 networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP- 269 0060). This now allows nodes to publish any type of content and 270 subscribe to and therefore receive the content. XEP-0268 will be 271 used to describe IODEF content. We now have an alpha version of the 272 server-side software and client-side software required to demonstrate 273 the "social networking" capability and are currently enhancing this 274 to support Cyber Incident management in real-time. 276 5. Vendors with Planned Support 278 5.1. Threat Central, HP 280 HP has developed HP Threat Central, a security intelligence platform 281 that enables automated, real-time collaboration between organizations 282 to combat today's increasingly sophisticated cyber attacks. One way 283 automated sharing of threat indicators is achieved is through close 284 integration with the HP ArcSight SIEM for automated upload and 285 consumption of information from the Threat Central Server. In 286 addition HP Threat Central supports open standards for sharing threat 287 information so that participants who do not use HP Security Products 288 can participate in the sharing ecosystem. General availability of 289 Threat Central will be in 2014. It is planned that future versions 290 also support IODEF for the automated upload and download of threat 291 information. 293 6. Acknowledgements 295 The MILE Implementation report has been compiled through the 296 submissions of implementers of INCH and MILE working group standards. 297 A special note of thanks to the following contributors: 299 John Atherton, Surevine 301 Humphrey Browning, Deep-Secure 303 Dario Forte, DFLabs 304 Tomas Sander, HP 306 Ulrich Seldeslachts, ACDC 308 Takeshi Takahashi, National Institute of Information and 309 Communications Technology Network Security Research Institute 311 7. IANA Considerations 313 This memo includes no request to IANA. 315 8. Security Considerations 317 This draft provides a summary of implementation reports from 318 researchers and vendors who have implemented RFCs and drafts from the 319 MILE and INCH working groups. There are no security considerations 320 added in this draft because of the nature of the document. 322 9. Informative References 324 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 325 Object Description Exchange Format", RFC 5070, 326 December 2007. 328 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document 329 Class for Reporting Phishing", RFC 5901, July 2010. 331 [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj, 332 "Sharing Transaction Fraud Data", RFC 5941, August 2010. 334 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 335 RFC 6545, April 2012. 337 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 338 Defense (RID) Messages over HTTP/TLS", RFC 6546, 339 April 2012. 341 Author's Address 343 Kathleen Moriarty (editor) 344 EMC Corporation 345 176 South Street 346 Hopkinton, MA 347 US 349 Email: Kathleen.Moriarty@emc.com