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]