idnits 2.17.1 draft-banghart-mile-rolie-csirt-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) == Outdated reference: A later version (-16) exists of draft-ietf-mile-rolie-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group J. Field 3 Internet-Draft Pivotal 4 Intended status: Informational S. Banghart 5 Expires: May 4, 2017 NIST 6 October 31, 2016 8 Definition of ROLIE CSIRT Extension 9 draft-banghart-mile-rolie-csirt-00 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 Contributing to this document 24 The source for this draft is being maintained in GitHub. Suggested 25 changes should be submitted as pull requests at 26 . Instructions are on that page 27 as well. Editorial changes can be managed in GitHub, but any 28 substantial issues need to be discussed on the MILE mailing list. 30 Status of This Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 4, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. New information-types . . . . . . . . . . . . . . . . . . . . 4 64 3.1. The "incident" information type . . . . . . . . . . . . . 4 65 3.2. The "indicator" information type . . . . . . . . . . . . 5 66 4. Usage of CSIRT Information Types in the Atom Publishing 67 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. / (forward slash) Resource URL . . . . . . . . . . . . . 5 69 5. Usage of CSIRT Information Types in the atom:feed element . . 5 70 6. Usage of CSIRT Information Types in an atom:entry . . . . . . 5 71 6.1. Use of the atom:link element . . . . . . . . . . . . . . 6 72 6.1.1. Link relations for the 'incident' 73 information-type . . . . . . . . . . . . . . . . . . 6 74 6.1.2. Link relations for the 'indicator' 75 information-type . . . . . . . . . . . . . . . . . . 6 76 6.1.3. Link relations for both information-types . . . . . . 7 77 6.2. Use of the rolie:format element . . . . . . . . . . . . . 7 78 6.2.1. IODEF Format . . . . . . . . . . . . . . . . . . . . 8 79 6.2.2. STIX Format . . . . . . . . . . . . . . . . . . . . . 8 80 6.3. Additional requirements for use of IODEF . . . . . . . . 8 81 6.3.1. The IODEF Document . . . . . . . . . . . . . . . . . 8 82 6.3.2. Category Element . . . . . . . . . . . . . . . . . . 9 83 6.3.3. Entry Elements . . . . . . . . . . . . . . . . . . . 9 84 6.3.4. User Authorization . . . . . . . . . . . . . . . . . 10 85 6.3.5. Expectation and Impact Classes . . . . . . . . . . . 10 86 6.3.6. Search . . . . . . . . . . . . . . . . . . . . . . . 10 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 7.1. incident information-type . . . . . . . . . . . . . . . . 11 89 7.2. indicator information-type . . . . . . . . . . . . . . . 11 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 92 Appendix A. Non-Normative Examples . . . . . . . . . . . . . . . 12 93 A.1. Use of Link Relations . . . . . . . . . . . . . . . . . . 12 94 A.1.1. Use Case: Incident Sharing . . . . . . . . . . . . . 13 95 A.1.2. Use Case: Collaborative Investigation . . . . . . . . 15 96 A.1.3. Use Case: Cyber Data Repository . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 Threats to computer security are evolving ever more rapidly as time 102 goes on. As software increases in complexity, the number of 103 vulnerabilities in systems and networks can increase exponentially. 104 Threat actors looking to exploit these vulnerabilities are making 105 more frequent and more widely distributed attacks across a large 106 variety of systems. The adoption of liberal information sharing 107 amongst attackers allows a discovered vulnerability to be shared and 108 used to attack a vulnerable system within a narrow window of time. 109 As the skills and knowledge required to identify and combat these 110 attacks become more and more specialized, even a well established and 111 secure system may find itself unable to quickly respond to an 112 incident. Effective identification of and response to a 113 sophisticated attack requires open cooperation and collaboration 114 between defending operators, software vendors, and end-users. To 115 improve the timeliness of responses, automation must be used to 116 acquire, contextualize, and put to use shared computer security 117 information. 119 CSIRTS share two primary forms of information: incidents and 120 indicators. Using these forms of information, analysts are able to 121 perform a wide range of activities both proactive and reactive to 122 ensure the security of their systems. 124 Incident information describes a cyber security incident. Such 125 information may include attack characteristics, information about the 126 attacker, and attack vector data. Sharing this information helps 127 analysts within the sharing community to inoculate their systems 128 against similar attacks, providing proactive protection. 130 Indicator information describes the symptoms or necessary pre- 131 conditions of an attack. Everything from system vulnerabilities to 132 unexpected network traffic can help analysts secure systems and 133 prepare for an attack. Making this information available for sharing 134 aids in the proactive defense of systems both within an operating 135 unit but also for any CSIRTs that are part of a sharing consortium. 137 As a means to bring automation of content discovery and dissemination 138 into the CSIRT domain, this specification provides an extension to 139 the Resource-Oriented Lightweight Information Exchange (ROLIE) core 140 [I-D.ietf-mile-rolie] designed to address CSIRT use cases. The 141 primary purpose of this extension is to define two new information 142 types: incident, and indicator, along with formats and link relations 143 that support these information-types. 145 2. Terminology 147 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 148 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 Definitions for some of the common computer security-related 152 terminology used in this document can be found in Section 2 of 153 [RFC5070]. 155 3. New information-types 157 This document defines the following two information types: 159 3.1. The "incident" information type 161 The "incident" information type represents any information describing 162 or pertaining to a computer security incident. This document uses 163 the definition of incident provided by [RFC4949]. Provided below is 164 a non-exhaustive list of information that may be considered to be an 165 incident information type. 167 o Timing information: start and end times for the incident and/or 168 the response. 170 o Descriptive information: plain text or machine readable data that 171 provides some degree of description of the incident itself. 173 o Response information: the methods and results of a response to the 174 incident. 176 o Meta and contact information: data about the CSIRT that recorded 177 the information, or the operator that enacted the response. 179 o Effect and result information: data that describes the effects of 180 an incident, or what the final results of the incident are. 182 Note again that this list is not exhaustive, any information that in 183 is the abstract realm of an incident should be classified under this 184 information-type. 186 3.2. The "indicator" information type 188 The "indicator" information type represents computer security 189 indicators or any information surrounding them. This document uses 190 the definition of indicator provided by [RFC4949]. Some examples of 191 indicator information is provided below, but note that indicator is 192 defined in an abstract sense, to be understood as a flexible and 193 widely-applicable definition. 195 o Specific vulnerabilities that indicate a vector for attack. 197 o Signs of malicious reconnaissance. 199 o Definitions of patterns of other indicators. 201 o Events that may indicate an attack and information regarding those 202 events. 204 o Meta information about the collecting agent. 206 This list is intended to provide examples of the indicator 207 information-type, not to define it. 209 4. Usage of CSIRT Information Types in the Atom Publishing Protocol 211 These requirements apply when a ROLIE repository contains any 212 Collections with categories with scheme attributes of either CSIRT 213 information type, or if the CSIRT information types appear in the 214 Categories document. 216 4.1. / (forward slash) Resource URL 218 The forward slash resource URL MUST be supported as defined in 219 Section 5.5 [I-D.ietf-mile-rolie]. Note that this is a stricter 220 requirement than the core document. 222 5. Usage of CSIRT Information Types in the atom:feed element 224 This document does not define any additional requirements for Feeds. 226 6. Usage of CSIRT Information Types in an atom:entry 228 This document defines the following requirements for any Entries that 229 are of the CSIRT information type categories. 231 6.1. Use of the atom:link element 233 These sections define requirements for atom:link elements in Entries. 234 Note that the requirements are determined by the information type 235 that appears in either the Entry or in the parent Feed. 237 6.1.1. Link relations for the 'incident' information-type 239 If the category of an Entry is the incident information type, then 240 the following requirements MUST be followed for inclusion of 241 atom:link elements. 243 +------------+----------------------------------------+-------------+ 244 | Name | Description | Conformance | 245 +------------+----------------------------------------+-------------+ 246 | indicators | Provides a link to a collection of | SHOULD | 247 | | zero or more instances of cyber | | 248 | | security indicators that are | | 249 | | associated with the resource. | | 250 | evidence | Provides a link to a collection of | SHOULD | 251 | | zero or more resources that provides | | 252 | | some proof of attribution for an | | 253 | | incident. The evidence may or may not | | 254 | | have any identified chain of custody. | | 255 | attacker | Provides a link to a collection of | SHOULD | 256 | | zero or more resources that provides a | | 257 | | representation of the attacker. | | 258 | vector | Provides a link to a collection of | SHOULD | 259 | | zero or more resources that provides a | | 260 | | representation of the method used by | | 261 | | the attacker. | | 262 +------------+----------------------------------------+-------------+ 264 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 265 Exchange 267 6.1.2. Link relations for the 'indicator' information-type 269 If the category of an Entry is the indicator information type, then 270 the following requirements MUST be followed for inclusion of 271 atom:link elements. 273 +-----------+-----------------------------------------+-------------+ 274 | Name | Description | Conformance | 275 +-----------+-----------------------------------------+-------------+ 276 | incidents | Provides a link to a collection of zero | SHOULD | 277 | | or more instances of incident | | 278 | | representations associated with the | | 279 | | resource. | | 280 +-----------+-----------------------------------------+-------------+ 282 Table 2: Link Relations for Resource-Oriented Lightweight Indicator 283 Exchange 285 6.1.3. Link relations for both information-types 287 Regardless of the category of an Entry, the following requirements 288 MUST be followed for inclusion of atom:link elements. 290 +-----------------------+-----------------------------+-------------+ 291 | Name | Description | Conformance | 292 +-----------------------+-----------------------------+-------------+ 293 | assessments | Provides a link to a | MAY | 294 | | collection of zero or more | | 295 | | resources that represent | | 296 | | the results of executing a | | 297 | | benchmark. | | 298 | reports | Provides a link to a | MAY | 299 | | collection of zero or more | | 300 | | resources that represent | | 301 | | RID reports. | | 302 | traceRequests | Provides a link to a | MAY | 303 | | collection of zero or more | | 304 | | resources that represent | | 305 | | RID traceRequests. | | 306 | investigationRequests | Provides a link to a | MAY | 307 | | collection of zero or more | | 308 | | resources that represent | | 309 | | RID investigationRequests. | | 310 +-----------------------+-----------------------------+-------------+ 312 Table 3: Link Relations for Resource-Oriented Lightweight Indicator 313 Exchange 315 6.2. Use of the rolie:format element 317 This document defines two additional valid values for the 'ns' 318 attribute of the rolie:format element. Both of these formats are 319 valid for either information type. 321 6.2.1. IODEF Format 323 If, and only if, the content of the Entry contains an IODEF document, 324 then the 'ns' attribute of the rolie:format element MUST be 'TODO- 325 IODEF-URN'. 327 Any entry using the IODEF format MUST conform to the requirements in 328 Section 6.3 330 The Incident Object Description Exchange Format (IODEF) is a format 331 for representing computer security information commonly exchanged 332 between Computer Security Incident Response Teams (CSIRTs) or other 333 operational security teams. 335 IODEF conveys indicators, incident reports, response activities, and 336 related meta-data in an XML serialization. This information is 337 formally structured in order to support and encourage automated 338 machine-to-machine security communication, as well as enhanced 339 processing at the endpoint. 341 The full IODEF specification provides further high-level discussion 342 and technical details. 344 6.2.2. STIX Format 346 If, and only if, the content of the Entry contains a STIX document, 347 then the 'ns' attribute of the rolie:format element MUST be 'TODO- 348 STIX-URN'. 350 STIX is a structured language for describing a wide range of security 351 resources. STIX approaches the problem with a focus on flexibility, 352 automation, readability, and extensibility. 354 The use of STIX as the content of an Entry does not impose any 355 additional requirements on ROLIE implementations. 357 6.3. Additional requirements for use of IODEF 359 This section provides the normative requirements for usage of the 360 IODEF format. 362 6.3.1. The IODEF Document 364 An IODEF document that is carried in an Atom Entry SHOULD NOT contain 365 a element. Instead, the related activity SHOULD be 366 available via a link rel=related. 368 An IODEF document that is carried in an Atom Entry SHOULD NOT contain 369 a element. Instead, the related history SHOULD be 370 available via a link rel="history" (todo: or a fully qualified link 371 rek name). The associated href MAY leverage OpenSearch to specify 372 the required query. 374 6.3.2. Category Element 376 A collection or entry containing IODEF incident content MUST contain 377 at least two element. One cateogry elemnt must have the 378 scheme attribute be equal to 379 'urn:ietf:params:rolie:category:iodef:purpose' and the other 380 'urn:ietf:params:rolie:category:iodef:restriction'. This metadata 381 provides valuable metadata for searching and organization. 383 When the scheme attribute of this element is 384 'urn:ietf:params:rolie:category:iodef:purpose', the term attribute 385 MUST be constrained as per section 3.2 of IODEF, e.g. traceback, 386 mitigation, reporting, or other. 388 When the scheme attribute of this element is 389 'urn:ietf:params:rolie:category:iodef:restriction', the term 390 attribute MUST be constrained as per section 3.2 of IODEF, e.g. 391 public, need-to-know, private, default. 393 6.3.3. Entry Elements 395 AUTHORS NOTE: This section is TODO. 397 An entry containing an IODEF payload MUST contain aa 398 element. This element The ID element for an Atom entry SHOULD be 399 established via the concatenation of the value of the name attribute 400 from the IODEF element and the corresponding value of 401 the element. This requirement ensures a simple and 402 direct one-to-one relationship between an IODEF incident ID and a 403 corresponding Feed entry ID and avoids the need for any system to 404 maintain a persistent store of these identity mappings. 406 (todo: Note that this implies a constraint on the IODEF document that 407 is more restrictive than the current IODEF schema. IODEF section 3.3 408 requires only that the name be a STRING type. Here we are stating 409 that name must be an IRI. Possible request to update IODEF to 410 constrain, or to support a new element or attribute). 412 6.3.4. User Authorization 414 When the content model for the Atom element of an Atom 415 Entry contains an , then authorization MUST be 416 adjudicated based upon the Atom element(s), whose values 417 have been mapped as per Section 6.3.2. 419 6.3.5. Expectation and Impact Classes 421 It is frequently the case that an organization will need to triage 422 their investigation and response activities based upon, e.g., the 423 state of the current threat environment, or simply as a result of 424 having limited resources. 426 In order to enable operators to effectively prioritize their response 427 activity, it is RECOMMENDED that feed implementers provide Atom 428 categories that correspond to the IODEF Expectation and Impact 429 classes. The availability of these feed categories will enable 430 clients to more easily retrieve and prioritize cyber security 431 information that has already been identified as having a specific 432 potential impact, or having a specific expectation. 434 Support for these categories may also enable efficiencies for 435 organizations that already have established (or plan to establish) 436 operational processes and workflows that are based on these IODEF 437 classes. 439 6.3.6. Search 441 Implementers SHOULD support search based upon the IODEF AlternativeID 442 class as a search parameter. 444 Implementers SHOULD support search based upon the four timestamp 445 elements of the IODEF Incident class: , , 446 , and . 448 Implementers MAY support additional search capabilities based upon 449 any of the remaining elements of the IODEF Incident class, including 450 the element. 452 Collections that support use of the RID schema as a content model in 453 the Atom member entry element (e.g. in a report resource 454 representation reachable via the "report" link relationship) MUST 455 support search operations that include the RID MessageType as a 456 search parameter, in addition to the aforementioned IODEF schema 457 elements, as contained within the element. 459 7. IANA Considerations 461 7.1. incident information-type 463 IANA has added an entry to the "ROLIE Security Resource Information 464 Type Sub-Registry" registry located at 465 . 467 The entry is as follows: 469 name: incident 471 index: TBD 473 reference: This document, Section 3.1 475 7.2. indicator information-type 477 IANA has added an entry to the "ROLIE Security Resource Information 478 Type Sub-Registry" registry located at 479 . 481 The entry is as follows: 483 name: indicator 485 index: TBD 487 reference: This document, Section 3.2 489 8. Security Considerations 491 This document implies the use of ROLIE in high-security use cases, as 492 such, added care should be taken to fortify and secure ROLIE 493 repositories and clients using this extension. The guidance in the 494 ROLIE core specification is strongly recommended, and implementers 495 should consider adding additional security measures as they see fit. 497 9. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, 501 DOI 10.17487/RFC2119, March 1997, 502 . 504 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 505 Object Description Exchange Format", RFC 5070, 506 DOI 10.17487/RFC5070, December 2007, 507 . 509 [I-D.ietf-mile-rolie] 510 Field, J., Banghart, S., and D. Waltermire, "Resource- 511 Oriented Lightweight Information Exchange", draft-ietf- 512 mile-rolie-03 (work in progress), July 2016. 514 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 515 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 516 . 518 Appendix A. Non-Normative Examples 520 TODO 522 A.1. Use of Link Relations 524 A key benefit of using the RESTful architectural style is the ability 525 to enable the client to navigate to related resources through the use 526 of hypermedia links. In the Atom Syndication Format, the type of the 527 related resource identified in a element is indicated via the 528 "rel" attribute, where the value of this attribute identifies the 529 kind of related resource available at the corresponding "href" 530 attribute. Thus, in lieu of a well-known URI template the URI itself 531 is effectively opaque to the client, and therefore the client must 532 understand the semantic meaning of the "rel" attribute in order to 533 successfully navigate. Broad interoperability may be based upon a 534 sharing consortium defining a well-known set of Atom Link Relation 535 types. These Link Relation types may either be registered with IANA, 536 or held in a private registry. 538 Individual CSIRTs may always define their own link relation types in 539 order to support specific use cases, however support for a core set 540 of well-known link relation types is encouraged as this will maximize 541 interoperability. 543 In addition, it may be beneficial to define use case profiles that 544 correspond to specific groupings of supported link relationship 545 types. In this way, a CSIRT may unambiguously specify the classes of 546 use cases for which a client can expect to find support. 548 The following sections provide non-normative examples of link 549 relation usage. Three distinct cyber security information sharing 550 use case scenarios are described. In each use case, the unique 551 benefits of adopting a resource-oriented approach to information 552 sharing are illustrated. It is important to note that these use 553 cases are intended to be a small representative set and is by no 554 means meant to be an exhaustive list. The intent is to illustrate 555 how the use of link relationship types will enable this resource- 556 oriented approach to cyber security information sharing to 557 successfully support the complete range of existing use cases, and 558 also to motivate an initial list of well-defined link relationship 559 types. 561 A.1.1. Use Case: Incident Sharing 563 This section provides a non-normative example of an incident sharing 564 use case. 566 In this use case, a member CSIRT shares incident information with 567 another member CSIRT in the same consortium. The client CSIRT 568 retrieves a feed of incidents, and is able to identify one particular 569 entry of interest. The client then does an HTTP GET on that entry, 570 and the representation of that resource contains link relationships 571 for both the associated "indicators" and the incident "history", and 572 so on. The client CSIRT recognizes that some of the indicator and 573 history may be relevant within her local environment, and can respond 574 proactively. 576 Example HTTP GET response for an incident entry: 578 579 580 http://www.example.org/csirt/private/incidents/123456 581 Sample Incident 582 584 586 2012-08-04T18:13:51.0Z 587 2012-08-05T18:13:51.0Z 589 592 594 596 598 601 603 605 606 608 610 611 123456 613 614 615 616 617 619 As can be seen in the example response, the Atom elements 620 enable the client to navigate to the related indicator resources, 621 and/or the history entries associated with this incident. 623 A.1.2. Use Case: Collaborative Investigation 625 This section provides a non-normative example of a collaborative 626 investigation use case. 628 In this use case, two member CSIRTs that belong to a closed sharing 629 consortium are collaborating on an incident investigation. The 630 initiating CSIRT performs an HTTP GET to retrieve the service 631 document of the peer CSIRT, and determines the collection name to be 632 used for creating a new investigation request. The initiating CSIRT 633 then POSTs a new incident entry to the appropriate collection URL. 634 The target CSIRT acknowledges the request by responding with an HTTP 635 status code 201 Created. 637 Example HTTP GET response for the service document: 639 HTTP/1.1 200 OK 640 Date: Fri, 24 Aug 2012 17:09:11 GMT 641 Content-Length: 934 642 Content-Type: application/atomsvc+xml;charset="utf-8" 644 645 647 649 RID Use Case Requests 650 652 Investigation Requests 653 application/atom+xml; type=entry 654 655 656 Trace Requests 657 application/atom+xml; type=entry 658 659 660 661 663 As can be seen in the example response, the Atom 664 elements enable the client to determine the appropriate collection 665 URL to request an investigation or a trace. 667 The client CSIRT then POSTs a new entry to the appropriate feed 668 collection. Note that the element of the new entry may 669 contain a RID message of type "InvestigationRequest" if desired, 670 however this would NOT be required. The entry content itself need 671 only be an IODEF document, with the choice of the target collection 672 resource URL indicating the callers intent. A CSIRT would be free to 673 use any URI template to accept investigationRequests. 675 POST /csirt/RID/InvestigationRequests HTTP/1.1 676 Host: www.example.org 677 Content-Type: application/atom+xml;type=entry 678 Content-Length: 852 680 681 682 New Investigation Request 683 http://www.example2.org/csirt/private/incidents/123456 684 685 686 2012-08-12T11:08:22Z 687 Name of peer CSIRT 688 689 691 692 123 694 695 696 697 698 700 The receiving CSIRT acknowledges the request with HTTP return code 701 201 Created. 703 HTTP/1.1 201 Created 704 Date: Fri, 24 Aug 2012 19:17:11 GMT 705 Content-Length: 906 706 Content-Type: application/atom+xml;type=entry 707 Location: http://www.example.org/csirt/RID/InvestigationRequests/823 708 ETag: "8a9h9he4qphqh" 710 711 712 New Investigation Request 713 http://www.example.org/csirt/RID/InvestigationRequests/823 714 715 716 2012-08-12T11:08:30Z 717 2012-08-12T11:08:30Z 718 Name of peer CSIRT 719 720 722 723 123 725 726 727 728 729 731 Consistent with HTTP/1.1 RFC, the location header indicates the URL 732 of the newly created InvestigationRequest. If for some reason the 733 request were not authorized, the client would receive an HTTP status 734 code 403 Unauthorized. In this case the HTTP response body may 735 contain additional details, if an as appropriate. 737 A.1.3. Use Case: Cyber Data Repository 739 This section provides a non-normative example of a cyber security 740 data repository use case. 742 In this use case a client accesses a persistent repository of cyber 743 security data via a RESTful usage model. Retrieving a feed 744 collection is analogous to an SQL SELECT statement producing a result 745 set. Retrieving an individual Atom Entry is analogous to a SQL 746 SELECT statement based upon a primary key producing a unique record. 747 The cyber security data contained in the repository may include 748 different data types, including indicators, incidents, benchmarks, or 749 any other related resources. In this use case, the repository is 750 queried via HTTP GET, and the results that are returned to the client 751 may optionally contain URL references to other cyber security 752 resources that are known to be related. These related resources may 753 also be persisted locally, or they may exist at another (remote) 754 cyber data respository. 756 Example HTTP GET request to a persistent repository for any resources 757 representing Distributed Denial of Service (DDOS) attacks: 759 GET /csirt/repository/ddos 760 Host: www.example.org 761 Accept: application/atom+xml 763 The corresponding HTTP response would be an XML document containing 764 the DDOS feed. 766 Example HTTP GET response for a DDOS feed: 768 HTTP/1.1 200 OK 769 Date: Fri, 24 Aug 2012 17:20:11 GMT 770 Content-Length: nnnn 771 Content-Type: application/atom+xml;type=feed;charset="utf-8" 773 774 782 783 emc-csirt-iodef-feed-service 784 http://www.example.org/csirt/repository/ddos 785 786 Atom formatted representation of a feed of known ddos resources. 787 788 2012-05-04T18:13:51.0Z 789 790 csirt@example.org 791 EMC CSIRT 792 794 795 798 799 http://www.example.org/csirt/repository/ddos/123456 800 Sample DDOS Incident 801 803 805 808 810 811 2012-08-04T18:13:51.0Z 812 2012-08-05T18:13:51.0Z 813 815 816 818 820 A short description of this DDOS attack, extracted 821 from the IODEF Incident class, element. 822 824 825 826 828 830 This feed document has two atom entries, one of which has been 831 elided. The completed entry illustrates an Atom element that 832 provides a summary of essential details about one particular DDOS 833 incident. Based upon this summary information and the provided 834 category information, a client may choose to do an HTTP GET operation 835 to retrieve the full details of the DDOS incident. This example 836 shows how a persistent repository may provide links to additional 837 resources, both local and remote. 839 Note that the provider of a persistent repostory is not obligated to 840 follow any particular URL template scheme. The repository available 841 at the hypothetical provider "www.example.com" uses a different URL 842 pattern than the hypothetical repository available at "www.cyber- 843 agency.gov". When a client de-references a link to resource that is 844 located in a remote repository the client may be challenged for 845 authentication credentials acceptable to that provider. If the two 846 repository providers choose to support a federated identity scheme or 847 some other form of single-sign-on technology, then the user 848 experience can be improved for interactive clients (e.g., a human 849 user at a browser). However, this is not required and is an 850 implementation choice that is out of scope for this specification. 852 Authors' Addresses 854 John P. Field 855 Pivotal Software, Inc. 856 625 Avenue of the Americas 857 New York, New York 858 USA 860 Phone: (646)792-5770 861 Email: jfield@pivotal.io 863 Stephen A. Banghart 864 National Institute of Standards and Technology 865 100 Bureau Drive 866 Gaithersburg, Maryland 867 USA 869 Phone: (301)975-4288 870 Email: sab3@nist.gov