Internet DRAFT - draft-ietf-mile-sci
draft-ietf-mile-sci
MILE Working Group T. Takahashi
Internet-Draft NICT
Intended status: Standards Track K. Landfield
Expires: July 18, 2014 McAfee
T. Millar
USCERT
Y. Kadobayashi
NAIST
Jan 14, 2014
IODEF-extension for structured cybersecurity information
draft-ietf-mile-sci-13.txt
Abstract
This document extends the Incident Object Description Exchange Format
(IODEF) defined in RFC 5070 [RFC5070] to exchange enriched
cybersecurity information among security experts at organizations and
facilitates their operations. It provides a well-defined pattern to
consistently embed 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 July 18, 2014.
Copyright Notice
Copyright (c) 2014 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
Takahashi, et al. Expires July 18, 2014 [Page 1]
Internet-Draft IODEF-SCI Jan 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5
4.1. IANA Table for Structured Cybersecurity Information . . . 5
4.2. Extended Data Type: XMLDATA . . . . . . . . . . . . . . . 6
4.3. Extending IODEF . . . . . . . . . . . . . . . . . . . . . 6
4.4. Basic Structure of the Extension Classes . . . . . . . . . 7
4.5. Defining Extension Classes . . . . . . . . . . . . . . . . 9
4.5.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 9
4.5.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 10
4.5.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.6. EventReport . . . . . . . . . . . . . . . . . . . . . 13
4.5.7. Verification . . . . . . . . . . . . . . . . . . . . . 14
4.5.8. Remediation . . . . . . . . . . . . . . . . . . . . . 15
5. Mandatory to Implement features . . . . . . . . . . . . . . . 15
5.1. An Example XML . . . . . . . . . . . . . . . . . . . . . . 16
5.2. An XML Schema for the Extension . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 22
6.2. Protection of Sensitive and Private Information . . . . . 23
6.3. Application and Server Security . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Takahashi, et al. Expires July 18, 2014 [Page 2]
Internet-Draft IODEF-SCI Jan 2014
1. Introduction
The number of incidents in cyber society is growing day by day.
Incident information needs to be reported, exchanged, and shared
among organizations in order to cope with the situation. IODEF is
one of the tools already in use that enables such an exchange.
To more efficiently run security operations, information exchanged
between organizations needs to be machine readable. IODEF provides a
means to describe the incident information, but it often needs to
include various non-structured types of incident-related data in
order to convey more specific details about what is occurring.
Further structure within IODEF increases the machine-readability of
the document thus providing a means for better automating certain
security operations.
Within the security community there exist various means for
specifying structured descriptions of cybersecurity information such
as [CAPEC][CCE][CCSS][CEE][CPE][CVE][CVRF][CVSS][CWE][CWSS][MAEC]
[OCIL][OVAL][SCAP][XCCDF]. In this context, cybersecurity
information encompasses a broad range of structured data
representation types that may be used to assess or report on the
security posture of an asset or set of assets. Such structured
descriptions facilitates a better understanding of an incident while
enabling more streamlined automated security operations. Because of
this, it would be beneficial to embed and convey these types of
information inside IODEF documents.
This document extends IODEF to embed and convey various types of
structured information. 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].
Takahashi, et al. Expires July 18, 2014 [Page 3]
Internet-Draft IODEF-SCI Jan 2014
3. Applicability
To maintain awareness of the continually changing security threat
landscape, organization needs to exchange cybersecurity information,
which includes the following information: attack pattern, platform
information, vulnerability and weakness, countermeasure instruction,
computer event logs, and severity assessments. IODEF provides a
scheme to describe and exchange such information among interested
parties. However, it does not define the detailed formats to specify
such information.
There already exists structured and detailed formats for describing
these types of information that can be used in facilitating such an
exchange. They include [CAPEC][CCE][CCSS][CEE][CPE]
[CVE][CVRF][CVSS][CWE][CWSS][MAEC][OCIL][OVAL][SCAP][XCCDF]. By
embedding them into the IODEF document, the document can convey more
detailed context information to the receivers, and the document can
be easily reused.
The use of structured information formats facilitates more advanced
security operations on the receiver side. Since the information is
machine readable, the data can be processed by computers thus
allowing better automation of security operations.
For instance, an organization wishing to report a security incident
wants to describe what vulnerability was exploited. In this case the
sender can simply use IODEF, where an XML-based [XML1.0] attack
pattern record that follows the syntax and vocabulary defined by an
industry specification is embedded, instead of describing everything
in free form text. The receiver can identify the needed details of
the attack pattern by looking up some of the XML tags defined by the
specification. The receiver can accumulate the attack pattern record
in its database and could distribute it to the interested parties as
needed, all without requiring human interventions.
In another example, an administrator is investigating an incident and
detected a configuration problem that he wishes to share with a
partner organization to prevent the same event from occurring. He
accesses configuration information in an internal repository that was
gathered prior to the initial attack specific to a new vulnerability
alert to confirm the configuration was in fact vulnerable. He uses
this information to automatically generate an XML-based software
configuration description, embed it in an IODEF document, and send
the resulting IODEF document to the partner organization.
Takahashi, et al. Expires July 18, 2014 [Page 4]
Internet-Draft IODEF-SCI Jan 2014
4. Extension Definition
This document extends IODEF to embed structured information by
introducing new classes that can be embedded consistently inside an
IODEF document as element contents of the AdditionalData and
RecordItem classes.
4.1. IANA Table for Structured Cybersecurity Information
This extension embeds structured cybersecurity information defined by
other specifications. The list of supported specifications is
managed by IANA, and this document defines the needed fields for the
list's entry.
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: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
Version: 1.2
Reference URI: http://standards.ieee.org/develop
/indconn/icsg/mmdef.html,
http://grouper.ieee.org/groups
/malware/malwg/Schema1.2/
Applicable Classes: AttackPattern
Note that the specification was developed by The Institute of
Electrical and Electronics Engineers, Incorporated (IEEE), through
the Industry Connections Security Group (ICSG) of its Standards
Association.
The table is to be managed by IANA following the allocation policy
specified in Section 7.
The SpecID attributes of extension classes (Section 4.5) 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
Takahashi, et al. Expires July 18, 2014 [Page 5]
Internet-Draft IODEF-SCI Jan 2014
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. Note that the look-up could be done manually or
automatically, but automatic download of data from IANA's website is
not recommended since it is not designed for mass retrieval of data
by multiple devices.
4.2. Extended Data Type: XMLDATA
This extension inherits all of the data types defined in the IODEF
data 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. Extending IODEF
This document defines eight extension classes, namely AttackPattern,
Platform, Vulnerability, Scoring, Weakness, EventReport, Verification
and Remediation. Figure 1 describes the relationships between the
IODEF Incident class [RFC5070] and the newly defined classes. It is
expressed in Unified Modeling Language (UML) syntax as with the RFC
5070 [RFC5070]. The UML representation is for illustrative purposes
only; elements are specified in XML as defined in Section 5.2.
Takahashi, et al. Expires July 18, 2014 [Page 6]
Internet-Draft IODEF-SCI Jan 2014
+---------------+
| 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
4.4. Basic Structure of the Extension Classes
Figure 2 shows the basic structure of the extension classes. Some of
the extension classes have extra elements as defined in Section 4.5,
but the basic structure is the same.
Takahashi, et al. Expires July 18, 2014 [Page 7]
Internet-Draft IODEF-SCI Jan 2014
+---------------------+
| New Class Name |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 2: Basic Structure
Three attributes are defined as below.
SpecID: REQUIRED. ENUM. A specification's identifier that
specifies the format of a structured 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 structured information 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 information. This is usually
used to support private schema that is not listed in the IANA
table (Section 4.1). This attribute MUST be used only when the
value of SpecID element is "private."
ContentID: OPTIONAL. STRING. An identifier of a structured
information. Depending on the extension classes, the content of
the structured information differs. This attribute enables IODEF
documents to covey the identifier of a structured information
instead of conveying the information itself.
Likewise, three elements are defined as below.
RawData: Zero or more. XMLDATA. An XML of a structured
information. This is 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 schema of the XML are consistent; if not, the namespace
identified by SpecID SHOULD be preferred, and the inconsistency
SHOULD be logged so a human can correct the problem.
Reference: Zero or more of iodef:Reference [RFC5070]. A reference
to a structured information. This element allows an IODEF
document to include a link to a structured information instead of
directly embedding it into a RawData element.
Takahashi, et al. Expires July 18, 2014 [Page 8]
Internet-Draft IODEF-SCI Jan 2014
Though ContentID, RawData, and Reference are optional attribute and
elements, one of them MUST be used to convey structured information.
Note that only one of them SHOULD be used to avoid confusing the
receiver.
4.5. Defining Extension Classes
This document defines the following seven extension classes.
4.5.1. AttackPattern
An AttackPattern is an extension class to the
Incident.Method.AdditionalData element with a dtype of "xml". It
describes attack patterns of incidents or events. It is RECOMMENDED
that Method class contain the extension elements whenever available.
An AttackPattern class is structured as follows.
+---------------------+
| AttackPattern |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
+---------------------+
Figure 3: AttackPattern class
This class has the following attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of an attack pattern
information. See Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of an attack pattern
information. See Section 4.4.
Reference: Zero or more. A reference to an attack pattern
information. See Section 4.4.
Takahashi, et al. Expires July 18, 2014 [Page 9]
Internet-Draft IODEF-SCI Jan 2014
Platform: Zero or more. An identifier of software platform involved
in the specific attack pattern. See Section 4.5.2.
4.5.2. Platform
A Platform is an extension class that identifies a software platform.
It is RECOMMENDED that AttackPattern, Vulnerability, Weakness, and
System classes contain the extension elements whenever available. A
Platform element is structured as follows.
+---------------------+
| Platform |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 4: Platform class
This class has the following attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of a platform
information. See Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of a platform information.
See Section 4.4.
Reference: Zero or more. A reference to a platform information.
See Section 4.4.
4.5.3. Vulnerability
A Vulnerability is an extension class to the
Incident.Method.AdditionalData element with a dtype of "xml". The
extension describes the vulnerabilities that are exposed or were
exploited in incidents. It is RECOMMENDED that Method class contain
the extension elements whenever available. A Vulnerability element
is structured as follows.
Takahashi, et al. Expires July 18, 2014 [Page 10]
Internet-Draft IODEF-SCI Jan 2014
+---------------------+
| Vulnerability |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 5: Vulnerability class
This class has the following attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of a vulnerability
information. See Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of a vulnerability
information. See Section 4.4.
Reference: Zero or more. A reference to a vulnerability
information. See Section 4.4.
Platform: Zero or more. An identifier of software platform affected
by the vulnerability. See Section 4.5.2.
Scoring: Zero or more. An indicator of the severity of the
vulnerability. See Section 4.5.4.
4.5.4. Scoring
A Scoring is an extension class that describes the severity scores in
terms of security. It is RECOMMENDED that Vulnerability and Weakness
classes contain the extension elements whenever available. A Scoring
class is structured as follows.
Takahashi, et al. Expires July 18, 2014 [Page 11]
Internet-Draft IODEF-SCI Jan 2014
+---------------------+
| Scoring |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 6: Scoring class
This class has two attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of a score set. See
Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of a score set. See
Section 4.4.
Reference: Zero or more. A reference to a score set. See
Section 4.4.
4.5.5. Weakness
A Weakness is an extension class to the
Incident.Method.AdditionalData element with a dtype of "xml". The
extension describes the weakness types that are exposed or were
exploited in incidents. It is RECOMMENDED that Method class contain
the extension elements whenever available. A Weakness element is
structured as follows.
+---------------------+
| Weakness |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 7: Weakness class
Takahashi, et al. Expires July 18, 2014 [Page 12]
Internet-Draft IODEF-SCI Jan 2014
This class has the following attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of a weakness
information. See Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of a weakness information.
See Section 4.4.
Reference: Zero or more. A reference to a weakness information.
See Section 4.4.
Platform: Zero or more. An identifier of software platform affected
by the weakness. See Section 4.5.2.
Scoring: Zero or more. An indicator of the severity of the
weakness. See Section 4.5.4.
4.5.6. EventReport
An EventReport is an extension class 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 contain the extension elements
whenever available. An EventReport element is structured as follows.
+---------------------+
| EventReport |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 8: EventReport class
This class has the following attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
Takahashi, et al. Expires July 18, 2014 [Page 13]
Internet-Draft IODEF-SCI Jan 2014
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of an event report.
See Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of an event report. See
Section 4.4.
Reference: Zero or more. A reference to an event report. See
Section 4.4.
4.5.7. Verification
A Verification is an extension class to the Incident.AdditionalData
element with a dtype of "xml". The extension elements describes
information on verifying security, e.g., checklist, to cope with
incidents. It is RECOMMENDED that Incident class contain the
extension elements whenever available. A Verification class is
structured as follows.
+---------------------+
| Verification |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 9: Verification class
This class has the following attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of a verification
information. See Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of a verification
information. See Section 4.4.
Takahashi, et al. Expires July 18, 2014 [Page 14]
Internet-Draft IODEF-SCI Jan 2014
Reference: Zero or more. A reference to a verification information.
See Section 4.4.
4.5.8. Remediation
A Remediation is an extension class 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 contain the extension elements
whenever available. A Remediation class is structured as follows.
+---------------------+
| Remediation |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| String ContentID |
+---------------------+
Figure 10: Remediation class
This class has the following attributes.
SpecID: REQUIRED. ENUM. See Section 4.4.
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ContentID: OPTIONAL. STRING. An identifier of a remediation
information. See Section 4.4.
Likewise, this class has the following elements.
RawData: Zero or more. XMLDATA. An XML of a remediation
information. See Section 4.4.
Reference: Zero or more. A reference to a remediation information.
See Section 4.4.
5. Mandatory to Implement features
The implementation of this document MUST be capable of sending and
receiving the XML conforming to the specification listed in the
initial IANA table described in Section 4.1 without error. An SCI
document is an XML document that MUST be well-formed and MUST be
valid according to schemata, including extension schemata, available
to the validator and applicable to the XML document. Note that the
receiver can look up the namespace in the IANA table to understand
Takahashi, et al. Expires July 18, 2014 [Page 15]
Internet-Draft IODEF-SCI Jan 2014
what specifications the embedded XML documents follows.
For the purpose of facilitating the understanding of mandatory to
implement features, the following subsections provide an XML
conformant to this document, and a schema for that.
5.1. An Example XML
An example IODEF document for checking implementation's MTI
conformity is provided here. The document carries MMDEF metadata.
Note that the metadata is generated by genMMDEF [MMDEF] with EICAR
[EICAR] files.
<?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://xml/metadataSharing.xsd">
<iodef-sci:RawData dtype="xml">
<malwareMetaData xmlns="http://xml/metadataSharing.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xml/metadataSharing.xsd
file:metadataSharing.xsd" version="1.200000" id="10000">
<company>N/A</company>
<author>MMDEF Generation Script</author>
<comment>Test MMDEF v1.2 file generated using genMMDEF
</comment>
<timestamp>2013-03-23T15:12:50.726000</timestamp>
<objects>
<file id="6ce6f415d8475545be5ba114f208b0ff">
<md5>6ce6f415d8475545be5ba114f208b0ff</md5>
<sha1>da39a3ee5e6b4b0d3255bfef95601890afd80709</sha1>
<sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca4
95991b7852b855</sha256>
<sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83
Takahashi, et al. Expires July 18, 2014 [Page 16]
Internet-Draft IODEF-SCI Jan 2014
f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b9
31bd47417a81a538327af927da3e</sha512>
<size>184</size>
<filename>eicar_com.zip</filename>
<MIMEType>application/zip</MIMEType>
</file>
<file id="44d88612fea8a8f36de82e1278abb02f">
<md5>44d88612fea8a8f36de82e1278abb02f</md5>
<sha1>3395856ce81f2b7382dee72602f798b642f14140</sha1>
<sha256>275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4
538aabf651fd0f</sha256>
<sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e565e
68847223b8e6b85cb48f3afad842726d99239c9e36505c64b0
dc9a061d9e507d833277ada336ab</sha512>
<size>68</size>
<crc32>1750191932</crc32>
<filename>eicar.com</filename>
<filenameWithinInstaller>eicar.com
</filenameWithinInstaller>
</file>
</objects>
<relationships>
<relationship type="createdBy" id="1">
<source>
<ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]</ref>
</source>
<target>
<ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]</ref>
</target>
<timestamp>2013-03-23T15:12:50.744000</timestamp>
</relationship>
</relationships>
</malwareMetaData>
</iodef-sci:RawData>
</iodef-sci:AttackPattern>
</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>
Takahashi, et al. Expires July 18, 2014 [Page 17]
Internet-Draft IODEF-SCI Jan 2014
<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.2. An XML Schema for the Extension
An XML schema describing the elements defined in this document is
given here.
<?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">
<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>
Takahashi, et al. Expires July 18, 2014 [Page 18]
Internet-Draft IODEF-SCI Jan 2014
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="Scoring">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element name="ScoreSet" 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="ContentID" 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="ContentID" type="xsd:string"
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"
Takahashi, et al. Expires July 18, 2014 [Page 19]
Internet-Draft IODEF-SCI Jan 2014
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="ContentID" 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="ContentID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<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"/>
Takahashi, et al. Expires July 18, 2014 [Page 20]
Internet-Draft IODEF-SCI Jan 2014
<xsd:attribute name="ext-SpecID" type="xsd:string"
use="optional"/>
<xsd:attribute name="ContentID" 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="ContentID" 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"
use="optional"/>
<xsd:attribute name="ContentID" 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"
Takahashi, et al. Expires July 18, 2014 [Page 21]
Internet-Draft IODEF-SCI Jan 2014
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="ContentID" 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. Specific security
considerations are detailed in the messaging and transport documents,
where the exchange of formatted information is automated. See Real-
time Inter-network Defense (RID) [RFC6545] Section 9 for a detailed
overview of security requirements and considerations.
It is RECOMMENDED that organizations who exchange data using this
document develop operating procedures that minimally consider the
following areas of concern.
6.1. Transport-Specific Concerns
The underlying messaging format, IODEF, provides data markers to
indicate the sensitivity level of specific classes within the
structure as well as for the entire XML document. The "restriction"
attribute accomplishes this with four attribute values in IODEF.
These values are RECOMMENDED for use at the application level, prior
to transport, to protect data as appropriate. A standard mechanism
to apply XML encryption using these attribute values as triggers is
defined in RID [RFC6545] Section 9.1. This mechanism may be used
whether or not the RID and RID Transport binding [RFC6546] are used
in the exchange to provide object level security on the data to
prevent possible intermediary systems or middle-boxes from having
Takahashi, et al. Expires July 18, 2014 [Page 22]
Internet-Draft IODEF-SCI Jan 2014
access to the data being exchanged. In areas where transmission
security or secrecy is questionable, the application of a XML digital
signature [xmldsig] and/or encryption on each report will counteract
both of these concerns. The data markers are RECOMMENDED for use by
applications for managing access controls, however access controls
and management of those controls are out-of-scope for this document.
Options such as the usage of a standard language (e.g. XACML
[XACML]) for the expression of authorization policies can be used to
enable source and destination systems to better coordinate and align
their respective policy expressions.
Any transport protocol used to exchange instances of IODEF documents
MUST provide appropriate guarantees of confidentiality, integrity,
and authenticity. The use of a standardized security protocol is
encouraged. The RID protocol [RFC6545] and its associated transport
binding [RFC6546] provide such security with options for mutual
authentication session encryption and include application levels
concerns such as policy and work flow.
The critical security concerns are that these structured information
may be falsified, accessed by unintended entities, or they may become
corrupt during transit. We expect that each exchanging organization
will determine the need, and mechanism, for transport protection.
6.2. Protection of Sensitive and Private Information
For a complete review of privacy considerations when transporting
incident related information, please see RID [RFC6545] Section 9.5.
Whether or not the RID protocol is used, the privacy considerations
are important to consider as incident information is often sensitive
and may contain privacy related information about individuals/
organizations or endpoints involved. Often times, organizations will
require legal review and formal polices to be established which
outline specific details of what information can be exchanged with
specific entities. Typically, identifying information is anonymized
where possible and appropriate. In some cases, information brokers
are used to further anonymize the source of exchanged information so
that other entities are unaware of the origin of a detected threat,
whether or not that threat was realized.
It is RECOMMENDED that policies and procedures for the exchange of
cybersecurity information are established prior to participation in
data exchanges. Policy and workflow procedures for the exchange of
cybersecurity information often require executive level approvals and
legal reviews to appropriately establish limits on what information
can be exchanged with specific organizations. RID [RFC6545] Section
9.6 outlines options and considerations for application developers to
consider for the policy and workflow design.
Takahashi, et al. Expires July 18, 2014 [Page 23]
Internet-Draft IODEF-SCI Jan 2014
6.3. Application and Server Security
The Cybersecurity Information extension is merely a data format.
Applications and transport protocols that store or exchange IODEF
documents using information that can be represented through this
extension will be a target for attacks. It is RECOMMENDED that
systems and applications storing or exchanging this information are
properly secured, have minimal services enabled, maintain access
controls and monitoring procedures.
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 Section 5.2.
This memo creates the following registry for IANA to manage:
Name of the registry: "Structured Cybersecurity Information (SCI)
specifications"
Name of its parent registry: "Incident Object Description Exchange
Format (IODEF)"
URL address of the registry: http://www.iana.org/assignments/iodef
Takahashi, et al. Expires July 18, 2014 [Page 24]
Internet-Draft IODEF-SCI Jan 2014
Namespace details: A registry entry for a Structured Cybersecurity
Information Specification (SCI specification) consists of:
Namespace: A URI [RFC3986] that identifies the XML namespace
used by the registered SCI specification. In the case where
the registrant does not request a particular URI, the IANA will
assign it a Uniform Resource Name (URN) that follows RFC 3553
[RFC3553]
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 extension
classes specified in Section 4.5 of this document. The
registered SCI specification MUST only be used with the
extension 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/Reference URI/Applicable Classes. Note that it is not
necessary to include defining reference for all assignments in
this new registry.
Initial registry contents: only one entry with the following
values.
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.0
Specification Name: Malware Metadata Exchange Format
Version: 1.2
Reference URI: http://standards.ieee.org/develop/indconn/icsg/
mmdef.html,http://grouper.ieee.org/groups/malware/malwg/
Schema1.2/
Applicable Classes: AttackPattern
Allocation Policy: Specification Required (which includes Expert
Review) [RFC5226].
Takahashi, et al. Expires July 18, 2014 [Page 25]
Internet-Draft IODEF-SCI Jan 2014
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 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, Eric Burger from
Georgetown University, Paul Cichonski from NIST, Panos Kampanakis
from CISCO, Pearl Liang from IANA, Ivan Kirillov from MITRE, Robert
Martin from MITRE, Alexey Melnikov from Isode, Kathleen Moriarty from
EMC, Lagadec Philippe from NATO, Sean Turner from IECA Inc., Shuhei
Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, Brian
Trammell from ETH Zurich, David Waltermire from NIST, and James
Wendorf from IEEE, for their sincere discussion and feedback on this
document.
9. References
9.1. Normative References
[MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group,
"Malware Metadata Exchange Format".
[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.
Takahashi, et al. Expires July 18, 2014 [Page 26]
Internet-Draft IODEF-SCI Jan 2014
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6545, April 2012.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546,
April 2012.
[XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and
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.
9.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.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 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.
Takahashi, et al. Expires July 18, 2014 [Page 27]
Internet-Draft IODEF-SCI Jan 2014
[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)".
[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)".
[EICAR] European Expert Group for IT-Security, "Anti-Malware
Testfile", 2003.
[MAEC] The MITRE Corporation, "Malware Attribute Enumeration and
Characterization".
[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.
Takahashi, et al. Expires July 18, 2014 [Page 28]
Internet-Draft IODEF-SCI Jan 2014
[XACML] Rissanen, E., "eXtensible Access Control Markup Language
(XACML) Version 3.0", January 2013, <http://
docs.oasis-open.org/xacml/3.0/
xacml-3.0-core-spec-os-en.pdf>.
[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.
[xmldsig] W3C Recommendation, "XML Signature Syntax and Processing
(Second Edition)", June 2008.
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
Takahashi, et al. Expires July 18, 2014 [Page 29]
Internet-Draft IODEF-SCI Jan 2014
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 July 18, 2014 [Page 30]
