[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/