idnits 2.17.1
draft-ietf-mile-sci-13.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 10 instances of too long lines in the document, the longest
one being 4 characters in excess of 72.
** The abstract seems to contain references ([RFC5070]), 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 (Jan 14, 2014) is 3748 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)
== Unused Reference: 'RFC3339' is defined on line 1208, but no explicit
reference was found in the text
== Unused Reference: 'RFC3552' is defined on line 1211, but no explicit
reference was found in the text
== Unused Reference: 'RFC5322' is defined on line 1222, but no explicit
reference was found in the text
== Unused Reference: 'RFC6116' is defined on line 1225, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'MMDEF'
** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XMLschemaPart1'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XMLschemaPart2'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNames'
Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MILE Working Group T. Takahashi
3 Internet-Draft NICT
4 Intended status: Standards Track K. Landfield
5 Expires: July 18, 2014 McAfee
6 T. Millar
7 USCERT
8 Y. Kadobayashi
9 NAIST
10 Jan 14, 2014
12 IODEF-extension for structured cybersecurity information
13 draft-ietf-mile-sci-13.txt
15 Abstract
17 This document extends the Incident Object Description Exchange Format
18 (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched
19 cybersecurity information among security experts at organizations and
20 facilitates their operations. It provides a well-defined pattern to
21 consistently embed structured information, such as identifier- and
22 XML-based information.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on July 18, 2014.
41 Copyright Notice
43 Copyright (c) 2014 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5
62 4.1. IANA Table for Structured Cybersecurity Information . . . 5
63 4.2. Extended Data Type: XMLDATA . . . . . . . . . . . . . . . 6
64 4.3. Extending IODEF . . . . . . . . . . . . . . . . . . . . . 6
65 4.4. Basic Structure of the Extension Classes . . . . . . . . . 7
66 4.5. Defining Extension Classes . . . . . . . . . . . . . . . . 9
67 4.5.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 9
68 4.5.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 10
69 4.5.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 10
70 4.5.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 11
71 4.5.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 12
72 4.5.6. EventReport . . . . . . . . . . . . . . . . . . . . . 13
73 4.5.7. Verification . . . . . . . . . . . . . . . . . . . . . 14
74 4.5.8. Remediation . . . . . . . . . . . . . . . . . . . . . 15
75 5. Mandatory to Implement features . . . . . . . . . . . . . . . 15
76 5.1. An Example XML . . . . . . . . . . . . . . . . . . . . . . 16
77 5.2. An XML Schema for the Extension . . . . . . . . . . . . . 18
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
79 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 22
80 6.2. Protection of Sensitive and Private Information . . . . . 23
81 6.3. Application and Server Security . . . . . . . . . . . . . 24
82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
83 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26
84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
86 9.2. Informative References . . . . . . . . . . . . . . . . . . 27
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
89 1. Introduction
91 The number of incidents in cyber society is growing day by day.
92 Incident information needs to be reported, exchanged, and shared
93 among organizations in order to cope with the situation. IODEF is
94 one of the tools already in use that enables such an exchange.
96 To more efficiently run security operations, information exchanged
97 between organizations needs to be machine readable. IODEF provides a
98 means to describe the incident information, but it often needs to
99 include various non-structured types of incident-related data in
100 order to convey more specific details about what is occurring.
101 Further structure within IODEF increases the machine-readability of
102 the document thus providing a means for better automating certain
103 security operations.
105 Within the security community there exist various means for
106 specifying structured descriptions of cybersecurity information such
107 as [CAPEC][CCE][CCSS][CEE][CPE][CVE][CVRF][CVSS][CWE][CWSS][MAEC]
108 [OCIL][OVAL][SCAP][XCCDF]. In this context, cybersecurity
109 information encompasses a broad range of structured data
110 representation types that may be used to assess or report on the
111 security posture of an asset or set of assets. Such structured
112 descriptions facilitates a better understanding of an incident while
113 enabling more streamlined automated security operations. Because of
114 this, it would be beneficial to embed and convey these types of
115 information inside IODEF documents.
117 This document extends IODEF to embed and convey various types of
118 structured information. Since IODEF defines a flexible and
119 extensible format and supports a granular level of specificity, this
120 document defines an extension to IODEF instead of defining a new
121 report format. For clarity, and to eliminate duplication, only the
122 additional structures necessary for describing the exchange of such
123 structured information are provided.
125 2. Terminology
127 The terminology used in this document follows the one defined in RFC
128 5070 [RFC5070].
130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
132 document are to be interpreted as described in RFC 2119 [RFC2119].
134 3. Applicability
136 To maintain awareness of the continually changing security threat
137 landscape, organization needs to exchange cybersecurity information,
138 which includes the following information: attack pattern, platform
139 information, vulnerability and weakness, countermeasure instruction,
140 computer event logs, and severity assessments. IODEF provides a
141 scheme to describe and exchange such information among interested
142 parties. However, it does not define the detailed formats to specify
143 such information.
145 There already exists structured and detailed formats for describing
146 these types of information that can be used in facilitating such an
147 exchange. They include [CAPEC][CCE][CCSS][CEE][CPE]
148 [CVE][CVRF][CVSS][CWE][CWSS][MAEC][OCIL][OVAL][SCAP][XCCDF]. By
149 embedding them into the IODEF document, the document can convey more
150 detailed context information to the receivers, and the document can
151 be easily reused.
153 The use of structured information formats facilitates more advanced
154 security operations on the receiver side. Since the information is
155 machine readable, the data can be processed by computers thus
156 allowing better automation of security operations.
158 For instance, an organization wishing to report a security incident
159 wants to describe what vulnerability was exploited. In this case the
160 sender can simply use IODEF, where an XML-based [XML1.0] attack
161 pattern record that follows the syntax and vocabulary defined by an
162 industry specification is embedded, instead of describing everything
163 in free form text. The receiver can identify the needed details of
164 the attack pattern by looking up some of the XML tags defined by the
165 specification. The receiver can accumulate the attack pattern record
166 in its database and could distribute it to the interested parties as
167 needed, all without requiring human interventions.
169 In another example, an administrator is investigating an incident and
170 detected a configuration problem that he wishes to share with a
171 partner organization to prevent the same event from occurring. He
172 accesses configuration information in an internal repository that was
173 gathered prior to the initial attack specific to a new vulnerability
174 alert to confirm the configuration was in fact vulnerable. He uses
175 this information to automatically generate an XML-based software
176 configuration description, embed it in an IODEF document, and send
177 the resulting IODEF document to the partner organization.
179 4. Extension Definition
181 This document extends IODEF to embed structured information by
182 introducing new classes that can be embedded consistently inside an
183 IODEF document as element contents of the AdditionalData and
184 RecordItem classes.
186 4.1. IANA Table for Structured Cybersecurity Information
188 This extension embeds structured cybersecurity information defined by
189 other specifications. The list of supported specifications is
190 managed by IANA, and this document defines the needed fields for the
191 list's entry.
193 Each entry has namespace [XMLNames], specification name, version,
194 reference URI, and applicable classes for each specification.
195 Arbitrary URIs that may help readers to understand the specification
196 could be embedded inside the Reference URI field, but it is
197 recommended that standard/informational URI describing the
198 specification is prepared and is embedded here.
200 The initial IANA table has only one entry, as below.
202 Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
203 Specification Name: Malware Metadata Exchange Format
204 Version: 1.2
205 Reference URI: http://standards.ieee.org/develop
206 /indconn/icsg/mmdef.html,
207 http://grouper.ieee.org/groups
208 /malware/malwg/Schema1.2/
209 Applicable Classes: AttackPattern
211 Note that the specification was developed by The Institute of
212 Electrical and Electronics Engineers, Incorporated (IEEE), through
213 the Industry Connections Security Group (ICSG) of its Standards
214 Association.
216 The table is to be managed by IANA following the allocation policy
217 specified in Section 7.
219 The SpecID attributes of extension classes (Section 4.5) must allow
220 the values of the specifications' namespace fields, but otherwise,
221 implementations are not required to support all specifications of the
222 IANA table and may choose which specifications to support, though the
223 specification listed in the initial table needs to be minimally
224 supported, as described in Section 5. In case an implementation
225 received a data it does not support, it may expand its functionality
226 by looking up the IANA table or notify the sender of its inability to
227 parse the data. Note that the look-up could be done manually or
228 automatically, but automatic download of data from IANA's website is
229 not recommended since it is not designed for mass retrieval of data
230 by multiple devices.
232 4.2. Extended Data Type: XMLDATA
234 This extension inherits all of the data types defined in the IODEF
235 data model. One data type is added: XMLDATA. An embedded XML data
236 is represented by the XMLDATA data type. This type is defined as the
237 extension to the iodef:ExtensionType [RFC5070], whose dtype attribute
238 is set to "xml".
240 4.3. Extending IODEF
242 This document defines eight extension classes, namely AttackPattern,
243 Platform, Vulnerability, Scoring, Weakness, EventReport, Verification
244 and Remediation. Figure 1 describes the relationships between the
245 IODEF Incident class [RFC5070] and the newly defined classes. It is
246 expressed in Unified Modeling Language (UML) syntax as with the RFC
247 5070 [RFC5070]. The UML representation is for illustrative purposes
248 only; elements are specified in XML as defined in Section 5.2.
250 +---------------+
251 | Incident |
252 +---------------+
253 | ENUM purpose |<>---------[IncidentID]
254 | STRING |<>--{0..1}-[AlternativeID]
255 | ext-purpose |<>--{0..1}-[RelatedActivity]
256 | ENUM lang |<>--{0..1}-[DetectTime]
257 | ENUM |<>--{0..1}-[StartTime]
258 | restriction |<>--{0..1}-[EndTime]
259 | |<>---------[ReportTime]
260 | |<>--{0..*}-[Description]
261 | |<>--{1..*}-[Assessment]
262 | |<>--{0..*}-[Method]
263 | | |<>--{0..*}-[AdditionalData]
264 | | |<>--{0..*}-[AttackPattern]
265 | | |<>--{0..*}-[Vulnerability]
266 | | |<>--{0..*}-[Weakness]
267 | |<>--{1..*}-[Contact]
268 | |<>--{0..*}-[EventData]
269 | | |<>--{0..*}-[Flow]
270 | | | |<>--{1..*}-[System]
271 | | | |<>--{0..*}-[AdditionalData]
272 | | | |<>--{0..*}-[Platform]
273 | | |<>--{0..*}-[Expectation]
274 | | |<>--{0..1}-[Record]
275 | | |<>--{1..*}-[RecordData]
276 | | |<>--{1..*}-[RecordItem]
277 | | |<>--{0..*}-[EventReport]
278 | |<>--{0..1}-[History]
279 | |<>--{0..*}-[AdditionalData]
280 | | |<>--{0..*}-[Verification]
281 | | |<>--{0..*}-[Remediation]
282 +---------------+
284 Figure 1: Incident class
286 4.4. Basic Structure of the Extension Classes
288 Figure 2 shows the basic structure of the extension classes. Some of
289 the extension classes have extra elements as defined in Section 4.5,
290 but the basic structure is the same.
292 +---------------------+
293 | New Class Name |
294 +---------------------+
295 | ENUM SpecID |<>--(0..*)-[ RawData ]
296 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
297 | STRING ContentID |
298 +---------------------+
300 Figure 2: Basic Structure
302 Three attributes are defined as below.
304 SpecID: REQUIRED. ENUM. A specification's identifier that
305 specifies the format of a structured information. The value
306 should be chosen from the namespaces [XMLNames] listed in the IANA
307 table (Section 4.1) or "private". The value "private" is prepared
308 for conveying structured information based on a format that is not
309 listed in the table. This is usually used for conveying data
310 formatted according to an organization's private schema. When the
311 value "private" is used, ext-SpecID element MUST be used.
313 ext-SpecID: OPTIONAL. STRING. A specification's identifier that
314 specifies the format of a structured information. This is usually
315 used to support private schema that is not listed in the IANA
316 table (Section 4.1). This attribute MUST be used only when the
317 value of SpecID element is "private."
319 ContentID: OPTIONAL. STRING. An identifier of a structured
320 information. Depending on the extension classes, the content of
321 the structured information differs. This attribute enables IODEF
322 documents to covey the identifier of a structured information
323 instead of conveying the information itself.
325 Likewise, three elements are defined as below.
327 RawData: Zero or more. XMLDATA. An XML of a structured
328 information. This is a complete document that is formatted
329 according to the specification and its version identified by the
330 SpecID/ext-SpecID. When this element is used, writers/senders
331 MUST ensure that the namespace specified by SpecID/ext-SpecID and
332 the schema of the XML are consistent; if not, the namespace
333 identified by SpecID SHOULD be preferred, and the inconsistency
334 SHOULD be logged so a human can correct the problem.
336 Reference: Zero or more of iodef:Reference [RFC5070]. A reference
337 to a structured information. This element allows an IODEF
338 document to include a link to a structured information instead of
339 directly embedding it into a RawData element.
341 Though ContentID, RawData, and Reference are optional attribute and
342 elements, one of them MUST be used to convey structured information.
343 Note that only one of them SHOULD be used to avoid confusing the
344 receiver.
346 4.5. Defining Extension Classes
348 This document defines the following seven extension classes.
350 4.5.1. AttackPattern
352 An AttackPattern is an extension class to the
353 Incident.Method.AdditionalData element with a dtype of "xml". It
354 describes attack patterns of incidents or events. It is RECOMMENDED
355 that Method class contain the extension elements whenever available.
356 An AttackPattern class is structured as follows.
358 +---------------------+
359 | AttackPattern |
360 +---------------------+
361 | ENUM SpecID |<>--(0..*)-[ RawData ]
362 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
363 | STRING ContentID |<>--(0..*)-[ Platform ]
364 +---------------------+
366 Figure 3: AttackPattern class
368 This class has the following attributes.
370 SpecID: REQUIRED. ENUM. See Section 4.4.
372 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
374 ContentID: OPTIONAL. STRING. An identifier of an attack pattern
375 information. See Section 4.4.
377 Likewise, this class has the following elements.
379 RawData: Zero or more. XMLDATA. An XML of an attack pattern
380 information. See Section 4.4.
382 Reference: Zero or more. A reference to an attack pattern
383 information. See Section 4.4.
385 Platform: Zero or more. An identifier of software platform involved
386 in the specific attack pattern. See Section 4.5.2.
388 4.5.2. Platform
390 A Platform is an extension class that identifies a software platform.
391 It is RECOMMENDED that AttackPattern, Vulnerability, Weakness, and
392 System classes contain the extension elements whenever available. A
393 Platform element is structured as follows.
395 +---------------------+
396 | Platform |
397 +---------------------+
398 | ENUM SpecID |<>--(0..*)-[ RawData ]
399 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
400 | STRING ContentID |
401 +---------------------+
403 Figure 4: Platform class
405 This class has the following attributes.
407 SpecID: REQUIRED. ENUM. See Section 4.4.
409 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
411 ContentID: OPTIONAL. STRING. An identifier of a platform
412 information. See Section 4.4.
414 Likewise, this class has the following elements.
416 RawData: Zero or more. XMLDATA. An XML of a platform information.
417 See Section 4.4.
419 Reference: Zero or more. A reference to a platform information.
420 See Section 4.4.
422 4.5.3. Vulnerability
424 A Vulnerability is an extension class to the
425 Incident.Method.AdditionalData element with a dtype of "xml". The
426 extension describes the vulnerabilities that are exposed or were
427 exploited in incidents. It is RECOMMENDED that Method class contain
428 the extension elements whenever available. A Vulnerability element
429 is structured as follows.
431 +---------------------+
432 | Vulnerability |
433 +---------------------+
434 | ENUM SpecID |<>--(0..*)-[ RawData ]
435 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
436 | STRING ContentID |<>--(0..*)-[ Platform ]
437 | |<>--(0..*)-[ Scoring ]
438 +---------------------+
440 Figure 5: Vulnerability class
442 This class has the following attributes.
444 SpecID: REQUIRED. ENUM. See Section 4.4.
446 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
448 ContentID: OPTIONAL. STRING. An identifier of a vulnerability
449 information. See Section 4.4.
451 Likewise, this class has the following elements.
453 RawData: Zero or more. XMLDATA. An XML of a vulnerability
454 information. See Section 4.4.
456 Reference: Zero or more. A reference to a vulnerability
457 information. See Section 4.4.
459 Platform: Zero or more. An identifier of software platform affected
460 by the vulnerability. See Section 4.5.2.
462 Scoring: Zero or more. An indicator of the severity of the
463 vulnerability. See Section 4.5.4.
465 4.5.4. Scoring
467 A Scoring is an extension class that describes the severity scores in
468 terms of security. It is RECOMMENDED that Vulnerability and Weakness
469 classes contain the extension elements whenever available. A Scoring
470 class is structured as follows.
472 +---------------------+
473 | Scoring |
474 +---------------------+
475 | ENUM SpecID |<>--(0..*)-[ RawData ]
476 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
477 | STRING ContentID |
478 +---------------------+
480 Figure 6: Scoring class
482 This class has two attributes.
484 SpecID: REQUIRED. ENUM. See Section 4.4.
486 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
488 ContentID: OPTIONAL. STRING. An identifier of a score set. See
489 Section 4.4.
491 Likewise, this class has the following elements.
493 RawData: Zero or more. XMLDATA. An XML of a score set. See
494 Section 4.4.
496 Reference: Zero or more. A reference to a score set. See
497 Section 4.4.
499 4.5.5. Weakness
501 A Weakness is an extension class to the
502 Incident.Method.AdditionalData element with a dtype of "xml". The
503 extension describes the weakness types that are exposed or were
504 exploited in incidents. It is RECOMMENDED that Method class contain
505 the extension elements whenever available. A Weakness element is
506 structured as follows.
508 +---------------------+
509 | Weakness |
510 +---------------------+
511 | ENUM SpecID |<>--(0..*)-[ RawData ]
512 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
513 | STRING ContentID |<>--(0..*)-[ Platform ]
514 | |<>--(0..*)-[ Scoring ]
515 +---------------------+
517 Figure 7: Weakness class
519 This class has the following attributes.
521 SpecID: REQUIRED. ENUM. See Section 4.4.
523 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
525 ContentID: OPTIONAL. STRING. An identifier of a weakness
526 information. See Section 4.4.
528 Likewise, this class has the following elements.
530 RawData: Zero or more. XMLDATA. An XML of a weakness information.
531 See Section 4.4.
533 Reference: Zero or more. A reference to a weakness information.
534 See Section 4.4.
536 Platform: Zero or more. An identifier of software platform affected
537 by the weakness. See Section 4.5.2.
539 Scoring: Zero or more. An indicator of the severity of the
540 weakness. See Section 4.5.4.
542 4.5.6. EventReport
544 An EventReport is an extension class to the
545 Incident.EventData.Record.RecordData.RecordItem element with a dtype
546 of "xml". The extension embeds structured event reports. It is
547 RECOMMENDED that RecordItem class contain the extension elements
548 whenever available. An EventReport element is structured as follows.
550 +---------------------+
551 | EventReport |
552 +---------------------+
553 | ENUM SpecID |<>--(0..*)-[ RawData ]
554 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
555 | STRING ContentID |
556 +---------------------+
558 Figure 8: EventReport class
560 This class has the following attributes.
562 SpecID: REQUIRED. ENUM. See Section 4.4.
564 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
566 ContentID: OPTIONAL. STRING. An identifier of an event report.
567 See Section 4.4.
569 Likewise, this class has the following elements.
571 RawData: Zero or more. XMLDATA. An XML of an event report. See
572 Section 4.4.
574 Reference: Zero or more. A reference to an event report. See
575 Section 4.4.
577 4.5.7. Verification
579 A Verification is an extension class to the Incident.AdditionalData
580 element with a dtype of "xml". The extension elements describes
581 information on verifying security, e.g., checklist, to cope with
582 incidents. It is RECOMMENDED that Incident class contain the
583 extension elements whenever available. A Verification class is
584 structured as follows.
586 +---------------------+
587 | Verification |
588 +---------------------+
589 | ENUM SpecID |<>--(0..*)-[ RawData ]
590 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
591 | STRING ContentID |
592 +---------------------+
594 Figure 9: Verification class
596 This class has the following attributes.
598 SpecID: REQUIRED. ENUM. See Section 4.4.
600 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
602 ContentID: OPTIONAL. STRING. An identifier of a verification
603 information. See Section 4.4.
605 Likewise, this class has the following elements.
607 RawData: Zero or more. XMLDATA. An XML of a verification
608 information. See Section 4.4.
610 Reference: Zero or more. A reference to a verification information.
611 See Section 4.4.
613 4.5.8. Remediation
615 A Remediation is an extension class to the Incident.AdditionalData
616 element with a dtype of "xml". The extension elements describes
617 incident remediation information including instructions. It is
618 RECOMMENDED that Incident class contain the extension elements
619 whenever available. A Remediation class is structured as follows.
621 +---------------------+
622 | Remediation |
623 +---------------------+
624 | ENUM SpecID |<>--(0..*)-[ RawData ]
625 | STRING ext-SpecID |<>--(0..*)-[ Reference ]
626 | String ContentID |
627 +---------------------+
629 Figure 10: Remediation class
631 This class has the following attributes.
633 SpecID: REQUIRED. ENUM. See Section 4.4.
635 ext-SpecID: OPTIONAL. STRING. See Section 4.4.
637 ContentID: OPTIONAL. STRING. An identifier of a remediation
638 information. See Section 4.4.
640 Likewise, this class has the following elements.
642 RawData: Zero or more. XMLDATA. An XML of a remediation
643 information. See Section 4.4.
645 Reference: Zero or more. A reference to a remediation information.
646 See Section 4.4.
648 5. Mandatory to Implement features
650 The implementation of this document MUST be capable of sending and
651 receiving the XML conforming to the specification listed in the
652 initial IANA table described in Section 4.1 without error. An SCI
653 document is an XML document that MUST be well-formed and MUST be
654 valid according to schemata, including extension schemata, available
655 to the validator and applicable to the XML document. Note that the
656 receiver can look up the namespace in the IANA table to understand
657 what specifications the embedded XML documents follows.
659 For the purpose of facilitating the understanding of mandatory to
660 implement features, the following subsections provide an XML
661 conformant to this document, and a schema for that.
663 5.1. An Example XML
665 An example IODEF document for checking implementation's MTI
666 conformity is provided here. The document carries MMDEF metadata.
667 Note that the metadata is generated by genMMDEF [MMDEF] with EICAR
668 [EICAR] files.
670
671
676
677 189493
678 2013-06-18T23:19:24+00:00
679 a candidate security incident
680
681
682
683
684 A candidate attack event
685
686
688
689
693 N/A
694 MMDEF Generation Script
695 Test MMDEF v1.2 file generated using genMMDEF
696
697 2013-03-23T15:12:50.726000
698
699
700 6ce6f415d8475545be5ba114f208b0ff
701 da39a3ee5e6b4b0d3255bfef95601890afd80709
702 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca4
703 95991b7852b855
704 cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83
705 f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b9
706 31bd47417a81a538327af927da3e
707 184
708 eicar_com.zip
709 application/zip
710
711
712 44d88612fea8a8f36de82e1278abb02f
713 3395856ce81f2b7382dee72602f798b642f14140
714 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4
715 538aabf651fd0f
716 cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e565e
717 68847223b8e6b85cb48f3afad842726d99239c9e36505c64b0
718 dc9a061d9e507d833277ada336ab
719 68
720 1750191932
721 eicar.com
722 eicar.com
723
724
725
726
727
728
731
732 file[@id="44d88612fea8a8f36de82e1278abb02f"]
733
734 2013-03-23T15:12:50.744000
735
736
737
738
739
740
741
742
743 iodef-sci.example.com
744 iodef-sci.example-com
745
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
766
767
768
769
771 5.2. An XML Schema for the Extension
773 An XML schema describing the elements defined in this document is
774 given here.
776
778
784
787
788
789
790
791
793
794
796
797
798
799
800
802
803
805
806
807
808
809
811
813
814
815
816
818
820
821
823
824
825
826
827
829
831
832
834
835
836
838
840
841
843
844
845
846
847
849
851
852
854
856
857
858
860
862
863
865
866
867
868
869
871
873
874
876
878
879
880
882
884
885
887
888
889
890
891
893
895
896
897
898
900
902
903
905
906
907
908
909
911
913
914
915
916
918
920
921
923
924
925
926
927
929
931
932
933
934
936
938
939
941
942
943
944
945
947
949
950
951
952
954
956
957
959
961 6. Security Considerations
963 This document specifies a format for encoding a particular class of
964 security incidents appropriate for exchange across organizations. As
965 merely a data representation, it does not directly introduce security
966 issues. However, it is guaranteed that parties exchanging instances
967 of this specification will have certain concerns. For this reason,
968 the underlying message format and transport protocol used MUST ensure
969 the appropriate degree of confidentiality, integrity, and
970 authenticity for the specific environment. Specific security
971 considerations are detailed in the messaging and transport documents,
972 where the exchange of formatted information is automated. See Real-
973 time Inter-network Defense (RID) [RFC6545] Section 9 for a detailed
974 overview of security requirements and considerations.
976 It is RECOMMENDED that organizations who exchange data using this
977 document develop operating procedures that minimally consider the
978 following areas of concern.
980 6.1. Transport-Specific Concerns
982 The underlying messaging format, IODEF, provides data markers to
983 indicate the sensitivity level of specific classes within the
984 structure as well as for the entire XML document. The "restriction"
985 attribute accomplishes this with four attribute values in IODEF.
986 These values are RECOMMENDED for use at the application level, prior
987 to transport, to protect data as appropriate. A standard mechanism
988 to apply XML encryption using these attribute values as triggers is
989 defined in RID [RFC6545] Section 9.1. This mechanism may be used
990 whether or not the RID and RID Transport binding [RFC6546] are used
991 in the exchange to provide object level security on the data to
992 prevent possible intermediary systems or middle-boxes from having
993 access to the data being exchanged. In areas where transmission
994 security or secrecy is questionable, the application of a XML digital
995 signature [xmldsig] and/or encryption on each report will counteract
996 both of these concerns. The data markers are RECOMMENDED for use by
997 applications for managing access controls, however access controls
998 and management of those controls are out-of-scope for this document.
999 Options such as the usage of a standard language (e.g. XACML
1000 [XACML]) for the expression of authorization policies can be used to
1001 enable source and destination systems to better coordinate and align
1002 their respective policy expressions.
1004 Any transport protocol used to exchange instances of IODEF documents
1005 MUST provide appropriate guarantees of confidentiality, integrity,
1006 and authenticity. The use of a standardized security protocol is
1007 encouraged. The RID protocol [RFC6545] and its associated transport
1008 binding [RFC6546] provide such security with options for mutual
1009 authentication session encryption and include application levels
1010 concerns such as policy and work flow.
1012 The critical security concerns are that these structured information
1013 may be falsified, accessed by unintended entities, or they may become
1014 corrupt during transit. We expect that each exchanging organization
1015 will determine the need, and mechanism, for transport protection.
1017 6.2. Protection of Sensitive and Private Information
1019 For a complete review of privacy considerations when transporting
1020 incident related information, please see RID [RFC6545] Section 9.5.
1021 Whether or not the RID protocol is used, the privacy considerations
1022 are important to consider as incident information is often sensitive
1023 and may contain privacy related information about individuals/
1024 organizations or endpoints involved. Often times, organizations will
1025 require legal review and formal polices to be established which
1026 outline specific details of what information can be exchanged with
1027 specific entities. Typically, identifying information is anonymized
1028 where possible and appropriate. In some cases, information brokers
1029 are used to further anonymize the source of exchanged information so
1030 that other entities are unaware of the origin of a detected threat,
1031 whether or not that threat was realized.
1033 It is RECOMMENDED that policies and procedures for the exchange of
1034 cybersecurity information are established prior to participation in
1035 data exchanges. Policy and workflow procedures for the exchange of
1036 cybersecurity information often require executive level approvals and
1037 legal reviews to appropriately establish limits on what information
1038 can be exchanged with specific organizations. RID [RFC6545] Section
1039 9.6 outlines options and considerations for application developers to
1040 consider for the policy and workflow design.
1042 6.3. Application and Server Security
1044 The Cybersecurity Information extension is merely a data format.
1045 Applications and transport protocols that store or exchange IODEF
1046 documents using information that can be represented through this
1047 extension will be a target for attacks. It is RECOMMENDED that
1048 systems and applications storing or exchanging this information are
1049 properly secured, have minimal services enabled, maintain access
1050 controls and monitoring procedures.
1052 7. IANA Considerations
1054 This document uses URNs to describe XML namespaces and XML schemata
1055 [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism
1056 described in [RFC3688].
1058 Registration request for the IODEF structured cybersecurity
1059 information extension namespace:
1061 URI: urn:ietf:params:xml:ns:iodef-sci-1.0
1063 Registrant Contact: Refer here to the authors' addresses section
1064 of the document.
1066 XML: None.
1068 Registration request for the IODEF structured cybersecurity
1069 information extension XML schema:
1071 URI: urn:ietf:params:xml:schema:iodef-sci-1.0
1073 Registrant Contact: Refer here to the authors' addresses section
1074 of the document.
1076 XML: Refer here to the XML Schema in Section 5.2.
1078 This memo creates the following registry for IANA to manage:
1080 Name of the registry: "Structured Cybersecurity Information (SCI)
1081 specifications"
1083 Name of its parent registry: "Incident Object Description Exchange
1084 Format (IODEF)"
1086 URL address of the registry: http://www.iana.org/assignments/iodef
1087 Namespace details: A registry entry for a Structured Cybersecurity
1088 Information Specification (SCI specification) consists of:
1090 Namespace: A URI [RFC3986] that identifies the XML namespace
1091 used by the registered SCI specification. In the case where
1092 the registrant does not request a particular URI, the IANA will
1093 assign it a Uniform Resource Name (URN) that follows RFC 3553
1094 [RFC3553]
1096 Specification Name: A string containing the spelled-out name of
1097 the SCI specification in human-readable form.
1099 Reference URI: A list of one or more of the URIs [RFC3986] from
1100 which the registered specification can be obtained. The
1101 registered specification MUST be readily and publicly available
1102 from that URI.
1104 Applicable Classes: A list of one or more of the extension
1105 classes specified in Section 4.5 of this document. The
1106 registered SCI specification MUST only be used with the
1107 extension classes in the registry entry.
1109 Information that must be provided to assign a new value: The above
1110 list of information.
1112 Fields to record in the registry: Namespace/Specification Name/
1113 Version/Reference URI/Applicable Classes. Note that it is not
1114 necessary to include defining reference for all assignments in
1115 this new registry.
1117 Initial registry contents: only one entry with the following
1118 values.
1120 Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.0
1122 Specification Name: Malware Metadata Exchange Format
1124 Version: 1.2
1126 Reference URI: http://standards.ieee.org/develop/indconn/icsg/
1127 mmdef.html,http://grouper.ieee.org/groups/malware/malwg/
1128 Schema1.2/
1130 Applicable Classes: AttackPattern
1132 Allocation Policy: Specification Required (which includes Expert
1133 Review) [RFC5226].
1135 The Designated Expert is expected to consult with the mile (Managed
1136 Incident Lightweight Exchange) working group or its successor if any
1137 such WG exists (e.g., via email to the working group's mailing list).
1138 The Designated Expert is expected to retrieve the SCI specification
1139 from the provided URI in order to check the public availability of
1140 the specification and verify the correctness of the URI. An
1141 important responsibility of the Designated Expert is to ensure that
1142 the registered Applicable Classes are appropriate for the registered
1143 SCI specification.
1145 8. Acknowledgment
1147 We would like to acknowledge David Black from EMC, who kindly
1148 provided generous support, especially on the IANA registry issues.
1149 We also would like to thank Jon Baker from MITRE, Eric Burger from
1150 Georgetown University, Paul Cichonski from NIST, Panos Kampanakis
1151 from CISCO, Pearl Liang from IANA, Ivan Kirillov from MITRE, Robert
1152 Martin from MITRE, Alexey Melnikov from Isode, Kathleen Moriarty from
1153 EMC, Lagadec Philippe from NATO, Sean Turner from IECA Inc., Shuhei
1154 Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, Brian
1155 Trammell from ETH Zurich, David Waltermire from NIST, and James
1156 Wendorf from IEEE, for their sincere discussion and feedback on this
1157 document.
1159 9. References
1161 9.1. Normative References
1163 [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group,
1164 "Malware Metadata Exchange Format".
1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1167 Requirement Levels", BCP 14, RFC 2119, March 1997.
1169 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1170 Resource Identifier (URI): Generic Syntax", STD 66,
1171 RFC 3986, January 2005.
1173 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
1174 Object Description Exchange Format", RFC 5070,
1175 December 2007.
1177 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1178 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1179 May 2008.
1181 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
1182 RFC 6545, April 2012.
1184 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
1185 Defense (RID) Messages over HTTP/TLS", RFC 6546,
1186 April 2012.
1188 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and
1189 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
1190 Edition)", W3C Recommendation, November 2008.
1192 [XMLschemaPart1]
1193 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
1194 "XML Schema Part 1: Structures Second Edition",
1195 W3C Recommendation, October 2004.
1197 [XMLschemaPart2]
1198 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1199 Second Edition", W3C Recommendation, October 2004.
1201 [XMLNames]
1202 Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
1203 Thomson, ""Namespaces in XML (Third Edition)",
1204 W3C Recommendation, December 2009.
1206 9.2. Informative References
1208 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
1209 Internet: Timestamps", RFC 3339, July 2002.
1211 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1212 Text on Security Considerations", BCP 72, RFC 3552,
1213 July 2003.
1215 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
1216 IETF URN Sub-namespace for Registered Protocol
1217 Parameters", BCP 73, RFC 3553, June 2003.
1219 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1220 January 2004.
1222 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1223 October 2008.
1225 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
1226 Uniform Resource Identifiers (URI) Dynamic Delegation
1227 Discovery System (DDDS) Application (ENUM)", RFC 6116,
1228 March 2011.
1230 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration
1231 and Classification (CAPEC)".
1233 [CCE] The MITRE Corporation, "Common Configuration Enumeration
1234 (CCE)".
1236 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration
1237 Scoring System (CCSS)", NIST Interagency Report 7502,
1238 December 2010.
1240 [CEE] The MITRE Corporation, "Common Event Expression (CEE)".
1242 [CPE] National Institute of Standards and Technology, "Common
1243 Platform Enumeration", June 2011.
1245 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures
1246 (CVE)".
1248 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)".
1250 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The
1251 Common Vulnerability Scoring System (CVSS) and Its
1252 Applicability to Federal Agency Systems".
1254 [CWE] The MITRE Corporation, "Common Weakness Enumeration
1255 (CWE)".
1257 [CWSS] The MITRE Corporation, "Common Weakness Scoring System
1258 (CWSS)".
1260 [EICAR] European Expert Group for IT-Security, "Anti-Malware
1261 Testfile", 2003.
1263 [MAEC] The MITRE Corporation, "Malware Attribute Enumeration and
1264 Characterization".
1266 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The
1267 Open Checklist Interactive Language (OCIL) Version 2.0",
1268 April 2011.
1270 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment
1271 Language (OVAL)".
1273 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A.
1274 Halbardier, "The Technical Specification for the Security
1275 Content Automation Protocol (SCAP): SCAP Version 1.2",
1276 NIST Special Publication 800-126 Revision 2,
1277 September 2011.
1279 [XACML] Rissanen, E., "eXtensible Access Control Markup Language
1280 (XACML) Version 3.0", January 2013, .
1284 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone
1285 and Neal Ziring, "Specification for the Extensible
1286 Configuration Checklist Description Format (XCCDF) version
1287 1.2 (DRAFT)", July 2011.
1289 [xmldsig] W3C Recommendation, "XML Signature Syntax and Processing
1290 (Second Edition)", June 2008.
1292 Authors' Addresses
1294 Takeshi Takahashi
1295 National Institute of Information and Communications Technology
1296 4-2-1 Nukui-Kitamachi Koganei
1297 184-8795 Tokyo
1298 Japan
1300 Phone: +80 423 27 5862
1301 Email: takeshi_takahashi@nict.go.jp
1303 Kent Landfield
1304 McAfee, Inc
1305 5000 Headquarters Drive
1306 Plano, TX 75024
1307 USA
1309 Email: Kent_Landfield@McAfee.com
1311 Thomas Millar
1312 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT
1313 245 Murray Lane SW, Building 410, MS #732
1314 Washington, DC 20598
1315 USA
1317 Phone: +1 888 282 0870
1318 Email: thomas.millar@us-cert.gov
1319 Youki Kadobayashi
1320 Nara Institute of Science and Technology
1321 8916-5 Takayama, Ikoma
1322 630-0192 Nara
1323 Japan
1325 Email: youki-k@is.aist-nara.ac.jp