idnits 2.17.1 draft-ietf-mile-grc-exchange-01.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 2 characters 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 date (November 6, 2012) is 4188 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6546' is mentioned on line 2745, but not defined == Missing Reference: '0-9' is mentioned on line 374, but not defined == Missing Reference: '0-4' is mentioned on line 374, but not defined == Missing Reference: '0-5' is mentioned on line 374, but not defined ** Obsolete normative reference: RFC 4051 (Obsoleted by RFC 6931) ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group K. Moriarty 3 Internet-Draft S. Tabet 4 Intended status: Standards Track EMC 5 Expires: May 10, 2013 D. Waltermire 6 NIST 7 November 6, 2012 9 GRC Report Exchange 10 draft-ietf-mile-grc-exchange-01.txt 12 Abstract 14 Governance, risk, and compliance (GRC) programs provide oversight 15 (governance) of risks and compliance initiatives within an 16 organization. GRC reports are increasingly provided in an XML 17 format. This specification defines a common method to securely 18 transport GRC and other XML reports. The defined messaging 19 capability provides policy options and markings in an XML schema, 20 options for confidentiality at the document/report level, and 21 security for the end-to-end communication. XML reports may be shared 22 between service providers and clients, enterprises, or within 23 enterprises. Reports may also be exchanged for official purposes 24 such as business report filings, compliance report filings, and the 25 handling of legal incidents (eWarrant, eDiscovery, etc.) This work 26 is a generalized format derived from the secure exchange of incident 27 information defined by RFC6545, Real-time Inter-network Defense 28 (RID). 30 Status of this Memo 32 This Internet-Draft is submitted 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 10, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Normative and Informative . . . . . . . . . . . . . . . . 5 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Report Types . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Communication between Entities . . . . . . . . . . . . . . . . 6 68 3.1. Inter-network Provider GRC Messaging . . . . . . . . . . . 6 69 3.2. GRC Report Exchange Communication Topology . . . . . . . . 7 70 3.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 7 71 3.4. GRC Report Exchange Data Types . . . . . . . . . . . . . . 7 72 3.4.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.4.2. Language . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4.3. Multilingual Strings . . . . . . . . . . . . . . . . . 8 75 3.4.4. Uniform Resource Locator strings . . . . . . . . . . . 8 76 3.4.5. Date-Time Strings . . . . . . . . . . . . . . . . . . 8 77 3.4.6. Timezone String . . . . . . . . . . . . . . . . . . . 9 78 3.4.7. Postal Address . . . . . . . . . . . . . . . . . . . . 9 79 3.4.8. Telephone and Fax Numbers . . . . . . . . . . . . . . 9 80 3.4.9. Email String . . . . . . . . . . . . . . . . . . . . . 10 81 3.5. GRC Report Exchange Message Types . . . . . . . . . . . . 10 82 4. GRC-Exchange Schema . . . . . . . . . . . . . . . . . . . . . 11 83 4.1. GRCPolicy Class . . . . . . . . . . . . . . . . . . . . . 13 84 4.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 17 85 4.3. GRCDocument . . . . . . . . . . . . . . . . . . . . . . . 19 86 4.4. Reference Class . . . . . . . . . . . . . . . . . . . . . 24 87 4.5. ReportID Class . . . . . . . . . . . . . . . . . . . . . . 24 88 4.6. Contact Class . . . . . . . . . . . . . . . . . . . . . . 26 89 4.6.1. RegistryHandle Class . . . . . . . . . . . . . . . . . 29 90 4.6.2. PostalAddress Class . . . . . . . . . . . . . . . . . 30 91 4.6.3. Email Class . . . . . . . . . . . . . . . . . . . . . 31 92 4.6.4. Telephone and Fax Classes . . . . . . . . . . . . . . 31 93 4.7. ExtensionType Class . . . . . . . . . . . . . . . . . . . 32 94 4.8. Node Class . . . . . . . . . . . . . . . . . . . . . . . . 35 95 4.9. Address Class . . . . . . . . . . . . . . . . . . . . . . 36 96 4.10. GRC-Exchange Name Spaces . . . . . . . . . . . . . . . . . 37 97 5. Extending the Enumerated Values of Attributes . . . . . . . . 37 98 6. GRC Report Exchange Messages . . . . . . . . . . . . . . . . . 38 99 6.1. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 38 100 6.2. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 39 101 6.3. Request . . . . . . . . . . . . . . . . . . . . . . . . . 40 102 6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 41 103 6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 42 104 7. GRC-Exchange Communication Flows . . . . . . . . . . . . . . . 43 105 7.1. Report Communication Flow . . . . . . . . . . . . . . . . 43 106 7.1.1. GRC-Exchange Report Example . . . . . . . . . . . . . 44 107 7.2. Request Communication Flow . . . . . . . . . . . . . . . . 44 108 7.2.1. Request Example . . . . . . . . . . . . . . . . . . . 45 109 7.2.2. Acknowledgement Message Example . . . . . . . . . . . 45 110 7.3. Query Communication Flow . . . . . . . . . . . . . . . . . 45 111 7.3.1. Query Example . . . . . . . . . . . . . . . . . . . . 46 112 7.3.2. Acknowledgement Message Example . . . . . . . . . . . 46 113 7.3.3. Result Message Example . . . . . . . . . . . . . . . . 47 114 8. Internationalization Issues . . . . . . . . . . . . . . . . . 47 115 9. GRC-Exchange Schema Definition . . . . . . . . . . . . . . . . 49 116 10. Requirements for GRC XML Schemas for GRC-Exchange . . . . . . 49 117 11. Security Requirements . . . . . . . . . . . . . . . . . . . . 50 118 11.1. XML Digital Signatures and Encryption . . . . . . . . . . 50 119 11.2. Public Key Infrastructure . . . . . . . . . . . . . . . . 53 120 11.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 54 121 11.2.2. Multi-Hop Request Authentication . . . . . . . . . . . 55 122 11.3. Consortiums and Public Key Infrastructures . . . . . . . . 56 123 11.4. Privacy Concerns and System Use Guidelines . . . . . . . . 57 124 11.5. Sharing Profiles and Policies . . . . . . . . . . . . . . 60 125 12. Security Considerations . . . . . . . . . . . . . . . . . . . 61 126 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 127 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 128 15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 129 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 130 16.1. Normative References . . . . . . . . . . . . . . . . . . . 64 131 16.2. Informative References . . . . . . . . . . . . . . . . . . 66 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 134 1. Introduction 136 Governance, risk, and compliance (GRC) programs provide oversight 137 (governance) of risks and compliance initiatives within an 138 organization. The areas typically covered by GRC include: 140 o Finance and Business Operations, 142 o Information Technology, 144 o Security, and 146 o Legal and Compliance 148 GRC Report Exchange provides a secure method to communicate relevant 149 information and reports, through the automated exchange of extensible 150 markup language (XML) documents. GRC Report Exchange considers 151 security, policy, and privacy issues as related to the exchange of 152 potentially sensitive information. Additionally, it enables 153 organizations accepting GRC report filings, such as service providers 154 or enterprises, the options to make appropriate decisions according 155 to their policy requirements. GRC Report Exchange includes 156 provisions for confidentiality, integrity, and authentication. 158 The data in GRC reports exchanged are represented in an XML 159 [W3C.REC-xml-20081126] document using the appropriate XML schema for 160 the included report. The XML document or formatted report is then 161 enveloped by the GRC Report Exchange schema to set policy options and 162 provide a common secure exchange method for such documents. By 163 following this model, a single method for all GRC reports can be 164 used, simplifying the integration of GRC reports across platforms. 166 Security and privacy considerations are of high concern since 167 potentially sensitive information may be passed through GRC Report 168 Exchange messages. GRC Report Exchange takes advantage of XML 169 security and privacy policy information set in the GRC Report 170 Exchange schema and provides standard settings for fine grain 171 controls within GRC XML schemas. The GRC Report Exchange schema acts 172 as an XML envelope to support the communication of GRC report 173 documents. GRC Report Exchange messages are encapsulated for 174 transport, which is defined in a separate document [RFC6546]. The 175 authentication, integrity, and authorization features GRC Report 176 Exchange and RID transport offer are used to achieve a necessary 177 level of security. 179 GRC report exchange is not strictly a technical problem. There are 180 numerous procedural, trust, and legal considerations that might 181 prevent an organization from sharing information. GRC Report 182 Exchange provides information and options that can be used by 183 organizations who must then apply their own policies for sharing 184 information. Organizations must develop policies and procedures for 185 the use of the GRC Report Exchange protocol and XML reports. 187 1.1. Normative and Informative 189 The XML schema [W3C.REC-xmlschema-1-20041028] and transport 190 requirements contained in this document are normative; all other 191 information provided is intended as informative. More specifically, 192 the following sections of this document are intended as informative: 193 Sections XXX. The following sections of this document are normative: 194 Sections XXX. 196 1.2. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [RFC2119]. 202 2. Report Types 204 There are many possible report types that may be exchanged using GRC 205 Report Exchange. The reports MUST all be XML formatted reports and 206 MAY leverage the data markings used by this specification to require 207 security options such as encryption on the entire report (XML 208 document) or a section of the report. 210 The types of reports may vary within each area of GRC. Example 211 report types broken out by GRC focus areas include: 213 o Finance and Business Operations 215 * Finance or business Filing Report 217 o Information Technology 219 * Service Level Agreement (SLA) Reports from service providers 220 (public cloud providers, community cloud providers, etc.) 222 o Security 224 * Security Report aligned to control requirements (ISO27002, NIST 225 800-53, etc.) from service providers 227 o Legal and Compliance 229 * eDiscovery Reports 231 * eWarrant Reports 233 * Compliance report aligned to specific regulations 235 * Report for internal or external audit aligned to risk and 236 control frameworks (ISO27002, NIST 800-53, COSO, COBIT, etc.) 238 3. Communication between Entities 240 Trust relationships. Service provider to tenant or client is the 241 most likely scenario for the initial use cases of GRC report 242 exchange. See Section 11.5 on profiles. 244 3.1. Inter-network Provider GRC Messaging 246 GRC Report Exchange provides a standard protocol and format that is 247 required to ensure inter-operability between vendors for the exchange 248 and filing of GRC reports. GRC Report Exchange provides the 249 framework necessary for communication between entities exchanging or 250 filing GRC reports. Several message types described in Section 6 are 251 necessary to facilitate the exchange or filing of reports. The 252 message types include the Report, Query, Acknowledgement, Result, and 253 the Request message. 255 The Report message is used when a GRC report is to be filed on a 256 system or associated database accepting GRC Report Exchange messages, 257 where no further action is required. A Query message is used to 258 request information on a particular report. The Acknowledgement and 259 Report messages are used to communicate the status and result of a 260 Query or Request message. 262 Use of the communication network and the GRC Report Exchange protocol 263 must be for pre-approved, authorized purposes only. It is the 264 responsibility of each participating party to adhere to guidelines 265 set forth in both a global use policy established through the peering 266 agreements for each bilateral peer or agreed-upon consortium 267 guidelines. The purpose of such policies is to avoid abuse of the 268 system; the policies shall be developed by a consortium of 269 participating entities. The global policy may be dependent on the 270 domain it operates under; for example, a government network or a 271 commercial network such as the Internet would adhere to different 272 guidelines to address the individual concerns. Privacy issues must 273 be considered in public networks such as the Internet. Privacy 274 issues are discussed in the Security Requirements section 275 (Section 11), along with other requirements that must be agreed upon 276 by participating entities. 278 The GRC Report Exchange system should be configurable to either 279 require user input or automatically provide or file reports. If the 280 trust relationship is not strong, it may not be in the peer's best 281 interest to accept a report or respond to a request. The trust 282 relationship may evolve over time through experience working with a 283 peer and knowledge and review of their policies and operating 284 procedures. 286 3.2. GRC Report Exchange Communication Topology 288 The most basic topology for communicating GRC Report Exchanges is a 289 direct connection or a bilateral relationship as illustrated below. 291 ______________ _____________ 292 | | | | 293 | GRC-RE |_____________________| GRC-RE | 294 |____________| |___________| 296 Figure 1: Direct Peer Topology 298 A star topology may be desirable in instances where a peer may be a 299 provider of GRC Reports. This requires trust relationships to be 300 established between the provider of information and each of the 301 consumers of that information. Examples may include clients that 302 file compliance or business reports to an authoritative entity. 304 The examples provided serve as an initial baseline set of expected 305 topologies that may change over time. 307 3.3. Message Formats 309 Section 6 describes the five GRC Report Exchange message types, to be 310 used with the appropriate XML documents. The messages are expected 311 to be generated and received on designated systems for GRC report 312 exchanges. 314 3.4. GRC Report Exchange Data Types 316 3.4.1. Boolean 318 A boolean value is represented by the BOOLEAN data type. 320 The BOOLEAN data type is implemented as "xs:boolean" 321 [W3C.REC-xmlschema-1-20041028] in the schema. 323 3.4.2. Language 325 A language value is represented by the LANG data type. 327 The LANG data type is a valid language code per [RFC5646] constrained 328 by the definition of "xs:language" [W3C.REC-xmlschema-1-20041028] 329 inherited from [W3C.REC-xml-20081126]. 331 3.4.3. Multilingual Strings 333 STRING data that represents multi-character attributes in a language 334 different than the default encoding of the document is of the 335 ML_STRING data type. 337 The ML_STRING data type is implemented as an "grc- 338 exchange:MLStringType" in the schema. 340 The base definition of this type is reused from the IODEF 341 specification [RFC5070], Section 2.4. This definition is fully 342 included in the GRC-Exchange specification in Section 4.8 to prevent 343 the need to use the IODEF schema. 345 3.4.4. Uniform Resource Locator strings 347 A uniform resource locator (URL) is represented by the URL data type. 348 The format of the URL data type is documented in [RFC3986]. 350 The URL data type is implemented as an "xs:anyURI" 351 [W3C.REC-xmlschema-1-20041028] in the schema. 353 3.4.5. Date-Time Strings 355 Date-time strings are represented by the DATETIME data type. Each 356 date-time string identifies a particular instant in time; ranges are 357 not supported. 359 Date-time strings are formatted according to a subset of ISO 8601: 360 2004 [ISO.8601.2000] documented in [RFC3339]. 362 The DATETIME data type is implemented as an "xs:dateTime" 363 [W3C.REC-xmlschema-1-20041028] in the schema. 365 The base definition of this type is reused from the IODEF 366 specification [RFC5070], Section 2.8. This definition is fully 367 included in the GRC-Exchange specification in Section 4.8 to prevent 368 the need to use the IODEF schema. 370 3.4.6. Timezone String 372 A timezone offset from UTC is represented by the TIMEZONE data type. 373 It is formatted according to the following regular expression: 374 "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". 376 The TIMEZONE data type is implemented as an "xs:string" 377 [W3C.REC-xmlschema-1-20041028] with a regular expression constraint 378 in the schema. This regular expression is identical to the timezone 379 representation implemented in an "xs:dateTime". 381 The base definition of this type is reused from the IODEF 382 specification [RFC5070], Section 2.9. This definition is fully 383 included in the GRC-Exchange specification in Section 4.8 to prevent 384 the need to use the IODEF schema. 386 3.4.7. Postal Address 388 A postal address is represented by the POSTAL data type. This data 389 type is an ML_STRING whose format is documented in Section 2.23 of 390 [RFC4519]. It defines a postal address as a free-form multi-line 391 string separated by the "$" character. 393 The POSTAL data type is implemented as an "xs:string" 394 [W3C.REC-xmlschema-1-20041028] in the schema. 396 The base definition of this type is reused from the IODEF 397 specification [RFC5070], Section 2.11. This definition is fully 398 included in the GRC-Exchange specification in Section 4.8 to prevent 399 the need to use the IODEF schema. 401 3.4.8. Telephone and Fax Numbers 403 A telephone or fax number is represented by the PHONE data type. The 404 format of the PHONE data type is documented in Section 2.35 of 405 [RFC4519]. 407 The PHONE data type is implemented as an "xs:string" 408 [W3C.REC-xmlschema-1-20041028] in the schema. 410 The base definition of this type is reused from the IODEF 411 specification [RFC5070], Section 2.13. This definition is fully 412 included in the GRC-Exchange specification in Section 4.8 to prevent 413 the need to use the IODEF schema. 415 3.4.9. Email String 417 An email address is represented by the EMAIL data type. The format 418 of the EMAIL data type is documented in Section 3.4.1 of [RFC5322]. 420 The EMAIL data type is implemented as an "xs:string" 421 [W3C.REC-xmlschema-1-20041028] in the schema. 423 The base definition of this type is reused from the IODEF 424 specification [RFC5070], Section 2.14. This definition is fully 425 included in the GRC-Exchange specification in Section 4.8 to prevent 426 the need to use the IODEF schema. 428 3.5. GRC Report Exchange Message Types 430 The five GRC Report Exchange message types are as follows: 432 1. Acknowledgement. This message is sent to the requestor of a 433 report (Request) or in response to a Query to notify on the state 434 of a request (approved, pending, not approved). 436 2. Result. This message is sent to the requestor of a GRC report 437 (Request) or in response to a Query. The Result may contain the 438 full report requested or a section of the report as appropriate 439 for the request in the Query. 441 3. Request. This message type is used to request a specific type of 442 GRC report. The Request MUST specify the XML schema and version 443 for the requested report along with any other parameters required 444 in the XML schema to generate the correct report. 446 4. Report. This message is used to provide a GRC Report. The 447 message can be considered a wrapper for any approved GRC schema 448 used to format a report for submission. 450 5. Query. This message is used to request information about a 451 specific GRC report. The XML schema and version used MUST be 452 specified along with any details required to provide the proper 453 Report response. The response is provided through the Report 454 message. 456 When an application receives a GRC Report Exchange message, it must 457 be able to determine the type of message and parse it accordingly. 458 The message type is specified in the GRCPolicy class. The GRCPolicy 459 class may also be used by the transport protocol to facilitate the 460 secure communication of the GRC Report Exchange. 462 4. GRC-Exchange Schema 464 There are three classes included in the GRC Report Exchange schema 465 required to facilitate communications. The RequestStatus class is 466 used to indicate the approval status of a report Request or Query; 467 the GRCDocument class identifies the XML schema to be used by the 468 provided or requested report; and the GRCPolicy class provides 469 information on the agreed-upon policies and specifies the type of 470 communication message being used. 472 The GRC Report Exchange schema acts as an envelope for the GRC XML 473 schema to facilitate secure GRC report communications. The intent in 474 maintaining a separate schema is for the flexibility of sending 475 messages between participating entities. Since GRC Report Exchange 476 is a separate schema that includes the appropriate GRC XML schema, 477 the GRC Report Exchange information acts as an envelope, and then the 478 GRCPolicy class can be easily extracted for use by the transport 479 protocol. 481 The security requirements of sending GRC reports and associated 482 information on finance, IT operations, legal, compliance, and 483 security across the network include the use of confidentiality 484 (encryption prior to the transport level), authentication 485 (potentially multi-hop), integrity, and non-repudiation. GRCPolicy 486 uses labels that correspond to policy and agreements to standardize 487 on handling requirements such as encryption and sharing limitations. 488 The GRCPolicy information should not be encrypted, hence GRC Report 489 Exchange is maintained separate from the GRC XML schema used to send 490 or request a report. This segregation enables flexibility for GRC 491 Report Exchange to be used with any GRC XML schema and removes the 492 need for decrypting and parsing the entire GRC Report and GRC Report 493 Exchange document to determine how it should be handled at each 494 entity communicating via GRC Report Exchange. 496 The purpose of the GRCPolicy class is to specify the message type for 497 the receiving host, facilitate the policy needs of GRC Reports, and 498 provide routing information in the form of an IP address of the 499 destination entity accepting GRC Report Exchange messages. 501 The policy information and guidelines are discussed in Section 502 Section 4.1. The policy is defined between GRC-Exchange peers and 503 within or between consortiums. The GRCPolicy is meant to be a tool 504 to facilitate the defined policies. This MUST be used in accordance 505 with policy set between clients, peers, consortiums, and/or regions. 506 Security, privacy, and confidentiality MUST be considered as 507 specified in this document. 509 The GRC Report Exchange (GRC-Exchange) schema is defined as follows: 511 +------------------+ 512 | GRC-Exchange | 513 +------------------+ 514 | LANG lang |<>---{0..1}----[ GRCPolicy ] 515 | | 516 | |<>---{0..1}----[ RequestStatus ] 517 | | 518 | |<>---{0..1}----[ GRCDocument ] 519 +------------------+ 521 Figure 2: The GRC-Exchange Schema 523 The aggregate classes that constitute the GRC-Exchange schema in the 524 grc-exchange namespace are as follows: 526 GRCPolicy 528 Zero or One. The GRCPolicy class is used by all message types to 529 facilitate policy agreements between peers, consortiums, or 530 federations, as well as to properly route messages. 532 RequestStatus 534 Zero or One. The RequestStatus class is used only in 535 Acknowledgement messages to report back to the entity requesting a 536 report or sending a report Query if the request is denied or 537 remains in a pending state. 539 GRCDocument 541 Zero or One. The GRCDocument class is used in each of the message 542 types to state the XML schema and version for the included XML 543 report, XML report request, or response. 545 The GRC-Exchange class defines one attribute as follows: 547 lang 549 REQUIRED. ENUM. A valid language code per [RFC5646] constrained 550 by the definition of "xs:language" [W3C.REC-xmlschema-1-20041028] 551 inherited from [W3C.REC-xml-20081126]. 553 Each of the three listed classes may be the only class included in 554 the GRC-Exchange class, hence the option for zero or one. In some 555 cases, GRCPolicy MAY be the only class in the GRC-Exchange definition 556 when used by the transport protocol [RFC6546], as that information 557 should be as small as possible and may not be encrypted. The 558 Acknowledgement message using the RequestStatus class MUST be able to 559 stand alone without the need for an GRC XML document to facilitate 560 the communication, limiting the data transported to the required 561 elements per [RFC6546]. 563 4.1. GRCPolicy Class 565 The GRCPolicy class facilitates the delivery of GRC Report Exchange 566 messages. 568 +--------------------------+ 569 | GRCPolicy | 570 +--------------------------+ 571 | |<>---{0..1}----[ ReportID ] 572 | ENUM restriction | 573 | STRING ext-restriction |<>-------------[ Node ] 574 | ENUM MsgType | 575 | STRING ext-MsgType |<>---{1..*}----[ PolicyRegion ] 576 | ENUM MsgDestination | 577 | STRING ext-MsgDestination| 578 | | 579 +--------------------------+ 581 Figure 3: The GRCPolicy Class 583 The aggregate elements that constitute the GRCPolicy class are as 584 follows: 586 ReportID 588 Zero or one. Global reference pointing back to the ReportID 589 defined in the GRC XML data model. The ReportID includes the 590 domain name of the entity who creates the report, a report number, 591 and an instance of that report number. The default report number 592 is a date, where the requested report is the most recent report on 593 or prior to the date specified. The format for the date SHALL be 594 YYYYMMDD, where Y is the year, M is the month, and D is the day. 595 The instance number is appended with a dash separating the values 596 and is used in cases for which there may be multiple reports 597 issued in a day. The format for the instance SHALL be HHMMSS, 598 where H is the hour as specified in a 24hour range, M is the 599 minute, S is the second provided in GMT. An alternate ID may be 600 specified within the GRC XML schema for the specific report. This 601 element has been derived from IODEF [RFC5070]. 603 Node 605 One. The Node class is used to identify a host or network device, 606 in this case to identify the system communicating GRC-Exchange 607 messages. The base definition of this class is reused from the 608 IODEF specification [RFC5070], Section 3.16. This definition is 609 fully included in the GRC-Exchange specification in Section 4.8 to 610 prevent the need to use the IODEF schema. 612 PolicyRegion 614 One or many. REQUIRED. The values for the attribute "region" are 615 used to determine what policy area may require consideration 616 before a trace can be approved. The PolicyRegion may include 617 multiple selections from the attribute list in order to fit all 618 possible policy considerations when crossing regions, consortiums, 619 or networks. 621 region 623 One. ENUM. 625 1. ClientToSP. An enterprise initiated the request to their 626 service provider. 628 2. SPToClient. An service provider passed a GRC request or 629 report to a client or an enterprise based on requested 630 services or service level agreements. 632 3. IntraConsortium. GRC report information that should have 633 no restrictions within the boundaries of a consortium with 634 the agreed-upon use and abuse guidelines. 636 4. PeerToPeer. GRC report information that should have no 637 restrictions between two peers but may require further 638 evaluation before continuance beyond that point with the 639 agreed-upon use and abuse guidelines. 641 5. BetweenConsortiums. GRC report information that should 642 have no restrictions between consortiums that have 643 established agreed-upon use and abuse guidelines. 645 6. ext-value. An escape value used to extend this attribute. 646 This attribute has been derived from IODEF [RFC5070], 647 Section 5.1 and is explained in Section 5, Extending the 648 Enumerated Values of Attributes. 650 Additionally, there is an extension attribute to add new 651 enumerated values: 653 ext-region. An escape value used to extend this attribute. 654 This attribute has been derived from IODEF [RFC5070] Section 655 5.1 and is explained in Section 5, Extending the Enumerated 656 Values of Attributes. 658 The GRCPolicy class has six attributes: 660 restriction 662 Optional. ENUM. This attribute indicates the disclosure 663 guidelines to which the sender expects the recipient to adhere 664 for the information represented in this class and its children. 665 This guideline provides no security since there are no 666 specified technical means to ensure that the recipient of the 667 document handles the information as the sender requested. 669 The value of this attribute is logically inherited by the 670 children of this class. That is to say, the disclosure rules 671 applied to this class, also apply to its children. 673 It is possible to set a granular disclosure policy, since all 674 of the high-level classes (i.e., children of the Incident 675 class) have a restriction attribute. Therefore, a child can 676 override the guidelines of a parent class, be it to restrict or 677 relax the disclosure rules (e.g., a child has a weaker policy 678 than an ancestor; or an ancestor has a weak policy, and the 679 children selectively apply more rigid controls). The implicit 680 value of the restriction attribute for a class that did not 681 specify one can be found in the closest ancestor that did 682 specify a value. 684 This attribute is defined as an enumerated value with a default 685 value of "private". Note that the default value of the 686 restriction attribute is only defined in the context of the 687 GRCPolicy class. In other classes where this attribute is 688 used, no default is specified. 690 This attribute is derived from IODEF [RFC5070] and is fully 691 included within this schema. 693 1. public. There are no restrictions placed in the 694 information. 696 2. need-to-know. The information may be shared with other 697 parties that are involved in the incident as determined by 698 the recipient of this document (e.g., multiple victim sites 699 can be informed of each other). 701 3. private. The information may not be shared. 703 4. default. The information can be shared according to an 704 information disclosure policy pre-arranged by the 705 communicating parties. 707 5. ext-value. An escape value used to extend this attribute. 708 This attribute has been derived from IODEF [RFC5070], 709 Section 5.1 and is explained in Section 5, Extending the 710 Enumerated Values of Attributes. 712 ext-restriction 714 OPTIONAL. STRING. A means by which to extend the restriction 715 attribute. This attribute has been derived from IODEF 716 [RFC5070] Section 5.1 and is explained in Section 5, Extending 717 the Enumerated Values of Attributes. 719 MsgType 721 REQUIRED. ENUM. The type of GRC-Exchange message sent. The 722 five types of messages are described in Section 3.5 and can be 723 noted as one of the five selections below. 725 1. Acknowledgement. This message is sent to the initiating 726 GRC-Exchange entity if a Request or Query has been denied 727 or is pending. 729 2. Result. This message provides the result of a Query. 731 3. Request. The purpose of the Request is to request a report 732 from an entity. 734 4. Report. This message is used to provide a GRC XML report. 736 5. Query. This message is used to request information either 737 about a specific report or group of reports. The actual 738 query is specified in the GRC XML Schema and is outside the 739 scope of this specification. 741 6. ext-value. An escape value used to extend this attribute. 742 This attribute has been derived from IODEF [RFC5070], 743 Section 5.1 and is explained in Section 5, Extending the 744 Enumerated Values of Attributes. 746 ext-MsgType 748 OPTIONAL. STRING. A means by which to extend the MsgType 749 attribute. This attribute has been derived from IODEF 750 [RFC5070] Section 5.1 and is explained in Section 5, Extending 751 the Enumerated Values of Attributes. 753 MsgDestination 755 REQUIRED. ENUM. The destination required at this level may 756 either be the system accepting GRC report exchange requests or 757 reports. The Node element lists the address of the host 758 receiving the GRC-Exchange message. 760 1. GRCSystem. The address listed in the Node element of the 761 GRCPolicy class is the system communicating via GRC- 762 Exchange that will receive the message. 764 2. ext-value. An escape value used to extend this attribute. 765 This attribute has been derived from IODEF [RFC5070] 766 Section 5.1 and is explained in Section 5, Extending the 767 Enumerated Values of Attributes. 769 ext-MsgDestination 771 OPTIONAL. STRING. A means by which to extend the 772 MsgDestination attribute. This attribute has been derived from 773 IODEF [RFC5070] Section 5.1 and is explained in Section 5, 774 Extending the Enumerated Values of Attributes. 776 4.2. RequestStatus 778 The RequestStatus class is an aggregate class in the GRC-Exchange 779 class. 781 +--------------------------------+ 782 | RequestStatus | 783 +--------------------------------+ 784 | | 785 | ENUM restriction | 786 | STRING ext-restriction | 787 | ENUM AuthorizationStatus | 788 | STRING ext-AuthorizationStatus | 789 | ENUM Justification | 790 | STRING ext-Justification | 791 | | 792 +--------------------------------+ 794 Figure 4: The RequestStatus Class 796 The RequestStatus class has six attributes: 798 restriction 800 OPTIONAL. ENUM. This attribute indicates the disclosure 801 guidelines to which the sender expects the recipient to adhere. 802 This guideline provides no real security since it is the choice 803 of the recipient of the document to honor it. This attribute 804 follows the same guidelines as "restriction" used in IODEF and 805 is explained in the GRCPolicy Class description in Section 4.1. 807 ext-restriction 809 OPTIONAL. STRING. A means by which to extend the restriction 810 attribute. This attribute has been derived from IODEF 811 [RFC5070] Section 5.1 and is explained in Section 5, Extending 812 the Enumerated Values of Attributes. 814 AuthorizationStatus 816 REQUIRED. ENUM. The listed values are used to provide a 817 response to the requesting entity of the ReportRequest or 818 ReportQuery. 820 1. Approved. The request was approved and will be provided. 821 The approved message MAY be sent if there will be a delay 822 in providing the report, otherwise, the Report or Result 823 MAY be provided without sending a Acknowledgement message. 825 2. Denied. The request has been denied. 827 3. Pending. Awaiting approval; a timeout period has been 828 reached, which resulted in this Pending status and 829 Acknowledgement message being generated. 831 4. ext-value. An escape value used to extend this attribute. 832 This attribute has been derived from IODEF [RFC5070] 833 Section 5.1 and is explained in Section 5, Extending the 834 Enumerated Values of Attributes. 836 ext-AuthorizationStatus 838 OPTIONAL. STRING. A means by which to extend the 839 AuthorizationStatus attribute. This attribute has been derived 840 from IODEF [RFC5070] Section 5.1 and is explained in Section 5, 841 Extending the Enumerated Values of Attributes. 843 Justification 844 OPTIONAL. ENUM. Provides a reason for a Denied or Pending 845 message. 847 1. SystemResource. A resource issue exists on the systems 848 that would be involved in the request. 850 2. Authentication. The enveloped digital signature [RFC3275] 851 failed to validate. 853 3. AuthenticationOrigin. The detached digital signature for 854 the original requestor on the RecordItem entry failed to 855 validate. 857 4. Encryption. Unable to decrypt the request. 859 5. UnrecognizedFormat. The format of the provided document 860 was unrecognized. 862 6. CannotProcess. The document could not be processed. 863 Reasons may include legal or policy decisions. Resolution 864 may require communication outside of this protocol to 865 resolve legal or policy issues. No further messages SHOULD 866 be sent until resolved. 868 7. Other. There were other reasons this request could not be 869 processed. 871 8. ext-value. An escape value used to extend this attribute. 872 This attribute has been derived from IODEF [RFC5070] 873 Section 5.1 and is explained in Section 5, Extending the 874 Enumerated Values of Attributes. 876 ext-Justification-ext 878 OPTIONAL. STRING. A means by which to extend the 879 Justification attribute. This attribute has been derived from 880 IODEF [RFC5070] Section 5.1 and is explained in Section 5, 881 Extending the Enumerated Values of Attributes. 883 4.3. GRCDocument 885 The GRCDocument class is an aggregate class in the GRC-Exchange 886 class. 888 +-------------------------+ 889 | GRCDocument | 890 +-------------------------+ 891 | |<>---{1..*}----[ ReportType ] 892 | ENUM Version | 893 | STRING ext-Version |<>---{0..1}----[ FromContact ] 894 | ENUM XMLSchemaID | 895 | STRING ext-XMLSchemaID |<>---{0..1}----[ URL ] 896 | ENUM restriction | 897 | STRING ext-restriction |<>---{1}-------[ XMLDocument ] 898 | | 899 | |<>---{0..*}----[ Signature ] 900 | | 901 | | 902 +-------------------------+ 904 Figure 5: The GRCDocument Class 906 The elements that constitute the GRCDocument class are as follows: 908 ReportType 910 One or many. REQUIRED. The values for the attribute "type" 911 are meant to assist in determining if the included XML report 912 or request is appropriate for the entity receiving the request 913 or report message. Multiple values may be selected for this 914 element; however, where possible, it should be restricted to 915 one value that most accurately describes the report type. 917 type 919 One. ENUM. 921 1. Filing. This ReportType is used when a GRC report is 922 included for expected filing purposes. Examples may 923 include the filing of a regulatory or business 924 operations report to a regulatory body. 926 2. Service Level Agreement. This option specifies the 927 report type as a report on a service level agreement. 928 This report may be sent from a service provide (SP) to a 929 tenant or client or from a trust authority to a 930 requesting entity. An SLA report may be associated with 931 any report format (XML) associated with an SLA 932 agreement, including but not limited to an IT or 933 security report. 935 3. Operational. An operational report may include any 936 standard operating reports used within or between 937 businesses or enterprises. This may be a routine 938 business, IT operational, or other type of report. 940 4. Compliance. A compliance report is specified when there 941 is a specific compliance report format required (as 942 specified by the schema used for the report). This type 943 may be used for internal or external compliance report 944 exchanges. 946 5. Audit. The Audit report type is distinguished from a 947 compliance report as the report contents may vary 948 depending on the report or report request in the 949 exchange. An audit report may take an approach of only 950 providing the state of compliance or details of findings 951 from an automated control review. 953 6. RiskAssessment. A RiskAssessment report differs from 954 the Compliance and Audit reports in that the report may 955 prioritize risks as specified in the XML schema and may 956 include GRC-XML risk ratings. A RiskAssessment may be 957 provided for any GRC area or on the GRC program as 958 specified by the GRCDocument. 960 7. OfficialBusiness. This option MUST be used if the GRC 961 information is requested by or affiliated with any 962 government or other official business request. This 963 could be used during an investigation for an eDiscovery, 964 eWarrant, or other use case. 966 8. Other. If this option is selected, a description of the 967 request MUST be provided so that policy decisions can be 968 made to proceed with the request or act upon the report. 969 The information should be provided in the GRC-Exchange 970 class meaning attribute. 972 9. ext-value. An escape value used to extend this type. 973 This value has been derived from IODEF [RFC5070], 974 Section 5.1 and is explained in Section 5, Extending the 975 Enumerated Values of Attributes. 977 ext-type 979 OPTIONAL. One. STRING. A means by which to extend the type 980 attribute. This attribute has been derived from IODEF 981 [RFC5070] Section 5.1 and is explained in Section 5, 982 Extending the Enumerated Values of Attributes. 984 FromContact 986 Zero or more. Contact. Provides contact information for the 987 parties responsible for a report provided in the GRC Report 988 Exchange as defined by the Contact class in Section 4.6. 990 URL 992 Zero or One. URL. A reference to the XML schema included. The 993 URL data type is defined in Section 3.4.4. The schemaLocation 994 for IODEF is already included in the RID schema, so this is not 995 necessary to include a URL for IODEF documents. 997 XMLDocument 999 One. ExtensionType. The XMLDocument is a complete XML document 1000 defined by the ExtensionType class in Section 4.7. This class 1001 follows the guidelines in [RFC5070] Section 5 where the data 1002 type is set to "xml" and meaning is set to "xml" to include an 1003 xml document. 1005 Signature 1007 Zero to many. ExtensionType. The Signature includes a 1008 complete XML document with the type specified by the 1009 ExtensionType class in Section 4.7. This class follows the 1010 guidelines in [RFC5070] Section 5 where the data type is set to 1011 "xml" and meaning is set to "xml" to include an xml document. 1012 The usage of this element is similar to RID [RFC6545] and is 1013 used to encapsulate the detached signature based on a specific 1014 class within the XML document to verify the originator of the 1015 message. If a detached signature is used, guidance for the 1016 encapsulated document MUST be provided as to which class should 1017 be used to create the signature. Alternatively, if no guidance 1018 is provided, the digital signature MUST be an enveloped 1019 signature of the entire XML document that is encapsulated. 1020 This attribute has been derived from RID [RFC6545], Section 1021 5.1.1. 1023 The GRCDocument class has six attributes: 1025 Version 1027 OPTIONAL. One. The Version attribute is the version number of 1028 the specified XML schema. That schema must be an approved 1029 version of a schema registered with IANA for use with GRC- 1030 Exchange. The IANA registry for managing schemas used with 1031 GRC-Exchange is specified in Section 13. This attribute has 1032 been derived from RID [RFC6545], Section 5.1.1. 1034 ext-value. An escape value used to extend this attribute. 1035 This attribute has been derived from IODEF [RFC5070], 1036 Section 5.1 and is explained in Section 5, Extending the 1037 Enumerated Values of Attributes. 1039 ext-Version 1041 OPTIONAL. One. STRING. The ext-Version attribute is the 1042 version number of the included XML schema. This attribute is 1043 used if a schema other than an IANA registered schema that has 1044 been added to the enumerated list for Version is included. 1045 This attribute has been derived from RID [RFC6545], Section 1046 5.1.1. 1048 XMLSchemaID 1050 OPTIONAL. One. URL. The XMLSchemaID attribute is the 1051 identifier, the defined namespace [W3C.REC-xml-names-20091208], 1052 of the XML schema of the XML document included. The 1053 XMLSchemaID and Version specify the format of the XMLDocument 1054 element. The only permitted values, include any namespace 1055 listed in the IANA managed list of registered schemas for use 1056 with GRC-Exchange. The IANA registry for managing schemas is 1057 specified in Section 13. This attribute has been derived from 1058 RID [RFC6545], Section 5.1.1. 1060 ext-value. An escape value used to extend this attribute. 1061 This attribute has been derived from IODEF [RFC5070], 1062 Section 5.1 and is explained in Section 5, Extending the 1063 Enumerated Values of Attributes. 1065 ext-XMLSchemaID 1067 OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier 1068 (defined namespace) of the XML schema of the XML document 1069 included. The ext-XMLSchemaID and ext-Version specify the 1070 format of the XMLDocument element and are used if the included 1071 schema is not an IANA registered schema that has been added to 1072 the enumerated list for XMLSchemaID. This attribute has been 1073 derived from RID [RFC6545], Section 5.1.1. 1075 restriction 1077 OPTIONAL. ENUM. This attribute indicates the disclosure 1078 guidelines to which the sender expects the recipient to adhere. 1079 This guideline provides no real security since it is the choice 1080 of the recipient of the document to honor it. This attribute 1081 follows the same guidelines as "restriction" used in IODEF and 1082 is explained in the GRCPolicy Class description in Section 4.1. 1084 ext-restriction 1086 OPTIONAL. STRING. A means by which to extend the restriction 1087 attribute. This attribute has been derived from IODEF 1088 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1089 the Enumerated Values of Attributes. 1091 4.4. Reference Class 1093 The Reference class is a reference to the GRC Schema used for the 1094 exchange. A reference consists of a name, a URL to this reference, 1095 and an optional description. 1097 +------------------+ 1098 | Reference | 1099 +------------------+ 1100 | |<>----------[ ReferenceName ] 1101 | |<>--{0..*}--[ URL ] 1102 | |<>--{0..*}--[ Description ] 1103 +------------------+ 1105 Figure 6: The Reference Class 1107 The aggregate classes that constitute Reference: 1109 ReferenceName 1111 One. ML_STRING. Name of the reference. 1113 URL 1115 Zero or many. URL. A URL associated with the reference. 1117 Description 1119 Zero or many. ML_STRING. A free-form text description of this 1120 reference. 1122 4.5. ReportID Class 1124 The ReportID class represents a report tracking number that is unique 1125 in the context of the reporting organization and identifies the 1126 activity characterized in a GRCDocument. This identifier would serve 1127 as an index into the organizational reporting system. The 1128 combination of the name attribute and the string in the element 1129 content MUST be a globally unique identifier describing the activity. 1130 Documents generated by a given organization MUST NOT reuse the same 1131 value unless they are referencing the same report instance. The 1132 ReportID class is derived from IODEF [RFC5070], Section 3.3. 1134 +------------------------+ 1135 | ReportID | 1136 +------------------------+ 1137 | STRING | 1138 | | 1139 | STRING name | 1140 | STRING instance | 1141 | ENUM restriction | 1142 | STRING ext-restriction | 1143 +------------------------+ 1145 Figure 7: The ReportID Class 1147 The ReportID class has four attributes: 1149 name 1151 Required. STRING. An identifier describing the organization 1152 that created the report. In order to have a globally unique 1153 organization name, the fully qualified domain name associated 1154 with the organization MUST be used. 1156 instance 1158 Optional. STRING. An identifier referencing a subset of the 1159 named report. 1161 restriction 1163 Optional. ENUM. This attribute follows the same guidelines as 1164 "restriction" explained in the GRCPolicy Class description in 1165 Section 4.1. 1167 ext-restriction 1169 OPTIONAL. STRING. A means by which to extend the restriction 1170 attribute. This attribute has been derived from IODEF 1171 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1172 the Enumerated Values of Attributes. 1174 4.6. Contact Class 1176 The Contact class describes contact information for organizations and 1177 personnel involved in the report exchange. This class allows for the 1178 naming of the involved party, specifying contact information for 1179 them, and identifying their role in the XML Report. The Contact 1180 class is derived from IODEF [RFC5070], Section 3.7. 1182 People and organizations are treated interchangeably as contacts; one 1183 can be associated with the other using the recursive definition of 1184 the class (the Contact class is aggregated into the Contact class). 1185 The 'type' attribute disambiguates the type of contact information 1186 being provided. 1188 The inheriting definition of Contact provides a way to relate 1189 information without requiring the explicit use of identifiers in the 1190 classes or duplication of data. A complete point of contact is 1191 derived by a particular traversal from the root Contact class to the 1192 leaf Contact class. As such, multiple points of contact might be 1193 specified in a single instance of a Contact class. Each child 1194 Contact class logically inherits contact information from its 1195 ancestors. 1197 +------------------------+ 1198 | Contact | 1199 +------------------------+ 1200 | ENUM role |<>-{0..1}-[ ContactName ] 1201 | STRING ext-role |<>-{0..*}-[ Description ] 1202 | ENUM type |<>-{0..*}-[ RegistryHandle ] 1203 | STRING ext-type |<>-{0..1}-[ PostalAddress ] 1204 | ENUM restriction |<>-{0..*}-[ Email ] 1205 | STRING ext-restriction |<>-{0..*}-[ Telephone ] 1206 | |<>-{0..1}-[ Fax ] 1207 | |<>-{0..1}-[ Timezone ] 1208 | |<>-{0..*}-[ AdditionalContact ] 1209 | |<>-{0..*}-[ AdditionalData ] 1210 +------------------------+ 1212 Figure 8: The Contact Class 1214 The aggregate classes that constitute the Contact class are: 1216 ContactName 1218 Zero or one. ML_STRING. The name of the contact. The contact 1219 may either be an organization or a person. The type attribute 1220 disambiguates the semantics. 1222 Description 1224 Zero or many. ML_STRING. A free-form description of this 1225 contact. In the case of a person, this is often the 1226 organizational title of the individual. 1228 RegistryHandle 1230 Zero or many. A handle name into the registry of the contact. 1232 PostalAddress 1234 Zero or one. The postal address of the contact. 1236 Email 1238 Zero or many. The email address of the contact. 1240 Telephone 1242 Zero or many. The telephone number of the contact. 1244 Fax 1246 Zero or one. The facsimile telephone number of the contact. 1248 Timezone 1250 Zero or one. TIMEZONE. The timezone in which the contact 1251 resides formatted according to Section Section 3.4.6. 1253 AdditionalContact 1255 Zero or many. A Contact instance contained within another 1256 Contact instance inherits the values of the parent(s). This 1257 recursive definition can be used to group common data 1258 pertaining to multiple points of contact and is especially 1259 useful when listing multiple contacts at the same organization. 1261 AdditionalData 1263 Zero or many. A mechanism by which to extend the data model. 1265 At least one of the aggregate classes MUST be present in an instance 1266 of the Contact class. This is not enforced in the GRC-Exchange 1267 schema as there is no simple way to accomplish it. 1269 The Contact class has six attributes: 1271 role 1273 Required. ENUM. Indicates the role the contact fulfills. 1274 This attribute is defined as an enumerated list: 1276 1. creator. The entity that generate the document. 1278 2. admin. An administrative contact for a host, network, or 1279 entity. 1281 3. tech. A technical contact for a host or network. 1283 4. cc. (also known as carbon-copy) An entity that is to be 1284 kept informed about the report. 1286 5. ext-value. An escape value used to extend this attribute. 1287 This attribute has been derived from IODEF [RFC5070], 1288 Section 5.1 and is explained in Section 5, Extending the 1289 Enumerated Values of Attributes. 1291 ext-role 1293 Optional. STRING. A means by which to extend the role 1294 attribute. This attribute has been derived from IODEF 1295 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1296 the Enumerated Values of Attributes. 1298 type 1300 Required. ENUM. Indicates the type of contact being 1301 described. This attribute is defined as an enumerated list: 1303 1. person. The information for this contact references an 1304 individual. 1306 2. organization. The information for this contact references 1307 an organization. 1309 3. ext-value. An escape value used to extend this attribute. 1310 This attribute has been derived from IODEF [RFC5070], 1311 Section 5.1 and is explained in Section 5, Extending the 1312 Enumerated Values of Attributes. 1314 ext-type 1316 Optional. STRING. A means by which to extend the type 1317 attribute. This attribute has been derived from IODEF 1318 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1319 the Enumerated Values of Attributes. 1321 restriction 1323 Optional. ENUM. This attribute follows the same guidelines as 1324 "restriction" used in IODEF and is explained in the GRCPolicy 1325 Class description in Section 4.1. 1327 ext-restriction 1329 OPTIONAL. STRING. A means by which to extend the restriction 1330 attribute. This attribute has been derived from IODEF 1331 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1332 the Enumerated Values of Attributes. 1334 This definition is from the IODEF specification [RFC5070], Section 1335 3.7. This definition is fully included in the GRC-Exchange 1336 specification to prevent the need to use the IODEF schema. 1338 4.6.1. RegistryHandle Class 1340 The RegistryHandle class represents a handle into an Internet 1341 registry or community-specific database. The handle is specified in 1342 the element content and the type attribute specifies the database. 1343 The RegistryHandle class is derived from IODEF [RFC5070], Section 1344 3.7.1. 1346 +---------------------+ 1347 | RegistryHandle | 1348 +---------------------+ 1349 | STRING | 1350 | | 1351 | ENUM registry | 1352 | STRING ext-registry | 1353 +---------------------+ 1355 Figure 9: The RegistryHandle Class 1357 The RegistryHandle class has two attributes: 1359 registry 1361 Required. ENUM. The database to which the handle belongs. 1362 The default value is 'local'. The possible values are: 1364 1. internic. Internet Network Information Center 1365 2. apnic. Asia Pacific Network Information Center 1367 3. arin. American Registry for Internet Numbers 1369 4. lacnic. Latin-American and Caribbean IP Address Registry 1371 5. ripe. Reseaux IP Europeens 1373 6. afrinic. African Internet Numbers Registry 1375 7. local. A database local to the CSIRT 1377 8. ext-value. An escape value used to extend this attribute. 1378 This attribute has been derived from IODEF [RFC5070], 1379 Section 5.1 and is explained in Section 5, Extending the 1380 Enumerated Values of Attributes. 1382 ext-registry 1384 Optional. STRING. A means by which to extend the registry 1385 attribute. This attribute has been derived from IODEF 1386 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1387 the Enumerated Values of Attributes. 1389 This definition is from the IODEF specification [RFC5070], Section 1390 3.7.1. This definition is fully included in the GRC-Exchange 1391 specification to prevent the need to use the IODEF schema. 1393 4.6.2. PostalAddress Class 1395 The PostalAddress class specifies a postal address formatted 1396 according to the POSTAL data type (Section 3.4.7). 1398 +---------------------+ 1399 | PostalAddress | 1400 +---------------------+ 1401 | POSTAL | 1402 | | 1403 | ENUM meaning | 1404 | ENUM lang | 1405 +---------------------+ 1407 Figure 10: The PostalAddress Class 1409 The PostalAddress class has two attributes: 1411 meaning 1412 Optional. ENUM. A free-form description of the element 1413 content. 1415 lang 1417 Required. ENUM. A valid language code per [RFC5646] 1418 constrained by the definition of "xs:language" 1419 [W3C.REC-xmlschema-1-20041028] inherited from 1420 [W3C.REC-xml-20081126]. 1422 This definition is from the IODEF specification [RFC5070], Section 1423 3.7.2. This definition is fully included in the GRC-Exchange 1424 specification to prevent the need to use the IODEF schema. 1426 4.6.3. Email Class 1428 The Email class specifies an email address formatted according to 1429 EMAIL data type (Section 3.4.9). 1431 +--------------+ 1432 | Email | 1433 +--------------+ 1434 | EMAIL | 1435 | | 1436 | ENUM meaning | 1437 +--------------+ 1439 Figure 11: The Email Class 1441 The Email class has one attribute: 1443 meaning 1445 Optional. ENUM. A free-form description of the element 1446 content. 1448 This definition is from the IODEF specification [RFC5070], Section 1449 3.7.3. This definition is fully included in the GRC-Exchange 1450 specification to prevent the need to use the IODEF schema. 1452 4.6.4. Telephone and Fax Classes 1454 The Telephone and Fax classes specify a voice or fax telephone number 1455 respectively, and are formatted according to PHONE data type 1456 (Section 3.4.8). 1458 +--------------------+ 1459 | {Telephone | Fax } | 1460 +--------------------+ 1461 | PHONE | 1462 | | 1463 | ENUM meaning | 1464 +--------------------+ 1466 Figure 12: The Telephone and Fax Classes 1468 The Telephone class has one attribute: 1470 meaning 1472 Optional. ENUM. A free-form description of the element 1473 content (e.g., hours of coverage for a given number). 1475 This definition is from the IODEF specification [RFC5070], Section 1476 3.7.4. This definition is fully included in the GRC-Exchange 1477 specification to prevent the need to use the IODEF schema. 1479 4.7. ExtensionType Class 1481 The ExtensionType class serves as an extension mechanism for 1482 information not otherwise represented in the data model. For 1483 relatively simple information, atomic data types (e.g., integers, 1484 strings) are provided with a mechanism to annotate their meaning. 1485 The class can to encapsulating entire XML documents conforming to an 1486 IANA registered Schema. This class is also used to provide a 1487 consistent location for the inclusion of digital signatures. 1489 Unlike XML, which is self-describing, atomic data must be documented 1490 to convey its meaning. This information is described in the 1491 'meaning' attribute. Since these description are outside the scope 1492 of the specification, some additional coordination may be required to 1493 ensure that a recipient of a document using the ExtensionType classes 1494 can make sense of the custom extensions. 1496 +------------------+ 1497 | AdditionalData | 1498 +------------------+ 1499 | ANY | 1500 | | 1501 | ENUM dtype | 1502 | STRING ext-dtype | 1503 | STRING meaning | 1504 | STRING formatid | 1505 | ENUM restriction | 1506 +------------------+ 1508 Figure 13: The ExtensionType Class 1510 The ExtensionType class has five attributes: 1512 dtype 1514 Required. ENUM. The data type of the element content. The 1515 permitted values for this attribute are shown below. The 1516 default value is "string". 1518 1. boolean. The element content is of type BOOLEAN. 1520 2. byte. The element content is of type BYTE. 1522 3. character. The element content is of type CHARACTER. 1524 4. date-time. The element content is of type DATETIME. 1526 5. integer. The element content is of type INTEGER. 1528 6. portlist. The element content is of type PORTLIST. 1530 7. real. The element content is of type REAL. 1532 8. string. The element content is of type STRING. 1534 9. file. The element content is a base64 encoded binary file 1535 encoded as a BYTE[] type. 1537 10. frame. The element content is a layer-2 frame encoded as 1538 a HEXBIN type. 1540 11. packet. The element content is a layer-3 packet encoded 1541 as a HEXBIN type. 1543 12. ipv4-packet. The element content is an IPv4 packet 1544 encoded as a HEXBIN type. 1546 13. ipv6-packet. The element content is an IPv6 packet 1547 encoded as a HEXBIN type. 1549 14. path. The element content is a file-system path encoded 1550 as a STRING type. 1552 15. url. The element content is of type URL. 1554 16. csv. The element content is a common separated value 1555 (CSV) list per Section 2 of [RFC4180] encoded as a STRING 1556 type. 1558 17. winreg. The element content is a Windows registry key 1559 encoded as a STRING type. 1561 18. xml. The element content is XML (see Section 5). 1563 19. ext-value. An escape value used to extend this attribute. 1564 This attribute has been derived from IODEF [RFC5070], 1565 Section 5.1 and is explained in Section 5, Extending the 1566 Enumerated Values of Attributes. 1568 ext-dtype 1570 Optional. STRING. A means by which to extend the dtype 1571 attribute. This attribute has been derived from IODEF 1572 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1573 the Enumerated Values of Attributes. 1575 meaning 1577 Optional. STRING. A free-form description of the element 1578 content. 1580 formatid 1582 Optional. STRING. An identifier referencing the format and 1583 semantics of the element content. 1585 restriction 1587 Optional. ENUM. This attribute follows the same guidelines as 1588 "restriction" explained in the GRCPolicy Class description in 1589 Section 4.1. 1591 This definition is from the IODEF specification [RFC5070], Section 1592 3.6. This definition is fully included in the GRC-Exchange 1593 specification to prevent the need to use the IODEF schema. 1595 4.8. Node Class 1597 The Node class names a system (e.g., PC, router) or network. 1599 This class was derived from IODEF [RFC5070] and is partially included 1600 in this specification. The original IODEF definition was derived 1601 from IDMEF [RFC4765]. 1603 +---------------+ 1604 | Node | 1605 +---------------+ 1606 | |<>--{0..*}--[ NodeName ] 1607 | |<>--{0..*}--[ Address ] 1608 | |<>--{0..1}--[ Location ] 1609 | |<>--{0..1}--[ DateTime ] 1610 +---------------+ 1612 Figure 14: The Node Class 1614 The aggregate classes that constitute Node are: 1616 NodeName 1618 Zero or more. ML_STRING. The name of the Node (e.g., fully 1619 qualified domain name). This information MUST be provided if 1620 no Address information is given. 1622 Address 1624 Zero or more. The hardware, network, or application address of 1625 the Node. If a NodeName is not provided, at least one Address 1626 MUST be specified. This class is defined in Section 4.9. 1628 Location 1630 Zero or one. ML_STRING. A free-from description of the 1631 physical location of the equipment. 1633 DateTime 1635 Zero or one. DATETIME. A timestamp of when the resolution 1636 between the name and address was performed. This information 1637 SHOULD be provided if both an Address and NodeName are 1638 specified. 1640 4.9. Address Class 1642 The Address class represents a hardware (layer-2), network (layer-3), 1643 or application (layer-7) address. 1645 This class was derived from IODEF [RFC5070] and is fully included in 1646 this specification. The original IODEF definition was derived from 1647 IDMEF [RFC4765]. 1649 +---------------------+ 1650 | Address | 1651 +---------------------+ 1652 | ENUM category | 1653 | STRING ext-category | 1654 | STRING vlan-name | 1655 | INTEGER vlan-num | 1656 +---------------------+ 1658 Figure 15: The Address Class 1660 The Address class has four attributes: 1662 category 1664 Required. ENUM. The type of address represented. The 1665 permitted values for this attribute are shown below. The 1666 default value is "ipv4-addr". 1668 asn. Autonomous System Number 1670 atm. Asynchronous Transfer Mode (ATM) address 1672 e-mail. Electronic mail address (RFC 822) 1674 ipv4-addr. IPv4 host address in dotted-decimal notation 1675 (a.b.c.d) 1677 ipv4-net. IPv4 network address in dotted-decimal notation, 1678 slash, significant bits (a.b.c.d/nn) 1680 ipv4-net-mask. IPv4 network address in dotted-decimal 1681 notation, slash, network mask in dotted-decimal notation 1682 (a.b.c.d/w.x.y.z) 1684 ipv6-addr. IPv6 host address 1686 ipv6-net. IPv6 network address, slash, significant bits 1687 ipv6-net-mask. IPv6 network address, slash, network mask 1689 mac. Media Access Control (MAC) address 1691 ext-value. An escape value used to extend this attribute. 1692 This attribute has been derived from IODEF [RFC5070], 1693 Section 5.1 and is explained in Section 5, Extending the 1694 Enumerated Values of Attributes. 1696 ext-category 1698 Optional. STRING. A means by which to extend the category 1699 attribute. This attribute has been derived from IODEF 1700 [RFC5070] Section 5.1 and is explained in Section 5, Extending 1701 the Enumerated Values of Attributes. 1703 vlan-name 1705 Optional. STRING. The name of the Virtual LAN to which the 1706 address belongs. 1708 vlan-num 1710 Optional. STRING. The number of the Virtual LAN to which the 1711 address belongs. 1713 4.10. GRC-Exchange Name Spaces 1715 The GRC-Exchange schema declares a namespace of "grc-exchange-1.0" 1716 and registers it per [W3C.REC-xml-names-20091208]. Any XML instance 1717 incorporating GRC-Exchange MUST use the element GRC-Exchange in the 1718 "urn:ietf:params:xml:ns:grc-exchange-1.0" namespace. It can be 1719 referenced as follows: 1721 1727 5. Extending the Enumerated Values of Attributes 1729 In order to support the evolving needs of XML Schema exchanges, some 1730 extensibility is built into the GRC Report Exchange protocol. This 1731 section discusses how new attributes that have no current 1732 representation in the data model can be incorporated into GRC- 1733 Exchange. These techniques are designed so that adding new data will 1734 not require a change to the schema. With proven value, well- 1735 documented additions can be incorporated into future versions of the 1736 specification. However, this approach also supports private 1737 additions relevant only to a closed consortium. 1739 The data model supports a means by which to add new enumerated values 1740 to an attribute, following the method used in IODEF [RFC5070] for the 1741 same purpose. For each attribute that supports this extension 1742 technique, there is a corresponding attribute in the same element 1743 whose name is identical, less a prefix of "ext-". This special 1744 attribute is referred to as the extension attribute, and the 1745 attribute being extended is referred to as an extensible attribute. 1746 For example, an extensible attribute named "foo" will have a 1747 corresponding extension attribute named "ext-foo". An element may 1748 have many extensible, and therefore many extension, attributes. In 1749 addition to a corresponding extension attribute, each extensible 1750 attribute has "ext-value" as one its possible values. This 1751 particular value serves as an escape sequence and has no valid 1752 meaning. 1754 In order to add a new enumerated value to an extensible attribute, 1755 the value of this attribute MUST be set to "ext-value", and the new 1756 desired value MUST be set in the corresponding extension attribute. 1757 For example, an extended instance of the type attribute of the Impact 1758 class would look as follows: 1760 1762 A given extension attribute MUST NOT be set unless the corresponding 1763 extensible attribute has been set to "ext-value". 1765 6. GRC Report Exchange Messages 1767 The GRC-Exchange schema is used in combination with GRC XML documents 1768 to facilitate GRC Report Exchange communications. Each message type 1769 varies slightly in format and purpose; hence, the requirements vary 1770 and are specified for each. 1772 Note: The implementation of GRC-Exchange may automate the ability to 1773 fill in the content required for each message type from the GRC 1774 management systems involved in the message exchange. 1776 6.1. Acknowledgement 1778 Description: This message is sent in response to a Request or a Query 1779 message to provide status as to the approval of a request. 1781 The following information is required for Acknowledgement messages 1782 and is provided through: 1784 GRC-Exchange Information: 1786 GRCPolicy 1788 GRC-Exchange message type, ReportID, and destination policy 1789 information 1791 RequestStatus class: 1793 AuthorizationStatus of request 1795 Standards for encryption and digital signatures [RFC3275], 1796 [W3C.REC-xmldsig-core-20080610]: 1798 Digital signature of responding entity authenticity of GRC- 1799 Exchange Message, from the entity creating this message using an 1800 enveloped XML digital signature. 1802 XML encryption as required by policy, agreements, and standard 1803 data markers. 1805 A pending status is automatically generated after a 5-minute timeout 1806 without system predefined or administrator action taken to approve or 1807 deny the request. If a request is left in a pending state for more 1808 than a configurable period of time (default of 5 minutes), a response 1809 is sent to the requestor with the enumeration value set to pending. 1810 If a request is denied, the response sets the enumeration value to 1811 denied. If the request is approved, but the response will be 1812 delayed, a response MAY be sent with the enumerated value set to 1813 approved. The approved message is not mandatory, however the pending 1814 and denied message types MUST be sent if the conditions are reached. 1816 6.2. Result 1818 Description: This message provides the result of an approved Query. 1819 The Query may be used when a query is made on a group of reports or a 1820 request is made for specific details within a report. If a standard 1821 report is requested based on a specific XML schema, Request MUST be 1822 used. The details of the Query will vary depending on the included 1823 GRC XML schema. The XML schema may provide specific guidance on how 1824 queries are conducted as this specification is intended to provide a 1825 generalized structure for many types of GRC information exchanges. 1827 The following information is required for Result messages and will be 1828 provided through: 1830 GRC-Exchange Information: 1832 GRCPolicy 1834 GRC-Exchange message type, ReportID, and destination policy 1835 information 1837 GRCDocument 1839 The GRCDocument class specifies the specific GRC-Exchange 1840 XML schema that is required per the Query. The Result will 1841 include the necessary information to appropriately respond 1842 to the request. 1844 GRC XML Information: 1846 GRC XML schema elements and attributes as appropriate for the 1847 Query. 1849 Standards for encryption and digital signatures [RFC3275]: 1851 Digital signature of sending entity for authenticity of Result 1852 message, from the entity creating this message using an 1853 enveloped XML digital signature. 1855 XML encryption as required by policy, agreements, and standard 1856 data markers. 1858 A Result message is sent back to the requesting entity of a Query. 1859 This will include the results of the query using the appropriate XML 1860 schema named in the request. Details of what standard queries are 1861 automated in addition to the standard responses are to be detailed by 1862 the appropriate GRC communities (GRC-XML, LI-XML, etc.) in guidance 1863 documents associated with each of the relevant schemas. 1865 6.3. Request 1867 Description: The Request is used to request a report in a 1868 standardized format using the referenced XML schema in the 1869 GRCDocument class. The report requested will be the most recent 1870 report to the date and time requested. 1872 The following information is required for Request messages and is 1873 provided through: 1875 GRC-Exchange Information: 1877 GRCPolicy 1879 GRC-Exchange message type, ReportID, and destination policy 1880 information 1882 GRC XML Information: 1884 GRC XML schema elements and attributes as appropriate for the 1885 Request. 1887 Standards for encryption and digital signatures [RFC3275]: 1889 Digital signature from initiating entity sending the GRC- 1890 Exchange message using a detached XML digital signature on the 1891 GRC-Exchange information. 1893 Digital signature of requesting entity for authenticity of the 1894 GRC-Exchange message, from the entity sending this message 1895 using an enveloped XML digital signature on the included GRC- 1896 XML document document. 1898 XML encryption as required by policy, agreements, and data 1899 markers. 1901 Security requirements include the ability to encrypt 1902 [W3C.REC-xmlenc-core-20021210] the contents of the ReportRequest 1903 message using the public key of the destination entity communicating 1904 via GCR-Exchange. If no report is available for the exact date and 1905 time in the request, the most recent report details prior to the date 1906 requested will be provided. If there is no report to provide per the 1907 specified date and time, the Acknowledgement message will be sent 1908 instead setting the AuthorizationStatus to denied and providing the 1909 appropriate reason for the deny. 1911 6.4. Report 1913 Description: This message is used to provide a report using a 1914 specified GRC XML schema. This message does not require any actions 1915 to be taken, except to file the report on the receiving system or 1916 associated database. This message may be in response to a Request or 1917 sent as a regularly scheduled report. 1919 The following information is required for Report messages and will be 1920 provided through: 1922 GRC-Exchange Information: 1924 GRCPolicy GRC-Exchange message type, ReportID, and destination 1925 policy information 1927 The following data is recommended if available and can be provided 1928 through: 1930 GRC XML Information: 1932 GRC XML schema elements and attributes as appropriate for the 1933 Request. 1935 Standards for encryption and digital signatures [RFC3275]: 1937 Digital signature from initiating entity, passed to all systems 1938 receiving the report using an enveloped XML digital signature. 1940 XML encryption as required by policy, agreements, and standard 1941 data markers. 1943 Security requirements include the ability to encrypt 1944 [W3C.REC-xmlenc-core-20021210] the contents of the Report message 1945 using the public key of the destination entity. Senders of a Report 1946 message should note that the information may be used to correlate 1947 information for the purpose of trending, pattern detection, etc., and 1948 may be shared with other parties unless otherwise agreed upon with 1949 the receiving entity in an established contract or agreement. 1950 Therefore, sending parties of a Report message may obfuscate or 1951 remove sensitive information before sending a Report message. A 1952 Report message may be sent either to file a report or in response to 1953 an ReportRequest, and data sensitivity must be considered in both 1954 cases. 1956 6.5. Query 1958 Description: The report Query message is used to request information 1959 from a trusted entity participating in GRC-Exchanges. The request 1960 can include the ReportID number, if known, or detailed information 1961 about the report or group of reports applicable to the query. 1963 The following information must be used for a report Query message and 1964 is provided through: 1966 GRC-Exchange Information: 1968 GRCPolicy 1970 GRC-Exchange message type, ReportID, and destination policy 1971 information 1973 GRC XML information (optional): 1975 GRC XML schema elements and attributes as appropriate for the 1976 report Query. 1978 Standards for encryption and digital signatures [RFC3275]: 1980 Digital signature from the entity initiating the GRC-Exchange 1981 message, passed to all systems receiving the report Query using 1982 an enveloped XML digital signature. 1984 XML encryption as required by policy, agreements, and standard 1985 data markers. 1987 The proper response to the Query message is a Result message. 1988 Security requirements include the ability to encrypt 1989 [W3C.REC-xmlenc-core-20021210] the contents of the report Request 1990 message using the public key of the destination entity communicating 1991 via GCR-Exchange. If no report is available for the exact date and 1992 time in the request, the most recent report details prior to the date 1993 requested will be provided. If there is no report to provide per the 1994 specified date and time, the Acknowledgement message will be sent 1995 instead setting the AuthorizationStatus to denied and providing the 1996 appropriate reason for the deny. 1998 7. GRC-Exchange Communication Flows 2000 The following section outlines the communication flows for GRC- 2001 Exchange and also provides examples of messages. 2003 7.1. Report Communication Flow 2005 The diagram below outlines the communication flow for a GRC-Exchange 2006 Report message sent from one entity to another. This communication 2007 flow is the simplest as no response is required. The Report may be a 2008 regularly scheduled report filing. 2010 Sending Entity Receiving Entity 2012 1. Generate Report message 2014 2. o----------Report----------> 2016 3. Receive and process report 2017 No Response 2019 Figure 16: GRC-Exchange Report Communication Flow 2021 The Report message MAY be encrypted [W3C.REC-xmlenc-core-20021210] 2022 for the recipient of the report depending upon the markers included 2023 in the restriction class either in the GRC-Exchange schema or in the 2024 GRC XML schema used for the report. When a report is received, the 2025 receiving entity must verify that the report has not already been 2026 filed. The ReportID and other distinguishing information in the 2027 specific report type can be used to compare with existing database 2028 entries. The Report message typically does not have a response, but 2029 the use of an Acknowledgement message is sometimes required to 2030 communicate status or error handling information. 2032 7.1.1. GRC-Exchange Report Example 2034 The example listed is of a Report based on ... 2036 In the following example, use of [W3C.REC-xmldsig-core-20080610] to 2037 generate digital signatures follows the guidance of XMLDsig 1.0 2038 [W3C.REC-xmldsig-core-20080610]. XMLDsig version 1.1 2039 [W3C.CR-xmldsig-core1-20110303] supports additional digest 2040 algorithms. Reference [RFC4051] for URIs intended for use with XML 2041 digital signatures, encryption, and canonicalization. SHA-1 SHOULD 2042 NOT be used, see [RFC6194] for further details. 2044 Example to be provided in an updated version of this document. 2046 7.2. Request Communication Flow 2048 The diagram below outlines the GRC-Exchange report request 2049 communication flow between participating entities. The proper 2050 response to a report Request is a Report message. If there is a 2051 problem with the request, such as a failure to validate the digital 2052 signature or decrypt the request, a Acknowledgement message is sent 2053 to the requestor. The Acknowledgement message should provide the 2054 reason why the message could not be processed. 2056 Sending Entity Receiving Entity 2058 1. Generate report Request 2060 2. o--------Request----------> 2062 3. Receive and process request 2064 4. If denied or pending, send notice 2066 5. <---Acknowledgement---o 2068 6. If request is approved, 2070 7. <----------Report----------o 2072 Figure 17: Request Communication Flow 2074 7.2.1. Request Example 2076 The following example of the report Request is based on the ReportID 2077 time-based identifier tied to the specified GRC XML GRCDocument. 2079 Example to be provided in an updated version of this document. 2081 7.2.2. Acknowledgement Message Example 2083 The example Acknowledgement message is in response to the report 2084 Request listed above. The entity that received the request was 2085 unable to validate the digital signature used to authenticate the 2086 sending RID system. 2088 Example to be provided in an updated version of this document. 2090 7.3. Query Communication Flow 2092 The diagram below outlines the GRC-Exchange report Query 2093 communication flow between participating entities. 2095 Sending Entity Receiving Entity 2097 1. Generate Report Query 2099 2. o---------Query-----------> 2101 3. Receive and process request 2103 4. If denied or pending, send notice 2105 5. <---Acknowledgement---o 2107 6. If request approved 2109 7. <----------Result----------o 2111 Figure 18: Query Communication Flow 2113 The report Query communication flow is used to request specific 2114 information about a GRC report or group of reports. Information may 2115 be shared between participating entities using this format. 2117 If there is a problem with the Query message, such as a failure to 2118 validate the digital signature [RFC3275] or decrypt the request, an 2119 Acknowledgement message is sent to the requestor. The 2120 Acknowledgement message should provide the reason why the message 2121 could not be processed. 2123 7.3.1. Query Example 2125 The following example includes the GRC-Exchange information and an 2126 example query using an included XML schema, which is also referenced 2127 in the GRCDocument class. 2129 Example to be provided in an updated version of this document. 2131 7.3.2. Acknowledgement Message Example 2133 The example Acknowledgement message is in response to the Query 2134 message listed above. The entity that received the request is 2135 responding with an answer to the Query. The Result in this instance 2136 will be delayed for more than the 5-minute default time period, hence 2137 a Acknowledgement message is sent to notify of the approval status. 2139 Example to be provided in an updated version of this document. 2141 7.3.3. Result Message Example 2143 The example Result message is in response to the Query request. This 2144 message type may be preceded by a Acknowledgement within the report 2145 Query flow of messages. It may be a direct response to a report 2146 Query request if the request is approved prior to the timeout period. 2147 This message provides a response to the request in the Query. 2149 Example to be provided in an updated version of this document. 2151 8. Internationalization Issues 2153 Internationalization and localization is of specific concern to the 2154 GRC-Exchange, since information will often need to be exchanged 2155 across language barriers. The GRC-Exchange supports this goal by 2156 depending on XML constructs, and through explicit design choices in 2157 the data model. 2159 GRC-Exchange documents are limited to the use of UTF-8 as it 2160 adequately provides the necessary support for internationalization. 2161 Additionally, each included document MUST specify the language in 2162 which their contents are encoded. The language can be specified with 2163 the attribute "xml:lang" (per Section 2.12 of [W3C.REC-xml-20081126]) 2164 in the top-level element (i.e., GRC-Exchange-Document@lang) and 2165 letting all other elements inherit that definition. All GRC-Exchange 2166 classes with a free-form text definition (i.e., all those defined of 2167 type grc-exchange:MLStringType) can also specify a language different 2168 from the rest of the document. The valid language codes for the 2169 "xml:lang" attribute are described in [RFC5646]. 2171 The data model supports multiple translations of free-form text. In 2172 the places where free-text is used for descriptive purposes, the 2173 given class always has a one-to-many cardinality to its parent (e.g., 2174 Description class). The intent is to allow the identical text to be 2175 encoded in different instances of the same class, but each being in a 2176 different language. This approach allows a GRC-Exchange document 2177 author to send recipients speaking different languages an identical 2178 document. The GRC-Exchange parser SHOULD extract the appropriate 2179 language relevant to the recipient. 2181 While the intent of the data model is to provide internationalization 2182 and localization, the intent is not to do so at the detriment of 2183 interoperability. While the GRC-Exchange does support different 2184 languages, the data model also relies heavily on standardized 2185 enumerated attributes that can crudely approximate the contents of 2186 the document. With this approach, an organization should be able to 2187 make some sense of an GRC-Exchange document it receives even if the 2188 text based data elements are written in a language unfamiliar to the 2189 consumer. 2191 The Node class identifies a host or network device. This document 2192 re-uses the definition of Node from the IODEF specification 2193 [RFC5070], Section 3.16. However, that document did not clearly 2194 specify whether a NodeName could be an Internationalized Domain Name 2195 (IDN). GRC-Exchange systems MUST treat the NodeName class as a 2196 domain name slot [RFC5890]. GRC-Exchange systems SHOULD support IDNs 2197 in the NodeName class; if they do so, the UTF-8 representation of the 2198 domain name MUST be used, i.e., all of the domain name's labels MUST 2199 be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels 2200 MUST NOT be used. An application communicating via GRC-Exchange can 2201 convert between A-labels and U-labels by using the Punycode encoding 2202 [RFC3492] for A-labels as described in the protocol specification for 2203 Internationalized Domain Names in Applications [RFC5891]. 2205 9. GRC-Exchange Schema Definition 2207 2208 2214 2218 2226 2228 2233 *** Schema to be included here *** 2235 10. Requirements for GRC XML Schemas for GRC-Exchange 2237 GRC Report Exchange is a generalized version of the Real-time Inter- 2238 network Defense (RID) [RFC6545] protocol. RID leverages certain 2239 aspects of the Incident Object Description Exchange Format (IODEF) 2240 [RFC5070] schema to provide the necessary security features such as 2241 confidentiality and integrity required for the exchange of 2242 potentially sensitive information. In generalizing RID into a schema 2243 and set of message exchange flows for GRC reports, the GRC XML 2244 schemas MUST include the following: classes, elements, and attributes 2245 with enumerated values to facilitate the automated security and 2246 confidentially concerns for GRC Report Exchange. A GRC XML schema 2247 within this document may refer to any type of XML schema used for 2248 Governance, Risk, and Compliance information or reporting. Examples 2249 include, but are not limited to GRC-XML, LI-XML, and security 2250 automation XML schemas. 2252 The restriction attribute, reused from IODEF [RFC5070] into GRC- 2253 Exchange, MUST be included in any individual class of a GRC XML 2254 schema that could require XML encryption 2255 [W3C.REC-xmlenc-core-20021210] just on the data contained in that 2256 class. If encryption is only required at the full document level 2257 based on the sensitivity and sharing requirements, the restriction 2258 attribute in GRC-Exchange may be sufficient. 2260 11. Security Requirements 2262 The content in this section is derived from RID [RFC6545]. 2264 11.1. XML Digital Signatures and Encryption 2266 GRC-Exchange leverages existing security standards and data markings 2267 in GRCPolicy to achieve the required levels of security for the 2268 exchange of GRC information. The use of standards include TLS and 2269 the XML security features of encryption 2270 [W3C.REC-xmlenc-core-20021210] and digital signatures [RFC3275], 2271 [W3C.REC-xmldsig-core-20080610]. The standards provide clear methods 2272 to ensure that messages are secure, authenticated, and authorized, 2273 and that the messages meet policy and privacy guidelines and maintain 2274 integrity. 2276 As specified in the relevant sections of this document, the XML 2277 digital signature [RFC3275] and XML encryption 2278 [W3C.REC-xmlenc-core-20021210] are used in the following cases: 2280 XML Digital Signature 2282 o For all message types, the full GRC-Exchange document MUST be 2283 signed using an enveloped signature by the sending peer to provide 2284 authentication and integrity to the receiving GRC-Exchange system. 2285 The signature is placed in an instance of the Signature element. 2287 o XML Signature Best Practices 2288 [W3C.WD-xmldsig-bestpractices-20110809] guidance SHOULD be 2289 followed to prevent or mitigate security risks. Examples include 2290 the recommendation to authenticate a signature prior to processing 2291 (executing potentially dangerous operations) and limiting the use 2292 of URIs since they may enable cross-site scripting attacks or 2293 access to local information. 2295 o XML Path Language (XPath) 2.0 [W3C.REC-xpath20-20101214] MUST be 2296 followed to specify the portion of the XML document to be signed. 2297 XPath is used to specify a location within an XML document. Best 2298 practice recommendations for using XPath 2299 [W3C.WD-xmldsig-bestpractices-20110809] SHOULD be referenced to 2300 reduce the risk of denial of service attacks. The use of XSLT 2301 transforms MUST be restricted according to security guidance in 2302 [W3C.WD-xmldsig-bestpractices-20110809]. 2304 XML Encryption 2306 o The document included in GRC-Exchange messages MAY be encrypted to 2307 provide an extra layer of security between peers so that the 2308 message is not only encrypted for transport. This behavior would 2309 be agreed upon between peers or a consortium, or determined on a 2310 per-message basis, depending on security requirements. It should 2311 be noted that there are cases for transport where the GRCPolicy 2312 class needs to be presented in clear text, as detailed in the 2313 transport document [RFC6546]. 2315 o A Request, or any other message type that may be relayed through 2316 GRC-Exchange systems before reaching the intended destination as a 2317 result of trust relationships, MAY be encrypted specifically for 2318 the intended recipient. This may be necessary if the GRC-Exchange 2319 network is being used for message transfer, the intermediate 2320 parties do not need to have knowledge of the request contents, and 2321 a direct communication path does not exist. In that case, the 2322 GRCPolicy class is used by intermediate parties and as such, 2323 GRCPolicy is maintained in clear text. 2325 o A message may be encrypted using the key of the request 2326 originator, while leaving the GRC-Exchange contents in clear text. 2327 In that case, the intermediate parties can view the GRCPolicy 2328 information and know a response has been provided without seeing 2329 the contents of the response. If the use of encryption were 2330 limited to sections of the message, the History class information 2331 would be encrypted. Otherwise, it is RECOMMENDED to encrypt the 2332 entire included schema plus GRC-Exchange document and use an 2333 enveloped signature, for the originator of the request. The 2334 existence of the Result message for an incident would tell any 2335 intermediate parties used in the path of the incident 2336 investigation that the incident handling has been completed. 2338 o The restriction attribute sets expectations for the privacy of an 2339 incident and is defined in Section 4.1. Following the guidance 2340 for XML encryption in the Security Requirements Section, the 2341 restriction attribute can be set in any of the GRC-Exchange 2342 classes to define restrictions and encryption requirements for the 2343 exchange of GRC information. The restriction options enable 2344 encryption capabilities for the complete exchange of an XML 2345 document (including any extensions), within specific classes of a 2346 schema that embeds the restriction attribute where more limited 2347 restrictions are desired. The restriction attribute is contained 2348 in each of the GRC-Exchange classes and MUST be used in accordance 2349 with confidentiality expectations for either sections of the 2350 included XML document or the complete included XML document. 2351 Consortiums and organizations should consider this guidance when 2352 creating exchange policies. 2354 o Expectations based on restriction setting: 2356 * If restriction is set to "private", the class or document MUST 2357 be encrypted for the recipient using XML encryption and the 2358 public key of the recipient. See Section 11.2 for a discussion 2359 on public key infrastructure (PKI) and other security 2360 requirements. 2362 * If restriction is set to "need-to-know", the class or document 2363 MUST be encrypted to ensure only those with need-to-know access 2364 can decrypt the data. The document can either be encrypted for 2365 each individual for which access is intended or a single group 2366 key may be used. The method used SHOULD adhere to any 2367 certificate policy and practices agreements between entities 2368 for the use of GRC-Exchange. A group key in this instance 2369 refers to a single key (symmetric) that is used to encrypt the 2370 block of data. The users with need-to-know access privileges 2371 may be given access to the shared key via a secure distribution 2372 method, for example, providing access to the symmetric key 2373 encrypted with each of users public keys. 2375 * If restriction is set to "public", the class or document MUST 2376 be sent in clear text. This setting can be critical if certain 2377 sections of a document or an entire document are to be shared 2378 without restrictions. This provides flexibility within an 2379 exchange to share out certain information freely where 2380 appropriate. 2382 * If restriction is set to "default", The information can be 2383 shared according to an information disclosure policy pre- 2384 arranged by the communicating parties. 2386 o Expectations based on placement of the restriction setting: 2388 * If restriction is set within one of the GRC-Exchange classes, 2389 the restriction applies to the entire included XML document. 2391 * If restriction is set within individual classes of the included 2392 XML document, the restriction applies to the specific class and 2393 the children of that class. 2395 The formation of policies is a very important aspect of using a 2396 messaging system like GRC-Exchange to exchange potentially sensitive 2397 information. Many considerations should be involved for peering 2398 parties, and some guidelines to protect the data, systems, and 2399 transport are covered in this section. Policies established should 2400 provide guidelines for communication methods, security, and fall-back 2401 procedures. See Sections 11.3 and Section 11.4 for additional 2402 information on consortiums and PKI considerations. 2404 The security considerations for the storage and exchange of 2405 information in GRC-Exchange messaging may include adherence to local, 2406 regional, or national regulations in addition to the obligations to 2407 protect information. GRC-Exchange Policy is a necessary tool for 2408 listing the requirements of messages to provide a method to 2409 categorize data elements for proper handling. Controls are also 2410 provided for the sending entity to protect messages from third 2411 parties through XML encryption. 2413 GRC-Exchange provides a method to exchange GRC request and Report 2414 messages between entities. Administrators have the ability to base 2415 decisions on the available resources and other factors of their 2416 enterprise and maintain control of GRC exchanges. Thus, GRC-Exchange 2417 provides the ability for participating networks to manage their own 2418 security controls, leveraging the information listed in GRCPolicy. 2420 GRC-Exchange is used to transfer or exchange XML documents in an IANA 2421 registered format. Implementations SHOULD NOT download schemas at 2422 runtime due to the security implications, and included documents MUST 2423 NOT be required to provide a resolvable location of their schema. 2425 11.2. Public Key Infrastructure 2427 It is RECOMMENDED that GRC-Exchange, the XML security functions, and 2428 transport protocols properly integrate with a PKI managed by the 2429 consortium, federate PKIs within a consortium, or use a PKI managed 2430 by a trusted third party. Entities MAY use shared keys as an 2431 alternate solution, although this may limit the ability to validate 2432 certificates and could introduce risk. For the Internet, a few of 2433 examples of existing efforts that could be leveraged to provide the 2434 supporting PKI include the Regional Internet Registry's (RIR's) PKI 2435 hierarchy, vendor issued certificates, or approved issuers of 2436 Extended Validation (EV) Certificates. Security and privacy 2437 considerations related to consortiums are discussed in Sections 11.3 2438 and Section 11.4. 2440 The use of PKI between entities or by a consortium SHOULD adhere to 2441 any applicable certificate policy and practices agreements for the 2442 use of GRC-Exchange. [RFC3647] specifies a commonly used format for 2443 certificate policy (CP) and certification practices statements (CPS). 2444 Systems with predefined relationships for GRC-Exchange include those 2445 who peer directly or through a consortium with agreed-upon 2446 appropriate use agreements. The agreements to trust other entities 2447 may be based on assurance levels that could be determined by a 2448 comparison of the CP, CPS, and/or GRC-Exchange operating procedures. 2449 The initial comparison of policies and ability to audit controls 2450 provides a baseline assurance level for entities to form and maintain 2451 trust relationships. Trust relationships may also be defined through 2452 a bridged or hierarchical PKI in which both peers belong. If shared 2453 keys or keys issued from a common CA are used, the verification of 2454 controls to determine the assurance level to trust other entities may 2455 be limited to the GRC-Exchange policies and operating procedures. 2457 XML security functions utilized in GRC-Exchange require a trust 2458 center such as a PKI for the distribution of credentials to provide 2459 the necessary level of security for this protocol. Layered transport 2460 protocols also utilize encryption and rely on a trust center. Public 2461 key certificate pairs issued by a trusted Certification Authority 2462 (CA) MAY be used to provide the necessary level of authentication and 2463 encryption for the GRC-Exchange protocol. The CA used for GRC- 2464 Exchange messaging must be trusted by all involved parties and may 2465 take advantage of similar efforts, such as the Internet2 federated 2466 PKI or the ARIN/RIR effort to provide a PKI to service providers. 2467 The PKI used for authentication also provides the necessary 2468 certificates needed for encryption used for the GRC-Exchange 2469 transport protocol [RFC6546]. 2471 11.2.1. Authentication 2473 Hosts receiving a GRC-Exchange message MUST be able to verify that 2474 the sender of the request is valid and trusted. Using digital 2475 signatures on a hash of the GRC-Exchange message with an X.509 2476 version 3 certificate issued by a trusted party MUST be used to 2477 authenticate the request. The X.509 version 3 specifications as well 2478 as the digital signature specifications and path validation standards 2479 set forth in [RFC5280] MUST be followed in order to interoperate with 2480 a PKI designed for similar purposes. Full path validation verifies 2481 the chaining relationship to a trusted root and also performs a 2482 certificate revocation check. The use of digital signatures in GRC- 2483 Exchange XML messages MUST follow the World Wide Web Consortium (W3C) 2484 recommendations for signature syntax and processing when either the 2485 XML encryption [W3C.REC-xmlenc-core-20021210] or digital signature 2486 [W3C.REC-xmldsig-core-20080610], [RFC3275] is used within a document. 2488 It might be helpful to define an extension to the authentication 2489 scheme that uses attribute certificates [RFC5755] in such a way that 2490 an application could automatically determine whether human 2491 intervention is needed to authorize a request; however, the 2492 specification of such an extension is out of scope for this document. 2494 The use of pre-shared keys may be considered for authentication at 2495 the transport layer. If this option is selected, the specifications 2496 set forth in "Pre-Shared Key Ciphersuites for Transport Layer 2497 Security (TLS)" [RFC4279] MUST be followed. Transport specifications 2498 are detailed in a separate document [RFC6546]. 2500 11.2.2. Multi-Hop Request Authentication 2502 The use of multi-hop authentication in a Request is used when a 2503 Request is sent to multiple entities in an iterative manner. Multi- 2504 hop authentication is REQUIRED in Requests that involve multiple 2505 entities where Requests are forwarded iteratively through peers. 2506 Bilateral trust relationships MAY be used between peers, then Multi- 2507 hop authentication MUST be used for cases where the originator of a 2508 message is authenticated several hops into the message flow. 2510 For practical reasons, entities may want to prioritize incident 2511 handling events based upon the immediate peer for a Request, the 2512 originator of a request, and other relevant information provided in 2513 metadata. In order to provide a higher assurance level of the 2514 authenticity of a Request, the originating GRC-Exchange system is 2515 included in the Request along with contact information and the 2516 information of all GRC-Exchange systems in the path the Request has 2517 taken. This information is provided through the GRC-Exchange From- 2518 Contact class nesting the list of systems and contacts involved in a 2519 request. 2521 To provide multi-hop authentication, the originating GRC-Exchange 2522 system MUST include a digital signature in the Request sent to all 2523 systems in the upstream path. The signature MUST be passed to all 2524 parties that receive a Request, and each party MUST be able to 2525 perform full path validation on the digital signature [RFC5280]. In 2526 order to accommodate that requirement, the signed data MUST remain 2527 unchanged as a request is passed along between providers and may be 2528 restricted to one element for which the signature is applied. A 2529 second benefit to this requirement is that the integrity of the 2530 filter used is ensured as it is passed to subsequent entities in the 2531 upstream trace of the incident. The trusted PKI also provides the 2532 keys used to digitally sign the selected data element for a Request 2533 to meet the requirement of authenticating the original request. Any 2534 host in the path of the trace should be able to verify the digital 2535 signature using the trusted PKI. 2537 In the case in which an enterprise using GRC-Exchange sends a Request 2538 to its provider, the signature from the enterprise MUST be included 2539 in the initial request. The provider may generate a new request to 2540 send upstream to members of the provider's consortium to continue the 2541 request. If the original request is sent, the originating provider, 2542 acting on behalf of the enterprise network with a request, MUST also 2543 digitally sign, with an enveloped signature, the full included XML 2544 document to assure the authenticity of the Request. A provider that 2545 offers GRC-Exchange as a service may be using its own PKI to secure 2546 GRC-Exchange communications between its GRC-Exchange system and the 2547 attached enterprise networks. Providers participating in the trace 2548 MUST be able to determine the authenticity of GRC-Exchange requests. 2550 11.3. Consortiums and Public Key Infrastructures 2552 Consortiums are an ideal way to establish a communication web of 2553 trust for GRC-Exchange messaging. It should be noted that direct 2554 relationships may be ideal for some communications, such as those 2555 between a provider of incident information and a subscriber of the 2556 incident reports. The consortium could provide centralized 2557 resources, such as a PKI, and established guidelines and control 2558 requirements for use of GRC-Exchange. The consortium may assist in 2559 establishing trust relationships between the participating providers 2560 to achieve the necessary level of cooperation and experience-sharing 2561 among the consortium entities. This may be established through PKI 2562 certificate policy [RFC3647] reviews to determine the appropriate 2563 trust levels between organizations or entities. The consortium may 2564 also be used for other purposes to better facilitate communication 2565 among providers in a common area (Internet, region, government, 2566 education, private networks, etc.). 2568 Using a PKI to distribute certificates used by GRC-Exchange systems 2569 provides an already established method to link trust relationships 2570 between consortiums that peer with SPs belonging to a separate 2571 consortium. In other words, consortiums could peer with other 2572 consortiums to enable communication of GRC-Exchange messages between 2573 the participating providers. The PKI along with Memorandums of 2574 Agreement could be used to link border directories to share public 2575 key information in a bridge, a hierarchy, or a single cross- 2576 certification relationship. 2578 Consortiums also need to establish guidelines for each participating 2579 provider to adhere. The RECOMMENDED guidelines include: 2581 o Physical and logical practices to protect GRC-Exchange systems; 2583 o Network and application layer protection for GRC-Exchange systems 2584 and communications; 2586 o Proper use guidelines for GRC-Exchange systems, messages, and 2587 requests; and 2589 o A PKI, certificate policy, and certification practices statement 2590 to provide authentication, integrity, and privacy. 2592 The functions described for a consortium's role parallel that of a 2593 PKI federation. The PKI federations that currently exist are 2594 responsible for establishing security guidelines and PKI trust 2595 models. The trust models are used to support applications to share 2596 information using trusted methods and protocols. 2598 A PKI can also provide the same level of security for communication 2599 between an end entity (enterprise, educational, or government 2600 customer network) and the provider. 2602 11.4. Privacy Concerns and System Use Guidelines 2604 Information sharing typically raises many concerns especially when 2605 privacy related information may be exchanged. The GRCPolicy class is 2606 used to automate the enforcement of the privacy concerns listed 2607 within this document. The privacy and system use concerns for the 2608 system communicating GRC-Exchange messages and other integrated 2609 components include the following: 2611 Service Provider Concerns: 2613 o Privacy information contained in Human Resources, legal, 2614 compliance and other reports. 2616 Customer Attached Networks Participating in GRC-Exchange with 2617 Provider: 2619 o Customer networks may include an enterprise, educational, 2620 government, or other attached networks to a provider participating 2621 in GRC-Exchange. Customers should review data handling policies 2622 to understand how data will be protected by a service provider. 2623 This information will enable customers to decide what types of 2624 data at what sensitivity level can be shared with service 2625 providers. This information could be used at the application 2626 layer to establish sharing profiles for entities and groups, see 2627 Section 11.5. 2629 o Customers should request information on the security and privacy 2630 considerations in place by their provider and the consortium of 2631 which the provider is a member. Customers should understand if 2632 their data were to be forwarded, how might it be sanitized and how 2633 will it be protected. Customers should also understand if 2634 limitations can be placed on how any data they share with their 2635 provider will be used in advance of sharing that data. 2637 o Customers should be aware that their data can and will be sent to 2638 other providers in order to complete a request unless an agreement 2639 stating otherwise is made in the service level agreements between 2640 the customer and provider. Customers considering privacy options 2641 may limit the use of this feature if they do not want the data 2642 forwarded. 2644 Parties Involved in Exchanges: 2646 o Privacy of information such as the source and destination used for 2647 communication purposes over the monitored or GRC-Exchange 2648 connected network(s). 2650 o Protection of data from being viewed by intermediate parties in 2651 the path of an Request request should be considered. 2653 o Privacy of information exchanged in reports. 2655 Consortium Considerations: 2657 o System use restrictions for information sharing within the local 2658 region's definitions of appropriate traffic. When participating 2659 in a consortium, appropriate use guidelines should be agreed upon 2660 and entered into contracts. 2662 o System use prohibiting the consortium's participating providers 2663 from inappropriately requesting information unlawfully within the 2664 jurisdiction or region. 2666 Inter-Consortium Considerations: 2668 o System use between peering consortiums should consider any 2669 government communication regulations that apply between those two 2670 regions, such as encryption export and import restrictions. 2672 o System use between consortiums SHOULD NOT request information and 2673 actions beyond the scope intended and permitted by law or inter- 2674 consortium agreements. 2676 o System use between consortiums should consider national boundary 2677 issues and request limits in their appropriate system use 2678 agreements. Appropriate use should include restrictions to 2679 prevent the use of the protocol to limit or restrict traffic that 2680 is otherwise permitted within the country in which the peering 2681 consortium resides. 2683 The security and privacy considerations listed above are for the 2684 consortiums, providers, and enterprises to agree upon. The agreed- 2685 upon policies may be facilitated through use of the GRCPolicy class 2686 and application layer options. Some privacy considerations are 2687 addressed through the GRC-Exchange guidelines for encryption and 2688 digital signatures as described in Section 11.1. 2690 GRC-Exchange messaging privacy concerns should be elaborated on 2691 here... 2693 Information shared through through GRC-Exchange could be sensitive. 2694 Such data in GRC-Exchange messages can be protected through the use 2695 of encryption [W3C.REC-xmlenc-core-20021210] enveloping the XML and 2696 GRC-Exchange document, using the public encryption key of the 2697 originating entity. 2699 The decision is left to the system users and consortiums to determine 2700 appropriate data to be shared given that the goal of the 2701 specification is to provide the appropriate technical options to 2702 remain compliant. Local, state, or national laws may dictate the 2703 appropriate reporting requirements for specific exchange types. 2705 Privacy becomes an issue whenever sensitive data traverses a network. 2707 In the case of a Request or Report, where the originating provider is 2708 aware of the entity that will receive the request for processing, the 2709 free-form text areas of the document could be encrypted 2710 [W3C.REC-xmlenc-core-20021210] using the public key of the 2711 destination entity to ensure that no other entity in the path can 2712 read the contents. The encryption is accomplished through the W3C 2713 [W3C.REC-xmlenc-core-20021210] specification for encrypting an 2714 element. 2716 GRC Report Exchanges must be legitimate incidents and not used for 2717 purposes such as sabotage or censorship. An example of such abuse of 2718 the system includes a report containing information about a 2719 competitor's compliance that may have been falsified to hurt their 2720 business. 2722 Intra-consortium GRC-Exchange communications raise additional issues, 2723 especially when the peering consortiums reside in different regions 2724 or nations. 2726 The GRC Report Exchange messages may be a valid use of the system 2727 within the confines of that country's network border; however, it may 2728 not be permitted to continue across network boundaries where such 2729 content is permitted under law. A continued Request, Query, or 2730 Report into a second country may break the laws and regulations of 2731 that nation. Any such messages MUST cease at the country's border. 2733 The privacy concerns listed in this section address issues among the 2734 trusted parties involved in a trace within an provider, a GRC- 2735 Exchange consortium, and peering GRC-Exchange consortiums. Data used 2736 for GRC-Exchange communications must also be protected from parties 2737 that are not trusted. This protection is provided through the 2738 authentication and encryption of documents as they traverse the path 2739 of trusted servers and the local security controls in place for the 2740 GRC Report Exchange systems. Each GRC-Exchange system MUST perform a 2741 bi-directional authentication when sending a GRC-Exchange message and 2742 use the public encryption key of the upstream or downstream peer to 2743 send a message or document over the network. This means that the 2744 document is decrypted and re-encrypted at each GRC-Exchange system 2745 via TLS over a transport protocol such as [RFC6546]. The GRC- 2746 Exchange messages may be decrypted at each GRC-Exchange system in 2747 order to properly process the request or relay the information. 2748 Today's processing power is more than sufficient to handle the 2749 minimal burden of encrypting and decrypting relatively small typical 2750 GRC-Exchange messages. 2752 11.5. Sharing Profiles and Policies 2754 The application layer can be used to establish workflows and rulesets 2755 specific to sharing profiles for entities or consortiums. The 2756 profiles can leverage sharing agreements to restrict data types or 2757 classifications of data that are shared. The level of information or 2758 classification of data shared with any entity may be based on 2759 protection levels offered by the receiving entity and periodic 2760 validation of those controls. The profile may also indicate how far 2761 information can be shared according to the entity and data type. The 2762 profile can also support if requests to share data from an entity 2763 must go directly to that entity. 2765 In some cases, pre-defined sharing profiles will be possible. These 2766 include any use case where an agreement is in place in advance of 2767 sharing. Examples may be between clients and providers, entities 2768 such as partners, or consortiums. There may be other cases when 2769 sharing profiles may not be established in advance. An organization 2770 may want to establish sharing profiles specific to possible user 2771 groups to prepare for possible incident scenarios. The user groups 2772 could include business partners, industry peers, service providers, 2773 experts not part of a service provider, law enforcement, or 2774 regulatory repotting bodies. 2776 Workflows to approve transactions may be specific to sharing profiles 2777 and data types. Application developers should include capabilities 2778 to enable these decision points for users of the system. 2780 Any expectations between entities to preserve the weight and 2781 admissibility of evidence should be handled at the policy and 2782 agreement level. A sharing profile may include notes or an indicator 2783 for approvers in workflows to reflect if such agreements exist. 2785 12. Security Considerations 2787 GRC Report Exchange has many security requirements and considerations 2788 built into the design of the protocol, several of which are described 2789 in the Security Requirements section. For a complete view of 2790 security, considerations include the availability, confidentiality, 2791 and integrity concerns for the transport, storage, and exchange of 2792 information. 2794 Authenticated encrypted tunnels between systems accepting GRC- 2795 Exchange communications are used to provide confidentiality, 2796 integrity, authenticity, and privacy for the data at the transport 2797 layer. Encryption and digital signatures are also used at the GRC 2798 XML document level through GRC-Exchange options to provide 2799 confidentiality, integrity, authenticity, privacy and traceability of 2800 the document contents. Trust relationships may be through direct 2801 peers or consortiums using established trust relationships of public 2802 key infrastructure (PKI) via cross-certifications. Trust levels can 2803 be established in cross-certification processes where entities 2804 compare PKI policies that include the specific management and 2805 handling of an entity's PKI and certificates issued under that 2806 policy. [RFC3647] defines an Internet X.509 Public Key 2807 Infrastructure Certificate Policy and Certification Practices 2808 Framework that may be used in the comparison of policies to establish 2809 trust levels and agreements between entities, an entity and a 2810 consortium, and consortia. The agreements SHOULD consider key 2811 management practices including the ability to perform path validation 2812 on certificates [RFC5280], key distribution techniques [RFC2585], 2813 Certificate Authority and Registration Authority management 2814 practices. 2816 The agreements between entities SHOULD also include a common 2817 understanding of the usage of GRC-Exchange security, policy, and 2818 privacy options discussed in this section. The formality, 2819 requirements, and complexity of the agreements for the certificate 2820 policy, practices, and the use of GRC-Exchange options SHOULD be 2821 decided by the entities or consortiums creating those agreements. 2823 13. IANA Considerations 2825 This document uses URNs to describe XML namespaces 2827 [W3C.REC-xml-names-20091208] and XML schemas 2828 [W3C.REC-xmlschema-1-20041028] conforming to a registry mechanism 2829 described in [RFC3688]. 2831 Registration request for the grc-exchange namespace: 2833 URI: urn:ietf:params:xml:ns:grc-exchange-1.0 2835 Registrant Contact: See the "Author's Address" section of this 2836 document. 2838 XML: None. Namespace URIs do not represent an XML specification. 2840 Registration request for the grc-exchange XML schema: 2842 URI: urn:ietf:params:xml:schema:grc-exchange-1.0 2844 Registrant Contact: See the "Author's Address" section of this 2845 document. 2847 XML: See Section 4, "GRC-Exchange Schema", of this document. 2849 Request for the specified registry to be created and managed by IANA: 2851 Name of the registry:"XML Schemas Exchanged via GRC-Exchange" 2853 Namespace details: A registry entry for an XML Schema Transferred 2854 via GRC-Exchange consists of: 2856 Schema Name: A short string that represents the schema 2857 referenced. This value is for reference only in the table. 2858 The version of the schema MUST be included in this string to 2859 allow for multiple versions of the same specification to be in 2860 the registry. 2862 Version: The version of the registered XML schema. The version 2863 is a string that SHOULD be formatted as numbers separated by a 2864 '.' (period) character. 2866 Namespace: The namespace of the referenced XML schema. This is 2867 represented in the GRC-Exchange GRCDocument class in the 2868 XMLSchemaID attribute as an enumerated value is represented by 2869 a URN or URI. 2871 Specification URI: A URI [RFC3986] from which the registered 2872 specification can be obtained. The specification MUST be 2873 publicly available from this URI. 2875 Information that must be provided to assign a new value: The above 2876 list of information. 2878 Fields to record in the registry: Schema Name/Version/Namespace/ 2879 Specification URI 2881 Initial registry contents: See section Section 13 2883 Allocation Policy: Expert Review [RFC5226] and Specification 2884 Required [RFC5226]. 2886 The Designated Expert is expected to consult with the MILE (Managed 2887 Incident Lightweight Exchange) working group or its successor if any 2888 such WG exists (e.g., via email to the working group's mailing list). 2889 The Designated Expert is expected to retrieve the XML schema 2890 specification from the provided URI in order to check the public 2891 availability of the specification and verify the correctness of the 2892 URI. An important responsibility of the Designated Expert is to 2893 ensure that the XML schema is appropriate for use in GRC-Exchange. 2895 Request for the specified registry to be created and managed by IANA: 2897 Name of the registry:"GRC-Exchange Enumeration List" 2899 The registry is intended to enable enumeration value additions to 2900 attributes in the grc-exchange XML schema. 2902 Fields to record in the registry: Attribute Name/Attribute Value/ 2903 Description 2905 Initial registry content: none. 2907 Allocation Policy: Expert Review [RFC5226] 2909 The Designated Expert is expected to consult with the mile (Managed 2910 Incident Lightweight Exchange) working group or its successor if any 2911 such WG exists (e.g., via email to the working group's mailing list). 2912 The Designated Expert is expected to review the request and validate 2913 the appropriateness of the enumeration for the attribute. If a draft 2914 specification is associated with the request, it MUST be reviewed by 2915 the Designated Expert. 2917 14. Acknowledgements 2919 Many thanks to colleagues and the Internet community for reviewing 2920 and commenting on the document. 2922 15. Summary 2924 Governance, Risk, and Compliance reports may contain some of the most 2925 sensitive information for a business. Reports may contain the 2926 prioritized risks for the effective management of Business 2927 Operations, IT, Security, Compliance, and Legal departments of an 2928 enterprise. There may be a regulatory or legal requirement to share 2929 information or formatted reports with a regulatory body or other 2930 entities in a legal review. Outsourcing of computer infrastructure 2931 has necessitated the need for service providers to share reports with 2932 tenants or clients to ensure SLAs and agreements on security 2933 requirements are met. Each of these use cases require a secure 2934 method to exchange reports. GRC Report Exchange provides a 2935 standardized method to exchange reports while considering the 2936 security, privacy and policy requirements without relying on the 2937 transport layer for security. Security is provided at the document 2938 level to provide methods to share a report where policy requirements 2939 can be implemented by mapping to technical options and data markers 2940 in the GRC-Exchange protocol. 2942 16. References 2944 16.1. Normative References 2946 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2947 Requirement Levels", BCP 14, RFC 2119, March 1997. 2949 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 2950 Infrastructure Operational Protocols: FTP and HTTP", 2951 RFC 2585, May 1999. 2953 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 2954 Language) XML-Signature Syntax and Processing", RFC 3275, 2955 March 2002. 2957 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2958 Internet: Timestamps", RFC 3339, July 2002. 2960 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2961 January 2004. 2963 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2964 Resource Identifier (URI): Generic Syntax", STD 66, 2965 RFC 3986, January 2005. 2967 [RFC4051] Eastlake, D., "Additional XML Security Uniform Resource 2968 Identifiers (URIs)", RFC 4051, April 2005. 2970 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 2971 for Transport Layer Security (TLS)", RFC 4279, 2972 December 2005. 2974 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2975 (LDAP): Schema for User Applications", RFC 4519, 2976 June 2006. 2978 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 2979 Object Description Exchange Format", RFC 5070, 2980 December 2007. 2982 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2983 Housley, R., and W. Polk, "Internet X.509 Public Key 2984 Infrastructure Certificate and Certificate Revocation List 2985 (CRL) Profile", RFC 5280, May 2008. 2987 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2988 October 2008. 2990 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 2991 Languages", BCP 47, RFC 5646, September 2009. 2993 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 2994 Attribute Certificate Profile for Authorization", 2995 RFC 5755, January 2010. 2997 [RFC5890] Klensin, J., "Internationalized Domain Names for 2998 Applications (IDNA): Definitions and Document Framework", 2999 RFC 5890, August 2010. 3001 [RFC5891] Klensin, J., "Internationalized Domain Names in 3002 Applications (IDNA): Protocol", RFC 5891, August 2010. 3004 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 3005 RFC 6545, February 2012. 3007 [W3C.REC-xml-20081126] 3008 Sperberg-McQueen, C., Yergeau, F., Maler, E., Bray, T., 3009 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth 3010 Edition)", World Wide Web Consortium Recommendation REC- 3011 xml-20081126, November 2008, 3012 . 3014 [W3C.REC-xml-names-20091208] 3015 Hollander, D., Layman, A., Thompson, H., Tobin, R., and T. 3016 Bray, "Namespaces in XML 1.0 (Third Edition)", World Wide 3017 Web Consortium Recommendation REC-xml-names-20091208, 3018 December 2009, 3019 . 3021 [W3C.REC-xmlenc-core-20021210] 3022 Eastlake, D. and J. Reagle, "XML Encryption Syntax and 3023 Processing", World Wide Web Consortium Recommendation REC- 3024 xmlenc-core-20021210, December 2002, 3025 . 3027 [W3C.REC-xmlschema-1-20041028] 3028 Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, 3029 "XML Schema Part 1: Structures Second Edition", World Wide 3030 Web Consortium Recommendation REC-xmlschema-1-20041028, 3031 October 2004, 3032 . 3034 [W3C.REC-xmldsig-core-20080610] 3035 Solo, D., Roessler, T., Reagle, J., Eastlake, D., and F. 3036 Hirsch, "XML Signature Syntax and Processing (Second 3037 Edition)", World Wide Web Consortium Recommendation REC- 3038 xmldsig-core-20080610, June 2008, 3039 . 3041 [W3C.CR-xmldsig-core1-20110303] 3042 Reagle, J., Nystroem, M., Yiu, K., Hirsch, F., Eastlake, 3043 D., Roessler, T., and D. Solo, "XML Signature Syntax and 3044 Processing Version 1.1", World Wide Web Consortium CR CR- 3045 xmldsig-core1-20110303, March 2011, 3046 . 3048 [W3C.WD-xmldsig-bestpractices-20110809] 3049 Datta, P. and F. Hirsch, "XML Signature Best Practices", 3050 World Wide Web Consortium WD WD-xmldsig-bestpractices- 3051 20110809, August 2011, . 3054 [W3C.REC-xpath20-20101214] 3055 Boag, S., Berglund, A., Kay, M., Simeon, J., Robie, J., 3056 Chamberlin, D., and M. Fernandez, "XML Path Language 3057 (XPath) 2.0 (Second Edition)", World Wide Web Consortium 3058 Recommendation REC-xpath20-20101214, December 2010, 3059 . 3061 16.2. Informative References 3063 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 3064 Separated Values (CSV) Files", RFC 4180, October 2005. 3066 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 3067 Considerations for the SHA-0 and SHA-1 Message-Digest 3068 Algorithms", RFC 6194, March 2011. 3070 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 3071 for Internationalized Domain Names in Applications 3072 (IDNA)", RFC 3492, March 2003. 3074 [RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion 3075 Detection Message Exchange Format (IDMEF)", RFC 4765, 3076 March 2007. 3078 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3079 Wu, "Internet X.509 Public Key Infrastructure Certificate 3080 Policy and Certification Practices Framework", RFC 3647, 3081 November 2003. 3083 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3084 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3085 May 2008. 3087 [ISO.8601.2000] 3088 International Organization for Standardization, "Data 3089 elements and interchange formats -- Information 3090 interchange -- Representation of dates and times", 3091 ISO Standard 8601, December 2000. 3093 Authors' Addresses 3095 Kathleen M. Moriarty 3096 EMC Corporation 3097 176 South Street 3098 Hopkinton, MA 3099 United States 3101 Phone: 3102 Email: Kathleen.Moriarty@emc.com 3103 Said Tabet 3104 EMC Corporation 3105 176 South Street 3106 Hopkinton, MA 3107 United States 3109 Phone: 3110 Email: Said.Tabet@emc.com 3112 David Waltermire 3113 National Institute of Standards and Technology 3114 100 Bureau Drive 3115 Gaithersburg, MD 3116 United States 3118 Phone: 3119 Email: david.waltermire@nist.gov