Individual Submission T. Takahashi
Internet-Draft NICT
Intended status: Informational K. Landfield
Expires: February 27, 2012 McAfee
T. Millar
USCERT
Y. Kadobayashi
NICT
Aug 26, 2011
IODEF-extension to support structured cybersecurity information
draft-takahashi-mile-sci-00.txt
Abstract
This document extends the Incident Object Description Exchange Format
(IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched
cybersecurity information exchange among cybersecurity entities by
embedding structured information formatted by the following
specifications: CAPEC[TM], CEE[TM], CPE[TM], CVE(R), CVRF, CVSS,
CWE[TM], CWSS[TM], OVAL(R), and XCCDF.
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 February 27, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Takahashi, et al. Expires February 27, 2012 [Page 1]
Internet-Draft IODEF-ext-sci Aug 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
4.1. Scoring . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. AttackPattern . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Weakness . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. PlatformID . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. EventReport . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Remediation . . . . . . . . . . . . . . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Reporting an attack . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 15
6.2. Using the iodef:restriction Attribute . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Appendix: XML Schema Definition for Extension . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Takahashi, et al. Expires February 27, 2012 [Page 2]
Internet-Draft IODEF-ext-sci Aug 2011
1. Introduction
Cyber attacks are getting more sophisticated, and their numbers are
increasing day by day. To cope with such situation, incident
information needs to be reported, exchanged, and shared among
organizations. IODEF is one of the tools enabling such exchange, and
is already in use.
On the other hand, there exist various other activities facilitating
detailed and structured description of cybersecurity information,
major of which includes CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS,
OVAL, and XCCDF. 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 exhange of such structured information are provided.
2. Terminology
The terminology used in this document follows the one defined in
[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 [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.
IODEF provides a scheme to exchange such information among interested
parties. However, the detailed common format to describe such
information is not defined in the IODEF base document.
On the other hand, to describe those information and to faciliate
exchange, a structured format for that is already available. Major
Takahashi, et al. Expires February 27, 2012 [Page 3]
Internet-Draft IODEF-ext-sci Aug 2011
of them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OVAL, and
XCCDF. By embedding them into the IODEF document, the documnt can
convey more detailed contents to the receivers, and the document can
be easily reused.
These structured cybersecuriity 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 CAPEC record is embedded instead of
describing everything in free format text. Receiver can also
identify the needed details of the attack pattern by looking up some
of the xml tags defined by CAPEC. Receiver can accummulate the
attack pattern information (CAPEC record) in its database and could
distribute it to the interested parties if needed, without needing
human interventions.
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.
The IODEF Incident element ([RFC5070], Section 3.2) 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 February 27, 2012 [Page 4]
Internet-Draft IODEF-ext-sci Aug 2011
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| | |<>--[ AdditionalData ]
| | |<>--[ Scoring ]
| |<>--{0..*}--[ Method ]
| | |<>--[ AdditionalData ]
| | |<>--[ AttackPattern ]
| | |<>--[ Vulnerability ]
| | |<>--[ Weakness ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| | |<>--[ Flow ]
| | | |<>--[ System ]
| | | |<>--[ AdditionalData ]
| | | |<>--[ PlatformID ]
| | |<>--[ Expectation ]
| | |<>--[ Record ]
| | |<>--[ RecordData ]
| | |<>--[ RecordItem ]
| | |<>--[ EventReport ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
| | |<>--[ Remediation ]
+--------------------+
This extension defines the following seven elements.
4.1. Scoring
A Scoring consists of an extension to the
Incident.Assessment.AdditionalData element with a dtype of "xml".
The extension describes the scoring of the severity of incidents or
events.
It is recommended that Assessment class SHOULD contain one or more of
the extension elements whenever available.
A Scoring class is structured as follows.
Takahashi, et al. Expires February 27, 2012 [Page 5]
Internet-Draft IODEF-ext-sci Aug 2011
+--------------------+
| Scoring |
+--------------------+
| STRING Version |<>----------[ SpecificationName ]
| |<>--(0..1)--[ SpecificationVersion ]
| |<>--(0..1)--[ Score ]
+--------------------+
This class has an attribute.
Version: REQUIRED. STRING. The version shall be the value 1.00, to
be compliant with this document.
This class is composed of three aggregate classes.
SpecificationName: One. ENUM. The name of the specification
specifying the format of the Score element. This field contains
one of the following values:
1. cvss. common vulnerability scoring system.
2. cwss. common weakness scoring system.
3. other. This is used to identify not-yet-enumerated
specifications.
SpecificationVersion: Zero or one. ML_STRING. The version of the
specification specifying the format of the Score element
Score: Zero or one. ML_STRING. Arbitrary information structured by
the specification identified by SpecificationName and
SpecificationVersion elements.
Writers/senders MUST ensure the SpecificationName and
SpecificationVersion are consistent with the contents of the Score;
if a reader/receiver detects an inconsistency, it SHOULD prefer the
specification and version derived from the content, and SHOULD log
the inconsistency so a human can correct the problem.
4.2. 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 February 27, 2012 [Page 6]
Internet-Draft IODEF-ext-sci Aug 2011
An AttackPattern class is structured as follows.
+--------------------+
| AttackPattern |
+--------------------+
| STRING Version |<>----------[ SpecificationName ]
| |<>--(0..1)--[ SpecificationVersion ]
| |<>--(1..*)--[ Record ]
+--------------------+
This class has an attribute.
Version: REQUIRED. STRING. The version shall be the value 1.00, to
be compliant with this document.
The AttackPattern class is composed of three aggregate classes.
SpecificationName: One. ENUM. The name of the specification
specifying the format of the Record element. This field contains
one of the following values:
1. capec. common attack pattern enumeration and classification.
2. other. This is used to identify not-yet-enumerated
specifications.
SpecificationVersion: Zero or one. ML_STRING. The version of the
specification specifying the format of the Score element
Record: One or more. ML_STRING. A complete document that is
formatted according to the schema referenced by the IANA
registration of the ENUM value used for SpecificationName and
SpecificationVersion elements.
Writers/senders MUST ensure the SpecificationName and
SpecificationVersion are consistent with the contents of the Record;
if a reader/receiver detects an inconsistency, it SHOULD prefer the
specification and version derived from the content, and SHOULD log
the inconsistency so a human can correct the problem.
4.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
Takahashi, et al. Expires February 27, 2012 [Page 7]
Internet-Draft IODEF-ext-sci Aug 2011
extension elements whenever available.
A Vulnerability element is structured as follows.
+--------------------+
| Vulnerability |
+--------------------+
| STRING Version |<>----------[ SpecificationName ]
| |<>--(0..1)--[ SpecificationVersion ]
| |<>--(1..*)--[ Record ]
+--------------------+
This class has an attribute.
Version: REQUIRED. STRING. The version shall be the value 1.00, to
be compliant with this document.
This class is composed of three aggregate classes.
SpecificationName: One. ENUM. The name of the specification
specifying the format of the Record element. This field contains
one of the following values:
1. cve. common vulnerability enumeration.
2. cvrf. common vulnerability reporting format.
3. other. This is used to identify not-yet-enumerated
specifications.
SpecificationVersion: Zero or one. ML_STRING. The version of the
specification specifying the format of the Score element
Record: One or more. ML_STRING. A complete document that is
formatted according to the schema referenced by the IANA
registration of the ENUM value used for SpecificationName and
SpecificationVersion elements.
Writers/senders MUST ensure the SpecificationName and
SpecificationVersion are consistent with the contents of the Record;
if a reader/receiver detects an inconsistency, it SHOULD prefer the
specification and version derived from the content, and SHOULD log
the inconsistency so a human can correct the problem.
4.4. Weakness
A Weakness consists of an extension to the
Incident.Method.AdditionalData element with a dtype of "xml". The
Takahashi, et al. Expires February 27, 2012 [Page 8]
Internet-Draft IODEF-ext-sci Aug 2011
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 |
+--------------------+
| STRING Version |<>----------[ SpecificationName ]
| |<>--(0..1)--[ SpecificationVersion ]
| |<>--(1..*)--[ Record ]
+--------------------+
This class has an attribute.
Version: REQUIRED. STRING. The version shall be the value 1.00, to
be compliant with this document.
This class is composed of three aggregate classes.
SpecificationName: One. ENUM. The name of the specification
specifying the format of the Record element. This field contains
one of the following values:
1. cwe. common weakness enumeration and classification.
2. other. This is used to identify not-yet-enumerated
specifications.
SpecificationVersion: Zero or one. ML_STRING. The version of the
specification specifying the format of the Score element
Record: One or more. ML_STRING. A complete document that is
formatted according to the schema referenced by the IANA
registration of the ENUM value used for SpecificationName and
SpecificationVersion elements.
Writers/senders MUST ensure the SpecificationName and
SpecificationVersion are consistent with the contents of the Record;
if a reader/receiver detects an inconsistency, it SHOULD prefer the
specification and version derived from the content, and SHOULD log
the inconsistency so a human can correct the problem.
Takahashi, et al. Expires February 27, 2012 [Page 9]
Internet-Draft IODEF-ext-sci Aug 2011
4.5. PlatformID
A PlatformID consists of an extension to the
Incident.EventData.Flow.System.AdditionalData element with a dtype of
"xml". The extension identifies a software platform.
It is recommended that System class SHOULD contain one or more of the
extension elements whenever available.
A PlatformID element is structured as follows.
+--------------------+
| PlatformID |
+--------------------+
| STRING Version |<>----------[ SpecificationName ]
| |<>--(0..1)--[ SpecificationVersion ]
| |<>--(1..*)--[ ID ]
+--------------------+
This class has an attribute.
Version: REQUIRED. STRING. The version shall be the value 1.00, to
be compliant with this document.
This class is composed of three aggregate classes.
SpecificationName: One. ENUM. The name of the specification
specifying the format of the ID element. This field contains one
of the following values:
1. cpe. common attack pattern enumeration and classification.
2. other. This is used to identify not-yet-enumerated
specifications.
SpecificationVersion: Zero or one. ML_STRING. The version of the
specification specifying the format of the Score element
ID: One or more. ML_STRING. An ID that is formatted according to
the rule referenced by the IANA registration of the ENUM value
used for SpecificationName and SpecificationVersion elements.
Writers/senders MUST ensure the SpecificationName and
SpecificationVersion are consistent with the contents of the ID; if a
reader/receiver detects an inconsistency, it SHOULD prefer the
specification and version derived from the content, and SHOULD log
the inconsistency so a human can correct the problem.
Takahashi, et al. Expires February 27, 2012 [Page 10]
Internet-Draft IODEF-ext-sci Aug 2011
4.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.
+--------------------+
| EventRecord |
+--------------------+
| STRING Version |<>----------[ SpecificationName ]
| |<>--(0..1)--[ SpecificationVersion ]
| |<>--(1..*)--[ Record ]
+--------------------+
This class has an attribute.
Version: REQUIRED. STRING. The version shall be the value 1.00, to
be compliant with this document.
This class is composed of three aggregate classes.
SpecificationName: One. ENUM. The name of the specification
specifying the format of the Record element. This field contains
one of the following values:
1. cee. common attack pattern enumeration and classification.
2. other. This is used to identify not-yet-enumerated
specifications.
SpecificationVersion: Zero or one. ML_STRING. The version of the
specification specifying the format of the Score element
Record: One or more. ML_STRING. A complete document that is
formatted according to the schema referenced by the IANA
registration of the ENUM value used for SpecificationName and
SpecificationVersion elements.
Writers/senders MUST ensure the SpecificationName and
SpecificationVersion are consistent with the contents of the Record;
if a reader/receiver detects an inconsistency, it SHOULD prefer the
specification and version derived from the content, and SHOULD log
the inconsistency so a human can correct the problem.
Takahashi, et al. Expires February 27, 2012 [Page 11]
Internet-Draft IODEF-ext-sci Aug 2011
4.7. Remediation
A Remediation consists of an extension to the Incident.AdditionalData
element with a dtype of "xml". The extension elements describes
incident remediation infomration 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.
+--------------------+
| Remediation |
+--------------------+
| STRING Version |<>----------[ SpecificationName ]
| |<>--(0..1)--[ SpecificationVersion ]
| |<>--(1..*)--[ Record ]
+--------------------+
This class has an attribute.
Version: REQUIRED. STRING. The version shall be the value 1.00, to
be compliant with this document.
This class is composed of three aggregate classes.
SpecificationName: One. ENUM. The name of the specification
specifying the format of the Record element. This field contains
one of the following values:
1. oval.
2. ocil.
3. xccdff.
4. other. This is used to identify not-yet-enumerated
specifications.
SpecificationVersion: Zero or one. ML_STRING. The version of the
specification specifying the format of the Score element
Record: One or more. ML_STRING. A complete document that is
formatted according to the schema referenced by the IANA
registration of the ENUM value used for SpecificationName and
SpecificationVersion elements.
Writers/senders MUST ensure the SpecificationName and
Takahashi, et al. Expires February 27, 2012 [Page 12]
Internet-Draft IODEF-ext-sci Aug 2011
SpecificationVersion are consistent with the contents of the Record;
if a reader/receiver detects an inconsistency, it SHOULD prefer the
specification and version derived from the content, and SHOULD log
the inconsistency so a human can correct the problem.
5. Examples
This section provides examples of an incident encoded in the IODEF.
These examples do not necessarily represent the only way to encode a
particular incident.
5.1. Reporting an attack
An example of a CSIRT reporting an attack.
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
189493
2001-09-13T23:19:24+00:00
Incident report in company xx
capec
1.6
[embed data in CAPEC format]
cve
[embed data in CVE format]
cwe
5.0
[embed data in CVE format]
Takahashi, et al. Expires February 27, 2012 [Page 13]
Internet-Draft IODEF-ext-sci Aug 2011
Example.com CSIRT
example-com
contact@csirt.example.com
192.0.2.200
57
192.0.2.16/28
80
cpe
2.2
[embed identifier in CPE format]
2001-09-13T18:11:21+02:00
a Web-server event record
cee
1.0
[embed data in CEE format]
Takahashi, et al. Expires February 27, 2012 [Page 14]
Internet-Draft IODEF-ext-sci Aug 2011
2001-09-14T08:19:01+00:00
Notification sent to
constituency-contact@192.0.2.200
oval
5.9
[embed OVAL-structured information here]
xccdf
1.2
[embed XCCDF-structured information here]
Figure 1: Example UML Element Diagram
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.
[Note: additional text will appear soon]
6.1. Transport-Specific Concerns
The critical security concerns are that phishing activity reports may
be falsified or the PhraudReport may become corrupt during transit.
In areas where transmission security or secrecy is questionable, the
Takahashi, et al. Expires February 27, 2012 [Page 15]
Internet-Draft IODEF-ext-sci Aug 2011
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.
6.2. Using the iodef:restriction Attribute
In some instances, data values in particular elements may contain
data deemed sensitive by the reporter. Although there are no
general-purpose rules on when to mark certain values as "private" or
"need-to-know" via the iodef:restriction attribute, the reporter is
cautioned not to apply element-level sensitivity markings unless they
believe the receiving party (i.e., the party they are exchanging the
event report data with) has a mechanism to adequately safeguard and
process the data as marked.
7. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688].
Registration request for the IODEF My-Extension namespace:
URI: urn:ietf:params:xml:ns:iodef-msmspecs-1.0
Registrant Contact: Refer here to the authors' addresses section
of the document.
XML: None
Registration request for the IODEF My-Extension XML schema:
URI: urn:ietf:params:xml:schema:iodef-msmspecs-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.
[Note: additional text will appear soon]
8. Acknowledgment
The following groups and individuals, listed alphabetically,
contributed substantially to this document and should be recognized
for their efforts.
Takahashi, et al. Expires February 27, 2012 [Page 16]
Internet-Draft IODEF-ext-sci Aug 2011
Black David, EMC
Robert Martin, MITRE
Kathleen Moriarty, EMC
Anthony Rutkowski, Yaana Technology
Brian Trammell, CERT/NetSA
9. Appendix: XML Schema Definition for Extension
The XML Schema describing the elements defined in the Extension
Defintion section is given here. Each of the examples in Section 5
should be verified to validate against this schema by automated
tools.
Takahashi, et al. Expires February 27, 2012 [Page 17]
Internet-Draft IODEF-ext-sci Aug 2011
Takahashi, et al. Expires February 27, 2012 [Page 18]
Internet-Draft IODEF-ext-sci Aug 2011
Example Schema Diagram
10. References
10.1. Normative References
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070,
December 2007.
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6045, November 2010.
10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
June 2006.
Takahashi, et al. Expires February 27, 2012 [Page 19]
Internet-Draft IODEF-ext-sci Aug 2011
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
March 2011.
[CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The
Common Vulnerability Scoring System (CVSS) and Its
Applicability to Federal Agency Systems".
[CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration
and Classification (CAPEC)".
[CEE] The MITRE Corporation, "Common Event Expression (CEE)".
[CPE] Andrew Buttner and Neal Ziring, "Common Platform
Enumeration (CPE) - Specification".
[CVE] The MITRE Corporation, "Common Vulnerability and Exposures
(CVE)".
[CVRF] ICASI, "http://www.icasi.org/cvrf".
[CWE] The MITRE Corporation, "Common Weakness Enumeration
(CWE)".
[CWSS] The MITRE Corporation, "Common Weakness Scoring System
(CWSS)".
[OCIL] Maria Casipe and Charles Schmidt, "The Open Checklist
Interactive Language (OCIL) Version 1.1".
[OVAL] The MITRE Corporation, "Open Vulnerability and Assessment
Language (OVAL)".
[XCCDF] Neal Ziring and Stephen D. Quinn, "Specification for the
Extensible Configuration Checklist Description Format
(XCCDF) version 1.1.4".
Takahashi, et al. Expires February 27, 2012 [Page 20]
Internet-Draft IODEF-ext-sci Aug 2011
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
Email: Kent_Landfield@McAfee.com
Thomas Millar
US CERT
Email: thomas.millar@us-cert.gov
Youki Kadobayashi
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi Koganei
184-8795 Tokyo
Japan
Phone: +80 423 27 5862
Email: youki-k@is.aist-nara.ac.jp
Takahashi, et al. Expires February 27, 2012 [Page 21]