idnits 2.17.1
draft-takahashi-mile-sci-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 4 instances of too long lines in the document, the longest one
being 6 characters in excess of 72.
** The abstract seems to contain references ([ISOIEC19770-2], [XCCDF],
[OVAL], [CVSS], [CWE], [TM], [CWSS], [CEE], [RFC5070], [OCIL], [CPE],
[CAPEC], [XDAS], [CVRF], [CVE]), which it shouldn't. Please replace
those with straight textual mentions of the documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (Oct 29, 2011) is 4564 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'TM' is mentioned on line 22, but not defined
== Unused Reference: 'RFC3339' is defined on line 1090, but no explicit
reference was found in the text
== Unused Reference: 'RFC3552' is defined on line 1093, but no explicit
reference was found in the text
== Unused Reference: 'RFC3986' is defined on line 1100, but no explicit
reference was found in the text
== Unused Reference: 'RFC5322' is defined on line 1104, but no explicit
reference was found in the text
== Unused Reference: 'RFC6116' is defined on line 1107, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970)
** Obsolete normative reference: RFC 6045 (Obsoleted by RFC 6545)
** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546)
Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Individual Submission T. Takahashi
3 Internet-Draft NICT
4 Intended status: Standards Track K. Landfield
5 Expires: May 1, 2012 McAfee
6 T. Millar
7 USCERT
8 Y. Kadobayashi
9 NICT
10 Oct 29, 2011
12 IODEF-extension to support structured cybersecurity information
13 draft-takahashi-mile-sci-02.txt
15 Abstract
17 This document extends the Incident Object Description Exchange Format
18 (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched
19 cybersecurity information exchange among cybersecurity entities by
20 embedding structured information formatted by specifications,
21 including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R)
22 [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], ISO/
23 IEC 19770-2 [ISOIEC19770-2], OCIL [OCIL], OVAL(R) [OVAL], XCCDF
24 [XCCDF], and XDAS [XDAS].
26 Status of this Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on May 1, 2012.
43 Copyright Notice
45 Copyright (c) 2011 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
63 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
64 4.1. Structured Cybersecurity Information Formats . . . . . . . 4
65 4.2. Extended Data Types . . . . . . . . . . . . . . . . . . . 5
66 4.2.1. EM_XML . . . . . . . . . . . . . . . . . . . . . . . . 5
67 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 6
68 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 7
69 4.3.2. PlatformID . . . . . . . . . . . . . . . . . . . . . . 8
70 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 9
71 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 11
72 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 12
73 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 13
74 4.3.7. Remediation . . . . . . . . . . . . . . . . . . . . . 14
75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
76 5.1. Reporting an attack . . . . . . . . . . . . . . . . . . . 16
77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
78 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 18
79 6.2. Using the iodef:restriction Attribute . . . . . . . . . . 19
80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
81 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 20
82 9. Appendix: XML Schema Definition for Extension . . . . . . . . 20
83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
85 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
88 1. Introduction
90 Cyber attacks are getting more sophisticated, and their numbers are
91 increasing day by day. To cope with such situation, incident
92 information needs to be reported, exchanged, and shared among
93 organizations. IODEF is one of the tools enabling such exchange, and
94 is already in use.
96 To efficiently run cybersecurity operations, these exchanged
97 information needs to be machine-readable. IODEF provides a
98 structured means to describe the information, but it needs to embed
99 various non-structured such information in order to convey detailed
100 information. Further structure within IODEF increases IODEF
101 documents' machine-readability and thus facilitates streamlining
102 cybersecurity operations.
104 On the other hand, there exist various other activities facilitating
105 detailed and structured description of cybersecurity information,
106 major of which includes CAPEC [CAPEC], CEE [CEE], CPE [CPE], CVE
107 [CVE], CVRF [CVRF], CVSS [CVSS], CWE [CWE], CWSS [CWSS], ISO/IEC
108 19770-2 [ISOIEC19770-2], OCIL [OCIL], OVAL [OVAL], XCCDF [XCCDF], and
109 XDAS [XDAS]. Since such structured description facilitates
110 cybersecurity operations, it would be beneficial to embed and convey
111 these information inside IODEF document.
113 To enable that, this document extends the IODEF to embed and convey
114 various structured cybersecurity information, with which
115 cybersecurity operations can be facilitated. Since IODEF defines a
116 flexible and extensible format and supports a granular level of
117 specificity, this document defines an extension to IODEF instead of
118 defining a new report format. For clarity, and to eliminate
119 duplication, only the additional structures necessary for describing
120 the exchange of such structured information are provided.
122 2. Terminology
124 The terminology used in this document follows the one defined in RFC
125 5070 [RFC5070].
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129 document are to be interpreted as described in RFC 2119 [RFC2119].
131 3. Applicability
133 To maintain cybersecurity, organization needs to exchange
134 cybersecurity information, which includes the following information:
135 attack pattern, platform information, vulnerability and weakness,
136 countermeasure instruction, computer event log, and the severity.
138 IODEF provides a scheme to exchange such information among interested
139 parties. However, the detailed common format to describe such
140 information is not defined in the IODEF base document.
142 On the other hand, to describe those information and to facilitate
143 exchange, a structured format for that is already available. Major
144 of them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OVAL, and
145 XCCDF. By embedding them into the IODEF document, the document can
146 convey more detailed contents to the receivers, and the document can
147 be easily reused.
149 These structured cybersecurity information facilitates cybersecurity
150 operation at the receiver side. Since the information is machine-
151 readable, the data can be processed by computers. That expedites the
152 automation of cybersecurity operations
154 For instance, an organization wishing to report a security incident
155 wants to describe what vulnerability was exploited. Then the sender
156 can simply use IODEF, where an CAPEC record is embedded instead of
157 describing everything in free format text. Receiver can also
158 identify the needed details of the attack pattern by looking up some
159 of the xml tags defined by CAPEC. Receiver can accumulate the attack
160 pattern information (CAPEC record) in its database and could
161 distribute it to the interested parties if needed, without needing
162 human interventions.
164 4. Extension Definition
166 This draft extends IODEF to embed structured cybersecurity
167 information by introducing new classes, with which these information
168 can be embedded inside IODEF document as element contents of
169 AdditionalData and RecordItem classes.
171 4.1. Structured Cybersecurity Information Formats
173 This extension intends to embed various structured cybersecurity
174 information. The below table describes the initial list of supported
175 specifications and their IDs, versions, and namespaces; future
176 assignments are to be made through Expert Review, as requested in
177 Section 7.
179 ID Specification Name Version Namespace
180 --------- ---------------------- ------- ------------------------
181 CAPEC_1.6 Common Attack Pattern 1.6 http://capec.mitre.org
182 Enumeration and /observables
183 Classification (CAPEC)
184 CEE_0.6 Common Event Expression 0.6 http://cee.mitre.org
185 (CEE)
186 CPE_2.3 Common Platform 2.3 http://cpe.mitre.org
187 Enumeration (CPE) /dictionary/2.0
188 CVE_1.0 Common Vulnerability 1.0 http://cve.mitre.org
189 and Exposures (CVE) /cve/downloads/1.0
190 CVRF_1.0 Common Vulnerability 1.0 http://www.icasi.org
191 Reporting Format /CVRF/schema/cvrf/1.0
192 (CVRF)
193 CVSS_2.0 Common Vulnerability 2 http://scap.nist.gov
194 Scoring System (CVSS) /schema/cvss-v2/1.0
195 CWE_5.0 Common Weakness 5.1 N/A
196 Enumeration (CWE)
197 CWSS_0.8 Common Weakness 0.8 N/A
198 Scoring System (CWSS)
199 OCIL_2.0 Open Checklist 2.0 http://scap.nist.gov
200 Interactive Language /schema/ocil/2.0
201 (OCIL)
202 OVAL_5.10 Open Vulnerability and 5.10 http://oval.mitre.org
203 Assessment Language /XMLSchema
204 (OVAL) /oval-definitions-5
205 XCCDF_1.2 Extensible 1.2 http://checklists.nist
206 Configuration .gov/xccdf/1.2
207 Checklist Description
208 Format (XCCDF)
209 XDAS_1998 Distributed Audit 1998 N/A
210 Service (XDAS)
211 19770-2 ISO/IEC 19770 Part 2 N/A
213 Figure 1: List of specifications
215 4.2. Extended Data Types
217 This extension inherits all of the data types defined in the IODEF
218 model. One data type is added: EM_XML.
220 4.2.1. EM_XML
222 An embedded complete XML document is represented by the EM_XML data
223 type. The elements of the document must match its root namespace
224 element.
226 4.3. Extended Classes
228 The IODEF Incident element [RFC5070] is summarized below. It is
229 expressed in Unified Modeling Language (UML) syntax as used in the
230 IODEF specification. The UML representation is for illustrative
231 purposes only; elements are specified in XML as defined in Appendix
232 A.
234 +--------------------+
235 | Incident |
236 +--------------------+
237 | ENUM purpose |<>---------[ IncidentID ]
238 | STRING ext-purpose |<>--{0..1}-[ AlternativeID ]
239 | ENUM lang |<>--{0..1}-[ RelatedActivity ]
240 | ENUM restriction |<>--{0..1}-[ DetectTime ]
241 | |<>--{0..1}-[ StartTime ]
242 | |<>--{0..1}-[ EndTime ]
243 | |<>---------[ ReportTime ]
244 | |<>--{0..*}-[ Description ]
245 | |<>--{1..*}-[ Assessment ]
246 | |<>--{0..*}-[ Method ]
247 | | |<>--[ AdditionalData ]
248 | | |<>--[ AttackPattern ]
249 | | |<>--[ Vulnerability ]
250 | | |<>--[ Weakness ]
251 | |<>--{1..*}-[ Contact ]
252 | |<>--{0..*}-[ EventData ]
253 | | |<>--[ Flow ]
254 | | | |<>--[ System ]
255 | | | |<>--[ AdditionalData ]
256 | | | |<>--[ PlatformID ]
257 | | |<>--[ Expectation ]
258 | | |<>--[ Record ]
259 | | |<>--[ RecordData ]
260 | | |<>--[ RecordItem ]
261 | | |<>--[ EventReport ]
262 | |<>--{0..1}-[ History ]
263 | |<>--{0..*}-[ AdditionalData ]
264 | | |<>--[ Remediation ]
265 +--------------------+
267 Figure 2: Incident class
269 This extension defines the following seven elements.
271 4.3.1. AttackPattern
273 An AttackPattern consists of an extension to the
274 Incident.Method.AdditionalData element with a dtype of "xml". The
275 extension describes attack patterns of incidents or events.
277 It is recommended that Method class SHOULD contain one or more of the
278 extension elements whenever available.
280 An AttackPattern class is structured as follows.
282 +------------------------+
283 | AttackPattern |
284 +------------------------+
285 | STRING Version |<>--(0..*)-[ Record ]
286 | ENUM SpecificationID |<>--(0..*)-[ Reference ]
287 | STRING AttackPatternID |<>--(0..*)-[ PlatformID ]
288 +------------------------+
290 Figure 3: AttackPattern class
292 This class has the following attributes.
294 Version: OPTIONAL. STRING. The version number of the extension
295 specification to which this class conforms. This value should be
296 1.00, to be compliant with this document. Its default value is
297 1.00.
299 SpecificationID: REQUIRED. ENUM. The ID of the specification and
300 its version specifying the format of the Record element. The
301 value should be chosen from the IDs listed in Figure 1, such as
302 CAPEC_1.6. Note that the lists in Figure 1 will be developed
303 further by IANA.
305 AttackPatternID: OPTIONAL. STRING. An ID of an attack pattern to
306 be reported. This attribute SHOULD be used whenever such ID is
307 available. In case a Record or Reference element is provided
308 along with this attribute, writers/senders MUST ensure that this
309 ID is consistent with the one provided by the element; if a
310 reader/receiver detects an inconsistency, it SHOULD prefer the
311 value of this attribute, and SHOULD log the inconsistency so a
312 human can correct the problem. Note that this attribute could be
313 omitted if no such ID is available. In this case, either Record
314 or Reference elements, or both of them, MUST be provided.
316 The AttackPattern class is composed of the following aggregate
317 classes.
319 Record: Zero or more. EM_XML. A complete document that is
320 formatted according to the specification and its version
321 identified by the value of the SpecificationID with the Figure 1.
323 Reference: Zero or more of iodef:Reference [RFC5070]. This element
324 allows an IODEF document to include a link to a structured
325 information instead of directly embedding it into a Record
326 element.
328 PlatformID: Zero or more. An identifier of software platform
329 involved in the specific attack pattern, which is elaborated in
330 Section 4.3.2. Some of the structured information embedded in the
331 Record element may include the identifier within it. In this
332 case, this PlatformID element SHOULD NOT be used. If a reader/
333 receiver detects the identifiers in both Record and PlatformID
334 elements and their inconsistency, it SHOULD prefer the identifiers
335 derived from the PlatformID element, and SHOULD log the
336 inconsistency so a human can correct the problem.
338 Writers/senders MUST ensure the specification name and version
339 identified by the SpecificationID are consistent with the contents of
340 the Record; if a reader/receiver detects an inconsistency, it SHOULD
341 prefer the specification name and version derived from the content,
342 and SHOULD log the inconsistency so a human can correct the problem.
344 4.3.2. PlatformID
346 A PlatformID identifies a software platform. It is recommended that
347 AttackPattern, Vulnerability, Weakness, and System classes contain
348 this elements whenever available.
350 A PlatformID element is structured as follows.
352 +----------------------+
353 | PlatformID |
354 +----------------------+
355 | STRING Version |<>--(1..*)-[ ID ]
356 | ENUM SpecificationID |
357 +----------------------+
359 Figure 4: PlatformID class
361 This class has the following attributes.
363 Version: OPTIONAL. STRING. The version number of the extension
364 specification to which this class conforms. This value should be
365 1.00, to be compliant with this document. Its default value is
366 1.00.
368 SpecificationID: REQUIRED. ENUM. The ID of the specification and
369 its version specifying the format of the ID element. The value
370 should be chosen from the IDs listed in Figure 1, such as CPE_2.3
371 and ISO/IEC 19770-2. Note that the lists in Figure 1 will be
372 developed further by IANA.
374 This class is composed of the following aggregate classes.
376 ID: One or more. ML_STRING. An ID that is formatted according to
377 the rule defined by the specification and its version identified
378 by the value of the SpecificationID with the Figure 1.
380 Writers/senders MUST ensure the specification name and version
381 identified by the SpecificationID are consistent with the contents of
382 the ID; if a reader/receiver detects an inconsistency, it SHOULD
383 prefer the specification name and version derived from the content,
384 and SHOULD log the inconsistency so a human can correct the problem.
386 4.3.3. Vulnerability
388 A Vulnerability consists of an extension to the
389 Incident.Method.AdditionalData element with a dtype of "xml". The
390 extension describes the (candidate) vulnerabilities of incidents or
391 events.
393 It is recommended that Method class SHOULD contain one or more of the
394 extension elements whenever available.
396 A Vulnerability element is structured as follows.
398 +------------------------+
399 | Vulnerability |
400 +------------------------+
401 | STRING Version |<>--(0..*)-[ Record ]
402 | ENUM SpecificationID |<>--(0..*)-[ Reference ]
403 | STRING VulnerabilityID |<>--(0..*)-[ PlatformID ]
404 | |<>--(0..*)-[ Scoring ]
405 +------------------------+
407 Figure 5: Vulnerability class
409 This class has the following attributes.
411 Version: OPTIONAL. STRING. The version number of the extension
412 specification to which this class conforms. This value should be
413 1.00, to be compliant with this document. Its default value is
414 1.00.
416 SpecificationID: REQUIRED. ENUM. The ID of the specification and
417 its version specifying the format of the Record element. The
418 value should be chosen from the IDs listed in Figure 1, such as
419 CVE_1.0 and CVRF_1.0. Note that the lists in Figure 1 will be
420 developed further by IANA.
422 VulnerabilityID: OPTIONAL. STRING. An ID of a vulnerability to be
423 reported. This attribute SHOULD be used whenever such ID is
424 available. In case a Record or Reference element is provided
425 along with this attribute, writers/senders MUST ensure that this
426 ID is consistent with the one provided by the element; if a
427 reader/receiver detects an inconsistency, it SHOULD prefer the
428 value of this attribute, and SHOULD log the inconsistency so a
429 human can correct the problem. Note that this attribute could be
430 omitted if no such ID is available. In this case, either Record
431 or Reference elements, or both of them, MUST be provided.
433 This class is composed of the following aggregate classes.
435 Record: Zero or one. EM_XML. A complete document that is formatted
436 according to the specification and its version identified by the
437 value of the SpecificationID with the Figure 1.
439 Reference: Zero or one of iodef:Reference [RFC5070]. This element
440 allows an IODEF document to include a link to a structured
441 information instead of directly embedding it into a Record
442 element.
444 PlatformID: Zero or more. An identifier of software platform
445 affected by the vulnerability, which is elaborated in
446 Section 4.3.2. Some of the structured information embedded in the
447 Record element may include the identifier within it. In this
448 case, this PlatformID element SHOULD NOT be used. If a reader/
449 receiver detects the identifiers in both Record and PlatformID
450 elements and their inconsistency, it SHOULD prefer the identifiers
451 derived from the PlatformID element, and SHOULD log the
452 inconsistency so a human can correct the problem.
454 Scoring: Zero or more. An indicator of the severity of the
455 vulnerability, such as CVSS score, which is elaborated in
456 Section 4.3.4. Some of the structured information may include
457 scores within it. In this case, the Scoring element SHOULD NOT be
458 used since the Record element contains the scores. If a reader/
459 receiver detects scores in both Record and Scoring elements and
460 their inconsistency, it SHOULD prefer the scores derived from the
461 Record element, and SHOULD log the inconsistency so a human can
462 correct the problem.
464 4.3.4. Scoring
466 A Scoring class describes the scores of the severity in terms of
467 security. It is recommended that Vulnerability and Weakness classes
468 contain the elements whenever available.
470 A Scoring class is structured as follows.
472 +----------------------+
473 | Scoring |
474 +----------------------+
475 | STRING Version |<>---------[ Score ]
476 | ENUM SpecificationID |
477 +----------------------+
479 Figure 6: Scoring class
481 This class has two attributes.
483 Version: OPTIONAL. STRING. The version number of the extension
484 specification to which this class conforms. This value should be
485 1.00, to be compliant with this document. Its default value is
486 1.00.
488 SpecificationID: REQUIRED. STRING. The ID of the specification and
489 its version specifying the format of the Score element. The value
490 should be chosen from the IDs listed in Figure 1, such as CVSS_2.0
491 and CWSS_0.8. Note that the lists in Figure 1 will be developed
492 further by IANA.
494 This class is composed of an aggregate class.
496 Score: One. EM_XML. Arbitrary information structured by the
497 specification identified by the specification and its version
498 identified by the value of the SpecificationID with the Figure 1.
500 Writers/senders MUST ensure the specification name and version
501 identified by the SpecificationID are consistent with the contents of
502 the Score; if a reader/receiver detects an inconsistency, it SHOULD
503 prefer the specification name and version derived from the content,
504 and SHOULD log the inconsistency so a human can correct the problem.
506 4.3.5. Weakness
508 A Weakness consists of an extension to the
509 Incident.Method.AdditionalData element with a dtype of "xml". The
510 extension describes the weakness types of incidents or events.
512 It is recommended that Method class SHOULD contain one or more of the
513 extension elements whenever available.
515 A Weakness element is structured as follows.
517 +----------------------+
518 | Weakness |
519 +----------------------+
520 | STRING Version |<>--(0..*)-[ Record ]
521 | ENUM SpecificationID |<>--(0..*)-[ Reference ]
522 | STRING WeaknessID |<>--(0..*)-[ PlatformID ]
523 | |<>--(0..*)-[ Scoring ]
524 +----------------------+
526 Figure 7: Weakness class
528 This class has the following attributes.
530 Version: OPTIONAL. STRING. The version number of the extension
531 specification to which this class conforms. This value should be
532 1.00, to be compliant with this document. Its default value is
533 1.00.
535 SpecificationID: REQUIRED. ENUM. The ID of the specification and
536 its version specifying the format of the Record element. The
537 value should be chosen from the IDs listed in Figure 1, such as
538 CWE_5.0. Note that the lists in Figure 1 will be developed
539 further by IANA.
541 WeaknessID: OPTIONAL. STRING. An ID of a weakness to be reported.
542 This attribute SHOULD be used whenever such ID is available. In
543 case a Record or Reference elements is provided along with this
544 attribute, writers/senders MUST ensure that this ID is consistent
545 with the one provided by the element; if a reader/receiver detects
546 an inconsistency, it SHOULD prefer the value of this attribute,
547 and SHOULD log the inconsistency so a human can correct the
548 problem. Note that this attribute could be omitted if no such ID
549 is available. In this case, either Record or Reference elements,
550 or both of them, MUST be provided.
552 This class is composed of the following aggregate classes.
554 Record: Zero or more. EM_XML. A complete document that is
555 formatted according to the specification and its version
556 identified by the value of the SpecificationID with the Figure 1.
558 Reference: Zero or one of iodef:Reference [RFC5070]. This element
559 allows an IODEF document to include a link to a structured
560 information instead of directly embedding it into a Record
561 element.
563 PlatformID: Zero or more. An identifier of software platform
564 affected by the weakness, which is elaborated in Section 4.3.2.
565 Some of the structured information embedded in the Record element
566 may include the identifier within it. In this case, this
567 PlatformID element SHOULD NOT be used. If a reader/receiver
568 detects the identifiers in both Record and PlatformID elements and
569 their inconsistency, it SHOULD prefer the identifiers derived from
570 the PlatformID element, and SHOULD log the inconsistency so a
571 human can correct the problem.
573 Scoring: Zero or more. An indicator of the severity of the
574 weakness, such as CWSS score, which is elaborated in
575 Section 4.3.4. Some of the structured information may include
576 scores within it. In this case, the Scoring element SHOULD NOT be
577 used since the Record element contains the scores. If a reader/
578 receiver detects scores in both Record and Scoring elements and
579 their inconsistency, it SHOULD prefer the scores derived from the
580 Record element, and SHOULD log the inconsistency so a human can
581 correct the problem.
583 4.3.6. EventReport
585 An EventReport consists of an extension to the
586 Incident.EventData.Record.RecordData.RecordItem element with a dtype
587 of "xml". The extension embeds structured event reports.
589 It is recommended that RecordItem class SHOULD contain one or more of
590 the extension elements whenever available.
592 An EventReport element is structured as follows.
594 +----------------------+
595 | EventReport |
596 +----------------------+
597 | STRING Version |<>--(0..*)-[ Record ]
598 | ENUM SpecificationID |<>--(0..*)-[ Reference ]
599 +----------------------+
601 Figure 8: EventReport class
603 This class has the following attributes.
605 Version: OPTIONAL. STRING. The version number of the extension
606 specification to which this class conforms. This value should be
607 1.00, to be compliant with this document. Its default value is
608 1.00.
610 SpecificationID: REQUIRED. ENUM. The ID of the specification and
611 its version specifying the format of the Record element. The
612 value should be chosen from the IDs listed in Figure 1, such as
613 CEE_0.6 and XDAS_1998. Note that the lists in Figure 1 will be
614 developed further by IANA.
616 This class is composed of three aggregate classes.
618 Record: Zero or one. EM_XML. A complete document that is formatted
619 according to the specification and its version identified by the
620 value of the SpecificationID with the Figure 1.
622 Reference: Zero or one of iodef:Reference [RFC5070]. This element
623 allows an IODEF document to include a link to a structured
624 information instead of directly embedding it into a Record
625 element.
627 This class MUST contain at least one of Record or Reference elements.
628 Writers/senders MUST ensure the specification name and version
629 identified by the SpecificationID are consistent with the contents of
630 the Record; if a reader/receiver detects an inconsistency, it SHOULD
631 prefer the specification name and version derived from the content,
632 and SHOULD log the inconsistency so a human can correct the problem.
634 4.3.7. Remediation
636 A Remediation consists of an extension to the Incident.AdditionalData
637 element with a dtype of "xml". The extension elements describes
638 incident remediation information including instructions. Note that
639 the term remediation includes a range of concepts, e.g., valudation.
641 It is recommended that Incident class SHOULD contain one or more of
642 this extension elements whenever available.
644 A Remediation class is structured as follows.
646 +----------------------+
647 | Remediation |
648 +----------------------+
649 | STRING Version |<>--(0..*)-[ Record ]
650 | ENUM SpecificationID |<>--(0..*)-[ Reference ]
651 +----------------------+
653 Figure 9: Remediation class
655 This class has an attribute.
657 Version: OPTIONAL. STRING. The version number of the extension
658 specification to which this class conforms. This value should be
659 1.00, to be compliant with this document. Its default value is
660 1.00.
662 SpecificationID: REQUIRED. ENUM. The ID of the specification and
663 its version specifying the format of the Record element. The
664 value should be chosen from the IDs listed in Figure 1, such as
665 OVAL_5.10, OCIL_2.0, and XCCDF_1.2. Note that the lists in
666 Figure 1 will be developed further by IANA.
668 This class is composed of three aggregate classes.
670 Record: Zero or one. EM_XML. A complete document that is formatted
671 according to the specification and its version identified by the
672 value of the SpecificationID with the Figure 1.
674 Reference: Zero or one of iodef:Reference [RFC5070]. This element
675 allows an IODEF document to include a link to a structured
676 information instead of directly embedding it into a Record
677 element.
679 This class MUST contain at least either of Record and Reference
680 elements. Writers/senders MUST ensure the specification name and
681 version identified by the SpecificationID are consistent with the
682 contents of the Record; if a reader/receiver detects an
683 inconsistency, it SHOULD prefer the specification name and version
684 derived from the content, and SHOULD log the inconsistency so a human
685 can correct the problem.
687 5. Examples
689 This section provides examples of an incident encoded in the IODEF.
690 These examples do not necessarily represent the only way to encode a
691 particular incident.
693 5.1. Reporting an attack
695 An example of a CSIRT reporting an attack.
697
698
703
704 189493
705 2001-09-13T23:19:24+00:00
706 Incident report in company xx
707
708
709
710
711
712 Structured information on attack pattern, exploited
713 vulnerability, and weakness
714
715
717 [CAPEC-formatted data]
718
719 Link to Capec-14
720 http://capec.mitre.org/data/definitions/14.html
721
722
723
725 [CVE-formatted data]
726
727 [CPE ID]
728
729
730 [CVSS scores]
731
732
733
735 [CWE-formatted data]
736
737 [CWSS scores]
738
739
740
742
743
744 Example.com CSIRT
745 example-com
746 contact@csirt.example.com
747
748
749
750
751
752 192.0.2.200
753 57
754
755
756
757
758 192.0.2.16/28
759
760
761 80
762
763
764
765 [CPE ID]
766
767
768
769
770
771
772
773
774
775 2001-09-13T18:11:21+02:00
776 a Web-server event record
777
778
779 [CEE-formatted data]
780
781
782
783
784
785
786
787
788 2001-09-14T08:19:01+00:00
789 Notification sent to
790 constituency-contact@192.0.2.200
791
792
793
794
795 [OVAL-formatted data]
796
797
798 [XCCDF-formatted data]
799
800
801
802
804 Figure 10: Example UML Element Diagram
806 6. Security Considerations
808 This document specifies a format for encoding a particular class of
809 security incidents appropriate for exchange across organizations. As
810 merely a data representation, it does not directly introduce security
811 issues. However, it is guaranteed that parties exchanging instances
812 of this specification will have certain concerns. For this reason,
813 the underlying message format and transport protocol used MUST ensure
814 the appropriate degree of confidentiality, integrity, and
815 authenticity for the specific environment.
817 Organizations that exchange data using this document are URGED to
818 develop operating procedures that document the following areas of
819 concern.
821 6.1. Transport-Specific Concerns
823 The underlying messaging format and protocol used to exchange
824 instances of the IODEF MUST provide appropriate guarantees of
825 confidentiality, integrity, and authenticity. The use of a
826 standardized security protocol is encouraged. The Real-time Inter-
827 network Defense (RID) protocol [RFC6045] and its associated transport
828 binding [RFC6046] provide such security.
830 The critical security concerns are that these structured information
831 may be falsified or they may become corrupt during transit. In areas
832 where transmission security or secrecy is questionable, the
833 application of a digital signature and/or message encryption on each
834 report will counteract both of these concerns. We expect that each
835 exchanging organization will determine the need, and mechanism, for
836 transport protection.
838 6.2. Using the iodef:restriction Attribute
840 In some instances, data values in particular elements may contain
841 data deemed sensitive by the reporter. Although there are no
842 general-purpose rules on when to mark certain values as "private" or
843 "need-to-know" via the iodef:restriction attribute, the reporter is
844 cautioned not to apply element-level sensitivity markings unless they
845 believe the receiving party (i.e., the party they are exchanging the
846 event report data with) has a mechanism to adequately safeguard and
847 process the data as marked.
849 7. IANA Considerations
851 This document uses URNs to describe XML namespaces and XML schemata
852 conforming to a registry mechanism described in [RFC3688].
854 Registration request for the IODEF structured cybersecurity
855 information extension namespace:
857 URI: urn:ietf:params:xml:ns:iodef-sci-1.0
859 Registrant Contact: Refer here to the authors' addresses section
860 of the document.
862 XML: None
864 Registration request for the IODEF structured cybersecurity
865 information extension XML schema:
867 URI: urn:ietf:params:xml:schema:iodef-sci-1.0
869 Registrant Contact: Refer here to the authors' addresses section
870 of the document.
872 XML: Refer here to the XML Schema in the appendix of the document.
874 Request for managing a namespace list:
876 the schemata of the embedded structured information are maintained
877 outside of the IETF currently, but the list of the embedded
878 specifications' namespaces need to be registered to IANA
879 repository. The initial list of the namespaces are shown in
880 Figure 1.
882 8. Acknowledgment
884 The following groups and individuals, listed alphabetically,
885 contributed substantially to this document and should be recognized
886 for their efforts.
888 Paul Cichonski, NIST
890 Black David, EMC
892 Robert Martin, MITRE
894 Kathleen Moriarty, EMC
896 Lagadec Philippe, NATO
898 Shuhei Yamaguchi, NICT
900 Anthony Rutkowski, Yaana Technology
902 Brian Trammell, CERT/NetSA
904 9. Appendix: XML Schema Definition for Extension
906 The XML Schema describing the elements defined in the Extension
907 Definition section is given here. Each of the examples in Section 5
908 should be verified to validate against this schema by automated
909 tools. [Note: this section will be thoroughly checked later.]
911
913
920
924
928
929
930
931
932
933
935
937
938
940
944
945
946
947
949
951
953
954
956
957
958
959
961
965
966
967
968
970
972
974
976
977
979
981
983
984
986
990
991
992
993
995
997
999
1001
1002
1004
1006
1008
1009
1011
1015
1016
1017
1018
1020
1021
1023
1026
1027
1029
1033
1034
1035
1036
1037
1038
1039
1040
1041
1043
1045
1046
1048
1052
1053
1054
1055
1056
1057
1058
1059
1060
1062
1064
1065
1067
1069 Example Schema Diagram
1071 10. References
1072 10.1. Normative References
1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1075 Requirement Levels", BCP 14, RFC 2119, March 1997.
1077 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
1078 Object Description Exchange Format", RFC 5070,
1079 December 2007.
1081 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",
1082 RFC 6045, November 2010.
1084 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time
1085 Inter-network Defense (RID) Messages", RFC 6046,
1086 November 2010.
1088 10.2. Informative References
1090 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
1091 Internet: Timestamps", RFC 3339, July 2002.
1093 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1094 Text on Security Considerations", BCP 72, RFC 3552,
1095 July 2003.
1097 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1098 January 2004.
1100 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1101 Resource Identifier (URI): Generic Syntax", STD 66,
1102 RFC 3986, January 2005.
1104 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1105 October 2008.
1107 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
1108 Uniform Resource Identifiers (URI) Dynamic Delegation
1109 Discovery System (DDDS) Application (ENUM)", RFC 6116,
1110 March 2011.
1112 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The
1113 Common Vulnerability Scoring System (CVSS) and Its
1114 Applicability to Federal Agency Systems".
1116 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration
1117 and Classification (CAPEC)".
1119 [CEE] The MITRE Corporation, "Common Event Expression (CEE)".
1121 [CPE] Brant A. Cheikes and David Waltermire and Karen Scarfone,
1122 "Common Platform Enumeration: Naming Specificatino Version
1123 2.3", Aug 2011.
1125 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures
1126 (CVE)".
1128 [CVRF] ICASI, "http://www.icasi.org/cvrf".
1130 [CWE] The MITRE Corporation, "Common Weakness Enumeration
1131 (CWE)".
1133 [CWSS] The MITRE Corporation, "Common Weakness Scoring System
1134 (CWSS)".
1136 [ISOIEC19770-2]
1137 ISO/IEC, "Information technology -- Software asset
1138 management -- Part 2: Software identification tag", 2009.
1140 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The
1141 Open Checklist Interactive Language (OCIL) Version 2.0",
1142 Apr 2011.
1144 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment
1145 Language (OVAL)".
1147 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone
1148 and Neal Ziring, "Specification for the Extensible
1149 Configuration Checklist Description Format (XCCDF) version
1150 1.2 (DRAFT)", Jul 2011.
1152 [XDAS] The Open Group, "Distributed Audit Service (XDAS),
1153 Preliminary Specification", Jan 1998.
1155 Authors' Addresses
1157 Takeshi Takahashi
1158 National Institute of Information and Communications Technology
1159 4-2-1 Nukui-Kitamachi Koganei
1160 184-8795 Tokyo
1161 Japan
1163 Phone: +80 423 27 5862
1164 Email: takeshi_takahashi@nict.go.jp
1165 Kent Landfield
1166 McAfee, Inc
1167 5000 Headquarters Drive
1168 Plano, TX 75024
1169 USA
1171 Email: Kent_Landfield@McAfee.com
1173 Thomas Millar
1174 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT
1175 245 Murray Lane SW, Building 410, MS #732
1176 Washington, DC 20598
1177 USA
1179 Phone: +1 888 282 0870
1180 Email: thomas.millar@us-cert.gov
1182 Youki Kadobayashi
1183 National Institute of Information and Communications Technology
1184 4-2-1 Nukui-Kitamachi Koganei
1185 184-8795 Tokyo
1186 Japan
1188 Email: youki-k@is.aist-nara.ac.jp