Network Working Group K. Moriarty Internet-Draft S. Tabet Intended status: Standards Track EMC Expires: April 9, 2012 October 7, 2011 GRC Report Exchange draft-moriarty-mile-grc-exchange-01.txt Abstract Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization. GRC reports are increasingly provided in an XML format. This specification defines a common method to securely transport GRC and other XML reports. The defined messaging capability provides policy options and markings in an XML schema, options for confidentiality at the document/report level, and security for the end-to-end communication. XML reports may be shared between service providers and clients, enterprises, or within enterprises. Reports may also be exchanged for official purposes such as business report filings, compliance report filings, and the handling of legal incidents (eWarrant, eDiscovery, etc.) This work is a generalized format derived from the secure exchange of incident information defined by RFC6045-bis, Real-time Inter-network Defense (RID). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 9, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Moriarty & Tabet Expires April 9, 2012 [Page 1] Internet-Draft grc-exchange October 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Normative and Informative . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Report Types . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Communication between Entities . . . . . . . . . . . . . . . . 6 3.1. Inter-network Provider GRC Messaging . . . . . . . . . . . 6 3.2. GRC Report Exchange Communication Topology . . . . . . . . 7 3.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 7 3.4. GRC Report Exchange Data Types . . . . . . . . . . . . . . 7 3.4.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. GRC Report Exchange Message Types . . . . . . . . . . . . 8 4. GRC-Exchange Schema . . . . . . . . . . . . . . . . . . . . . 8 4.1. GRCPolicy Class . . . . . . . . . . . . . . . . . . . . . 11 4.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 17 4.3. ReportSchema . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Reference Class . . . . . . . . . . . . . . . . . . . . . 20 4.5. GRC-Exchange Name Spaces . . . . . . . . . . . . . . . . . 21 5. Extending the Enumerated Values of Attributes . . . . . . . . 21 6. GRC Report Exchange Messages . . . . . . . . . . . . . . . . . 22 6.1. RequestAuthorization . . . . . . . . . . . . . . . . . . . 22 6.2. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. ReportRequest . . . . . . . . . . . . . . . . . . . . . . 24 6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.5. ReportQuery . . . . . . . . . . . . . . . . . . . . . . . 26 7. GRC-Exchange Communication Flows . . . . . . . . . . . . . . . 27 7.1. Report Communication Flow . . . . . . . . . . . . . . . . 27 7.1.1. GRC-Exchange Report Example . . . . . . . . . . . . . 27 7.2. Report Request Communication Flow . . . . . . . . . . . . 28 7.2.1. ReportRequest Example . . . . . . . . . . . . . . . . 28 7.2.2. RequestAuthorization Message Example . . . . . . . . . 28 7.3. ReportQuery Communication Flow . . . . . . . . . . . . . . 29 7.3.1. ReportQuery Example . . . . . . . . . . . . . . . . . 29 7.3.2. RequestAuthorization Message Example . . . . . . . . . 30 7.3.3. Result Message Example . . . . . . . . . . . . . . . . 30 8. GRC-Exchange Schema Definition . . . . . . . . . . . . . . . . 30 Moriarty & Tabet Expires April 9, 2012 [Page 2] Internet-Draft grc-exchange October 2011 9. Requirements for GRC XML Schemas for GRC-Exchange . . . . . . 31 10. Security Requirements . . . . . . . . . . . . . . . . . . . . 32 10.1. XML Digital Signatures and Encryption . . . . . . . . . . 32 10.2. Message Transport . . . . . . . . . . . . . . . . . . . . 35 10.3. Message Delivery Protocol - Integrity and Authentication . . . . . . . . . . . . . . . . . . . . . . 35 10.4. Transport Communication . . . . . . . . . . . . . . . . . 36 10.5. Authentication of The GRC Report Exchange Protocol . . . . 37 10.5.1. Multi-Hop Authentication . . . . . . . . . . . . . . . 38 10.6. Consortiums and Public Key Infrastructures . . . . . . . . 38 10.7. Privacy Concerns and System Use Guidelines . . . . . . . . 39 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 14.1. Normative References . . . . . . . . . . . . . . . . . . . 43 14.2. Informative References . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Moriarty & Tabet Expires April 9, 2012 [Page 3] Internet-Draft grc-exchange October 2011 1. Introduction Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization. The areas typically covered by GRC include: o Finance and Business Operations, o Information Technology, o Security, and o Legal and Compliance GRC Report Exchange provides a secure method to communicate incident information, enabling the exchange of GRC extensible markup language (XML) documents. GRC Report Exchange considers security, policy, and privacy issues related to the exchange of potentially sensitive information, enabling organizations accepting GRC report filings, service providers, or enterprises the options to make appropriate decisions according to their policies. GRC Report Exchange includes provisions for confidentiality, integrity, and authentication. The data in GRC reports to be included in GRC Report Exchange are represented in an XML [XML1.0] document using the appropriate XML schema for the GRC report and the GRC Report Exchange schema. By following this model, a single method for all GRC reports can be used, simplifying the integration of GRC reports across platforms. Security and privacy considerations are of high concern since potentially sensitive information may be passed through GRC Report Exchange messages. GRC Report Exchange takes advantage of XML security and privacy policy information set in the GRC Report Exchange schema and provides standard settings for fine grain controls within GRC XML schemas. The GRC Report Exchange schema acts as an XML envelope to support the communication of GRC report documents. GRC Report Exchange messages are encapsulated for transport, which is defined in a separate document [RFC6046] [RFC6046]. The authentication, integrity, and authorization features GRC Report Exchange and RID transport offer are used to achieve a necessary level of security. GRC report exchange is not strictly a technical problem. There are numerous procedural, trust, and legal considerations that might prevent an organization from sharing information. GRC Report Exchange provides information and options that can be used by organizations who must then apply their own policies for sharing information. Organizations must develop policies and procedures for Moriarty & Tabet Expires April 9, 2012 [Page 4] Internet-Draft grc-exchange October 2011 the use of the GRC Report Exchange protocol and XML reports. 1.1. Normative and Informative The XML schema [XMLschema] and transport requirements contained in this document are normative; all other information provided is intended as informative. More specifically, the following sections of this document are intended as informative: Sections XXX. The following sections of this document are normative: Sections XXXX. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Report Types There are many possible report types that may be exchanged using GRC Report Exchange. The reports MUST all be XML formatted reports and MAY leverage the data markings used by this specification to require security options such as encryption on the entire report (XML document) or a section of the report. The types of reports may vary within each area of GRC. Example report types broken out by GRC focus areas include: o Finance and Business Operations * Finance or business Filing Report o Information Technology * Service Level Agreement (SLA) Reports from service providers (public cloud providers, community cloud providers, etc.) o Security * Security Report aligned to control requirements (ISO27002, NIST 800-53, etc.) from service providers o Legal and Compliance * eDiscovery Reports * eWarrant Reports Moriarty & Tabet Expires April 9, 2012 [Page 5] Internet-Draft grc-exchange October 2011 * Compliance report aligned to specific regulations * Report for internal or external audit aligned to risk and control frameworks (ISO27002, NIST 800-53, COSO, COBIT, etc.) 3. Communication between Entities Trust relationships. Service provider to tenant or client is the ms likely scenario for the initial use cases of GRC report exchange. 3.1. Inter-network Provider GRC Messaging GRC Report Exchange provides a standard protocol and format is required to ensure inter-operability between vendors for the exchange of GRC reports and GRC filing of reports. GRC Report Exchange provides the framework necessary for communication between entities filing or exchanging GRC reports. Several message types described in Section 5 are necessary to facilitate the exchange or filing of reports. The message types include the Report, ReportQuery, RequestAuthorization, Result, and the ReportRequest request message. The Report message is used when a GRC report is to be filed on a system or associated database accepting GRC Report Exchange messages, where no further action is required. A ReportQuery message is used to request information on a particular report. The RequestAuthorization and Report messages are used to communicate the status and result of a ReportQuery or ReportRequest request. Use of the communication network and the GRC Report Exchange protocol must be for pre-approved, authorized purposes only. It is the responsibility of each participating party to adhere to guidelines set forth in both a global use policy established through the peering agreements for each bilateral peer or agreed-upon consortium guidelines. The purpose of such policies is to avoid abuse of the system; the policies shall be developed by a consortium of participating entities. The global policy may be dependent on the domain it operates under; for example, a government network or a commercial network such as the Internet would adhere to different guidelines to address the individual concerns. Privacy issues must be considered in public networks such as the Internet. Privacy issues are discussed in the Security Requirements section, along with other requirements that must be agreed upon by participating entities. The GRC Report Exchange system should be configurable to either require user input or automatically provide or file reports. If the trust relationship is not strong, it may not be in the peer's best Moriarty & Tabet Expires April 9, 2012 [Page 6] Internet-Draft grc-exchange October 2011 interest to accept a report or respond to a request. The trust relationship may be noted in a confidence rating based on relationships and experience working with peers. The confidence ratings must adhere to specifications for selecting the percentage used to avoid abuse of the system. 3.2. GRC Report Exchange Communication Topology The most basic topology for communicating GRC Report Exchanges is a direct connection or a bilateral relationship as illustrated below. ______________ _____________ | | | | | GRC-RE |_____________________| GRC-RE | |____________| |___________| Figure 1: Direct Peer Topology A star topology may be desirable in instances where a peer may be a provider of GRC Reports. This requires trust relationships to be established between the provider of information and each of the consumers of that information. Examples may include clients that file compliance or business reports to an authoritative entity. The examples provided serve as an initial baseline set of expected topologies that may change over time. 3.3. Message Formats Section 5 describes the five GRC Report Exchange message types, to be used with the appropriate XML documents. The messages are generated and received on designated systems for GRC report exchanges. 3.4. GRC Report Exchange Data Types GRC Report Exchange is derived from the RID and IODEF data models and inherits all of the data types defined in those models. 3.4.1. Boolean A boolean value is represented by the BOOLEAN data type. The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in the schema. This Section will be expanded when the schema is further finalized Moriarty & Tabet Expires April 9, 2012 [Page 7] Internet-Draft grc-exchange October 2011 3.5. GRC Report Exchange Message Types The five GRC Report Exchange message types are as follows: 1. RequestAuthorization. This message is sent to the requestor of a report (ReportRequest) or in response to a ReportQuery to notify on the state of a request (approved, pending, not approved). 2. Result. This message is sent to the requestor of a GRC report (ReportRequest) or in response to ReportQuery. The Result may contain the full report requested or a section of the report as appropriate for the request in the ReportQuery. 3. ReportRequest. This message type is used to request a specific type of GRC report. The ReportRequest MUST specify the XML schema and version for the requested report along with any other parameters required in the XML schema to generate the correct report. 4. Report. This message is used to provide a GRC Report. The message can be considered a wrapper for any approved GRC schema used to format a report for submission. 5. ReportQuery. This message is used to request information about a specific GRC report. The XML schema and version used MUST be specified along with any details required to provide the proper Report response. The response is provided through the Report message. When an application receives a GRC Report Exchange message, it must be able to determine the type of message and parse it accordingly. The message type is specified in the GRCPolicy class. The GRCPolicy class may also be used by the transport protocol to facilitate the secure communication of the GRC Report Exchange. 4. GRC-Exchange Schema There are three classes included in the GRC Report Exchange schema required to facilitate communications. The RequestStatus class is used to indicate the approval status of a ReportRequest or ReportQuery; the ReportSchema class identifies the XML schema to be used by the provided or requested report; and the GRCPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used. The GRC Report Exchange schema acts as an envelope for the GRC XML schema to facilitate secure GRC report communications. The intent in Moriarty & Tabet Expires April 9, 2012 [Page 8] Internet-Draft grc-exchange October 2011 maintaining a separate schema is for the flexibility of sending messages between participating entities. Since GRC-Exchange is a separate schema that includes the appropriate GRC XML schema, the GRC-Exchange information acts as an envelope, and then the GRCPolicy class can be easily extracted for use by the transport protocol. The security requirements of sending GRC reports and associated information on finance, IT operations, legal, compliance, and security across the network include the use of confidentiality (encryption prior to the transport level), authentication (potentially multi-hop), integrity, and non-repudiation. GRCPolicy uses labels that correspond to policy and agreements to standardize on handling requirements such as encryption and sharing limitations. The GRCPolicy information should not be encrypted, hence GRC-Exchange is maintained separate from the GRC XML schema used to send or request a report. This segregation enables flexibility for GRC- Exchange to be used with any GRC XML schema and removes the need for decrypting and parsing the entire GRC Report and GRC-Exchange document to determine how it should be handled at each entity communicating via GRC-Exchange. The purpose of the GRCPolicy class is to specify the message type for the receiving host, facilitate the policy needs of GRC Reports, and provide routing information in the form of an IP address of the destination entity accepting GRC-Exchange messages. The policy information and guidelines are discussed in Section 9.7. The policy is defined between GRC-Exchange peers and within or between consortiums. The GRCPolicy is meant to be a tool to facilitate the defined policies. This MUST be used in accordance with policy set between clients, peers, consortiums, and/or regions. Security, privacy, and confidentiality MUST be considered as specified in this document. The GRC-Exchange schema is defined as follows: +------------------+ | GRC-Exchange | +------------------+ | ANY | | |<>---{0..1}----[ GRCPolicy ] | ENUM restriction | | |<>---{0..1}----[ RequestStatus ] | STRING meaning | | |<>---{0..1}----[ ReportSchema ] +------------------+ Figure 2: The GRC-Exchange Schema Moriarty & Tabet Expires April 9, 2012 [Page 9] Internet-Draft grc-exchange October 2011 The aggregate classes that constitute the GRC-Exchange schema in the grc-exchange namespace are as follows: GRCPolicy Zero or One. The GRCPolicy class is used by all message types to facilitate policy agreements between peers, consortiums, or federations, as well as to properly route messages. RequestStatus Zero or One. The RequestStatus class is used only in RequestAuthorization messages to report back to the entity requesting a report or sending a ReportQuery if the request is denied or remains in a pending state. ReportSchema Zero or One. The ReportSchema class is used in each of the message types to state the XML schema and version for the included XML report, XML report request, or response. The GRC-Exchange class defines two attributes as follows: restriction Optional. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere for the information represented in this class and its children. This guideline provides no security since there are no specified technical means to ensure that the recipient of the document handles the information as the sender requested. The value of this attribute is logically inherited by the children of this class. That is to say, the disclosure rules applied to this class, also apply to its children. It is possible to set a granular disclosure policy, since all of the high-level classes (i.e., children of the Incident class) have a restriction attribute. Therefore, a child can override the guidelines of a parent class, be it to restrict or relax the disclosure rules (e.g., a child has a weaker policy than an ancestor; or an ancestor has a weak policy, and the children selectively apply more rigid controls). The implicit value of the restriction attribute for a class that did not specify one can be found in the closest ancestor that did specify a value. Moriarty & Tabet Expires April 9, 2012 [Page 10] Internet-Draft grc-exchange October 2011 This attribute is defined as an enumerated value with a default value of "private". Note that the default value of the restriction attribute is only defined in the context of the Incident class. In other classes where this attribute is used, no default is specified. This attribute is derived from IODEF [RFC5070] and fully included within this schema. 1. public. There are no restrictions placed in the information. 2. need-to-know. The information may be shared with other parties that are involved in the incident as determined by the recipient of this document (e.g., multiple victim sites can be informed of each other). 3. private. The information may not be shared. 4. default. The information can be shared according to an information disclosure policy pre-arranged by the communicating parties. meaning Optional. STRING. A free-form description of the element content. Each of the three listed classes may be the only class included in the GRC-Exchange class, hence the option for zero or one. In some cases, GRCPolicy MAY be the only class in the GRC-Exchange definition when used by the transport protocol [RFC6046], as that information should be as small as possible and may not be encrypted. The RequestStatus message MUST be able to stand alone without the need for an GRC XML document to facilitate the communication, limiting the data transported to the required elements per [RFC6046]. 4.1. GRCPolicy Class The GRCPolicy class facilitates the delivery of GRC Report Exchange messages. Moriarty & Tabet Expires April 9, 2012 [Page 11] Internet-Draft grc-exchange October 2011 +------------------------+ | GRCPolicy | +------------------------+ | | | ENUM restriction |<>-------------[ Node ] | ENUM MsgType | | ENUM MsgDestination |<>---{1..*}----[ Contact ] | ENUM ext-MsgType | | ENUM ext-MsgDestination|<>---{0..1}----[ ReportID ] | | | |<>---{1..*}----[ PolicyRegion ] | | | |<>---{1..*}----[ ReportType ] +------------------------+ Figure 3: The GRCPolicy Class The aggregate elements that constitute the GRCPolicy class are as follows: Node One. The Node class is used to identify a host or network device, in this case to identify the system communicating GRC-Exchange messages. The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16. This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema. Contact One or more. Contact information for the parties involved in the GRC Report Exchange. This definition is from the IODEF specification [RFC5070], Section 3.7. This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema. ReportID Zero or one. Global reference pointing back to the ReportID defined in the GRC XML data model. The ReportID includes the domain name of the entity who creates the report, a report number, and an instance of that report number. The default report number is a date, where the requested report is the most recent report on or prior to the date specified. The format for the date SHALL be YYYYMMDD, where Y is the year, M is the month, and D is the day. The instance number is appended with a dash separating the values and is used in cases for which there may be multiple reports Moriarty & Tabet Expires April 9, 2012 [Page 12] Internet-Draft grc-exchange October 2011 issued in a day. The format for the instance SHALL be HHMMSS, where H is the hour as specified in a 24hour range, M is the minute, S is the second provided in GMT. An alternate ID may be specified within the GRC XML schema for the specific report. PolicyRegion One or many. REQUIRED. The values for the attribute "region" are used to determine what policy area may require consideration before a trace can be approved. The PolicyRegion may include multiple selections from the attribute list in order to fit all possible policy considerations when crossing regions, consortiums, or networks. region One. ENUM. 1. ClientToSP. An enterprise initiated the request to their service provider. 2. SPToClient. An service provider passed a GRC request or report to a client or an enterprise based on requested services or service level agreements. 3. IntraConsortium. GRC report information that should have no restrictions within the boundaries of a consortium with the agreed-upon use and abuse guidelines. 4. PeerToPeer. GRC report information that should have no restrictions between two peers but may require further evaluation before continuance beyond that point with the agreed-upon use and abuse guidelines. 5. BetweenConsortiums. GRC report information that should have no restrictions between consortiums that have established agreed-upon use and abuse guidelines. 6. AcrossNationalBoundaries. This selection must be set if the message type will cross national boundaries. There could be instances of reports or report requests where that may not be known in advance, but should be known at the instance where boundaries are crossed during the communication exchange. This must also be set if the security requirements of the request is based upon regulations of a specific nation that may not apply to all nations. The stricter requirements should be upheld. This is different from the "BetweenConsortiums" setting since it may be possible to have Moriarty & Tabet Expires April 9, 2012 [Page 13] Internet-Draft grc-exchange October 2011 multiple nations as members of the same consortium, and this option must be selected if the report information may have different restrictions in other nations. 7. LawEnforcement. This option is used when GRC information is exchanged with LawEnforcement, local government, or other authorities requesting or receiving a report. Examples may include eDiscovery or eWarrant use cases. If the law enforcement agency resides within a different nation that the sending entity, the "AcrossNationalBoundaries" enumeration MUST also be set. 8. ext-value. An escape value used to extend this attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. ReportType One or many. REQUIRED. The values for the attribute "type" are meant to assist in determining if a report or report request is appropriate for the entity receiving the request or report. Multiple values may be selected for this element; however, where possible, it should be restricted to one value that most accurately describes the report type. type One. ENUM. 1. Filing. This ReportType is used when a GRC report is included for expected filing purposes. Examples may include the filing of a regulatory or business operations report to a regulatory body. 2. Service Level Agreement. This option specifies the report type as a report on a service level agreement. This report may be sent from a service provide (SP) to a tenant or client or from a trust authority to a requesting entity. An SLA report may be associated with any report format (XML) associated with an SLA agreement, including but not limited to an IT or security report. 3. Operational. An operational report may include any standard operating reports used within or between businesses or enterprises. This may be a routine business, IT operational, or other type of report. Moriarty & Tabet Expires April 9, 2012 [Page 14] Internet-Draft grc-exchange October 2011 4. Compliance. A compliance report is specified when there is a specific compliance report format required (as specified by the schema used for the report). This type may be used for internal or external compliance report exchanges. 5. Audit. The Audit report type is distinguished from a compliance report as the report contents may vary depending on the report or report request in the exchange. An audit report may take an approach of only providing the state of compliance or details of findings from an automated control review. 6. RiskAssessment. A RiskAssessment report differs from the Compliance and Audit reports in that the report may prioritize risks as specified in the XML schema and may include GRC-XML risk ratings. A RiskAssessment may be provided for any GRC area or on the GRC program as specified by the ReportSchema. 7. OfficialBusiness. This option MUST be used if the GRC information is requested by or affiliated with any government or other official business request. This could be used during an investigation for an eDiscovery, eWarrant, or other use case. 8. Other. If this option is selected, a description of the request MUST be provided so that policy decisions can be made to proceed with the request or act upon the report. The information should be provided in the GRC-Exchange class meaning attribute. 9. ext-value. An escape value used to extend this attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. The GRCPolicy class has five attributes: restriction OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF and is explained in the GRCPolicy Class description. MsgType Moriarty & Tabet Expires April 9, 2012 [Page 15] Internet-Draft grc-exchange October 2011 REQUIRED. ENUM. The type of GRC-Exchange message sent. The five types of messages are described in Section 5 and can be noted as one of the five selections below. 2. RequestAuthorization. This message is sent to the initiating GRC-Exchange entity if a ReportRequest or ReportQuery has been denied or is pending. 3. Result. This message provides the result of a ReportQuery. 4. ReportRequest. The purpose of the ReportRequest is to request a report from an entity. 5. Report. This message is used to provide a GRC XML report. 6. ReportQuery. This message is used to request information either about a specific report or group of reports. The actual query is specified in the GRC XML Schema and is outside the scope of this specification. Additionally, there is an extension attribute to add new enumerated values: ext-value. An escape value used to extend this attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. MsgDestination REQUIRED. ENUM. The destination required at this level may either be the system accepting GRC report exchange requests or reports. The Node element lists the address of the host receiving the GRC-Exchange message. 1. GRCSystem. The address listed in the Node element of the GRCPolicy class is the GRC-Exchange system that will receive the message. 2. ext-value. An escape value used to extend this attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. MsgType-ext OPTIONAL. STRING. A means by which to extend the MsgType attribute. This attribute has been derived from IODEF Moriarty & Tabet Expires April 9, 2012 [Page 16] Internet-Draft grc-exchange October 2011 [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. MsgDestination-ext OPTIONAL. STRING. A means by which to extend the MsgDestination attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. 4.2. RequestStatus The RequestStatus class is an aggregate class in the GRC-Exchange class. +--------------------------------+ | RequestStatus | +--------------------------------+ | | | ENUM restriction | | ENUM AuthorizationStatus | | ENUM Justification | | STRING ext-AuthorizationStatus | | STRING ext-Justification | | | +--------------------------------+ Figure 4: The RequestStatus Class The RequestStatus class has five attributes: restriction OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF and is explained in the GRCPolicy Class description. AuthorizationStatus REQUIRED. ENUM. The listed values are used to provide a response to the requesting entity of the ReportRequest or ReportQuery. 1. Approved. The request was approved and will be provided. The approved message MAy be sent if there will be a delay Moriarty & Tabet Expires April 9, 2012 [Page 17] Internet-Draft grc-exchange October 2011 in providing the report, otherwise, the Report or Result MAY be provided without sending a RequestAuthorization message. 2. Denied. The request has been denied. 3. Pending. Awaiting approval; a timeout period has been reached, which resulted in this Pending status and RequestAuthorization message being generated. 4. ext-value. An escape value used to extend this attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. Justification OPTIONAL. ENUM. Provides a reason for a Denied or Pending message. 2. SystemResource. A resource issue exists on the systems that would be involved in the request. 3. Authentication. The enveloped digital signature [RFC3275] failed to validate. 4. AuthenticationOrigin. The detached digital signature for the original requestor on the RecordItem entry failed to validate. 5. Encryption. Unable to decrypt the request. 6. Other. There were other reasons this request could not be processed. 7. ext-value. An escape value used to extend this attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. AuthorizationStatus-ext OPTIONAL. STRING. A means by which to extend the AuthorizationStatus attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. Moriarty & Tabet Expires April 9, 2012 [Page 18] Internet-Draft grc-exchange October 2011 Justification-ext OPTIONAL. STRING. A means by which to extend the Justification attribute. This attribute has been derived from IODEF [RFC5070], Section 5.1 and is explained in Section 5, Extending the Enumerated Values of Attributes. 4.3. ReportSchema The ReportSchema class is an aggregate class in the GRC-Exchange class. +-------------------+ | ReportSchema | +-------------------+ | | | STRING Version | | ENUM GRCSchemaID |<>---{1..*}----[ GRCSchema ] | ENUM restriction | | |<>---{0..*}----[ Reference ] | | +-------------------+ Figure 5: The ReportSchema Class The elements that constitute the ReportShema class are as follows: GRCSchema One or more. EM_XML. The GRCSchema is a complete XML document formatted according to the specification identified in the attributes of this class. Reference OPTIONAL. One. A reference to the XML schema types included for the exchange. The Reference class is derived from IODEF [RFC5070] and fully included within this specification to avoid the need for including the IODEF schema. The ReportSchema class has three attributes: Version REQUIRED. One. The Version attribute is the version number of the specified XMLSchema. Moriarty & Tabet Expires April 9, 2012 [Page 19] Internet-Draft grc-exchange October 2011 GRCSchemaID REQUIRED. One. The GRCSchemaID attribute is the identifier (ID) of the XMLSchema used to exchange data. The GRCSchemaID and Version specify the format of the GRCSchema element. restriction OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF and is explained in the GRCPolicy Class description. 4.4. Reference Class The Reference class is a reference to the GRC Schema used for the exchange. A reference consists of a name, a URL to this reference, and an optional description. +------------------+ | Reference | +------------------+ | |<>----------[ ReferenceName ] | |<>--{0..*}--[ URL ] | |<>--{0..*}--[ Description ] +------------------+ Figure 6: The Reference Class The aggregate classes that constitute Reference: ReferenceName One. ML_STRING. Name of the reference. URL Zero or many. URL. A URL associated with the reference. Description Zero or many. ML_STRING. A free-form text description of this reference. Moriarty & Tabet Expires April 9, 2012 [Page 20] Internet-Draft grc-exchange October 2011 4.5. GRC-Exchange Name Spaces The GRC-Exchange schema declares a namespace of "grc-exchange-1.0" and registers it per [XMLnames]. Each XXXXX document MUST use the "grc-exchange-1.0" namespace in the top-level element GRC-Exchange- Document. It can be referenced as follows: 5. Extending the Enumerated Values of Attributes In order to support the evolving needs of XML Schema exchanges, some extensibility is built into the GRC Report Exchange protocol. This section discusses how new attributes that have no current representation in the data model can be incorporated into GRC- Exchange. These techniques are designed so that adding new data will not require a change to the schema. With proven value, well documented additions can be incorporated into future versions of the specification. However, this approach also supports private additions relevant only to a closed consortium. The data model supports a means by which to add new enumerated values to an attribute, following the method used in IODEF [RFC5070] for the same purpose. For each attribute that supports this extension technique, there is a corresponding attribute in the same element whose name is identical, less a prefix of "ext-". This special attribute is referred to as the extension attribute, and the attribute being extended is referred to as an extensible attribute. For example, an extensible attribute named "foo" will have a corresponding extension attribute named "ext-foo". An element may have many extensible, and therefore many extension, attributes. In addition to a corresponding extension attribute, each extensible attribute has "ext-value" as one its possible values. This particular value serves as an escape sequence and has no valid meaning. In order to add a new enumerated value to an extensible attribute, the value of this attribute MUST be set to "ext-value", and the new desired value MUST be set in the corresponding extension attribute. For example, an extended instance of the type attribute of the Impact class would look as follows: Moriarty & Tabet Expires April 9, 2012 [Page 21] Internet-Draft grc-exchange October 2011 A given extension attribute MUST NOT be set unless the corresponding extensible attribute has been set to "ext-value". 6. GRC Report Exchange Messages The GRC-Exchange schema is used in combination with GRC XML documents to facilitate GRC Report Exchange communications. Each message type varies slightly in format and purpose; hence, the requirements vary and are specified for each. Note: The implementation of GRC-Exchange may automate the ability to fill in the content required for each message type from the GRC management systems involved in the message exchange. 6.1. RequestAuthorization Description: This message is sent in response to a ReportRequest or a ReportQuery message to provide status as to the approval of a request. The following information is required for RequestAuthorization messages and is provided through: GRC-Exchange Information: GRCPolicy GRC-Exchange message type, ReportID, and destination policy information RequestStatus class: AuthorizationStatus of request Standards for encryption and digital signatures [RFC3275], [XMLsig]: Digital signature of responding entity authenticity of GRC- Exchange Message, from the entity creating this message using an enveloped XML digital signature. XML encryption as required by policy, agreements, and standard data markers. A pending status is automatically generated after a 5-minute timeout without system predefined or administrator action taken to approve or deny the request. If a request is left in a pending state for more than a configurable period of time (default of 5 minutes), a response Moriarty & Tabet Expires April 9, 2012 [Page 22] Internet-Draft grc-exchange October 2011 is sent to the requestor with the enumeration value set to pending. If a request is denied, the response sets the enumeration value to denied. If the request is approved, but the response will be delayed, a response MAY be sent with the enumerated value set to approved. The approved message is not mandatory, however the pending and denied message types MUST be sent if the conditions are reached. 6.2. Result Description: This message provides the result of an approved ReportQuery. The ReportQuery may be used when a query is made on a group of reports or a request is made for specific details within a report. If a standard report is requested based on a specific XML schema, ReportRequest MUST be used. The details of the ReportQuery will vary depending on the included GRC XML schema. The XML schema may provide specific guidance on how queries are conducted as this specification is intended to provide a generalized structure for many types of GRC information exchanges. The following information is required for Result messages and will be provided through: GRC-Exchange Information: GRCPolicy GRC-Exchange message type, ReportID, and destination policy information ReportSchema The ReportSchema class specifies the specific GRC-Exchange XML schema that is required per the ReportQuery. The Result will include the necessary information to appropriately respond to the request. GRC XML Information: GRC XML schema elements and attributes as appropriate for the ReportQuery. Standards for encryption and digital signatures [RFC3275]: Digital signature of sending entity for authenticity of Result message, from the entity creating this message using an enveloped XML digital signature. Moriarty & Tabet Expires April 9, 2012 [Page 23] Internet-Draft grc-exchange October 2011 XML encryption as required by policy, agreements, and standard data markers. A Result message is sent back to the requesting entity of a ReportQuery. This will include the results of the query using the appropriate XML schema named in the request. Details of what standard queries are automated in addition to the standard responses are to be detailed by the appropriate GRC communities (GRC-XML, LI- XML, etc.) in guidance documents associated with each of the relevant schemas. 6.3. ReportRequest Description: The ReportRequest is used to request a report in a standardized format using the referenced XML schema in the ReportSchema class. The report requested will be the most recent report to the date and time requested. The following information is required for ReportRequest messages and is provided through: GRC-Exchange Information: GRCPolicy GRC-Exchange message type, ReportID, and destination policy information GRC XML Information: GRC XML schema elements and attributes as appropriate for the ReportRequest. Standards for encryption and digital signatures [RFC3275]: Digital signature from initiating entity sending the GRC- Exchange message using a detached XML digital signature on the GRC-Exchange information. Digital signature of requesting entity for authenticity of the GRC-Exchange message, from the entity sending this message using an enveloped XML digital signature on the included GRC- XML document document. XML encryption as required by policy, agreements, and data markers. Security requirements include the ability to encrypt [XMLencrypt] the Moriarty & Tabet Expires April 9, 2012 [Page 24] Internet-Draft grc-exchange October 2011 contents of the ReportRequest message using the public key of the destination entity communicating via GCR-Exchange. If no report is available for the exact date and time in the request, the most recent report details prior to the date requested will be provided. If there is no report to provide per the specified date and time, the RequestAuthorization message will be sent instead setting the AuthorizationStatus to denied and providing the appropriate reason for the deny. 6.4. Report Description: This message is used to provide a report using a specified GRC XML schema. This message does not require any actions to be taken, except to file the report on the receiving system or associated database. This message may be in response to a ReportRequest or sent as a regularly scheduled report. The following information is required for Report messages and will be provided through: GRC-Exchange Information: GRCPolicy GRC-Exchange message type, ReportID, and destination policy information The following data is recommended if available and can be provided through: GRC XML Information: GRC XML schema elements and attributes as appropriate for the ReportRequest. Standards for encryption and digital signatures [RFC3275]: Digital signature from initiating entity, passed to all systems receiving the report using an enveloped XML digital signature. XML encryption as required by policy, agreements, and standard data markers. Security requirements include the ability to encrypt [XMLencrypt] the contents of the Report message using the public key of the destination entity. Senders of a Report message should note that the information may be used to correlate information for the purpose of trending, pattern detection, etc., and may be shared with other parties unless otherwise agreed upon with the receiving entity in an established contract or agreement. Therefore, sending parties of a Moriarty & Tabet Expires April 9, 2012 [Page 25] Internet-Draft grc-exchange October 2011 Report message may obfuscate or remove sensitive information before sending a Report message. A Report message may be sent either to file a report or in response to an ReportRequest, and data sensitivity must be considered in both cases. 6.5. ReportQuery Description: The ReportQuery message is used to request information from a trusted entity participating in GRC-Exchanges. The request can include the ReportID number, if known, or detailed information about the report or group of reports applicable to the query. The following information must be used for a ReportQuery message and is provided through: GRC-Exchange Information: GRCPolicy GRC-Excahnge message type, ReportID, and destination policy information GRC XML information (optional): GRC XML schema elements and attributes as appropriate for the ReportQuery. Standards for encryption and digital signatures [RFC3275]: Digital signature from the entity initiating the GRC-Excahnge message, passed to all systems receiving the ReportQuery using an enveloped XML digital signature. XML encryption as required by policy, agreements, and standard data markers. The proper response to the ReportQuery message is a Result message. Security requirements include the ability to encrypt [XMLencrypt] the contents of the ReportRequest message using the public key of the destination entity communicating via GCR-Exchange. If no report is available for the exact date and time in the request, the most recent report details prior to the date requested will be provided. If there is no report to provide per the specified date and time, the RequestAuthorization message will be sent instead setting the AuthorizationStatus to denied and providing the appropriate reason for the deny. Moriarty & Tabet Expires April 9, 2012 [Page 26] Internet-Draft grc-exchange October 2011 7. GRC-Exchange Communication Flows The following section outlines the communication flows for GRC- Exchange and also provides examples of messages. 7.1. Report Communication Flow The diagram below outlines the communication flow for a GRC-Exchange Report message sent from one entity to another. This communication flow is the simplest as no response is required. The Report may be a regularly scheduled report filing. Sending Entity Receiving Entity 1. Generate Report message 2. o----------Report----------> 3. Receive and process report No Response Figure 7: GRC-Exchange Report Communication Flow The Report message MAY be encrypted [XMLencrypt] for the recipient of the report depending upon the markers included in the restriction class either in the GRC-Exchange schema or in the GRC XML schema used for the report. When a report is received, the the receiving entity must verify that the report has not already been filed. The ReportID and other distinguishing information in the specific report type can be used to compare with existing database entries. The Report message typically does not have a response. . 7.1.1. GRC-Exchange Report Example The example listed is of a Report based on ... In the following example, use of [XMLsig] to generate digital signatures does not currently provide digest algorithm agility, as [XMLsig] only supports SHA-1. A future version of [XMLsig] may support additional digest algorithms to support digest algorithm agility. Example to be provided in an updated version of this document. Moriarty & Tabet Expires April 9, 2012 [Page 27] Internet-Draft grc-exchange October 2011 7.2. Report Request Communication Flow The diagram below outlines the GRC-Exchange report request communication flow between participating entities. The proper response to a ReportRequest is a Report message. If there is a problem with the request, such as a failure to validate the digital signature or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed. Sending Entity Receiving Entity 1. Generate ReportRequest 2. o----ReportRequest--------> 3. Receive and process request 4. If denied or pending, send notice 5. <---RequestAuthorization---o 6. If request is approved, 7. <----------Report----------o Figure 8: ReportRequest Communication Flow 7.2.1. ReportRequest Example The following example of the ReportRequest is based on the ReportID time-based identifier tied to the specified GRC XML ReportSchema. Example to be provided in an updated version of this document. 7.2.2. RequestAuthorization Message Example The example RequestAuthorization message is in response to the ReportRequest listed above. The entity that received the request was unable to validate the digital signature used to authenticate the sending RID system. Example to be provided in an updated version of this document. Moriarty & Tabet Expires April 9, 2012 [Page 28] Internet-Draft grc-exchange October 2011 An example Report has been provided in the previous section. No Report message would be provided in this example as a result of the denied request. 7.3. ReportQuery Communication Flow The diagram below outlines the GRC-Exchange ReportQuery communication flow between participating entities. Sending Entity Receiving Entity 1. Generate ReportQuery 2. o------ReportQuery--------> 3. Receive and process request 4. If denied or pending, send notice 5. <---RequestAuthorization---o 6. If request approved 7. <----------Result----------o Figure 9: ReportQuery Communication Flow The ReportQuery communication flow is used to request specific information about a GRC report or group of reports. Information may be shared between participating entities using this format. If there is a problem with the ReportQuery message, such as a failure to validate the digital signature [RFC3275] or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed. 7.3.1. ReportQuery Example The following example includes the GRC-Exchange information and an example query using an included XML schema, which is also referenced in the ReportSchema class. Example to be provided in an updated version of this document. Moriarty & Tabet Expires April 9, 2012 [Page 29] Internet-Draft grc-exchange October 2011 7.3.2. RequestAuthorization Message Example The example RequestAuthorization message is in response to the ReportQuery message listed above. The entity that received the request is responding with an answer to the ReportQuery. The Result in this instance will be delayed for more than the 5-minute default time period, hence a RequestAuthorization message is sent to notify of the approval status. Example to be provided in an updated version of this document. 7.3.3. Result Message Example The example Result message is in response to the ReportQuery request. This message type may be preceded by a RequestAuthorization within the ReportQuery flow of messages. It may be a direct response to an ReportQuery request if the request is approved prior to the timeout period. This message provides a response to the request in the ReportQuery. Example to be provided in an updated version of this document. 8. GRC-Exchange Schema Definition Moriarty & Tabet Expires April 9, 2012 [Page 30] Internet-Draft grc-exchange October 2011 *** Schema to be included here *** 9. Requirements for GRC XML Schemas for GRC-Exchange GRC Report Exchange is a generalized version of the Real-time Inter- network Defense (RID) [RFC6045-bis] protocol. RID leverages certain aspects of the Incident Object Description Exchange Format (IODEF) [RFC5070] schema to provide the necessary security features such as confidentiality and integrity required for the exchange of potentially sensitive information. In generalizing RID into a schema and set of message exchange flows for GRC reports, the GRC XML schemas MUST include the following classes, elements, and enumerations to facilitate the automated security and confidentially fears of GRC Report Exchange. A GRC XML schema within this document may refer to any type of XML schema used for Governance, Risk, and Compliance information or reporting. Examples include, but are not limited to GRC-XML, LI-XML, and security automation XML schemas. Moriarty & Tabet Expires April 9, 2012 [Page 31] Internet-Draft grc-exchange October 2011 The restriction attribute, reused from IODEF [RFC5070] into GRC- Exchange, MUST be included in any individual class of a GRC XML schema that could require XML encryption [XMLencrypt] just on the data contained in that class. If encryption is only required at the full document level based on the sensitivity and sharing requirements, the restriction attribute in GRC-Exchange may be sufficient. 10. Security Requirements 10.1. XML Digital Signatures and Encryption GRC-Exchange leverages existing security standards and data markings in GRCPolicy to achieve the required levels of security for the exchange of GRC information. The use of standards include TLS and the XML security features of encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig]. The standards provide clear methods to ensure that messages are secure, authenticated, and authorized, and that the messages meet policy and privacy guidelines and maintain integrity. As specified in the relevant sections of this document, the XML digital signature [RFC3275] and XML encryption [XMLencrypt] are used in the following cases: XML Digital Signature o The originator of the ReportRequest or ReportQuery MUST use an enveloped signature to sign the included GRC XML document. The enveloped digital signature provides authentication to all participants receiving the original Report or a forwarded Report. If the Report details could change, the XML digital signature specification [XMLsig] MUST be followed to specify what elements may be changed within the signed document to allow the signature to be validated. If the GRC XML document is changed within the allowed parameters, the entity including the changes MUST digitally sign [XMLsig] the updated document, while including the original detached signature. This signature MUST be passed to all recipients of the Report or Result. If this option is used, the implementation MUST follow the guidance specified in the XML Digital Signature [XMLsig] specification for two or more enveloped signatures. o For all message types, the full GRC XML and GRC-Exchange document MUST be signed using an enveloped signature by the sending peer to provide authentication and integrity to the receiving entity. Moriarty & Tabet Expires April 9, 2012 [Page 32] Internet-Draft grc-exchange October 2011 XML Encryption o The GRC XML and GRC-Exchange document may be encrypted to provide an extra layer of security between peers so that the message is not only encrypted for the transport, but also while stored. This behavior would be agreed upon between peers or a consortium, or determined on a per-message basis, depending on security requirements. It should be noted that there are cases for transport where the GRCPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6046-bis]. o A Report, Result, or any other message type that may be relayed through multiple entities may be in part of whole encrypted for a set of intended recipients. This may be necessary if some parties receiving the XML document require full access based on need-to- know requirements and some only require access to a portion of the XML document. In cases such as this, the GRC-Exchange information is maintained in clear text while the appropriate portions of the XML document are encrypted. o The restriction attribute sets expectations for the privacy of an XML document and is defined in section 3.2 of RFC5070. Following the guidance for XML encryption in the Security Requirements Section, the restriction attribute can be set in any of the GRC- Exchange classes to define restrictions and encryption requirements for the exchange of GRC information. The restriction options enable encryption capabilities for the complete exchange of a GRC XML document, within specific classes of the GRC XML schema where more limited restrictions are desired. The restriction attribute is contained in each of the GRC-Exchange classes and MUST be used in accordance with confidentiality expectations for either sections of the GRC XML document or the complete GRC XML document. Consortiums and organizations should consider this guidance when creating exchange policies. o Expectations based on restriction setting: * If restriction is set to "private", the class or document MUST be encrypted for the recipient using XML encryption and the public key of the recipient. The use of PKI between entities SHOULD adhere to any applicable certificate policy and practices agreements for the use of GRC-Exchange. * If restriction is set to "need-to-know", the class or document MUST be encrypted to ensure only those with need-to-know access can decrypt the data. The document can either be encrypted for each individual for which access is intended or a single group key may be used. The method used SHOULD adhere to any Moriarty & Tabet Expires April 9, 2012 [Page 33] Internet-Draft grc-exchange October 2011 certificate policy and practices agreements between entities for the use of GRC-Exchange. A group key in this instance refers to a single key (symmetric) that is used to encrypt the block of data. The users with need-to-know access privileges may be given access to the shared key via a secure distribution method, for example, providing access to the symmetric key encrypted with each of users public keys. * If restriction is set to "public", the class or document MUST be sent in clear text. This setting can be critical if certain sections of a document or an entire document are to be shared without restrictions. This provides flexibility within a report to share out certain information freely where appropriate. * If restriction is set to "default", The information can be shared according to an information disclosure policy pre- arranged by the communicating parties. o Expectations based on placement of the restriction setting: * If restriction is set within one of the GRC-Exchange classes, the restriction applies to the entire GRC XML document. * If restriction is set within individual classes of the GRC XML schema included, the restriction applies to the specific class of the GRC XML document and the children of that class. The formation of policies is a very important aspect of using a messaging system to exchange potentially sensitive information. Many considerations should be involved for peering parties, and some guidelines to protect the data, systems, and transport are covered in this section. Policies established should provide guidelines for communication methods, security, and fall-back procedures. See sections 8.5 and 8.6 for additional information on consortiums and PKI considerations. The security considerations for the storage and exchange of information in GRC-Exchange messaging may include adherence to local, regional, or national regulations in addition to the obligations to protect client information. GRCPolicy is a necessary tool for listing the requirements of messages to provide a method to categorize data elements for proper handling. Controls are also provided for the sending entity to protect messages from third parties through XML encryption. GRC-Exchange provides a method to communicate request and Report messages between peers, from a provider to client, or to file reports Moriarty & Tabet Expires April 9, 2012 [Page 34] Internet-Draft grc-exchange October 2011 to a centralized repository as required. GRC-Exchange provides the ability for participating entities to manage their own security controls, leveraging the information listed in GRCPolicy, mapped to their policies and agreements. 10.2. Message Transport The transport specifications are fully defined in a separate document, leveraging the transport for RID in [RFC6046-bis]. The specified transport protocols MUST use encryption to provide an additional level of security and integrity, while supporting mutual authentication through bi-directional certificate usage. Any subsequent transport method defined should take advantage of existing standards for ease of implementation and integration of RID systems. Session encryption for the transport of GRC Report Exchange messages is enforced in the transport specification. The privacy and security considerations are addressed fully in GRC Report Exchange to protect sensitive portions of documents and provide a method to authenticate the messages. Therefore, GRC Report Exchange messages do not rely on the security provided by the transport layer alone. The encryption requirements and considerations for RID are discussed in Section 9.1 of this document. XML security functions such as the digital signature [RFC3275] and encryption [XMLencrypt] provide a standards-based method to encrypt and digitally sign messages. GRC-Exchange messages specify system use and privacy guidelines through the GRCPolicy class. A public key infrastructure (PKI) provides the base for authentication and authorization, encryption, and digital signatures to establish trust relationships between members of a consortium or a peering consortium. XML security functions such as the digital signature [RFC3275] and encryption [XMLencrypt] can be used within the contents of the message for privacy and security in cases for which certain elements must remain encrypted or signed as they are sent or forwarded to multiple recipients. For example, the digital signature on a Report can be used to verify the identity of originator of the Report. 10.3. Message Delivery Protocol - Integrity and Authentication The GRC-Exchange protocol must be able to guarantee delivery and meet the necessary security requirements of a state-of-the-art protocol. In order to guarantee delivery, TCP should be considered as the underlying protocol within the current network standard practices. Security requirements must include the integrity, authentication, privacy, and authorization of the messages sent between systems Moriarty & Tabet Expires April 9, 2012 [Page 35] Internet-Draft grc-exchange October 2011 communicating via GRC-Exchange. The communication between GRC- Exchange systems must be authenticated and encrypted to ensure the integrity of the messages and the systems involved in the communications. Another concern that needs to be addressed is authentication for a request that traverses multiple networks. In this scenario, systems in the path of the multi-hop ReportRequest need to authorize a request from not only the direct peer but also from the initiating entity as discussed in Section 9.5. Several methods can be used to ensure integrity and privacy of the communication. The transport mechanism selected MUST follow the defined transport protocol [RFC6046] when using GRC-Exchange messaging to ensure consistency among the peers. Consortiums may vary their selected transport mechanisms and thus must decide upon a mutual protocol to use for transport when communicating with peers in a neighboring consortium using GRC-Exchange. GRC-Exchange systems MUST implement and deploy HTTPS as defined in the transport document [RFC6046] and optionally support other protocols such as the Blocks Extensible Exchange Protocol (BEEP). GRC-Exchange, the XML security functions, and transport protocols must properly integrate with a public key infrastructure (PKI) managed by the consortium or one managed by a trusted entity. For the Internet, a few of examples of existing efforts that could be leveraged to provide the supporting PKI include the American Registry for Internet Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued certificates, or approved issuers of Extended Validation (EV) Certificates. Security and privacy considerations related to consortiums are discussed in Sections 8.5 and 8.6. 10.4. Transport Communication In order to address the integrity and authenticity of messages, transport encryption MUST be used to secure the traffic sent between entities exchanging GRC requests and reports. Systems with predefined relationships for GRC-Exchange include those who peer within a consortium with agreed-upon appropriate use regulations and for peering consortiums. Trust relationships may also be defined through a bridged or hierarchical PKI in which both peers belong. Systems used to send authenticated GRC-Exchange messages between networks MUST use a secured system and interface to connect to a border network's RID systems. Each connection to a GRC-Excahnge system MUST meet the security requirements agreed upon through the consortium regulations, peering, or SLAs. The GRC-Exchange system MUST only listen for and send GRC-Exchange messages on the designated port, which also MUST be over an encrypted tunnel meeting the minimum requirement of algorithms and key lengths established by the Moriarty & Tabet Expires April 9, 2012 [Page 36] Internet-Draft grc-exchange October 2011 consortium, peering, or SLA. The selected cryptographic algorithms for symmetric encryption, digital signatures, and hash functions MUST meet minimum security levels of the times. The encryption strength MUST adhere to import and export regulations of the involved countries for data exchange. 10.5. Authentication of The GRC Report Exchange Protocol In order to ensure the authenticity of the GRC-Exchange messages, a message authentication scheme is used to secure the protocol. XML security functions utilized in GRC-Exchange require a trust center such as a PKI for the distribution of credentials to provide the necessary level of security for this protocol. Layered transport protocols also utilize encryption and rely on a trust center. Public key certificate pairs issued by a trusted Certification Authority (CA) MAY be used to provide the necessary level of authentication and encryption for the GRC-Exchange protocol. The CA used for GRC- Exchange messaging must be trusted by all involved parties and may take advantage of similar efforts, such as the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI to network providers. The PKI used for authentication also provides the necessary certificates needed for encryption used for the RID transport protocol [RFC6046]. The use of pre-shared keys may be considered for authentication. If this option is selected, the specifications set forth in "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST be followed. Hosts receiving a GRC-Exchange message MUST be able to verify that the sender of the request is valid and trusted. Using digital signatures on a hash of the GRC-Exchange message with an X.509 version 3 certificate issued by a trusted party MUST be used to authenticate the request. The X.509 version 3 specifications as well as the digital signature specifications and path validation standards set forth in [RFC5280] MUST be followed in order to interoperate with a PKI designed for similar purposes. The use of digital signatures in GRC-Exchange XML messages MUST follow the World Wide Web Consortium (W3C) recommendations for signature syntax and processing when either the XML encryption [XMLencrypt] or digital signature [XMLsig], [RFC3275] is used within a document. Transport specifications are detailed in a separate document [RFC6046]. It might be helpful to define an extension to the authentication scheme that uses attribute certificates [RFC5755] in such a way that an application could automatically determine whether human intervention is needed to authorize a request; however, the specification of such an extension is out of scope for this document. Moriarty & Tabet Expires April 9, 2012 [Page 37] Internet-Draft grc-exchange October 2011 10.5.1. Multi-Hop Authentication The use of multi-hop authentication for a Report message may be used when a Report is sent to multiple entities in an iterative manner. For practical reasons, the entities may want to prioritize report requests based upon the immediate peer making the request, the originator of a request (if different from the peer sending the request), and other information contained int he GRC XML schema. A second measure MUST be taken to ensure the identity of the originator of the request or report. The originating entity MUST include an enveloped digital signature of the GRC XML document following the XML digital signature specifications from W3C [XMLsig]. The signature MUST be passed to all parties that receive the forwarded message, and each party MUST be able to perform full path validation on the digital signature [RFC5280]. Full path validation verifies the chaining relationship to a trusted root and also performs a certificate revocation check. In order to accommodate that requirement, the XML Digital Signature [XMLsig] specification must be followed for two or more enveloped signatures. If additions are made to a Report, the specification for two or more digital signatures [XMLsig] MUST be followed to authenticate the origin of the XML document components. In the case in which an enterprise network using GRC-Exchange sends a report or request to its service provider (SP), the signature from the enterprise MUST be included in the initial request. The SP may generate forward the request if appropriate. If the original request is sent, the originating SP, acting on behalf of the enterprise network, MUST also digitally sign, with an enveloped signature, the full GRC XML document to assure the authenticity of the request. An SP that offers GRC-Exchange to provide reports as a service may be using its own PKI to secure communications between the SP and its tenants or clients. 10.6. Consortiums and Public Key Infrastructures Direct relationships may be ideal for most GRC-Exchange communications, such as those between a service provider and its tenants for which reports will be issued. Consortiums can be used to establish a communication web of trust for GRC-Exchange messaging where appropriate. The consortium could provide centralized resources, such as a PKI, and established guidelines for use of the GRC-Exchange protocol. The consortium may assist in establishing trust relationships between the participating entities to achieve the necessary level of cooperation and experience-sharing among the consortium entities. This may be established through PKI certificate policy [RFC3647] reviews to determine the appropriate trust levels Moriarty & Tabet Expires April 9, 2012 [Page 38] Internet-Draft grc-exchange October 2011 between organizations or entities. The consortium may also be used for other purposes to better facilitate communication among entities in a common area (Internet, region, government, education, private networks, etc.). Using a PKI to distribute certificates used in GRC-Exchange communication provides an already established method to link trust relationships between entities or consortiums that peer with entities belonging to a separate consortium. In other words, consortiums could peer with other consortiums to enable communication of GRC- Exchange messages between the participating entities to extend trust relationships. The PKI along with Memorandums of Agreement could be used to link border directories to share public key information in a bridge, a hierarchy, or a single cross-certification relationship. Consortiums also need to establish guidelines for each participating entities to adhere. The RECOMMENDED guidelines include: o Physical and logical practices to protect of systems; o Network and application layer protection for systems and communications; o Proper use guidelines for GRC-Exchange messages and requests; and o A PKI and policy to provide authentication, integrity, and privacy. The functions described for a consortium's role parallel that of a PKI federation. The PKI federations that currently exist are responsible for establishing security guidelines and PKI trust models. The trust models are used to support applications to share information using trusted methods and protocols. A PKI can also provide the same level of security for communication between an end entity (enterprise, educational, or government customer network) and the SP. The PKI may be a subordinate CA or in the CA hierarchy from the SP or consortium to establish the trust relationships necessary as the request is made to other connected networks. 10.7. Privacy Concerns and System Use Guidelines The GRCPolicy class is used to automate the enforcement of the privacy concerns listed within this document. The privacy and system use concerns that MUST be addressed in the GRC-Exchange communication system and other integrated components include the following: Moriarty & Tabet Expires April 9, 2012 [Page 39] Internet-Draft grc-exchange October 2011 Privacy Concerns: o Privacy of data collected for continuous monitoring for IT Operations, Security, Compliance, and Audit reports. This data may be of the entity being monitored or tenant data in a service provider model. Agreements MUST be established for the proper handling of this data to the data owners requirements. o Privacy of data monitored and stored on systems used in legal exchanges such as eDiscovery or eWarrant reorts. Information Sharing Considerations: o System use between peering consortiums MUST also adhere to any government communication regulations that apply between those two regions, such as encryption export and import restrictions. This may include consortiums that are categorized as "BetweenConsortiums" or "AcrossNationalBoundaries". o System use between consortiums MUST NOT request reports beyond the scope intended and permitted by law or established agreements. o GRC Report Exchange communications between entities classified as "AcrossNationalBoundaries" MUST respect national boundary issues and limit requests to appropriate agreements including those which involve peering consortia. The security and privacy considerations listed above are for the consortiums, SPs, and enterprises to agree upon. The agreed-upon policies may be facilitated through use of the GRCPolicy class. Some privacy considerations are addressed through the GRC-Exchange guidelines for encryption and digital signatures as described in Section 9.1. Privacy becomes an issue whenever sensitive data traverses a network. The specific concerns for each GRC XML schema used must be considered individually. The exchange of information in provided Reports, should be detailed in agreements and contracts prior to information sharing exchanges taking place. The agreements should consider the level of detail to be provided in a report, what information MUST not be communicated, and how information is protected in exchanges. Intra-consortium GRC-Exchange communications raise additional issues, especially when the peering consortiums reside in different regions or nations. Data privacy regulations and other applicable regulations MUST be considered in information sharing or exchange policies. Moriarty & Tabet Expires April 9, 2012 [Page 40] Internet-Draft grc-exchange October 2011 The privacy concerns listed in this section address issues among the trusted parties involved in a GRC Report exchanges. Data used in GRC-Exchange communications must also be protected from parties that are not trusted. This protection is provided through the authentication and encryption of documents as they traverse the path of trusted servers. Each system communicating GRC-Exchange messages MUST perform a bi-directional authentication when sending a GRC- Exchange message and use the public encryption key of the upstream or downstream peer to send a message or document over the network. This means that the document is decrypted and re-encrypted at each GRC- Exchange system via TLS over the transport protocol [RFC6046]. The GRC-Exchange messages may be decrypted at each GRC-Exchange system in order to properly process the request or relay the information. Today's processing power is more than sufficient to handle the minimal burden of encrypting and decrypting relatively small typical GRC Report Exchange messages. 11. Security Considerations GRC Report Exchange has many security requirements and considerations built into the design of the protocol, several of which are described in the Security Requirements section. For a complete view of security, considerations include the availability, confidentiality, and integrity concerns for the transport, storage, and exchange of information. Authenticated encrypted tunnels between systems accepting GRC- Exchange communications are used to provide confidentiality, integrity, authenticity, and privacy for the data at the transport layer. Encryption and digital signatures are also used at the GRC XML document level through GRC-Exchange options to provide confidentiality, integrity, authenticity, privacy and traceability of the document contents. Trust relationships may be through direct peers or consortiums using established trust relationships of public key infrastructure (PKI) via cross-certifications. Trust levels can be established in cross-certification processes where entities compare PKI policies that include the specific management and handling of an entity's PKI and certificates issued under that policy. [RFC3647] defines an Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework that may be used in the comparison of policies to establish trust levels and agreements between entities, an entity and a consortium, and consortia. The agreements SHOULD consider key management practices including the ability to perform path validation on certificates [RFC5280], key distribution techniques [RFC2585], Certificate Authority and Registration Authority management practices. Moriarty & Tabet Expires April 9, 2012 [Page 41] Internet-Draft grc-exchange October 2011 The agreements between entities SHOULD also include a common understanding of the usage of GRC-Exchange security, policy, and privacy options discussed in this section. The formality, requirements, and complexity of the agreements for the certificate policy, practices, and the use of GRC-Exchange options SHOULD be decided by the entities or consortiums creating those agreements. 12. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas [XMLschema] conforming to a registry mechanism described in [RFC3688]. Registration request for the grc-exchange namespace: URI: urn:ietf:params:xml:ns:grc-exchange-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. Registration request for the grc-exchange XML schema: URI: urn:ietf:params:xml:schema:grc-exchange-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: See Section 7, "GRC-Exchange Schema Definition", of this document. 13. Summary Governance, Risk, and Compliance reports may contain some of the most sensitive information for a business. Reports may contain the the prioritized risks for the effective management of Business Operations, IT, Security, Compliance, and Legal departments of an enterprise. There may be a regulatory or legal requirement to share information or formatted reports with a regulatory body or other entities in a legal review. Outsourcing of computer infrastructure has necessitated the need for service providers to share reports with tenants or clients to ensure SLAs and agreements on security requirements are met. Each of these use cases require a secure method to exchange reports. GRC Report Exchange provides a standardized method to exchange reports while considering the Moriarty & Tabet Expires April 9, 2012 [Page 42] Internet-Draft grc-exchange October 2011 security, privacy and policy requirements without relying on the transport layer for security. Security is provided at the document level to provide methods to share a report where policy requirements can be implemented by mapping to technical options and data markers in the GRC-Exchange protocol. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007. [RFC5275] Turner, S., "CMS Symmetric Key Management and Distribution", RFC 5275, June 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010. [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010. Moriarty & Tabet Expires April 9, 2012 [Page 43] Internet-Draft grc-exchange October 2011 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time Inter-network Defense (RID) Messages", RFC 6046, November 2010. [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C Recommendation XML 1.0, November 2008, . [XMLNames] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation , December 2009, . [XMLencrypt] Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Syntax and Processing", W3C Recommendation , December 2002, . [XMLschema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation Second Edition, October 2004, . [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. Simon, "XML-Signature Syntax and Processing", W3C Recommendation Second Edition, June 2008, . 14.2. Informative References [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. Acknowledgements Many thanks to colleagues and the Internet community for reviewing Moriarty & Tabet Expires April 9, 2012 [Page 44] Internet-Draft grc-exchange October 2011 and commenting on the document. Authors' Addresses Kathleen M. Moriarty EMC Corporation 176 South Street Hopkinton, MA United States Phone: Email: Kathleen.Moriarty@emc.com Said Tabet EMC Corporation 176 South Street Hopkinton, MA United States Phone: Email: Said.Tabet@emc.com Moriarty & Tabet Expires April 9, 2012 [Page 45]