Individual Submission K. Goodier Internet-Draft L-3 Com Intended status: Standards Track D. Rajnovic Expires: March 25, 2012 Cisco September 22, 2011 Guidelines for Extensions to IODEF for Managed Incident Lightweight Exchange draft-goodier-mile-data-markers-00.txt Abstract This document provides extensions to Managed Incident Lightweight Exchange (MILE). MILE describes a subset of Incident Object Description Exchange Format (IODEF) defined in RFC 5070. The Data Markers extension is aimed at exchanging data tags or markers that label categories of information that have significance in the exchange of incident information. These data marker extension is aimed at exchanging data tags or markers that label information exchanged during incident handling. Data markers include sensitivity and data handling requirements that can prevent possible criminal errors in mismarking data. Both network and information security incidents typically result in the loss of service, data, and resources both human and system. Existing extensions to the IODEF- Document Class for Reporting Phishing [RFC 5901] have already been introduced for network security incidents. Data markers introduce extensions for information security incidents so that network providers and Computer Security Incident Response Teams (CSIRT) are equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Data Markers also support Real-time Inter-network Defense (RID) [RFC 6045] that outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute Goodier & Rajnovic Expires March 25, 2012 [Page 1] Internet-Draft MILE Template September 2011 working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 25, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Goodier & Rajnovic Expires March 25, 2012 [Page 2] Internet-Draft MILE Template September 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Applicability of Data Marker Extensions to IODEF . . . . . . . 4 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Extension Definition . . . . . . . . . . . . . . . . . . . 7 2.2.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 7 2.2.2. Example Enumerated Type Extension Definition: E.164 Address . . . . . . . . . . . . . . . . . . . . 8 2.2.3. Example Element Definition: Test . . . . . . . . . . . 9 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Security Considerations . . . . . . . . . . . . . . . . . 10 2.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 2.6. Appendix: XML Schema Definition for Extension . . . . . . 11 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 5.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Goodier & Rajnovic Expires March 25, 2012 [Page 3] Internet-Draft MILE Template September 2011 1. Introduction Guidance has improved for the handling of privacy and other data markers to ensure the consistent application of security controls in profiled implementations. Organizations require help from data marking parties to digitally define the related context and semantics. Rapid incident detection and coordination requires automation. Increases in internet engineering outsourcing via cloud services requires tighter security and knowledge on how data is protected and incidents that could affect that data. It is critical to have automated means to both detect and mitigate/stop attack traffic while augmenting the governance of any internet-based enterprise. Enterprise data marking standards that secure cyberspace particularly within private and hybrid networks require governance methodologies that enable a workforce who has a responsibility to locate and retrieve data in support of Lines of Businesses (LoBs) and specific missions. Data markers provide additional semantic or metadata labeling of IODEF Documents (e.g., for handling or disposition instructions, or compliance with data protection and data retention regulations). 1.1. Terminology Data marker attributes containing enumerated values within IODEF elements may be further extended. For a data marker attribute named "foo", this is achieved by giving the value of "foo" as "ext-marker- value", and adding a new attribute named "ext-marker-foo" containing the extended value. The attributes which can be extended in this way are defined in [RFC5070], and limited by these values. 2. Applicability of Data Marker Extensions to IODEF Before deciding to extend IODEF, the first step is to determine whether an IODEF extension is a good fit for a given problem. There are two answers to this question for data markers: 1. Data markers are critical to the reporting or sharing of information about an incident. 2. Without a data makers extension, IODEF can not adequately represent information about an incident. 2.1. Applicability The five standard use cases that apply to the data markers extension follow: Goodier & Rajnovic Expires March 25, 2012 [Page 4] Internet-Draft MILE Template September 2011 1. Use Case 1:Information Sharing 2. Use Case 2:Incident Query 3. Use Case 3:Investigation Request-Results Sent 4. Use Case 4:Investigation Request-Request Sent 5. Use Case 5:Trace Back Request Use Case 1: Information Sharing: An incident type is identified and marked and CSIRTs would like to share that information with other CSIRTs. The incident information may be a list of IP addresses known to be malicious or a type of an attack described (for example) in MAEC and embedded in an IODEF document. In this use case, a central authority, US CERT, may have knowledge of several instances of an attack type for which the supported community should be notified to increase awareness and detection capabilities for the attack type or sources. Information Sharing Flow: US CERT generates an IODEF document, using the relevant SCAP and marked data information sources, and sends a RID Report message out to all Agency CSIRTs with one or more attack type descriptions or information about malicious entities. No response is required for this communication type. Use Case 2: Incident Query: An incident query communication is used when one CSIRT would like to know if a type of attack has been detected by other CSIRTs. The information provided back can be limited to descriptions of the attack without providing source and destination information if that data is marked as controlled or classified. This use case is sending the request to US CERT because they may have a broad knowledge set of attack types within the government sector to share with Agency CSIRTs. Incident Query Flow: An Agency CSIRT sends an appropriately marked IncidentQuery to US CERT. US CERT responds with an appropriately marked Report message. Use Case 3: Investigation Request-Results Sent: An incident is detected by a CSIRT and further investigation is required to identify and mitigate or stop the attack. In this use case instance, the Agency CSIRT will detect and data mark the incident. It could be identified by any CSIRT including US CERT or the Provider CSIRT in other use cases. Investigation Request Flow: An Agency CSIRT detects an incident. The source of the incident is identified using SCAP and event information and an IODEF document with data markers with data markers is generated. The IODEF document is sent to the Provider CSIRT in a RID Investigation message using the appropriate transport protocol and data markers. The Provider CSIRT decides to work on the incident investigation, then sends the proper ly data marked Result message when the investigation is complete. Note: The Result message Goodier & Rajnovic Expires March 25, 2012 [Page 5] Internet-Draft MILE Template September 2011 can contain the information deemed appropriate for sharing with the Agency CSIRT. Data markers for policy and privacy considerations relative to the incident are required. In this use case, the Provider CSIRT sends the full investigation Report including the source of the attack and the action taken to stop the attack, traffic from the source address was blocked. Use Case 4: Investigation Request-Request Sent: An incident is detected by a CSIRT and further investigation is required to identify and mitigate or stop the attack. In this use case instance, the Agency CSIRT will detect the incident. It could be identified by any CSIRT including US CERT or the Provider CSIRT in other use cases. Investigation Request Flow: An Agency CSIRT detects an incident. The source of the incident is identified using SCAP and event information and an IODEF document with data markers is generated. The IODEF document is sent to the Provider CSIRT in a RID Investigation message using the appropriate transport protocol and data markers. The Provider CSIRT is unable to work on the Investigation request, a RequestAuthorization message is sent to the Agency CSIRT to notify them of the inability to respond at this time. The Agency CSIRT takes an action to block the source address from accessing the application that was targeted using the tools available to them from the Provider. Use Case 5: Trace Back Request: In the case where the source of an incident is unknown (possibly spoofed), the ability to iteratively track an incident through providers or networks may be necessary. This communication flow is similar to the Investigation request, but could involve multiple CSIRTs until a source is found or a party does not have the resources to participate. The actions taken in this case may be close to the source of an attack or downstream Provider depending on who cooperates and marks data. This use case just describes one of the many possible flows that could occur in the trace back request. Trace Back Request Flow: An Agency CSIRT detects an incident using event information and the appropriate information for that event (application server is targeted in a DDoS attack). The Agency CSIRT generates an IODEF document and encapsulates it in a RID wrapper with data markers for a TraceRequest. The TraceRequest is sent to the upstream to their Provider's CSIRT. The Provider CSIRT confirms receipt with a RequestAuthorization message indicating that this can be looked at now by the Provider CSIRT. The investigation begins at the Provider CSIRT, and the next upstream provider has been found (where the traffic is originating), a TraceRequest message is sent to the next Provider CSIRT. The next Provider CSIRT sends a RequestAuthorization response to both the Agency CSIRT (originator of request) and the Provider CSIRT who sent the TraceRequest. The response provided in the AuthorizationRequest is yes and the incident will be investigated. The investigation has Goodier & Rajnovic Expires March 25, 2012 [Page 6] Internet-Draft MILE Template September 2011 completed and a Result message is sent to the Agency CSIRT. The information provided in the report must be marked according to the policy of the CSIRT that sends the report. In this use case, the information provided is limited to a description of the actions taken with appropriate data markers, the traffic has been rate limited with no information on the true source of the attack. 2.2. Extension Definition This section defines the data markers extension. Extensions to enumerated types are defined in one subsection for each attribute to be extended, enumerating the new values with an explanation of the meaning of the new value. An example enumeration extension is shown in Section 2.2.2, below. Element extensions are defined in one subsection for each element, in top-down order, from the element contained within AdditionalData or RecordItem; an example element extension is shown in Section 2.2.3, below. Each element should be described by a UML diagram as in Figure 1, followed by a description of each of the attributes, and a short description of each of the child elements. Child elements should then be defined in a subsequent subsection, if not already defined in the IODEF document itself, or in another referenced MILE extension document. +---------------------+ | Element | +---------------------+ | TYPE attribute0 |<>----------[ChildExactlyOne] | TYPE attribute1 |<>--{0..1}--[ChildZeroOrOne] | |<>--{0..*}--[ChildZeroOrMore] | |<>--{1..*}--[ChildOneOrMore] +---------------------+ Figure 1: Example UML Element Diagram Elements containing child elements should indicate the multiplicity of those child elements, as shown in the figure above. Allowable TYPEs are discussed in the following subsection. 2.2.1. IODEF Data Types The allowable TYPEs for attributes within IODEF are enumerated in section 2 of [RFC5070], and consist of: o INTEGER Goodier & Rajnovic Expires March 25, 2012 [Page 7] Internet-Draft MILE Template September 2011 o REAL o CHARACTER o STRING o ML_STRING (for strings in encodings other than that of the enclosing document) o BYTE for bytes or byte vectors in Base 64 encoding o HEXBIN for bytes in ascii-hexadecimal encoding o ENUM for enumerated types; allowable values of the enumeration must be defined in the attribute definition o DATETIME for ISO 8601:2000 [RFC3339] encoded timestamps o TIMEZONE for timezones as encoded in section 2.9 of [RFC5070]. o PORTLIST for port lists as encoded in section 2.10 of [RFC5070]. o POSTAL for postal addresses as defined in section 2.23 of [RFC4519]. o NAME for names of natural or legal persons as defined in section 2.3 of [RFC4519]. o PHONE for telephone numbers as defined in section 2.35 of [RFC4519]. o EMAIL for email addresses as defined in section 3.4.1. of [RFC2822]. o URL for URLs as in [RFC2396]. In addition to these simple data types, IODEF provides a compound data type for representing network address information. Addresses included within an extension element should be represented by containing an IODEF:Address element, which supports IPv4 and [RFC2373] IPv6 addresses, as well as MAC, ATM, and BGP autonomous system numbers. Application-layer addresses should be represented with the URL simple attribute type, instead. 2.2.2. Example Enumerated Type Extension Definition: E.164 Address This example extends the IODEF Address element to support the encoding of ENUM-mapped telephone numbers [RFC6116]. Goodier & Rajnovic Expires March 25, 2012 [Page 8] Internet-Draft MILE Template September 2011 Attribute: Address@category Extended value(s): enum-e164 Content format: An E.164 telephone number encoded as a domain name in the e164.int space, e.g. "2.1.2.1.5.5.5.2.1.2.1.e164.int." for +1 212 555 1212, as per section 3.2 of [RFC6116]. Additional considerations: none. 2.2.3. Example Element Definition: Test This example defines the Test class for labeling IODEF test data. The Test class is intended to be included within an AdditionalData element in an IODEF Document. If a Test element is present, it indicates that an IODEF Document contains test data, not a reference to a real incident. The Test class contains information about how the test data was generated. +---------------------+ | Test | +---------------------+ | ENUM category | | STRING generator | | | | | +---------------------+ Figure 2: The Test class The Test class has two attributes: category: Required. ENUM. The type of test data. The permitted values for this attribute are shown below. The default value is "unspecified". 1. unspecified. The document contains test data, but no further information is available. 2. internal. The test data is intended for the internal use of an implementor, and should not be distributed or used outside the context in which it was generated. 3. unit. The test data is intended for unit testing of an implementation, and may be included with the implementation to Goodier & Rajnovic Expires March 25, 2012 [Page 9] Internet-Draft MILE Template September 2011 support this as part of the build and deployment process. 4. interoperability. The test data is intended for interoperability testing of an implementation, and may be freely shared to support this purpose. generator: Optional. STRING. A free-form string identifying the person, entity, or program which generated the test data. 2.3. Examples This section contains example IODEF-Documents illustrating the extension. If example situations are outlined in the applicability section, documents for those examples should be provided in the same order as in the applicability section. Example documents should be tested to validate against the schema given in the appendix. 2.4. Security Considerations [SECDIR and RFC-EDITOR NOTE: Despite the title, this section is NOT a Security Considerations section, rather a template Security Considerations section for future extension documents to be built from this template. See Section 3 for Security Considerations for this document.] Any security considerations [RFC3552] raised by this extension or its deployment should be detailed in this section. Guidance should focus on ensuring the users of this extension do so in a secure fashion, with special attention to non-obvious implications of the transmission or storage of the information represented by an extension. 2.5. IANA Considerations [IANA and RFC-EDITOR NOTE: Despite the title, this section is NOT an IANA Considerations section, rather a template IANA Considerations section for future extension documents to be built from this template. See Section 4 for IANA Considerations for this document.] Any IANA considerations [RFC5226] for the document should be detailed in this section; if none, the section should exist and contain the text "this document has no actions for IANA". IODEF Extensions adding elements to the AdditionalData section of an IODEF document should register their own namespaces and schemas for extensions with IANA; therefore, this section should contain at least a registration request for the namespace and the schema, as follows, modified as appropriate for the extension: Goodier & Rajnovic Expires March 25, 2012 [Page 10] Internet-Draft MILE Template September 2011 Registration request for the IODEF My-Extension namespace: URI: urn:ietf:params:xml:ns:iodef-myextension-1.0 Registrant Contact: Refer here to the authors' addresses section of the document, or to an organizational contact in the case of an extension supported by an external organization. XML: None Registration request for the IODEF My-Extension XML schema: URI: urn:ietf:params:xml:schema:iodef-myextension-1.0 Registrant Contact: Refer here to the authors' addresses section of the document, or to an organizational contact in the case of an extension supported by an external organization. XML: Refer here to the XML Schema in the appendix of the document, or to a well-known external reference in the case of an extension with an externally-defined schema. 2.6. Appendix: XML Schema Definition for Extension The XML Schema describing the elements defined in the Extension Defintion section is given here. Each of the examples in section Section 2.3 should be verified to validate against this schema by automated tools. 3. Security Considerations This document defines a template for MILE extensions to the IODEF and RID documents; as such, it has no security considerations on its own. 4. IANA Considerations This section will be updated. 5. References 5.1. Normative References [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007. Goodier & Rajnovic Expires March 25, 2012 [Page 11] Internet-Draft MILE Template September 2011 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010. 5.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, March 2011. Goodier & Rajnovic Expires March 25, 2012 [Page 12] Internet-Draft MILE Template September 2011 Authors' Addresses Dr. Katherine S. Goodier L-3 Communications" 2720 Technology Drive Annapolis Junction USA Phone: +01 301 547 7043 Email: katherine.goodier@l-3com.com Damir Rajnovic Cisco Email: gaus@cisco.com Goodier & Rajnovic Expires March 25, 2012 [Page 13]