Network Working Group C. Hoff Internet-Draft Cisco Systems Intended status: Experimental S. Johnston Expires: January 6, 2011 Google G. Reese enStratus B. Sapiro TELUS July 5, 2010 CloudAudit 1.0 - Automated Audit, Assertion, Assessment, and Assurance API (A6) draft-hoff-cloudaudit-00 Abstract CloudAudit provides an open, extensible and secure interface that allows cloud computing providers to expose Audit, Assertion, Assessment, and Assurance (A6) information for cloud infrastructure (IaaS), platform (PaaS), and application (SaaS) services to authorized clients. Requirements Language 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 RFC 2119 [RFC2119]. 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 January 6, 2011. Copyright Notice Hoff, et al. Expires January 6, 2011 [Page 1] Internet-Draft CloudAudit July 2010 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Repository . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Glossary namespace . . . . . . . . . . . . . . . . . . . . 5 5.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Service namespace . . . . . . . . . . . . . . . . . . . . 6 5.2.1. Local Assertions . . . . . . . . . . . . . . . . . . . 6 5.2.2. Remote Assertions . . . . . . . . . . . . . . . . . . 9 5.2.3. Third-party Assertions . . . . . . . . . . . . . . . . 10 6. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Initial Registry Contents . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Hoff, et al. Expires January 6, 2011 [Page 2] Internet-Draft CloudAudit July 2010 1. Introduction CloudAudit provides a common interface, naming convention, set of processes and technologies utilizing the HTTP protocol to enable cloud service providers to automate the collection and assertion of operational, security, audit, assessment, and assurance information. This provides duly authorized and authenticated consumers and brokers of cloud computing services to automate requests for this data and metadata. CloudAudit supports the notion of requests for both structured and unstructured data and metadata aligned to compliance and audit frameworks. Specific compliance framework definitions and namespaces ("compliance packs")) will be made available incrementally. The first CloudAudit release is designed to be as simple as possible so as it can be implemented by creating a consistent namespace and directory structure and placement of files to a standard web server that implements HTTP [RFC2616]. Subsequent releases may add the ability to write definitions and assertions, and to request new assertions be generated (e.g. a network scan). That is, while 1.x versions are read-only, subsequent releases may be read-write. A duly authorized and authenticated client will typically interrogate the service and verify compliance with local policy before making use of it. It may do so by checking certain pre-defined parameters (for example, the geographical location of the servers, compliance with prevailing security standards, etc.) or it may enumerate some/all of the information available and present it to an operator for a manual decision. This process may be fully automated, for example when searching for least cost services or for an alternative service for failover. As it is impossible to tell in advance what information will be of interest to clients and what service providers will be willing to expose, a safely extensible mechanism has been devised which allows any domain name owner to publish both definitions and assertions. 2. Notational Conventions 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 BCP 14, [RFC2119], as scoped to those conformance targets. This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC2616]. Hoff, et al. Expires January 6, 2011 [Page 3] Internet-Draft CloudAudit July 2010 Additionally, the following rules are included from [RFC3986]: URI. 3. Discovery 3.1. Repository Clients SHOULD detect support for CloudAudit by verifying that a HTTP GET or HEAD for the repository root (e.g. /.well-known/cloudaudit) is successful (e.g. "200 OK"). Clients MAY also verify that requests for invalid URLs (e.g. /.well-known/) return an error (e.g. "404 Not Found"). If clients do not confirm the existence of a CloudAudit repository then they may be susceptible to false negatives (e.g. falsely assuming an assertion is absent when in fact the entire repository is absent) and if they do not confirm the absence of errors for invalid URLs then they may be susceptible to false positives (e.g. falsely assuming an assertion is present when in fact any assertion is present). 3.2. Links Servers MAY specify the root of a CloudAudit repository in the HTTP Link: header and/or HTML LINK element with rel="http://cloudaudit.org". This allows one or more services to delgate requests to a single local or remote/third-party server. Clients SHOULD check for the presence of these links before assuming that there is a local CloudAudit repository. HTML Discovery Link: ; rel="http://cloudaudit.org" HTTP Discovery 4. Enumeration Servers MAY render a HyperText Markup Language (HTML) response to a HTTP request for a directory containing an A or LINK element for every child with a HREF attribute containing the relative URL of the child. Clients MUST NOT rely on this functionality, which will vary from server to server. Hoff, et al. Expires January 6, 2011 [Page 4] Internet-Draft CloudAudit July 2010 5. Namespaces CloudAudit defines two namespaces; the glossary namespace which contains definitions and the service namespace which contains assertions. It relies on the Domain Name Service (DNS) to divide the glossary and service namespaces in an extensible fashion without relying on registries. A domain name (e.g. example.com) under the control of the party is broken into its components (e.g. example, com), reversed (e.g. com, example) and recombined (e.g. com.example). That party "owns" this namespace so long as the domain is registered to them and they may subdivide it with components in order to reference and/or categorise glossary definitions and service assertions. These MAY or MAY NOT represent valid hosts in the DNS. URI schemes and paths are NOT supported (e.g. https://example.com/cloud), however it is possible for a service to advertise an alternate name (e.g. cloud.example.com) via the HTTP Link header and/or HTML LINK element (Section 3). 5.1. Glossary namespace The glossary allows clients to enumerate and/or resolve definitions, and to obtain additional documentation. Servers MUST provide a plain text representation and MAY provide alternative representations (such as HTML) via HTTP content negotiation. 5.1.1. Examples 5.1.1.1. Generic The following shows a client obtaining a definition for org.iso.3166-1. < GET /.well-known/cloudaudit/glossary/org/iso/3166-1 HTTP/1.1 < Host: iso.org < > HTTP/1.1 200 OK > Content-Length: 24 > Content-Type: text/plain > > ISO 3166-1 Country Codes 5.1.1.2. Compliance The following shows a client obtaining a defintion for gov.nist.crc.sp800-53.r2. Hoff, et al. Expires January 6, 2011 [Page 5] Internet-Draft CloudAudit July 2010 < GET /.well-known/cloudaudit/glossary/gov/nist/crc/sp800-53/r2 HTTP/1.1 < Host: nist.gov < > HTTP/1.1 200 OK > Content-Length: 102 > Content-Type: text/plain > > NIST SP800-53 (Rev. 2) Recommended Security Controls for Federal Information Systems and Organizations 5.2. Service namespace Assertions can be made about the local service and/or remote service(s). 5.2.1. Local Assertions Local assertions refer to the service(s) sharing the same URL end- point as the CloudAudit repository. They can be identified by the absence of a '/-/' component in the URL (which is used as a delineator for Remote Assertions Section 5.2.2) and can normally be implemented using symbolic links or web server configuration. 5.2.1.1. Examples 5.2.1.1.1. Generic This example shows a client retrieving the ISO 3166-1 country code(s) from which the cloud.example.com service is being provided. < GET /.well-known/cloudaudit/service/org/iso/3166-1 HTTP/1.1 < Host: cloud.example.com < > HTTP/1.1 200 OK > Content-Length: 3 > Content-Type: text/plain > > US 5.2.1.1.2. Compliance - Human Readable Response This example shows a client retrieving a response to a control section 15.3.1 of ISO 27002 (v2005) from which the cloud.example.com service is being provided. The response is valid HTML and intended to be human readable. Hoff, et al. Expires January 6, 2011 [Page 6] Internet-Draft CloudAudit July 2010 < GET /.well-known/cloudaudit/service//org/iso/27002/v2005/15/3/1 HTTP/1.1 < Host: cloud.example.com < > HTTP/1.1 200 OK > Content-Length: 822 > Content-Type: text/html > > > > > ISO 27002 v2005 15.3.1 > >

Information systems audit controls

> > > 5.2.1.1.3. Compliance - Atom Response This example shows a client retrieving a response to a control section 15.3.1 of ISO 27002 (v2005) from which the cloud.example.com service is being provided. The response is in an ATOM format [RFC4287] and intended to be machine processed. < GET /.well-known/cloudaudit/service//org/iso/27002/v2005/15/3/1/manifest.xml HTTP/1.1 < Host: cloud.example.com < > HTTP/1.1 200 OK > Content-Length: 3432 > Content-Type: text/xml > > > > ISO 27002 v2005 15.3.1 > > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/ > Information systems audit controls > 2010-01-13T18:30:02Z > Cloud Audit Manual Bootstrap Package > > Jon James > jonjames@cloudhosting.com > > Copyright (c) 2009, Cloud Hosting Inc. > Hoff, et al. Expires January 6, 2011 [Page 7] Internet-Draft CloudAudit July 2010 > > > Audit Schedule > > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditschedule.xls > 2009-12-28T12:24:02Z > the 2010 audit schedule for cloud hosting inc. > > Eric Smith > ericsmith@cloudhosting.com > > > Mary Huxley > maryhuxley@kpwey.com > http://www.kpwey.com > > > > > KPWEY LLP Audit Contract > > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/contract.pdf > 2009-01-12T11:45:02Z > The audit contract with KPWEY for external audit services > > The document details the services procured to support the audit plan; see page 14 for specific details. > > > Eric Smith > ericsmith@cloudhosting.com > > > Mary Huxley > maryhuxley@kpwey.com > http://www.kpwey.com > > > > > Audit Scope > > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditscope.zip > 2009-12-28T12:25:02Z > The audit scope for the planned audits in 2010 > > Sarah Chan > sarahchan@cloudhosting.com > Hoff, et al. Expires January 6, 2011 [Page 8] Internet-Draft CloudAudit July 2010 > > David Kohl > davidkohl@kpwey.com > > > Mary Huxley > maryhuxley@kpwey.com > http://www.kpwey.com > > > 5.2.1.1.4. Compliance - Non-Existent This example shows a client atempting to retrieve a non existent response to a control section of NIST SP800-53 (Rev 2) from which the cloud.example.com service is being provided. < GET /.well-known/cloudaudit/glossary/gov/nist/crc/sp800-53/r2/cp-2 HTTP/1.1 < Host: cloud.example.com < > HTTP/1.1 404 Not Found > Content-Length: 148 > Content-Type: text/html > > > > 404 Not Found >

Error: Not Found

>

The requested URL was not found on this server.

> > 5.2.2. Remote Assertions There are a number of scenarios where it is necessary to answer CloudAudit queries on behalf of others, including: o Responding to queries on behalf of multiple servers o Responding to queries from multiple clients o Proxying in order to supplement or override assertions o Incompatibilities with existing systems and software that prevents co-location Remote assertions are supported by embedding both the name (e.g. cloud.example.com) and the assertion queried (e.g. 3166-1.iso.org) in Hoff, et al. Expires January 6, 2011 [Page 9] Internet-Draft CloudAudit July 2010 the URL. The name and assertion MUST be delineated with a '/-/' URL component as they may vary in length. 5.2.2.1. Examples This example shows a client retrieving the ISO 3166-1 country code(s) from which the cloud.example.com service is being provided, from the remote server cloudaudit.net. < GET /.well-known/cloudaudit/service/com/example/cloud/-/org/iso/3166-1 HTTP/1.1 < Host: cloudaudit.net < > HTTP/1.1 200 OK > Content-Length: 3 > Content-Type: text/plain > > US 5.2.3. Third-party Assertions It may be necessary for third-parties to make assertions, for example where an auditor certifies compliance with a given standard at a given time. This can be achieved either by retrieving a trusted representation (for example, an image containing a physical signature, or a digitally signed document) from the first-party or by being redirected to a third-party and retrieving the assertion directly from them. 6. Digital Signatures Digital signatures allow clients to verify the integrity of the assertions (both first-party and third-party). 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations The content of CloudAudit repositories MAY NOT be secure, private or integrity-guaranteed, and due caution should be exercised. Clients SHOULD use Transport Layer Security (TLS) [RFC5246] or equivalent to ensure confidentiality and integrity when accessing CloudAudit Hoff, et al. Expires January 6, 2011 [Page 10] Internet-Draft CloudAudit July 2010 repositories over a public network such as the Internet. The Domain Name System (DNS) MAY be susceptible to attacks and care should be taken to authenticate servers, for example by verifying the chain of trust and infromation contained in SSL certificates provided, by using a Virtual Private Network (VPN) service, by relying on DNSSEC [RFC4033], etc. Malicious clients MAY seek to obtain sensitive information via CloudAudit which could then be used to launch an attack. Such information should only be made available to authorised clients who have been authenticated via HTTP authentication [RFC2617] or equivalent. Servers may make false first-party assertions or may refer to third- party assertions that do not apply to them, or that expand the scope of the intended meaning. Clients that do not trust servers may choose only to rely on trusted third-party assertions, in which case the integrity of the assertion SHOULD be verified by transferring it over Transport Layer Security (TLS) [RFC5246] or equivalent or by verifying a digital signature applied to the assertion using OpenPGP [RFC4880] or equivalent 9. Acknowledgements The authors would like to acknowledge all members of the CloudAudit Working Group, editors of framework specification documents (including Doug Barbin, Mike Versace, James Arlen and Dave Lewis), the publishers of frameworks (including ISACA, HHS, ISO, NIST and PCI) and early adopters of the standard. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. Hoff, et al. Expires January 6, 2011 [Page 11] Internet-Draft CloudAudit July 2010 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [W3C.REC-html401-19991224] Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, . 10.2. Informative References Appendix A. Initial Registry Contents The CloudAudit registry's initial contents are: o Assertion Name: org.iso.3166-1 o Description: Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes o Reference: http://www.iso.org/iso/iso-3166-1_decoding_table Hoff, et al. Expires January 6, 2011 [Page 12] Internet-Draft CloudAudit July 2010 Authors' Addresses Christofer Hoff Cisco Systems 200 Beaver Brook Road Building 200 Boxborough, MA 01719 USA Phone: +1.9786310302 Email: hoffc@cisco.com Sam Johnston Google Brandschenkestrasse 110 Zurich, 8002 Switzerland Phone: +41.446681679 Email: sj@google.com George Reese enStratus 1201 Marquette Ave Suite 150 Minneapolis, MN 55403 USA Phone: +1.6127463091 Email: george.reese@enstratus.com Ben Sapiro TELUS Security Labs 25 York Street Toronto M5J 2V5 Canada Phone: +1.6478899432 Email: ben@sapiro.net Hoff, et al. Expires January 6, 2011 [Page 13]