CloudAudit 1.0 - Automated Audit, Assertion, Assessment, and Assurance API (A6) Cisco Systems
200 Beaver Brook Road Building 200 Boxborough 01719 MA USA +1.9786310302 hoffc@cisco.com
Google
Brandschenkestrasse 110 Zurich 8002 Switzerland +41.446681679 sj@google.com
enStratus
1201 Marquette Ave Suite 150 Minneapolis MN 55403 USA +1.6127463091 george.reese@enstratus.com
TELUS Security Labs
25 York Street Toronto M5J 2V5 Canada +1.6478899432 ben@sapiro.net
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. 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.
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 . 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.
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, , as scoped to those conformance targets. This document uses the Augmented Backus-Naur Form (ABNF) notation of . Additionally, the following rules are included from : URI.
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/<random>) 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).
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.
]]>
; rel="http://cloudaudit.org"]]>
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.
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 ().
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.
The following shows a client obtaining a definition for org.iso.3166-1.
HTTP/1.1 200 OK > Content-Length: 24 > Content-Type: text/plain > > ISO 3166-1 Country Codes]]>
The following shows a client obtaining a defintion for gov.nist.crc.sp800-53.r2.
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 ]]>
Assertions can be made about the local service and/or remote service(s).
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 ) and can normally be implemented using symbolic links or web server configuration.
This example shows a client retrieving the ISO 3166-1 country code(s) from which the cloud.example.com service is being provided.
HTTP/1.1 200 OK > Content-Length: 3 > Content-Type: text/plain > > US]]>
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.
HTTP/1.1 200 OK > Content-Length: 822 > Content-Type: text/html > > > > > ISO 27002 v2005 15.3.1 > >

Information systems audit controls

>
    >
  • Audit Schedule - the 2010 audit schedule for cloud hosting inc. >
  • KPWEY LLP Audit Contract - 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. >
  • Audit Scope - The audit scope for the planned audits in 2010 >
> > ]]>
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 and intended to be machine processed.
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. > > > > 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 > > > David Kohl > davidkohl@kpwey.com > > > Mary Huxley > maryhuxley@kpwey.com > http://www.kpwey.com > > > ]]>
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.
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.

> > ]]>
There are a number of scenarios where it is necessary to answer CloudAudit queries on behalf of others, including: Responding to queries on behalf of multiple servers Responding to queries from multiple clients Proxying in order to supplement or override assertions 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 the URL. The name and assertion MUST be delineated with a '/-/' URL component as they may vary in length.
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.
HTTP/1.1 200 OK > Content-Length: 3 > Content-Type: text/plain > > US]]>
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.
Digital signatures allow clients to verify the integrity of the assertions (both first-party and third-party).
This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.
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) or equivalent to ensure confidentiality and integrity when accessing CloudAudit 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 , 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 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) or equivalent or by verifying a digital signature applied to the assertion using OpenPGP or equivalent
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.
The CloudAudit registry's initial contents are: Assertion Name: org.iso.3166-1 Description: Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes Reference: http://www.iso.org/iso/iso-3166-1_decoding_table