idnits 2.17.1 draft-ietf-mile-rolie-csirt-05.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 (September 5, 2019) is 1692 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: 'RFC4287' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC5023' is defined on line 601, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-dulaunoy-misp-core-format-07 ** Downref: Normative reference to an Informational draft: draft-dulaunoy-misp-core-format (ref. 'I-D.dulaunoy-misp-core-format') ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) Summary: 4 errors (**), 0 flaws (~~), 5 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: March 8, 2020 Pivotal 6 September 5, 2019 8 Definition of ROLIE CSIRT Extension 9 draft-ietf-mile-rolie-csirt-05 11 Abstract 13 This document extends the Resource-Oriented Lightweight Information 14 Exchange (ROLIE) core to add the information type categories and 15 related requirements needed to support Computer Security Incident 16 Response Team (CSIRT) use cases. The indicator and incident 17 information types are defined as ROLIE extensions. Additional 18 supporting requirements are also defined that describe the use of 19 specific formats and link relations pertaining to the new information 20 types. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 8, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Information-type Extensions . . . . . . . . . . . . . . . . . 4 59 3.1. The "incident" information type . . . . . . . . . . . . . 4 60 3.2. The "indicator" information type . . . . . . . . . . . . 4 61 4. Data format requirements . . . . . . . . . . . . . . . . . . 5 62 4.1. Incident Object Description Exchange Format . . . . . . . 5 63 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 64 4.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Structured Threat Information eXpression (STIX) Format . 6 66 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6 67 4.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Malware Information Sharing Platform (MISP) Format . . . 7 69 4.3.1. Creating MISP Event Entries . . . . . . . . . . . . . 7 70 4.3.2. MISP Feeds and Manifests . . . . . . . . . . . . . . 8 71 5. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Link relations for the 'incident' 73 information-type . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Link relations for the 'indicator' 75 information-type . . . . . . . . . . . . . . . . . . . . 9 76 5.3. Link relations for both information-types . . . . . . . . 10 77 6. atom:category Extensions . . . . . . . . . . . . . . . . . . 10 78 6.1. Newly registered category values . . . . . . . . . . . . 10 79 6.2. Expectation and Impact Classes . . . . . . . . . . . . . 11 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. information-type registrations . . . . . . . . . . . . . 11 82 7.1.1. incident information-type . . . . . . . . . . . . . . 11 83 7.1.2. indicator information-type . . . . . . . . . . . . . 11 84 7.2. atom:category scheme registrations . . . . . . . . . . . 12 85 7.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 12 86 7.2.2. category:csirt:iodef:restriction . . . . . . . . . . 12 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 89 Appendix A. Examples of Use . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 Threats to computer security are evolving ever more rapidly as time 95 goes on. As software increases in complexity, the number of 96 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 CSIRTs share two primary forms of information: incidents and 114 indicators. Using these forms of information, analysts are able to 115 perform a wide range of activities both proactive and reactive to 116 ensure 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 [RFC2119]. 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 3. Information-type Extensions 151 3.1. The "incident" information type 153 When an "atom:category" element has a "scheme" attribute equal to 154 "urn:ietf:params:rolie:category:information-type", the "term" 155 attribute defines the information type of the associated resource. A 156 new valid "term" value for this "scheme": "incident", is described in 157 this section, and registered in Section 7.1.1. 159 The "incident" information type represents any information describing 160 or pertaining to a computer security incident. This document uses 161 the definition of incident provided by [RFC4949]. Provided below is 162 a non-exhaustive list of information that may be considered to be an 163 incident information type. 165 o Timing information: start and end times for the incident and/or 166 the response. 168 o Descriptive information: plain text or machine readable data that 169 provides some degree of description of the incident itself. 171 o Response information: the methods and results of a response to the 172 incident. 174 o Meta and contact information: data about the CSIRT that recorded 175 the information, or the operator that enacted the response. 177 o Effect and result information: data that describes the effects of 178 an incident, or what the final results of the incident are. 180 Note again that this list is not exhaustive, any information that in 181 is the abstract realm of an incident should be classified under this 182 information-type. 184 3.2. The "indicator" information type 186 When an "atom:category" element has a "scheme" attribute equal to 187 "urn:ietf:params:rolie:category:information-type", the "term" 188 attribute defines the information type of the associated resource. A 189 new valid "term" value for this "scheme": "indicator", is described 190 in this section, and registered in Section 7.1.2. 192 The "indicator" information type represents computer security 193 indicators or any information surrounding them. This document uses 194 the definition of indicator provided by [RFC4949]. Some examples of 195 indicator information is provided below, but note that indicator is 196 defined in an abstract sense, to be understood as a flexible and 197 widely-applicable definition. 199 o Specific vulnerabilities that indicate a vector for attack. 201 o Signs of malicious reconnaissance. 203 o Definitions of patterns of other indicators. 205 o Events that may indicate an attack and information regarding those 206 events. 208 o Meta information about the collecting agent. 210 This list is intended to provide examples of the indicator 211 information-type, not to define it. 213 4. Data format requirements 215 This section defines usage guidance and additional requirements 216 related to data formats above and beyond those specified in 217 [RFC8322]. The following formats are expected to be commonly used to 218 express software descriptor information. For this reason, this 219 document specifies additional requirements to ensure 220 interoperability. 222 4.1. Incident Object Description Exchange Format 224 4.1.1. Description 226 The Incident Object Description Exchange Format (IODEF) is a format 227 for representing computer security information commonly exchanged 228 between Computer Security Incident Response Teams (CSIRTs) or other 229 operational security teams. 231 IODEF conveys indicators, incident reports, response activities, and 232 related meta-data in an XML serialization. This information is 233 formally structured in order to support and encourage automated 234 machine-to-machine security communication, as well as enhanced 235 processing at the endpoint. 237 The full IODEF specification [RFC7970] provides further high-level 238 discussion and technical details. 240 4.1.2. Requirements 242 For an Entry to be considered as a "IODEF Entry", it MUST fulfill the 243 following conditions: 245 o The information-type of the Entry is "indicator" or "incident". 246 For a typical Entry, this is derived from the information type of 247 the Feed it is contained in. For a standalone Entry, this is 248 provided by an "atom:category" element. 250 o The document linked to by the "href" attribute of the 251 "atom:content" element is an IODEF document as per [RFC7970] 253 A "IODEF Entry" MUST conform to the following requirements: 255 o The value of the "type" attribute of the "atom:content" element 256 MUST be "application/xml". 258 o There MUST be at least one "rolie:property" with the "name" 259 attribute equal to "urn:ietf:params:rolie:property:content-id" and 260 the "value" attribute exactly equal to the "" or the 261 "" element in the attached IODEF document. This 262 allows for ROLIE consumers to more easily search for IODEF 263 documents without needing to download the document itself. 265 4.2. Structured Threat Information eXpression (STIX) Format 267 4.2.1. Description 269 STIX is a structured language for describing a wide range of security 270 resources. STIX approaches the problem with a focus on flexibility, 271 automation, readability, and extensibility. 273 The full STIX specification [stix2] provides further high-level 274 discussion and technical details. 276 4.2.2. Requirements 278 For an Entry to be considered as a "STIX Entry", it MUST fulfill the 279 following conditions: 281 o The information-type of the Entry is "indicator" or "incident". 282 For a typical Entry, this is derived from the information type of 283 the Feed it is contained in. For a standalone Entry, this is 284 provided by an "atom:category" element. 286 o The document linked to by the "href" attribute of the 287 "atom:content" element is a STIX object as per [stix2] 289 A "STIX Entry" MUST conform to the following requirements: 291 o The value of the "type" attribute of the "atom:content" element 292 MUST be "application/xml" or "application/json". 294 o There MUST be at least one "rolie:property" with the "name" 295 attribute equal to "urn:ietf:params:rolie:property:content-id" and 296 the "value" attribute exactly equal to the "" element in the 297 attached STIX object . This allows for ROLIE consumers to more 298 easily search for STIX objects without needing to download the 299 document itself. 301 4.3. Malware Information Sharing Platform (MISP) Format 303 MISP involves documentation, utilities, and formats designed to 304 facilitate the day-to=day duties of security operators. MISP 305 includes it's own data format that is used to share between MISP 306 features. While MISP has Feed features that can share and distribute 307 events, it has support for linking to other sharing methods like 308 ROLIE. 310 MISP is defined by a family of internet drafts and are actively being 311 worked on. With that in mind, this extension will provide non- 312 normative guidance on using MISP format data in ROLIE. In the 313 future, when the MISP format is formally published, this document 314 will be updated to normative requirements around MISP content. 316 4.3.1. Creating MISP Event Entries 318 MISP content should be syndicated in ROLIE using the following 319 guidance: 321 o The information-type of the Entry is "indicator". For a typical 322 Entry, this is derived from the information type of the Feed it is 323 contained in. For a standalone Entry, this is provided by an 324 "atom:category" element. 326 o The document linked to by the "href" attribute of the 327 "atom:content" element is a MISP Event object as per 328 [I-D.dulaunoy-misp-core-format] 330 o The value of the "type" attribute of the "atom:content" element 331 should be "application/xml". 333 o There should be at least one "rolie:property" with the "name" 334 attribute equal to "urn:ietf:params:rolie:property:content-id" and 335 the "value" attribute exactly equal to the "" element in the 336 attached MISP Event . This allows for ROLIE consumers to more 337 easily search for MISP Events without needing to download the 338 document itself. 340 o It is also recommended to expose information in the ROLIE Entry 341 that is required and recommended to expose in the MISP Manifest 342 format. This ensures better compatibility between a ROLIE Feed 343 and a MISP Manifest 345 * The following fields are required by the MISP draft: info, 346 Orgc, timestamp, date 348 * The following fields are recommended by the MISP draft: 349 analysis, threat_level_id 351 4.3.2. MISP Feeds and Manifests 353 MISP Feeds are hosted lists of MISP events, each event represented by 354 its UUID. Users request Events on a one-by-one basis and are served 355 the full Event on each request. 357 MISP Manifest files list MISP events by their UUIDs as well, but 358 provide a variety of metadata for each Event inline. After examining 359 the minimized and stripped Event in the manifest, a user could search 360 for the Event UUID of interest in a locally located folder of Event 361 files where the file name is the UUID of the Event. 363 ROLIE hosting MISP data would operate as a combination of these 364 approaches. Each ROLIE Feed would contain a list of Event Entries, 365 each with metadata and identifying information about a given Event. 366 Should the user be interested in the Event, the Event Entry provides 367 a direct link to download the full Event. In short, a ROLIE MISP 368 Feed is minimally mappable to a MISP Manifest file where a resolvable 369 link to the MISP Event was injected into each Event described in the 370 Manifest. 372 With that in mind, a MISP Feed as well as a MISP Manifest with 373 attached local file list could be fully converted and hosted as a 374 ROLIE repository. As a lower overhead alternative, a ROLIE server 375 could simply provide a view into MISP data. 377 5. atom:link Extensions 379 This section defines additional link relationships that 380 implementations MUST support. These relationships are not registered 381 in the Link Relation IANA table as their use case is too narrow. 382 Each relationship is named and described. 384 These relations come in related pairs. The first of each pair is 385 expected to be more common, as they can be determined at the time 386 that the Entry is created. The second of each pair will often need 387 to be added retroactively to an Entry. 389 5.1. Link relations for the 'incident' information-type 391 If a ROLIE server supports either the incident information-types, 392 then these link relations MUST be support 394 +------------+------------------------------------------------------+ 395 | Name | Description | 396 +------------+------------------------------------------------------+ 397 | indicators | Provides a link to a collection of zero or more | 398 | | instances of cyber security indicators that are | 399 | | associated with the resource. | 400 | evidence | Provides a link to a collection of zero or more | 401 | | resources that provides some proof of attribution | 402 | | for an incident. The evidence may or may not have | 403 | | any identified chain of custody. | 404 | attacker | Provides a link to a collection of zero or more | 405 | | resources that provides a representation of the | 406 | | attacker. | 407 | vector | Provides a link to a collection of zero or more | 408 | | resources that provides a representation of the | 409 | | method used by the attacker. | 410 +------------+------------------------------------------------------+ 412 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 413 Exchange 415 5.2. Link relations for the 'indicator' information-type 417 If a ROLIE server supports the indicator information-types, then 418 these link relations MUST be supported. 420 +-----------+-------------------------------------------------------+ 421 | Name | Description | 422 +-----------+-------------------------------------------------------+ 423 | incidents | Provides a link to a collection of zero or more | 424 | | instances of incident representations associated with | 425 | | the resource. | 426 +-----------+-------------------------------------------------------+ 428 Table 2: Link Relations for Resource-Oriented Lightweight Indicator 429 Exchange 431 5.3. Link relations for both information-types 433 If a ROLIE server supports either the incident or the indicator 434 information-types, then these link relations MUST be supported. 436 +-----------------------+-------------------------------------------+ 437 | Name | Description | 438 +-----------------------+-------------------------------------------+ 439 | assessments | Provides a link to a collection of zero | 440 | | or more resources that represent the | 441 | | results of executing a benchmark. | 442 | reports | Provides a link to a collection of zero | 443 | | or more resources that represent RID | 444 | | reports. | 445 | traceRequests | Provides a link to a collection of zero | 446 | | or more resources that represent RID | 447 | | traceRequests. | 448 | investigationRequests | Provides a link to a collection of zero | 449 | | or more resources that represent RID | 450 | | investigationRequests. | 451 +-----------------------+-------------------------------------------+ 453 Table 3: Link Relations for Resource-Oriented Lightweight Indicator 454 Exchange 456 6. atom:category Extensions 458 6.1. Newly registered category values 460 This document registers two additional registered atom:category 461 names: 'urn:ietf:params:rolie:category:csirt:iodef:purpose' and 462 'urn:ietf:params:rolie:category:csirt:iodef:restriction'. These 463 categories expose important information from inside the attached 464 IODEF document. The Purpose and Restriction elements are often used 465 to sort or cateogrize IODEF documents, and in some use cases, 466 determine the security and access permissions of the document. 468 When the name attribute of the category is 469 'urn:ietf:params:rolie:category:csirt:iodef:purpose', the value 470 attribute SHOULD be constrained as per section 3.2 of IODEF 471 [RFC7970], e.g. traceback, mitigation, reporting, or other. 473 When the name attribute of the category is 474 'urn:ietf:params:rolie:category:csirt:iodef:restriction', the value 475 attribute SHOULD be constrained as per section 3.2 of IODEF 476 [RFC7970], e.g. public, need-to-know, private, default. 478 6.2. Expectation and Impact Classes 480 It is frequently the case that an organization will need to triage 481 their investigation and response activities based upon, e.g., the 482 state of the current threat environment, or simply as a result of 483 having limited resources. 485 In order to enable operators to effectively prioritize their response 486 activity, it is RECOMMENDED that feed implementers provide Atom 487 categories that correspond to the IODEF Expectation and Impact 488 classes. The availability of these feed categories will enable 489 clients to more easily retrieve and prioritize cyber security 490 information that has already been identified as having a specific 491 potential impact, or having a specific expectation. 493 Support for these categories may also enable efficiencies for 494 organizations that already have established (or plan to establish) 495 operational processes and workflows that are based on these IODEF 496 classes. 498 7. IANA Considerations 500 7.1. information-type registrations 502 IANA has added the following entries to the "ROLIE Security Resource 503 Information Type Sub-Registry" registry located at 504 . 506 7.1.1. incident information-type 508 The entry is as follows: 510 name: incident 512 index: TBD 514 reference: This document, Section 3.1 516 7.1.2. indicator information-type 518 The entry is as follows: 520 name: indicator 522 index: TBD 524 reference: This document, Section 3.2 526 7.2. atom:category scheme registrations 528 IANA has added the following entries to the "ROLIE URN Parameters" 529 registry located in . 531 7.2.1. category:csirt:iodef:purpose 533 The entry is as follows: 535 name: category:csirt:iodef:purpose 537 Extension IRI: urn:ietf:params:rolie:category:csirt:iodef:purpose 539 Reference: This document, Section 6.1 541 Subregistry: None 543 7.2.2. category:csirt:iodef:restriction 545 The entry is as follows: 547 name: category:csirt:iodef:restriction 549 Extension IRI: 550 urn:ietf:params:rolie:category:csirt:iodef:restriction 552 Reference: This document, Section 6.1 554 Subregistry: None 556 8. Security Considerations 558 This document implies the use of ROLIE in high-security use cases, as 559 such, added care should be taken to fortify and secure ROLIE 560 repositories and clients using this extension. The guidance in the 561 ROLIE core specification is strongly recommended, and implementers 562 should consider adding additional security measures as they see fit. 564 When providing a private workspace for closed sharing, it is 565 recommended that the ROLIE repository checks user authorization when 566 the user sends a GET request to the service document. If the user is 567 not authorized to send any requests to a given workspace or 568 collection, that workspace or collection should be truncated from the 569 service document in the response. In this way the existence of 570 unauthorized content remains unknown to potential attackers, 571 hopefully reducing attack surface. 573 When sharing IODEF 2 documents using a ROLIE server, care should be 574 taken to seperate IODEF Entries into different workspaces based on 575 the "restriction" attribute of the IODEF Document (and therefore the 576 restriction property in ROLIE). Security and access controls are 577 most effectively deployed at the workspace level, as such, keeping 578 private and need-to-know IODEF documents in their own workspace helps 579 prevent unintended information leakage. 581 9. Normative References 583 [I-D.dulaunoy-misp-core-format] 584 Dulaunoy, A. and A. Iklody, "MISP core format", draft- 585 dulaunoy-misp-core-format-07 (work in progress), February 586 2019. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 594 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 595 December 2005, . 597 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 598 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 599 . 601 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 602 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 603 October 2007, . 605 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 606 Object Description Exchange Format", RFC 5070, 607 DOI 10.17487/RFC5070, December 2007, 608 . 610 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 611 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 612 November 2016, . 614 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 615 Oriented Lightweight Information Exchange (ROLIE)", 616 RFC 8322, DOI 10.17487/RFC8322, February 2018, 617 . 619 [stix2] Organization for the Advancement of Structured Information 620 Standards (OASIS) Cyber Threat Intelligence (CTI) 621 Technical Committee, "Structured Threat Information 622 Expression 2.0", July 2017, . 625 Appendix A. Examples of Use 627 Use of this extension in a ROLIE repository will not typically change 628 that repository's operation. As such, the general examples provided 629 by the ROLIE core document would serve as examples. Provided below 630 is a sample incident ROLIE entry containing an IODEF document: 632 633 635 f762c77c-057d-45c9-b805-677ab89aaf7c 636 Sample Incident 637 2018-09-04T18:13:51.0Z 638 2019-08-05T18:13:51.0Z 639 A document containing an indicator of comprimise. 640 641 642 644 647 649 651 653 Below is a sample indicator ROLIE entry containing a STIX document: 655 656 658 0c99df51-767f-4940-8a09-c4b607b6fe21 659 Sample Indicator 660 2018-09-04T18:13:51.0Z 661 2019-08-05T18:13:51.0Z 662 A document containing an incident report. 663 664 665 667 670 672 674 676 Authors' Addresses 678 Stephen A. Banghart 679 National Institute of Standards and Technology 680 100 Bureau Drive 681 Gaithersburg, Maryland 682 USA 684 Phone: (301)975-4288 685 Email: sab3@nist.gov 687 John P. Field 688 Pivotal Software, Inc. 689 625 Avenue of the Americas 690 New York, New York 691 USA 693 Phone: (646)792-5770 694 Email: jfield@pivotal.io