MILE Working Group                                          T. Takahashi
Internet-Draft                                                      NICT
Intended status: Standards Track                            K. Landfield
Expires: December 20, 2013                                        McAfee
                                                               T. Millar
                                                                  USCERT
                                                          Y. Kadobayashi
                                                                   NAIST
                                                            Jun 18, 2013


        IODEF-extension for structured cybersecurity information
                       draft-ietf-mile-sci-07.txt

Abstract

   This document extends the Incident Object Description Exchange Format
   (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched
   cybersecurity information among cybersecurity entities and facilitate
   their operations.  It provides the capability of embedding structured
   information, such as identifier- and XML-based information.

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
   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 December 20, 2013.

Copyright Notice

   Copyright (c) 2013 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



Takahashi, et al.       Expires December 20, 2013               [Page 1]

Internet-Draft                  IODEF-SCI                       Jun 2013


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Extension Definition . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  IANA Table for Structured Cybersecurity Information  . . .  4
     4.2.  Extended Data Type: XMLDATA  . . . . . . . . . . . . . . .  5
     4.3.  Extended Classes . . . . . . . . . . . . . . . . . . . . .  5
       4.3.1.  AttackPattern  . . . . . . . . . . . . . . . . . . . .  6
       4.3.2.  Platform . . . . . . . . . . . . . . . . . . . . . . .  8
       4.3.3.  Vulnerability  . . . . . . . . . . . . . . . . . . . .  9
       4.3.4.  Scoring  . . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.5.  Weakness . . . . . . . . . . . . . . . . . . . . . . . 11
       4.3.6.  EventReport  . . . . . . . . . . . . . . . . . . . . . 12
       4.3.7.  Verifcation  . . . . . . . . . . . . . . . . . . . . . 13
       4.3.8.  Remediation  . . . . . . . . . . . . . . . . . . . . . 14
   5.  Mandatory to Implement features  . . . . . . . . . . . . . . . 15
     5.1.  MTI schema for an embedded XML . . . . . . . . . . . . . . 16
     5.2.  An Example XML . . . . . . . . . . . . . . . . . . . . . . 17
     5.3.  An XML Schema for the Extension  . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
     6.1.  Transport-Specific Concerns  . . . . . . . . . . . . . . . 22
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  Appendix I: Candidate Specifications for the IANA Table  . . . 25
   10. Appendix II: An Example XML using Candidate Specifications . . 29
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     11.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33













Takahashi, et al.       Expires December 20, 2013               [Page 2]

Internet-Draft                  IODEF-SCI                       Jun 2013


1.  Introduction

   The number of cyber attacks is growing day by day, and incident
   information needs to be reported, exchanged, and shared among
   organizations in order to cope with the situation.  IODEF is one of
   the tools enabling such exchange, and is already in use.

   To efficiently run cybersecurity operations, these exchanged
   information needs to be machine-readable.  IODEF provides a
   structured means to describe the information, but it needs to embed
   various non-structured such information in order to convey detailed
   information.  Further structure within IODEF increases IODEF
   documents' machine-readability and thus facilitates streamlining
   cybersecurity operations.

   On the other hand, there exist various other activities facilitating
   detailed and structured description of cybersecurity information, as
   listed in Section 9 .  Since such structured description facilitates
   cybersecurity operations, it would be beneficial to embed and convey
   these information inside IODEF document.

   To enable that, this document extends the IODEF to embed and convey
   various structured cybersecurity information, with which
   cybersecurity operations can be facilitated.  Since IODEF defines a
   flexible and extensible format and supports a granular level of
   specificity, this document defines an extension to IODEF instead of
   defining a new report format.  For clarity, and to eliminate
   duplication, only the additional structures necessary for describing
   the exchange of such structured information are provided.


2.  Terminology

   The terminology used in this document follows the one defined in RFC
   5070 [RFC5070] .

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119] .


3.  Applicability

   To maintain cybersecurity, organization needs to exchange
   cybersecurity information, which includes the following information:
   attack pattern, platform information, vulnerability and weakness,
   countermeasure instruction, computer event log, and the severity.




Takahashi, et al.       Expires December 20, 2013               [Page 3]

Internet-Draft                  IODEF-SCI                       Jun 2013


   IODEF provides a scheme to describe and exchange such information
   among interested parties.  However, it does not define the detailed
   format to describe such information.

   On the other hand, there already exist structured and detailed
   formats for describing those information and facilitating such
   exchange.  Major of them are listed in Section 9 .  By embedding them
   into the IODEF document, the document can convey more detailed
   contents to the receivers, and the document can be easily reused.

   These structured cybersecurity information facilitates cybersecurity
   operation at the receiver side.  Since the information is machine-
   readable, the data can be processed by computers.  That expedites the
   automation of cybersecurity operations

   For instance, an organization wishing to report a security incident
   wants to describe what vulnerability was exploited.  Then the sender
   can simply use IODEF, where an XML [XML1.0] -based attack pattern
   record that follows the syntax and vocabulary defined by an industry
   specification is embedded instead of describing everything in free
   format text.  Receiver can identify the needed details of the attack
   pattern by looking up some of the XML tags defined by the
   specification.  Receiver can accumulate the attack pattern record in
   its database and could distribute it to the interested parties if
   needed, without needing human interventions.

   Another example is that, when an administrator wishes to check the
   configuration of host computers in his organization, he may send a
   query to host computers, which may automatically generate XML-based
   software configuration information upon receiving thequery by running
   a software and may embed that to an IODEF document, which is then
   sent back to the administrator.


4.  Extension Definition

   This draft extends IODEF to embed structured cybersecurity
   information by introducing new classes, with which these information
   can be embedded inside IODEF document as element contents of
   AdditionalData and RecordItem classes.

4.1.  IANA Table for Structured Cybersecurity Information

   This extension embeds structured cybersecurity information defined by
   the other specifications.  The list of supported specifications is
   managed by IANA, and this draft defines the needed field for the
   list's entry.




Takahashi, et al.       Expires December 20, 2013               [Page 4]

Internet-Draft                  IODEF-SCI                       Jun 2013


   Each entry has namespace [XMLNames] , specification name, version,
   reference URI, and applicable classes for each specification.
   Arbitrary URIs that may help readers to understand the specification
   could be embedded inside the Reference URI field, but it is
   recommended that standard/informational URI describing the
   specification is prepared and is embedded here.

   The initial IANA table has only one entry, as below.



     Namespace:          http://www.ietf.org/draft_IODEF-SCI/MTI
     Specification Name: IODEF-SCI MTI
     Version:            1.0
     Reference URI:      http://www.ietf.org/draft_IODEF-SCI/MTI
     Applicable Classes: AttackPattern


   The table is to be managed by IANA using the Expert Review [RFC5226]
   and Specification Required [RFC5226] allocation policies as further
   specified in Section 7 .

   The SpecID attributes of extended classes (Section 4.3) must allow
   the values of the specifications' namespace fields, but otherwise,
   implementations are not required to support all specifications of the
   IANA table and may choose which specifications to support, though the
   specification listed in the initial table needs to be minimally
   supported, as described in Section 5.  In case an implementation
   received a data it does not support, it may expand its functionality
   by looking up the IANA table or notify the sender of its inability to
   parse the data by using any means defined outside the scope of this
   specification.

4.2.  Extended Data Type: XMLDATA

   This extension inherits all of the data types defined in the IODEF
   model.  One data type is added: XMLDATA.  An embedded XML data is
   represented by the XMLDATA data type.  This type is defined as the
   extension to the iodef:ExtensionType [RFC5070] , whose dtype
   attribute is set to "xml."

4.3.  Extended Classes

   The IODEF Incident element [RFC5070] is summarized below.  It is
   expressed in Unified Modeling Language (UML) syntax as used in the
   IODEF specification.  The UML representation is for illustrative
   purposes only; elements are specified in XML as defined in Appendix
   A.



Takahashi, et al.       Expires December 20, 2013               [Page 5]

Internet-Draft                  IODEF-SCI                       Jun 2013


+---------------+
| Incident      |
+---------------+
| ENUM purpose  |<>---------[IncidentID]
| STRING        |<>--{0..1}-[AlternativeID]
|   ext-purpose |<>--{0..1}-[RelatedActivity]
| ENUM lang     |<>--{0..1}-[DetectTime]
| ENUM          |<>--{0..1}-[StartTime]
|   restriction |<>--{0..1}-[EndTime]
|               |<>---------[ReportTime]
|               |<>--{0..*}-[Description]
|               |<>--{1..*}-[Assessment]
|               |<>--{0..*}-[Method]
|               |            |<>--{0..*}-[AdditionalData]
|               |                  |<>--{0..*}-[AttackPattern]
|               |                  |<>--{0..*}-[Vulnerability]
|               |                  |<>--{0..*}-[Weakness]
|               |<>--{1..*}-[Contact]
|               |<>--{0..*}-[EventData]
|               |            |<>--{0..*}-[Flow]
|               |            |     |<>--{1..*}-[System]
|               |            |           |<>--{0..*}-[AdditionalData]
|               |            |                 |<>--{0..*}-[Platform]
|               |            |<>--{0..*}-[Expectation]
|               |            |<>--{0..1}-[Record]
|               |                  |<>--{1..*}-[RecordData]
|               |                        |<>--{1..*}-[RecordItem]
|               |                              |<>--{0..*}-[EventReport]
|               |<>--{0..1}-[History]
|               |<>--{0..*}-[AdditionalData]
|               |            |<>--{0..*}-[Verification]
|               |            |<>--{0..*}-[Remediation]
+---------------+


                         Figure 1: Incident class

   This extension defines the following seven elements.

4.3.1.  AttackPattern

   An AttackPattern consists of an extension to the
   Incident.Method.AdditionalData element with a dtype of "xml".  The
   extension describes attack patterns of incidents or events.

   It is recommended that Method class SHOULD contain one or more of the
   extension elements whenever available.




Takahashi, et al.       Expires December 20, 2013               [Page 6]

Internet-Draft                  IODEF-SCI                       Jun 2013


   An AttackPattern class is structured as follows.


   +------------------------+
   | AttackPattern          |
   +------------------------+
   | ENUM SpecID            |<>--(0..*)-[ RawData ]
   | STRING ext-SpecID      |<>--(0..*)-[ Reference ]
   | STRING AttackPatternID |<>--(0..*)-[ Platform ]
   +------------------------+


                       Figure 2: AttackPattern class

   This class has the following attributes.

   SpecID:  REQUIRED.  ENUM.  A specification's identifier that
      specifies the format of a structured cybersecurity information.
      The value should be chosen from the namespaces [XMLNames] listed
      in the IANA table (Section 4.1) or "private".  The value "private"
      is prepared for conveying RawData based on a format that is not
      listed in the table.  This is usually used for conveying data
      formatted according to an organization's private schema.  When the
      value "private" is used, ext-SpecID element MUST be used.

   ext-SpecID:  OPTIONAL.  STRING.  A specification's identifier that
      specifies the format of a structured cybersecurity information.
      When this element is used, the value of SpecID element must be
      "private."

   AttackPatternID:  OPTIONAL.  STRING.  An identifier of an attack
      pattern to be reported.  This attribute SHOULD be used whenever
      such identifier is available.  Both RawData and Reference elements
      MUST NOT be used when this attribute is used, while either of them
      MUST be used if this attribute is omitted.

   The AttackPattern class is composed of the following aggregate
   classes.

   RawData:  Zero or more.  XMLDATA.  A complete document that is
      formatted according to the specification and its version
      identified by the SpecID/ext-SpecID.  When this element is used,
      writers/senders MUST ensure that the namespace specified by
      SpecID/ext-SpecID and the one used in the RawData element are
      consistent; if not, the namespace identified by SpecID SHOULD be
      prefered, and the inconsistency SHOULD be logged so a human can
      correct the problem.




Takahashi, et al.       Expires December 20, 2013               [Page 7]

Internet-Draft                  IODEF-SCI                       Jun 2013


   Reference:  Zero or more of iodef:Reference [RFC5070] .  This element
      allows an IODEF document to include a link to a structured
      information instead of directly embedding it into a RawData
      element.

   Platform:  Zero or more.  An identifier of software platform involved
      in the specific attack pattern, which is elaborated in
      Section 4.3.2 .

4.3.2.  Platform

   A Platform identifies a software platform.  It is recommended that
   AttackPattern, Vulnerability, Weakness, and System classes contain
   this elements whenever available.

   A Platform element is structured as follows.


   +----------------------+
   | Platform             |
   +----------------------+
   | ENUM SpecID          |<>--(0..*)-[ RawData ]
   | STRING ext-SpecID    |<>--(0..*)-[ Reference ]
   | STRING PlatformID    |
   +----------------------+


                         Figure 3: Platform class

   This class has the following attributes.

   SpecID:  REQUIRED.  ENUM.  The meaning of this attribute is the same
      as that of the AttackPattern class (Section 4.3.1) .

   ext-SpecID:  OPTIONAL.  STRING.  The meaning of this attribute is the
      same as that of the AttackPattern class (Section 4.3.1) .

   PlatformID:  OPTIONAL.  STRING.  An identifier of a platform to be
      reported.  This attribute SHOULD be used whenever such identifier
      is available.  Both RawData and Reference elements MUST NOT be
      used when this attribute is used, while either of them MUST be
      used if this attribute is omitted.

   This class is composed of the following aggregate classes.







Takahashi, et al.       Expires December 20, 2013               [Page 8]

Internet-Draft                  IODEF-SCI                       Jun 2013


   RawData:  Zero or more.  XMLDATA.  The meaning of this element is the
      same as that of the AttackPattern class (Section 4.3.1) .

   Reference:  Zero or more of iodef:Reference [RFC5070] .  The meaning
      of this element is the same as that of the AttackPattern class
      (Section 4.3.1) .

4.3.3.  Vulnerability

   A Vulnerability consists of an extension to the
   Incident.Method.AdditionalData element with a dtype of "xml".  The
   extension describes the (candidate) vulnerabilities of incidents or
   events.

   It is recommended that Method class SHOULD contain one or more of the
   extension elements whenever available.

   A Vulnerability element is structured as follows.


   +------------------------+
   | Vulnerability          |
   +------------------------+
   | ENUM SpecID            |<>--(0..*)-[ RawData ]
   | STRING ext-SpecID      |<>--(0..*)-[ Reference ]
   | STRING VulnerabilityID |<>--(0..*)-[ Platform ]
   |                        |<>--(0..*)-[ Scoring ]
   +------------------------+


                       Figure 4: Vulnerability class

   This class has the following attributes.

   SpecID:  REQUIRED.  ENUM.  The meaning of this attribute is the same
      as that of the AttackPattern class (Section 4.3.1) .

   ext-SpecID:  OPTIONAL.  STRING.  The meaning of this attribute is the
      same as that of the AttackPattern class (Section 4.3.1) .

   VulnerabilityID:  OPTIONAL.  STRING.  An identifier of a
      vulnerability to be reported.  This attribute SHOULD be used
      whenever such identifier is available.  Both RawData and Reference
      elements MUST NOT be used when this attribute is used, while
      either of them MUST be used if this attribute is omitted.

   This class is composed of the following aggregate classes.




Takahashi, et al.       Expires December 20, 2013               [Page 9]

Internet-Draft                  IODEF-SCI                       Jun 2013


   RawData:  Zero or more.  XMLDATA.  The meaning of this element is the
      same as that of the AttackPattern class (Section 4.3.1) .

   Reference:  Zero or more of iodef:Reference [RFC5070] .  The meaning
      of this element is the same as that of the AttackPattern class
      (Section 4.3.1) .

   Platform:  Zero or more.  An identifier of software platform affected
      by the vulnerability, which is elaborated in Section 4.3.2 .

   Scoring:  Zero or more.  An indicator of the severity of the
      vulnerability, such as CVSS and CCSS scores, which is elaborated
      in Section 4.3.4 .  Some of the structured information may include
      scores within it.  In this case, the Scoring element SHOULD NOT be
      used since the RawData element contains the scores.  If a reader/
      receiver detects scores in both RawData and Scoring elements and
      their inconsistency, it SHOULD prefer the scores derived from the
      RawData element, and SHOULD log the inconsistency so a human can
      correct the problem.

4.3.4.  Scoring

   A Scoring class describes the scores of the severity in terms of
   security.  It is recommended that Vulnerability and Weakness classes
   contain the elements whenever available.

   A Scoring class is structured as follows.


   +----------------------+
   | Scoring              |
   +----------------------+
   | ENUM SpecID          |<>---------[ ScoreSet ]
   | STRING ext-SpecID    |
   +----------------------+


                          Figure 5: Scoring class

   This class has two attributes.

   SpecID:  REQUIRED.  ENUM.  The meaning of this attribute is the same
      as that of the AttackPattern class (Section 4.3.1) .

   ext-SpecID:  OPTIONAL.  STRING.  The meaning of this attribute is the
      same as that of the AttackPattern class (Section 4.3.1) .

   This class is composed of an aggregate class.



Takahashi, et al.       Expires December 20, 2013              [Page 10]

Internet-Draft                  IODEF-SCI                       Jun 2013


   ScoreSet:  One. XMLDATA.  A complete document that is formatted
      according to the specification and its version identified by the
      SpecID/ext-SpecID.  This element includes a set of score
      information.  When this element is used, writers/senders MUST
      ensure that the namespace specified by SpecID/ext-SpecID and the
      one used in the RawData element are consistent; if not, the
      namespace identified by SpecID SHOULD be prefered, and the
      inconsistency SHOULD be logged so a human can correct the problem.

   Writers/senders MUST ensure the specification name and version
   identified by the SpecID are consistent with the contents of the
   Score; if a reader/receiver detects an inconsistency, it SHOULD
   prefer the specification name and version derived from the content,
   and SHOULD log the inconsistency so a human can correct the problem.

4.3.5.  Weakness

   A Weakness consists of an extension to the
   Incident.Method.AdditionalData element with a dtype of "xml".  The
   extension describes the weakness types of incidents or events.

   It is recommended that Method class SHOULD contain one or more of the
   extension elements whenever available.

   A Weakness element is structured as follows.


   +----------------------+
   | Weakness             |
   +----------------------+
   | ENUM SpecID          |<>--(0..*)-[ RawData ]
   | STRING ext-SpecID    |<>--(0..*)-[ Reference ]
   | STRING WeaknessID    |<>--(0..*)-[ Platform ]
   |                      |<>--(0..*)-[ Scoring ]
   +----------------------+


                         Figure 6: Weakness class

   This class has the following attributes.

   SpecID:  REQUIRED.  ENUM.  The meaning of this attribute is the same
      as that of the AttackPattern class (Section 4.3.1) .

   ext-SpecID:  OPTIONAL.  STRING.  The meaning of this attribute is the
      same as that of the AttackPattern class (Section 4.3.1) .





Takahashi, et al.       Expires December 20, 2013              [Page 11]

Internet-Draft                  IODEF-SCI                       Jun 2013


   WeaknessID:  OPTIONAL.  STRING.  An identifier of a weakness to be
      reported.  This attribute SHOULD be used whenever such identifier
      is available/ Both RawData and Reference elements MUST NOT be used
      when this attribute is used, while either of them MUST be used if
      this attribute is omitted.

   This class is composed of the following aggregate classes.

   RawData:  Zero or more.  XMLDATA.  The meaning of this element is the
      same as that of the AttackPattern class (Section 4.3.1) .

   Reference:  Zero or more of iodef:Reference [RFC5070] .  The meaning
      of this element is the same as that of the AttackPattern class
      (Section 4.3.1) .

   Platform:  Zero or more.  An identifier of software platform affected
      by the weakness, which is elaborated in Section 4.3.2 .

   Scoring:  Zero or more.  An indicator of the severity of the
      weakness, such as CWSS score, which is elaborated in Section 4.3.4
      .

4.3.6.  EventReport

   An EventReport consists of an extension to the
   Incident.EventData.Record.RecordData.RecordItem element with a dtype
   of "xml".  The extension embeds structured event reports.

   It is recommended that RecordItem class SHOULD contain one or more of
   the extension elements whenever available.

   An EventReport element is structured as follows.


   +----------------------+
   | EventReport          |
   +----------------------+
   | ENUM SpecID          |<>--(0..*)-[ RawData ]
   | STRING ext-SpecID    |<>--(0..*)-[ Reference ]
   | STRING EventID       |
   +----------------------+


                        Figure 7: EventReport class

   This class has the following attributes.





Takahashi, et al.       Expires December 20, 2013              [Page 12]

Internet-Draft                  IODEF-SCI                       Jun 2013


   SpecID:  REQUIRED.  ENUM.  The meaning of this attribute is the same
      as that of the AttackPattern class (Section 4.3.1) .

   ext-SpecID:  OPTIONAL.  STRING.  The meaning of this attribute is the
      same as that of the AttackPattern class (Section 4.3.1) .

   EventID:  OPTIONAL.  STRING.  An identifier of an event to be
      reported.  This attribute SHOULD be used whenever such identifier
      is available.  Both RawData and Reference elements MUST NOT be
      used when this attribute is used, while either of them MUST be
      used if this attribute is omitted.

   This class is composed of three aggregate classes.

   RawData:  Zero or more.  XMLDATA.  The meaning of this element is the
      same as that of the AttackPattern class (Section 4.3.1) .

   Reference:  Zero or more of iodef:Reference [RFC5070] .  The meaning
      of this element is the same as that of the AttackPattern class
      (Section 4.3.1) .

   This class MUST contain at least one of RawData or Reference
   elements.  Writers/senders MUST ensure the specification name and
   version identified by the SpecID are consistent with the contents of
   the RawData; if a reader/receiver detects an inconsistency, it SHOULD
   prefer the specification name and version derived from the content,
   and SHOULD log the inconsistency so a human can correct the problem.

4.3.7.  Verifcation

   A Verification consists of an extension to the
   Incident.AdditionalData element with a dtype of "xml".  The extension
   elements describes incident on vefifying incidents.

   A Verification class is structured as follows.


   +----------------------+
   | Verification         |
   +----------------------+
   | ENUM SpecID          |<>--(0..*)-[ RawData ]
   | STRING ext-SpecID    |<>--(0..*)-[ Reference ]
   | STRING VerificationID|
   +----------------------+


                       Figure 8: Verification class




Takahashi, et al.       Expires December 20, 2013              [Page 13]

Internet-Draft                  IODEF-SCI                       Jun 2013


   This class has the following attributes.

   SpecID:  REQUIRED.  ENUM.  The meaning of this attribute is the same
      as that of the AttackPattern class (Section 4.3.1) .

   ext-SpecID:  OPTIONAL.  STRING.  The meaning of this attribute is the
      same as that of the AttackPattern class (Section 4.3.1) .

   VerificationID:  OPTIONAL.  STRING.  An identifier of an check item
      to be reported.  This attribute SHOULD be used whenever such
      identifier is available.  Both RawData and Reference elements MUST
      NOT be used when this attribute is used, while either of them MUST
      be used if this attribute is omitted.

   This class is composed of two aggregate classes.

   RawData:  Zero or more.  XMLDATA.  The meaning of this element is the
      same as that of the AttackPattern class (Section 4.3.1) .

   Reference:  Zero or more of iodef:Reference [RFC5070] .  The meaning
      of this element is the same as that of the AttackPattern class
      (Section 4.3.1) .

   This class MUST contain at least either of RawData and Reference
   elements.  Writers/senders MUST ensure the specification name and
   version identified by the SpecID are consistent with the contents of
   the RawData; if a reader/receiver detects an inconsistency, it SHOULD
   prefer the specification name and version derived from the content,
   and SHOULD log the inconsistency so a human can correct the problem.

4.3.8.  Remediation

   A Remediation consists of an extension to the Incident.AdditionalData
   element with a dtype of "xml".  The extension elements describes
   incident remediation information including instructions.

   It is recommended that Incident class SHOULD contain one or more of
   this extension elements whenever available.

   A Remediation class is structured as follows.











Takahashi, et al.       Expires December 20, 2013              [Page 14]

Internet-Draft                  IODEF-SCI                       Jun 2013


   +----------------------+
   | Remediation          |
   +----------------------+
   | ENUM SpecID          |<>--(0..*)-[ RawData ]
   | STRING ext-SpecID    |<>--(0..*)-[ Reference ]
   | String RemediationID |
   +----------------------+


                        Figure 9: Remediation class

   This class has the following attributes.

   SpecID:  REQUIRED.  ENUM.  The meaning of this attribute is the same
      as that of the AttackPattern class (Section 4.3.1) .

   ext-SpecID:  OPTIONAL.  STRING.  The meaning of this attribute is the
      same as that of the AttackPattern class (Section 4.3.1) .

   RemediationID:  OPTIONAL.  STRING.  An identifier of a remediation
      information to be reported.  This attribute SHOULD be used
      whenever such identifier is available.  Both RawData and Reference
      elements MUST NOT be used when this attribute is used, while
      either of them MUST be used if this attribute is omitted.

   This class is composed of two aggregate classes.

   RawData:  Zero or more.  XMLDATA.  The meaning of this element is the
      same as that of the AttackPattern class (Section 4.3.1) .

   Reference:  Zero or more of iodef:Reference [RFC5070] .  The meaning
      of this element is the same as that of the AttackPattern class
      (Section 4.3.1) .

   This class MUST contain at least either of RawData and Reference
   elements.  Writers/senders MUST ensure the specification name and
   version identified by the SpecID are consistent with the contents of
   the RawData; if a reader/receiver detects an inconsistency, it SHOULD
   prefer the specification name and version derived from the content,
   and SHOULD log the inconsistency so a human can correct the problem.


5.  Mandatory to Implement features

   The implementation of this draft MUST be capable of sending and
   receiving the XML conforming to the specification listed in the
   initial IANA table described in Section 4.1, i.e., IODEF-SCI MTI
   version 1.0, without error.



Takahashi, et al.       Expires December 20, 2013              [Page 15]

Internet-Draft                  IODEF-SCI                       Jun 2013


   The receiver MUST be capable of validating received XML documents
   that are embedeed inside that against their schemata.  Note that the
   receiver can look up the namespace in the IANA table to understand
   what specifications the embedded XML documents follows.

   This section provides the schema of the IODEF-SCI MTI version 1.0, an
   XML comformant to this draft, and a scehma for that.

5.1.  MTI schema for an embedded XML

   This draft identified IODEF-SCI MTI version 1.0 as its MTI, and its
   schema is provided here.  Note that the schema is generated for the
   purpose of testing minimal interoperability of the implementations.


 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://www.ietf.org/draft_IODEF-SCI/MTI"
  xmlns="http://www.ietf.org/draft_IODEF-SCI/MTI"
  elementFormDefault="qualified" version="1.0">

 <xs:element name="AttackInfo">
   <xs:complexType>
     <xs:sequence>
       <xs:element name="item" type="ItemType" minOccurs="1"
        maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="version" type="xs:token" use="optional"/>
   </xs:complexType>
 </xs:element>

 <xs:complexType name="ItemType">
   <xs:sequence>
     <xs:element name="category" type="xs:string" maxOccurs="1"
      minOccurs="0"/>
     <xs:element name="synopsis" type="xs:string" maxOccurs="1"
      minOccurs="0"/>
     <xs:element name="timestamp" type="xs:dateTime" maxOccurs="1"
      minOccurs="0"/>
     <xs:element name="attackSource" type="xs:string" maxOccurs="1"
      minOccurs="0"/>
     <xs:element name="attackTarget" type="xs:string" maxOccurs="1"
      minOccurs="0"/>
     <xs:element name="reference" type="xs:string" maxOccurs="unbounded"
      minOccurs="0"/>
   </xs:sequence>
   <xs:attribute use="optional" name="id" type="xs:string"/>
 </xs:complexType>



Takahashi, et al.       Expires December 20, 2013              [Page 16]

Internet-Draft                  IODEF-SCI                       Jun 2013


 </xs:schema>


5.2.  An Example XML

   An example IODEF document for checking implementation's MTI
   conformity is provided here.  The document carries an XML that
   follows the MTI schema described in Section 5.1.  Implementations of
   this specification must be capable of parsing the example XML.


<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document version="1.00" lang="en"
 xmlns="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:iodef-sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Incident purpose="reporting">
    <IncidentID name="iodef-sci.example.com">189493</IncidentID>
    <ReportTime>2013-06-18T23:19:24+00:00</ReportTime>
    <Description>a candidate security incident</Description>
    <Assessment>
      <Impact completion="failed" type="admin" />
    </Assessment>
    <Method>
      <Description>A candidate attack event</Description>
      <AdditionalData dtype="xml">
        <iodef-sci:AttackPattern
         SpecID="http://www.ietf.org/draft_IODEF-SCI/MTI">
          <iodef-sci:RawData dtype="xml">
            <AttackInfo
             xmlns="http://www.ietf.org/draft_IODEF-SCI/MTI"
             version="1.0">
              <item>
                <category>DNS named version attempt</category>
                <synopsis>It is possible to obtain the version number
                          of the remote DNS server.</synopsis>
                <timestamp>2013-06-28T15:12:50.726000</timestamp>
                <attackSource>150.65.32.90:37225</attackSource>
                <attackTarget>200.130.27.73:53</attackTarget>
                <reference>http://iodef-sci.example.com/10028</reference>
              </item>
            </AttackInfo>
          </iodef-sci:RawData>
        </iodef-sci:AttackPattern>
        <iodef-sci:AttackPattern
         SpecID="http://www.ietf.org/draft_IODEF-SCI/MTI"
         AttackPatternID="AttackInfo-10030"/>



Takahashi, et al.       Expires December 20, 2013              [Page 17]

Internet-Draft                  IODEF-SCI                       Jun 2013


      </AdditionalData>
    </Method>
    <Contact role="creator" type="organization">
      <ContactName>iodef-sci.example.com</ContactName>
      <RegistryHandle registry="arin">iodef-sci.example-com
      </RegistryHandle>
      <Email>contact@csirt.example.com</Email>
    </Contact>
    <EventData>
      <Flow>
        <System category="source">
          <Node>
            <Address category="ipv4-addr">192.0.2.200</Address>
            <Counter type="event">57</Counter>
          </Node>
        </System>
        <System category="target">
          <Node>
            <Address category="ipv4-net">192.0.2.16/28</Address>
          </Node>
          <Service ip_protocol="4">
            <Port>80</Port>
          </Service>
        </System>
      </Flow>
      <Expectation action="block-host" />
      <Expectation action="other" />
    </EventData>
  </Incident>
</IODEF-Document>


5.3.  An XML Schema for the Extension

   An XML Schema describing the elements defined in this draft is given
   here.  Any XMLs compliant to this draft including the ones in
   Section 5.2 and Section 10 should be verified against this schema by
   automated tools.


<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="urn:ietf:params:xml:ns:iodef-sci-1.0"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:iodef-sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
 elementFormDefault="qualified" attributeFormDefault="unqualified">




Takahashi, et al.       Expires December 20, 2013              [Page 18]

Internet-Draft                  IODEF-SCI                       Jun 2013


<xsd:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
 schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"/>

<xsd:complexType name="XMLDATA">
  <xsd:complexContent>
    <xsd:restriction base="iodef:ExtensionType">
      <xsd:sequence>
        <xsd:any namespace="##any" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="dtype" type="iodef:dtype-type"
       use="required" fixed="xml"/>
      <xsd:attribute name="ext-dtype" type="xsd:string" use="optional"/>
      <xsd:attribute name="meaning" type="xsd:string"/>
      <xsd:attribute name="formatid" type="xsd:string"/>
      <xsd:attribute name="restriction" type="iodef:restriction-type"/>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

  <xsd:element name="Scoring">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="ScoreSet" type="iodef-sci:XMLDATA"
         minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="AttackPattern">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice>
        <xsd:element ref="iodef-sci:Platform" minOccurs="0"
         maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
      <xsd:attribute name="AttackPatternID" type="xsd:string"



Takahashi, et al.       Expires December 20, 2013              [Page 19]

Internet-Draft                  IODEF-SCI                       Jun 2013


       use="optional"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="Vulnerability">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice>
        <xsd:element ref="iodef-sci:Platform" minOccurs="0"
         maxOccurs="unbounded"/>
        <xsd:element ref="iodef-sci:Scoring" minOccurs="0"
         maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
      <xsd:attribute name="VulnerabilityID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="Weakness">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice>
        <xsd:element ref="iodef-sci:Platform" minOccurs="0"
         maxOccurs="unbounded"/>
        <xsd:element ref="iodef-sci:Scoring" minOccurs="0"
         maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
      <xsd:attribute name="WeaknessID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>




Takahashi, et al.       Expires December 20, 2013              [Page 20]

Internet-Draft                  IODEF-SCI                       Jun 2013


  <xsd:element name="Platform">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
      <xsd:attribute name="PlatformID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="EventReport">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
      <xsd:attribute name="EventID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="Verification">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"



Takahashi, et al.       Expires December 20, 2013              [Page 21]

Internet-Draft                  IODEF-SCI                       Jun 2013


       use="optional"/>
      <xsd:attribute name="VerificationID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="Remediation">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
      <xsd:attribute name="RemediationID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>



6.  Security Considerations

   This document specifies a format for encoding a particular class of
   security incidents appropriate for exchange across organizations.  As
   merely a data representation, it does not directly introduce security
   issues.  However, it is guaranteed that parties exchanging instances
   of this specification will have certain concerns.  For this reason,
   the underlying message format and transport protocol used MUST ensure
   the appropriate degree of confidentiality, integrity, and
   authenticity for the specific environment.

   Organizations that exchange data using this document are URGED to
   develop operating procedures that document the following areas of
   concern.

6.1.  Transport-Specific Concerns

   The underlying messaging format and protocol used to exchange
   instances of the IODEF MUST provide appropriate guarantees of
   confidentiality, integrity, and authenticity.  The use of a



Takahashi, et al.       Expires December 20, 2013              [Page 22]

Internet-Draft                  IODEF-SCI                       Jun 2013


   standardized security protocol is encouraged.  The Real-time Inter-
   network Defense (RID) protocol [RFC6045] and its associated transport
   binding [RFC6046] provide such security.

   The critical security concerns are that these structured information
   may be falsified or they may become corrupt during transit.  In areas
   where transmission security or secrecy is questionable, the
   application of a digital signature and/or message encryption on each
   report will counteract both of these concerns.  We expect that each
   exchanging organization will determine the need, and mechanism, for
   transport protection.


7.  IANA Considerations

   This document uses URNs to describe XML namespaces and XML schemata
   [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism
   described in [RFC3688] .

   Registration request for the IODEF structured cybersecurity
   information extension namespace:

      URI: urn:ietf:params:xml:ns:iodef-sci-1.0

      Registrant Contact: Refer here to the authors' addresses section
      of the document.

      XML: None

   Registration request for the IODEF structured cybersecurity
   information extension XML schema:

      URI: urn:ietf:params:xml:schema:iodef-sci-1.0

      Registrant Contact: Refer here to the authors' addresses section
      of the document.

      XML: Refer here to the XML Schema in the appendix of the document.

   This memo creates the following registry for IANA to manage:

      Name of the registry: "IODEF Structured Cyber Security Information
      Specifications"

      Namespace details: A registry entry for a Structured Cyber
      Security Information Specification (SCI specification) consists
      of:




Takahashi, et al.       Expires December 20, 2013              [Page 23]

Internet-Draft                  IODEF-SCI                       Jun 2013


         Namespace: A URI [RFC3986] that is the XML namespace name used
         by the registered SCI specification.

         Specification Name: A string containing the spelled-out name of
         the SCI specification in human-readable form.

         Reference URI: A list of one or more of the URIs [RFC3986] from
         which the registered specification can be obtained.  The
         registered specification MUST be readily and publicly available
         from that URI.

         Applicable Classes: A list of one or more of the Extended
         Classes specified in Section 4.3 of this document.  The
         registered SCI specification MUST only be used with the
         Extended Classes in the registry entry.

      Information that must be provided to assign a new value: The above
      list of information.

      Fields to record in the registry: Namespace/Specification Name/
      Version/Applicable Classes.

      Initial registry contents: none

      Allocation Policy: Expert Review [RFC5226] and Specification
      Required [RFC5226] .

   The Designated Expert is expected to consult with the mile (Managed
   Incident Lightweight Exchange) working group or its successor if any
   such WG exists (e.g., via email to the working group's mailing list).
   The Designated Expert is expected to retrieve the SCI specification
   from the provided URI in order to check the public availability of
   the specification and verify the correctness of the URI.  An
   important responsibility of the Designated Expert is to ensure that
   the registered Applicable Classes are appropriate for the registered
   SCI specification.


8.  Acknowledgment

   We would like to acknowledge Mr. David Black from EMC, who kindly
   provided generous support, especially on the IANA registry issues.
   We also would like to thank Jon Baker from MITRE, Paul Cichonski from
   NIST, Panos Kampanakis from CISCO, Robert Martin from MITRE, Kathleen
   Moriarty from EMC, Lagadec Philippe from NATO, Shuhei Yamaguchi from
   NICT, Anthony Rutkowski from Yaana Technology, Brian Trammel from
   CERT/NetSA, and David Waltermire from NIST for their sincere
   discussion and feedback on this document.



Takahashi, et al.       Expires December 20, 2013              [Page 24]

Internet-Draft                  IODEF-SCI                       Jun 2013


9.  Appendix I: Candidate Specifications for the IANA Table

   This draft defined the structure of the IANA table in Section 4.1 .
   Though the management of the table is up to IANA, this appendix
   provides candidate entries.  Note that OVAL and CVE are registered
   trademarks, and CAPEC, CCE, CEE, CPE, CWE, CWSS, MAEC, and OCIL are
   trademarks, of The MITRE Corporation.

   1.   CAPEC 1.6


     Namespace:          http://capec.mitre.org/observables
     Specification Name: Common Attack Pattern Enumeration and
                         Classification
     Version:            1.6
     Reference URI:      http://capec.mitre.org/
     Applicable Classes: AttackPattern


   2.   CCE 5.0


     Namespace:          http://cce.mitre.org
     Specification Name: Common Configuration Enumeration
     Version:            5.0
     Reference URI:      http://cce.mitre.org/
     Applicable Classes: Verification


   3.   CCSS 1.0


  Namespace:          N/A
  Specification Name: Common Configuration Scoring System
  Version:            1.0
  Reference URI:      http://csrc.nist.gov/publications/PubsNISTIRs.html
                      #NIST-IR-7502
  Applicable Classes: Scoring


   4.   CEE 1.0 alpha


     Namespace:          http://cee.mitre.org
     Specification Name: Common Event Expression
     Version:            1.0 alpha
     Reference URI:      http://cee.mitre.org/
     Applicable Classes: EventReport



Takahashi, et al.       Expires December 20, 2013              [Page 25]

Internet-Draft                  IODEF-SCI                       Jun 2013


   5.   CPE 2.3 Language


  Namespace:          http://cpe.mitre.org/language/2.0
  Specification Name: Common Platform Enumeration Reference
  Version:            2.3
  Reference URI:      http://scap.nist.gov/specifications/cpe/,
                      http://csrc.nist.gov/publications/PubsNISTIRs.html
                      #NIST-IR-7695
  Applicable Classes: Platform


   6.   CPE 2.3 Dictionary


  Namespace:          http://cpe.mitre.org/dictionary/2.0
  Specification Name: Common Platform Enumeration Dictionary
  Version:            2.3
  Reference URI:      http://scap.nist.gov/specifications/cpe/,
                      http://csrc.nist.gov/publications/PubsNISTIRs.html
                      #NIST-IR-7697
  Applicable Classes: Platform


   7.   CVE 1.0


     Namespace:          http://cve.mitre.org/cve/downloads/1.0
     Specification Name: Common Vulnerability and Exposures
     Version:            1.0
     Reference URI:      http://cve.mitre.org/
     Applicable Classes: Vulnerability


   8.   CVRF 1.0


     Namespace:          http://www.icasi.org/CVRF/schema/cvrf/1.0
     Specification Name: Common Vulnerability Reporting Format
     Version:            1.0
     Reference URI:      http://www.icasi.org/cvrf
     Applicable Classes: Vulnerability


   9.   CVSS 2.0






Takahashi, et al.       Expires December 20, 2013              [Page 26]

Internet-Draft                  IODEF-SCI                       Jun 2013


     Namespace:          http://scap.nist.gov/schema/cvss-v2/1.0
     Specification Name: Common Vulnerability Scoring System
     Version:            2
     Reference URI:      http://www.first.org/cvss
     Applicable Classes: Scoring


   10.  CWE 5.0


     Namespace:          N/A
     Specification Name: Common Weakness Enumeration
     Version:            5.1
     Reference URI:      http://cwe.mitre.org/
     Applicable Classes: Weakness


   11.  CWSS 0.8


     Namespace:          N/A
     Specification Name: Common Weakness Scoring System
     Version:            0.8
     Reference URI:      http://cwe.mitre.org/cwss/
     Applicable Classes: Scoring


   12.  MAEC 2.0


  Namespace:          http://maec.mitre.org/XMLSchema/maec-core-2
  Specification Name: Malware Attribute Enumeration and Characterization
  Version:            2.0
  Reference URI:      http://maec.mitre.org/
  Applicable Classes: EventReport, AttackPattern


   13.  MMDEF 2.0


  Namespace:          http://maec.mitre.org/XMLSchema/maec-core-2
  Specification Name: Malware Metadata Exchange Format
  Version:            2.0
  Reference URI:      https://standards.ieee.org/develop/indconn/icsg/mmdef.htm
  Applicable Classes: AttackPattern






Takahashi, et al.       Expires December 20, 2013              [Page 27]

Internet-Draft                  IODEF-SCI                       Jun 2013


   14.  OCIL 2.0


  Namespace:          http://scap.nist.gov/schema/ocil/2.0
  Specification Name: Open Checklist Interactive Language
  Version:            2.0
  Reference URI:      http://scap.nist.gov/specifications/ocil/,
                      http://csrc.nist.gov/publications/PubsNISTIRs.html
                      #NIST-IR-7692
  Applicable Classes: Verification


   15.  OVAL 5.10.1 Definitions


    Namespace:          http://oval.mitre.org/XMLSchema/oval-definitions-5
    Specification Name: Open Vulnerability and Assessment Language
    Version:            5.10.1
    Reference URI:      http://oval.mitre.org/
    Applicable Classes: Verification


   16.  OVAL 5.10.1 Results


     Namespace:          http://oval.mitre.org/XMLSchema/oval-results-5
     Specification Name: Open Vulnerability and Assessment Language
     Version:            5.10.1
     Reference URI:      http://oval.mitre.org/
     Applicable Classes: Verification


   17.  OVAL 5.10.1 Common


     Namespace:          http://oval.mitre.org/XMLSchema/oval-common-5
     Specification Name: Open Vulnerability and Assessment Language
     Version:            5.10.1
     Reference URI:      http://oval.mitre.org/
     Applicable Classes: Verification


   18.  XCCDF 1.2








Takahashi, et al.       Expires December 20, 2013              [Page 28]

Internet-Draft                  IODEF-SCI                       Jun 2013


  Namespace:          http://checklists.nist.gov/xccdf/1.2
  Specification Name: Extensible Configuration Checklist Description
                      Format
  Version:            1.2
  Reference URI:      http://scap.nist.gov/specifications/xccdf/,
                      http://csrc.nist.gov/publications/PubsNISTIRs.html
                      #NIST-IR-7275-r4
  Applicable Classes: Verification



10.  Appendix II: An Example XML using Candidate Specifications

   This section provides an example of an incident encoded in the IODEF.
   This do not necessarily represent the only way to encode a particular
   incident.  This example reports an attack to a CSIRT and is extended
   from the example described in [RFC5070] .  It uses identifiers whose
   dictionary follows CVE 1.0 schema, and it aembeds XML following CEE
   0.6.  Though these specifications are not listed in the IANA table at
   this moment, this section shows the example to demonstrate the
   usability of the draft.


<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document version="1.00" lang="en"
 xmlns="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:iodef-sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Incident purpose="reporting">
    <IncidentID name="csirt.example.com">189493</IncidentID>
    <ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
    <Description>Incident report in company xx</Description>
    <Assessment>
      <Impact completion="failed" type="admin"/>
    </Assessment>
    <Method>
      <Description>An identifier of a vulnerability is embedded
      </Description>
      <AdditionalData dtype="xml">
        <iodef-sci:Vulnerability
         SpecID="http://cve.mitre.org/cve/downloads/1.0"
         VulnerabilityID="CVE-2010-0483"/>
      </AdditionalData>
    </Method>
    <Contact role="creator" type="organization">
      <ContactName>Example.com CSIRT</ContactName>
      <RegistryHandle registry="arin">example-com</RegistryHandle>



Takahashi, et al.       Expires December 20, 2013              [Page 29]

Internet-Draft                  IODEF-SCI                       Jun 2013


      <Email>contact@csirt.example.com</Email>
    </Contact>
        <EventData>
      <Flow>
        <System category="source">
          <Node>
            <Address category="ipv4-addr">192.0.2.200</Address>
            <Counter type="event">57</Counter>
          </Node>
        </System>
        <System category="target">
          <Node>
            <Address category="ipv4-net">192.0.2.16/28</Address>
          </Node>
          <Service ip_protocol="6">
            <Port>80</Port>
          </Service>
          <AdditionalData dtype="xml">
            <iodef-sci:Platform
             SpecID="http://cpe.mitre.org/dictionary/2.0"
             PlatformID="cpe://microsoft:windows:xp:pro:sp2"/>
          </AdditionalData>
        </System>
      </Flow>
      <Expectation action="block-host" />
      <Expectation action="other"/>
      <!-- <RecordItem> has an excerpt from a log -->
      <Record>
        <RecordData>
          <DateTime>2001-09-13T18:11:21+02:00</DateTime>
          <Description>a Web-server event record</Description>
          <RecordItem dtype="xml">
            <iodef-sci:EventReport SpecID="http://cee.mitre.org">
              <iodef-sci:RawData dtype="xml">
                <cee:cee xmlns="http://cee.mitre.org/1.0/profile/"
                 xmlns:cee="http://cee.mitre.org/1.0/">
                  <cee:event>
                    <host>system.example.com</host>
                    <pname>auth</pname>
                    <time>2011-12-20T12:38:05.123456-05:00</time>
                    <appname>application</appname>
                    <pid>123</pid>
                    <sev>10</sev>
                    <action>login</action>
                    <domain>app</domain>
                    <object>account</object>
                    <service>web</service>
                    <status>success</status>



Takahashi, et al.       Expires December 20, 2013              [Page 30]

Internet-Draft                  IODEF-SCI                       Jun 2013


                  </cee:event>
                </cee:cee>
              </iodef-sci:RawData>
            </iodef-sci:EventReport>
          </RecordItem>
        </RecordData>
      </Record>
    </EventData>
    <History>
      <!-- Contact was previously made with the source network owner -->
      <HistoryItem action="contact-source-site">
        <DateTime>2001-09-14T08:19:01+00:00</DateTime>
        <Description>Notification sent to
         constituency-contact@192.0.2.200</Description>
      </HistoryItem>
    </History>
  </Incident>
</IODEF-Document>



11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5070]  Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
              Object Description Exchange Format", RFC 5070,
              December 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6045]  Moriarty, K., "Real-time Inter-network Defense (RID)",
              RFC 6045, November 2010.

   [RFC6046]  Moriarty, K. and B. Trammell, "Transport of Real-time
              Inter-network Defense (RID) Messages", RFC 6046,
              November 2010.

   [XML1.0]   Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and



Takahashi, et al.       Expires December 20, 2013              [Page 31]

Internet-Draft                  IODEF-SCI                       Jun 2013


              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", W3C Recommendation, November 2008.

   [XMLschemaPart1]
              Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
              "XML Schema Part 1: Structures Second Edition",
              W3C Recommendation, October 2004.

   [XMLschemaPart2]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", W3C Recommendation, October 2004.

   [XMLNames]
              Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
              Thomson, ""Namespaces in XML (Third Edition)",
              W3C Recommendation, December 2009.

11.2.  Informative References

   [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.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 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.

   [CAPEC]    The MITRE Corporation, "Common Attack Pattern Enumeration
              and Classification (CAPEC)".

   [CCE]      The MITRE Corporation, "Common Configuration Enumeration
              (CCE)".

   [CCSS]     Scarfone, K. and P. Mell, "The Common Configuration
              Scoring System (CCSS)", NIST Interagency Report 7502,
              December 2010.

   [CEE]      The MITRE Corporation, "Common Event Expression (CEE)".



Takahashi, et al.       Expires December 20, 2013              [Page 32]

Internet-Draft                  IODEF-SCI                       Jun 2013


   [CPE]      National Institute of Standards and Technology, "Common
              Platform Enumeration", June 2011.

   [CVE]      The MITRE Corporation, "Common Vulnerability and Exposures
              (CVE)".

   [CVRF]     ICASI, "Common Vulnerability Reporting Framework (CVRF)".

   [CVSS]     Peter Mell, Karen Scarfone, and Sasha Romanosky, "The
              Common Vulnerability Scoring System (CVSS) and Its
              Applicability to Federal Agency Systems".

   [CWE]      The MITRE Corporation, "Common Weakness Enumeration
              (CWE)".

   [CWSS]     The MITRE Corporation, "Common Weakness Scoring System
              (CWSS)".

   [MAEC]     The MITRE Corporation, "Malware Attribute Enumeration and
              Characterization".

   [MMDEF]    IEEE ICSG Malware Metadata Exchange Format Working Group,
              "Malware Metadata Exchange Format".

   [OCIL]     David Waltermire and Karen Scarfone and Maria Casipe, "The
              Open Checklist Interactive Language (OCIL) Version 2.0",
              April 2011.

   [OVAL]     The MITRE Corporation, "Open Vulnerability and Assessment
              Language (OVAL)".

   [SCAP]     Waltermire, D., Quinn, S., Scarfone, K., and A.
              Halbardier, "The Technical Specification for the Security
              Content Automation Protocol (SCAP): SCAP Version 1.2",
              NIST Special Publication 800-126 Revision 2,
              September 2011.

   [XCCDF]    David Waltermire and Charles Schmidt and Karen Scarfone
              and Neal Ziring, "Specification for the Extensible
              Configuration Checklist Description Format (XCCDF) version
              1.2 (DRAFT)", July 2011.










Takahashi, et al.       Expires December 20, 2013              [Page 33]

Internet-Draft                  IODEF-SCI                       Jun 2013


Authors' Addresses

   Takeshi Takahashi
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi Koganei
   184-8795 Tokyo
   Japan

   Phone: +80 423 27 5862
   Email: takeshi_takahashi@nict.go.jp


   Kent Landfield
   McAfee, Inc
   5000 Headquarters Drive
   Plano, TX 75024
   USA

   Email: Kent_Landfield@McAfee.com


   Thomas Millar
   US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT
   245 Murray Lane SW, Building 410, MS #732
   Washington, DC 20598
   USA

   Phone: +1 888 282 0870
   Email: thomas.millar@us-cert.gov


   Youki Kadobayashi
   Nara Institute of Science and Technology
   8916-5 Takayama, Ikoma
   630-0192 Nara
   Japan

   Email: youki-k@is.aist-nara.ac.jp













Takahashi, et al.       Expires December 20, 2013              [Page 34]