[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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/<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).

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.
<link rel="http://cloudaudit.org" href="http://example.com/.well-known/cloudaudit/com.example.ec2">

                              HTML Discovery

Link: <http://example.com/.well-known/cloudaudit/com.example.ec2>; 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
>
> <html>
> <body>
> <head>
> <title>ISO 27002 v2005 15.3.1</title>
> </head>
> <H1>Information systems audit controls</H1>
> <UL>
> <LI><a href="http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditschedule.xls">Audit Schedule</a> - <i>the 2010 audit schedule for cloud hosting inc.</i>
> <LI><a href="http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/contract.pdf">KPWEY LLP Audit Contract</a> - <i>The audit contract with KPWEY for external audit services</i> - <span>The document details the services procured to support the audit plan; see page 14 for specific details.</span>
> <LI><a href="http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditscope.zip">Audit Scope</a> - <i>The audit scope for the planned audits in 2010</i>
> </UL>
> </body>
> </html>

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
>
> <?xml version="1.0" encoding="UTF-8"?>
> <feed xmlns="http://www.w3.org/2005/Atom">
>    <title>ISO 27002 v2005 15.3.1</title>
>    <link href="http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/" rel="self"/>
>    <id>http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/</id>
>    <subtitle>Information systems audit controls</subtitle>
>    <updated>2010-01-13T18:30:02Z</updated>
>    <generator uri="http://cloudaudit.org/development/bootstrap.tgz" version="1.0">Cloud Audit Manual Bootstrap Package</generator>
>    <author>
>        <name>Jon James</name>
>        <email>jonjames@cloudhosting.com</email>
>    </author>
>    <rights type="text">Copyright (c) 2009, Cloud Hosting Inc.</rights>
>    <category term="/iso/27002/v2005/" label="ISO 27002 v5"/>



Hoff, et al.             Expires January 6, 2011                [Page 7]


Internet-Draft                 CloudAudit                      July 2010


>
>    <entry>
>        <title>Audit Schedule</title>
>        <link href="http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditschedule.xls" type="application/msexcel" rel="related"></link>
>        <id>http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditschedule.xls</id>
>        <updated>2009-12-28T12:24:02Z</updated>
>        <summary>the 2010 audit schedule for cloud hosting inc.</summary>
>        <author>
>            <name>Eric Smith</name>
>            <email>ericsmith@cloudhosting.com</email>
>        </author>
>        <contributor>
>            <name>Mary Huxley</name>
>            <email>maryhuxley@kpwey.com</email>
>            <uri>http://www.kpwey.com</uri>
>        </contributor>
>    </entry>
>
>    <entry>
>        <title>KPWEY LLP Audit Contract</title>
>        <link href="http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/contract.pdf" type="application/pdf" rel="related"></link>
>        <id>http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/contract.pdf</id>
>        <updated>2009-01-12T11:45:02Z</updated>
>        <summary>The audit contract with KPWEY for external audit services</summary>
>        <content type="text" xml:lang="en">
>            The document details the services procured to support the audit plan; see page 14 for specific details.
>        </content>
>        <author>
>            <name>Eric Smith</name>
>            <email>ericsmith@cloudhosting.com</email>
>        </author>
>        <contributor>
>            <name>Mary Huxley</name>
>            <email>maryhuxley@kpwey.com</email>
>            <uri>http://www.kpwey.com</uri>
>        </contributor>
>    </entry>
>
>    <entry>
>        <title>Audit Scope</title>
>        <link href="http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditscope.zip" type="application/zip" rel="related"></link>
>        <id>http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditscope.zip</id>
>        <updated>2009-12-28T12:25:02Z</updated>
>        <summary>The audit scope for the planned audits in 2010</summary>
>        <author>
>            <name>Sarah Chan</name>
>            <email>sarahchan@cloudhosting.com</email>
>        </author>



Hoff, et al.             Expires January 6, 2011                [Page 8]


Internet-Draft                 CloudAudit                      July 2010


>        <contributor>
>            <name>David Kohl</name>
>            <email>davidkohl@kpwey.com</email>
>        </contributor>
>        <contributor>
>            <name>Mary Huxley</name>
>            <email>maryhuxley@kpwey.com</email>
>            <uri>http://www.kpwey.com</uri>
>        </contributor>
>    </entry>
> </feed>

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
>
> <html>
> <head>
> <title>404 Not Found</title>
> </head><body><h1>Error: Not Found</h1>
> <h2>The requested URL was not found on this server.</h2>
> </body>
> </html>

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,
              <http://www.w3.org/TR/1999/REC-html401-19991224>.

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/