idnits 2.17.1 draft-ietf-mile-rolie-csirt-06.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 28, 2019) is 1642 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: 'RFC2119' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC4287' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC5023' is defined on line 609, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) == Outdated reference: A later version (-17) exists of draft-dulaunoy-misp-core-format-07 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group S. Banghart 3 Internet-Draft NIST 4 Intended status: Standards Track J. Field 5 Expires: April 30, 2020 Pivotal 6 October 28, 2019 8 Definition of ROLIE CSIRT Extension 9 draft-ietf-mile-rolie-csirt-06 11 Abstract 13 This document extends the Resource-Oriented Lightweight Information 14 Exchange (ROLIE) core to add the Indicator and Incident information 15 types, relevant categories, and related requirements needed to 16 support Computer Security Incident Response Team (CSIRT) use cases. 17 Additional supporting requirements are also defined that describe the 18 use of specific formats and link relations pertaining to the new 19 information types. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 30, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Information-type Extensions . . . . . . . . . . . . . . . . . 4 58 3.1. The "incident" information type . . . . . . . . . . . . . 4 59 3.2. The "indicator" information type . . . . . . . . . . . . 5 60 4. Data format requirements . . . . . . . . . . . . . . . . . . 5 61 4.1. Incident Object Description Exchange Format . . . . . . . 6 62 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6 63 4.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Structured Threat Information eXpression (STIX) Format . 6 65 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 66 4.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 7 67 4.3. Malware Information Sharing Platform (MISP) Format . . . 7 68 4.3.1. Creating MISP Event Entries . . . . . . . . . . . . . 8 69 4.3.2. MISP Feeds and Manifests . . . . . . . . . . . . . . 8 70 5. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Link relations for the 'incident' 72 information-type . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Link relations for the 'indicator' 74 information-type . . . . . . . . . . . . . . . . . . . . 10 75 5.3. Link relations for both information-types . . . . . . . . 10 76 6. atom:category Extensions . . . . . . . . . . . . . . . . . . 11 77 6.1. Newly registered category values . . . . . . . . . . . . 11 78 6.2. Expectation and Impact Classes . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7.1. information-type registrations . . . . . . . . . . . . . 12 81 7.1.1. incident information-type . . . . . . . . . . . . . . 12 82 7.1.2. indicator information-type . . . . . . . . . . . . . 12 83 7.2. atom:category scheme registrations . . . . . . . . . . . 12 84 7.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 13 85 7.2.2. category:csirt:iodef:restriction . . . . . . . . . . 13 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 9.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. Examples of Use . . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 Threats to computer security are evolving ever more rapidly as time 96 goes on. As software increases in complexity, the number of 97 vulnerabilities in systems and networks can increase exponentially. 98 Threat actors looking to exploit these vulnerabilities are making 99 more frequent and more widely distributed attacks across a large 100 variety of systems. The adoption of liberal information sharing 101 amongst attackers allows a discovered vulnerability to be shared and 102 used to attack a vulnerable system within a narrow window of time. 103 As the skills and knowledge required to identify and combat these 104 attacks become more and more specialized, even a well established and 105 secure system may find itself unable to quickly respond to an 106 incident. Effective identification of and response to a 107 sophisticated attack requires open cooperation and collaboration 108 between defending operators, software vendors, and end-users. To 109 improve the timeliness of responses, automation must be used to 110 acquire, contextualize, and put to use shared computer security 111 information. 113 Computer Security Incident Response Teams (CSIRTs) share two primary 114 forms of information: incidents and indicators. Using these forms of 115 information, analysts are able to perform a wide range of activities 116 both proactive and reactive to improve the security of their systems. 118 Incident information describes a cyber security incident. Such 119 information may include attack characteristics, information about the 120 attacker, and attack vector data. Sharing this information helps 121 analysts within the sharing community to inoculate their systems 122 against similar attacks, providing proactive protection. 124 Indicator information describes the symptoms or necessary pre- 125 conditions of an attack. Everything from system vulnerabilities to 126 unexpected network traffic can help analysts secure systems and 127 prepare for an attack. Making this information available for sharing 128 aids in the proactive defense of systems both within an operating 129 unit but also for any CSIRTs that are part of a sharing consortium. 131 As a means to bring automation of content discovery and dissemination 132 into the CSIRT domain, this specification provides an extension to 133 the Resource-Oriented Lightweight Information Exchange (ROLIE) core 134 [RFC8322] designed to address CSIRT use cases. The primary purpose 135 of this extension is to define two new information types: incident, 136 and indicator, along with formats and link relations that support 137 these information-types. 139 2. Terminology 141 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 142 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC8174]. 145 Definitions for some of the common computer security-related 146 terminology used in this document can be found in Section 2 of 147 [RFC5070]. 149 As an extension of [RFC8322], this document refers to many terms 150 defined in that document. In particular, the use of "Entry" and 151 "Feed" are aligned with the definitions presented there. 153 Several places in this document refer to the "information-type" of a 154 Resource (Entry or Feed). This refers to the "term" attribute of an 155 "atom:category" element whose scheme is 156 "urn:ietf:params:rolie:category:information-type". For an Entry, 157 this value can be inherited from it's containing Feed as per 158 [RFC8322]. 160 3. Information-type Extensions 162 3.1. The "incident" information type 164 When an "atom:category" element has a "scheme" attribute equal to 165 "urn:ietf:params:rolie:category:information-type", the "term" 166 attribute defines the information type of the associated resource. A 167 new valid "term" value for this "scheme": "incident", is described in 168 this section, and registered in Section 7.1.1. 170 The "incident" information type represents any information describing 171 or pertaining to a computer security incident. This document uses 172 the definition of incident provided by [RFC4949]. Provided below is 173 a non-exhaustive list of information that may be considered to be an 174 incident information type. 176 o Timing information: start and end times for the incident and/or 177 the response. 179 o Descriptive information: plain text or machine readable data that 180 provides some degree of description of the incident itself. 182 o Response information: the methods and results of a response to the 183 incident. 185 o Meta and contact information: data about the CSIRT that recorded 186 the information, or the operator that enacted the response. 188 o Effect and result information: data that describes the effects of 189 an incident, or what the final results of the incident are. 191 Note again that this list is not exhaustive, any information that is 192 in the abstract realm of an incident should be classified under this 193 information-type. 195 3.2. The "indicator" information type 197 When an "atom:category" element has a "scheme" attribute equal to 198 "urn:ietf:params:rolie:category:information-type", the "term" 199 attribute defines the information type of the associated resource. A 200 new valid "term" value for this "scheme": "indicator", is described 201 in this section, and registered in Section 7.1.2. 203 The "indicator" information type represents computer security 204 indicators or any information surrounding them. This document uses 205 the definition of indicator provided by [RFC4949]. Some examples of 206 indicator information are provided below, but note that indicator is 207 defined in an abstract sense, to be understood as a flexible and 208 widely-applicable definition. 210 o Specific vulnerabilities that indicate a vector for attack. 212 o Signs of malicious reconnaissance. 214 o Definitions of patterns of other indicators. 216 o Events that may indicate an attack and information regarding those 217 events. 219 o Meta information about the collecting agent. 221 This list is intended to provide examples of the indicator 222 information-type, not to define it. 224 4. Data format requirements 226 This section defines usage guidance and additional requirements 227 related to data formats above and beyond those specified in 228 [RFC8322]. The following formats are expected to be commonly used to 229 express software descriptor information. For this reason, this 230 document specifies additional requirements to ensure 231 interoperability. 233 4.1. Incident Object Description Exchange Format 235 4.1.1. Description 237 The Incident Object Description Exchange Format (IODEF) is a format 238 for representing computer security information commonly exchanged 239 between Computer Security Incident Response Teams (CSIRTs) or other 240 operational security teams. 242 IODEF conveys indicators, incident reports, response activities, and 243 related meta-data in an XML serialization. This information is 244 formally structured in order to support and encourage automated 245 machine-to-machine security communication, as well as enhanced 246 processing at the endpoint. 248 The full IODEF specification [RFC7970] provides further high-level 249 discussion and technical details. 251 4.1.2. Requirements 253 For an Entry to be considered as a "IODEF Entry", it MUST fulfill the 254 following conditions: 256 o The information-type of the Entry is "indicator" or "incident". 257 For a typical Entry, this is derived from the information type of 258 the Feed it is contained in. For a standalone Entry, this is 259 provided by an "atom:category" element. 261 o The document linked to by the "href" attribute of the 262 "atom:content" element is an IODEF document as per [RFC7970] 264 A "IODEF Entry" MUST conform to the following requirements: 266 o The value of the "type" attribute of the "atom:content" element 267 MUST be "application/xml". 269 o There MUST be at least one "rolie:property" with the "name" 270 attribute equal to "urn:ietf:params:rolie:property:content-id" and 271 the "value" attribute exactly equal to the "" or the 272 "" element in the attached IODEF document. This 273 allows for ROLIE consumers to more easily search for IODEF 274 documents without needing to download the document itself. 276 4.2. Structured Threat Information eXpression (STIX) Format 277 4.2.1. Description 279 STIX is a structured language for describing a wide range of security 280 resources. STIX approaches the problem with a focus on flexibility, 281 automation, readability, and extensibility. 283 The full STIX specification [stix2] provides further high-level 284 discussion and technical details. 286 4.2.2. Requirements 288 For an Entry to be considered as a "STIX Entry", it MUST fulfill the 289 following conditions: 291 o The information-type of the Entry is "indicator" or "incident". 292 For a typical Entry, this is derived from the information type of 293 the Feed it is contained in. For a standalone Entry, this is 294 provided by an "atom:category" element. 296 o The document linked to by the "href" attribute of the 297 "atom:content" element is a STIX object as per [stix2] 299 A "STIX Entry" MUST conform to the following requirements: 301 o The value of the "type" attribute of the "atom:content" element 302 MUST be "application/xml" or "application/json". 304 o There MUST be at least one "rolie:property" with the "name" 305 attribute equal to "urn:ietf:params:rolie:property:content-id" and 306 the "value" attribute exactly equal to the "" element in the 307 attached STIX object . This allows for ROLIE consumers to more 308 easily search for STIX objects without needing to download the 309 document itself. 311 4.3. Malware Information Sharing Platform (MISP) Format 313 MISP involves documentation, utilities, and formats designed to 314 facilitate the day-to-day duties of security operators. MISP 315 includes it's own data format that is used to share between MISP 316 features. While MISP has Feed features that can share and distribute 317 events, it has support for linking to other sharing methods like 318 ROLIE. 320 MISP is defined by a family of internet drafts currently being 321 developed in the IETF. With that in mind, this extension will 322 provide non-normative guidance on using MISP format data in ROLIE. 323 In the future, when the MISP format is formally published, this 324 document will be updated to normative requirements around MISP 325 content. 327 4.3.1. Creating MISP Event Entries 329 MISP content should be syndicated in ROLIE using the following 330 guidance: 332 o The information-type of the Entry is "indicator". For a typical 333 Entry, this is derived from the information type of the Feed it is 334 contained in. For a standalone Entry, this is provided by an 335 "atom:category" element. 337 o The document linked to by the "href" attribute of the 338 "atom:content" element is a MISP Event object as per 339 [I-D.dulaunoy-misp-core-format] 341 o The value of the "type" attribute of the "atom:content" element 342 should be "application/xml". 344 o There should be at least one "rolie:property" with the "name" 345 attribute equal to "urn:ietf:params:rolie:property:content-id" and 346 the "value" attribute exactly equal to the "" element in the 347 attached MISP Event. This allows for ROLIE consumers to more 348 easily search for MISP Events without needing to download the 349 document itself. 351 o It is also recommended to expose information in the ROLIE Entry 352 that is required and recommended to expose in the MISP Manifest 353 format. This ensures better compatibility between a ROLIE Feed 354 and a MISP Manifest. 356 * The following fields are required by the MISP draft: info, 357 Orgc, timestamp, date 359 * The following fields are recommended by the MISP draft: 360 analysis, threat_level_id 362 4.3.2. MISP Feeds and Manifests 364 MISP Feeds are hosted lists of MISP events, each event represented by 365 its UUID. Users request Events on a one-by-one basis and are served 366 the full Event on each request. 368 MISP Manifest files list MISP events by their UUIDs as well, but 369 provide a variety of metadata for each Event inline. After examining 370 the minimized and stripped Event in the manifest, a user could search 371 for the Event UUID of interest in a locally located folder of Event 372 files where the file name is the UUID of the Event. 374 ROLIE hosting MISP data would operate as a combination of these 375 approaches. Each ROLIE Feed would contain a list of Event Entries, 376 each with metadata and identifying information about a given Event. 377 Should the user be interested in the Event, the Event Entry provides 378 a direct link to download the full Event. In short, a ROLIE MISP 379 Feed is minimally mappable to a MISP Manifest file where a resolvable 380 link to the MISP Event was injected into each Event described in the 381 Manifest. 383 With that in mind, a MISP Feed as well as a MISP Manifest with 384 attached local file list could be fully converted and hosted as a 385 ROLIE repository. As a lower overhead alternative, a ROLIE server 386 could simply provide a view into MISP data. 388 5. atom:link Extensions 390 This section defines additional link relationships that 391 implementations MUST support. These relationships are not registered 392 in the Link Relation IANA table as their use case is too narrow. 393 Each relationship is named and described. 395 These relations come in related pairs. The first of each pair is 396 expected to be more common, as they can be determined at the time 397 that the Entry is created. The second of each pair will often need 398 to be added retroactively to an Entry. 400 5.1. Link relations for the 'incident' information-type 402 If a ROLIE server supports the incident information-type, then these 403 link relations MUST be supported. 405 +------------+------------------------------------------------------+ 406 | Name | Description | 407 +------------+------------------------------------------------------+ 408 | indicators | Provides a link to a collection of zero or more | 409 | | instances of cyber security indicators that are | 410 | | associated with the resource. | 411 | evidence | Provides a link to a collection of zero or more | 412 | | resources that provides some proof of attribution | 413 | | for an incident. The evidence may or may not have | 414 | | any identified chain of custody. | 415 | attacker | Provides a link to a collection of zero or more | 416 | | resources that provides a representation of the | 417 | | attacker. | 418 | vector | Provides a link to a collection of zero or more | 419 | | resources that provides a representation of the | 420 | | method used by the attacker. | 421 +------------+------------------------------------------------------+ 423 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 424 Exchange 426 5.2. Link relations for the 'indicator' information-type 428 If a ROLIE server supports the indicator information-type, then these 429 link relations MUST be supported. 431 +-----------+-------------------------------------------------------+ 432 | Name | Description | 433 +-----------+-------------------------------------------------------+ 434 | incidents | Provides a link to a collection of zero or more | 435 | | instances of incident representations associated with | 436 | | the resource. | 437 +-----------+-------------------------------------------------------+ 439 Table 2: Link Relations for Resource-Oriented Lightweight Indicator 440 Exchange 442 5.3. Link relations for both information-types 444 If a ROLIE server supports either the incident or the indicator 445 information-types, then these link relations MUST be supported. 447 +-----------------------+-------------------------------------------+ 448 | Name | Description | 449 +-----------------------+-------------------------------------------+ 450 | assessments | Provides a link to a collection of zero | 451 | | or more resources that represent the | 452 | | results of executing a benchmark. | 453 | reports | Provides a link to a collection of zero | 454 | | or more resources that represent RID | 455 | | reports. | 456 | traceRequests | Provides a link to a collection of zero | 457 | | or more resources that represent RID | 458 | | traceRequests. | 459 | investigationRequests | Provides a link to a collection of zero | 460 | | or more resources that represent RID | 461 | | investigationRequests. | 462 +-----------------------+-------------------------------------------+ 464 Table 3: Link Relations for Resource-Oriented Lightweight Indicator 465 Exchange 467 6. atom:category Extensions 469 6.1. Newly registered category values 471 This document registers two additional registered atom:category 472 names: 'urn:ietf:params:rolie:category:csirt:iodef:purpose' and 473 'urn:ietf:params:rolie:category:csirt:iodef:restriction'. These 474 categories expose important information from inside the attached 475 IODEF document. The Purpose and Restriction elements are often used 476 to sort or cateogrize IODEF documents, and in some use cases, 477 determine the security and access permissions of the document. 479 When the name attribute of the category is 480 'urn:ietf:params:rolie:category:csirt:iodef:purpose', the value 481 attribute SHOULD be constrained as per section 3.2 of IODEF 482 [RFC7970], e.g. traceback, mitigation, reporting, or other. 484 When the name attribute of the category is 485 'urn:ietf:params:rolie:category:csirt:iodef:restriction', the value 486 attribute SHOULD be constrained as per section 3.2 of IODEF 487 [RFC7970], e.g. public, need-to-know, private, default. 489 6.2. Expectation and Impact Classes 491 It is frequently the case that an organization will need to triage 492 their investigation and response activities based upon, e.g., the 493 state of the current threat environment, or simply as a result of 494 having limited resources. 496 In order to enable operators to effectively prioritize their response 497 activity, it is RECOMMENDED that feed implementers provide Atom 498 categories that correspond to the IODEF Expectation and Impact 499 classes. The availability of these feed categories will enable 500 clients to more easily retrieve and prioritize cyber security 501 information that has already been identified as having a specific 502 potential impact, or having a specific expectation. 504 Support for these categories may also enable efficiencies for 505 organizations that already have established (or plan to establish) 506 operational processes and workflows that are based on these IODEF 507 classes. 509 7. IANA Considerations 511 7.1. information-type registrations 513 IANA has added the following entries to the "ROLIE Security Resource 514 Information Type Sub-Registry" registry located at 515 . 517 7.1.1. incident information-type 519 The entry is as follows: 521 name: incident 523 index: TBD 525 reference: This document, Section 3.1 527 7.1.2. indicator information-type 529 The entry is as follows: 531 name: indicator 533 index: TBD 535 reference: This document, Section 3.2 537 7.2. atom:category scheme registrations 539 IANA has added the following entries to the "ROLIE URN Parameters" 540 registry located in . 542 7.2.1. category:csirt:iodef:purpose 544 The entry is as follows: 546 name: category:csirt:iodef:purpose 548 Extension IRI: urn:ietf:params:rolie:category:csirt:iodef:purpose 550 Reference: This document, Section 6.1 552 Subregistry: None 554 7.2.2. category:csirt:iodef:restriction 556 The entry is as follows: 558 name: category:csirt:iodef:restriction 560 Extension IRI: 561 urn:ietf:params:rolie:category:csirt:iodef:restriction 563 Reference: This document, Section 6.1 565 Subregistry: None 567 8. Security Considerations 569 This document implies the use of ROLIE in high-security use cases; as 570 such, added care should be taken to fortify and secure ROLIE 571 repositories and clients using this extension. The guidance in the 572 ROLIE core specification is strongly recommended, and implementers 573 should consider adding additional security measures as they see fit. 575 When providing a private workspace for closed sharing, it is 576 recommended that the ROLIE repository checks user authorization when 577 the user sends a GET request to the service document. If the user is 578 not authorized to send any requests to a given workspace or 579 collection, that workspace or collection should be truncated from the 580 service document in the response. In this way the existence of 581 unauthorized content remains unknown to potential attackers, 582 hopefully reducing attack surface. 584 When sharing IODEF Version 2 documents using a ROLIE server, care 585 should be taken to seperate IODEF Entries into different workspaces 586 based on the "restriction" attribute of the IODEF Document (and 587 therefore the restriction property in ROLIE). Security and access 588 controls are most effectively deployed at the workspace level, as 589 such, keeping private and need-to-know IODEF documents in their own 590 workspace helps prevent unintended information leakage. 592 9. References 594 9.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 602 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 603 December 2005, . 605 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 606 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 607 . 609 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 610 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 611 October 2007, . 613 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 614 Object Description Exchange Format", RFC 5070, 615 DOI 10.17487/RFC5070, December 2007, 616 . 618 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 619 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 620 November 2016, . 622 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 623 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 624 May 2017, . 626 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 627 Oriented Lightweight Information Exchange (ROLIE)", 628 RFC 8322, DOI 10.17487/RFC8322, February 2018, 629 . 631 [stix2] Organization for the Advancement of Structured Information 632 Standards (OASIS) Cyber Threat Intelligence (CTI) 633 Technical Committee, "Structured Threat Information 634 Expression 2.0", July 2017, . 637 9.2. Informative References 639 [I-D.dulaunoy-misp-core-format] 640 Dulaunoy, A. and A. Iklody, "MISP core format", draft- 641 dulaunoy-misp-core-format-07 (work in progress), February 642 2019. 644 Appendix A. Examples of Use 646 Use of this extension in a ROLIE repository will not typically change 647 that repository's operation. As such, the general examples provided 648 by the ROLIE core document would serve as examples. Provided below 649 is a sample incident ROLIE entry containing an IODEF document: 651 652 654 f762c77c-057d-45c9-b805-677ab89aaf7c 655 Sample Incident 656 2018-09-04T18:13:51.0Z 657 2019-08-05T18:13:51.0Z 658 A document containing an indicator of comprimise. 659 660 661 663 666 668 670 672 Below is a sample indicator ROLIE entry containing a STIX document: 674 675 677 0c99df51-767f-4940-8a09-c4b607b6fe21 678 Sample Indicator 679 2018-09-04T18:13:51.0Z 680 2019-08-05T18:13:51.0Z 681 A document containing an incident report. 682 683 684 686 689 691 693 695 Authors' Addresses 697 Stephen A. Banghart 698 National Institute of Standards and Technology 699 100 Bureau Drive 700 Gaithersburg, Maryland 701 USA 703 Phone: (301)975-4288 704 Email: sab3@nist.gov 706 John P. Field 707 Pivotal Software, Inc. 708 625 Avenue of the Americas 709 New York, New York 710 USA 712 Phone: (646)792-5770 713 Email: jfield@pivotal.io