An Overview of the Conceptual Architecture for the Cloudtrust Protocol (CTP) in the FULL

An overview of the conceptual architecture for the cloudtrust protocol (CTP) in THE FULL CONTEXT OF THEcsa gOVERNANCE, rISK, AND cOMPLIANCE sTACK

Ronald B. Knode31 January 2012Draft v1.3

Reclaiming visibility and value for cloud consumers and providers: The CloudTrust Protocol (CTP) was invented to restore to the enterprise the ability to confirm that “whatever is claimed to be happening in the cloud is, indeed, happening … and nothing else.”[1] Beneath all the enterprise anxieties about security, privacy, integrity, and compliance lies the inability to use traditional methods to see, monitor, measure, or control activities and operations in a cloud. The CTP provides a basis for cloud consumers to recover that ability “to see what is going on in the cloud” and thereby solve their cloud service value equation. No potential cloud consumer or workload should be invalidated apriori simply because of industry or policy mandates or legacy computing circumstances.

Likewise, no cloud provider should be disqualified apriori simply because of an inability to disclose or confirm their own security reality to their marketplace. The CTP was invented to solve the “security plus transparency”value equation for cloud providers as well as consumers.[2] The CTP is first and foremost a technique for generating enterprise payoffs for cloud service consumers and providers. Its capacity to provide continuous monitoring of important elements of security service also make it a valuable capstone to the Governance, Risk and Compliance (GRC) stack of the CSA.

This overview is intended to provide an architectural template for an implementation of the CTP independent of the other elements of the CSA GRC stack, while still acknowledging the benefits of the CTP alongside other elements of the CSA GRC stack.

All rights reserved. This document is a proprietary product of CSC and, as such, any unauthorized use, disclosure, or reproduction of this publication or portions thereof in any form, without written permission CSC, is strictly prohibited.

Ronald B. Knode6 June 2011and Requirements Overview

CloudTrust Protocol (CTP)

The CloudTrust Protocol (CTP) is the mechanism by which cloud service consumers (also known as “cloud users” or “cloud service owners”) ask for and receive information about important processing characteristics as applied to cloud service providers. As highlighted in Figure1, the CTP introduces a Transparency-as-a-Service (TaaS) capability that recovers information typically lost in the transition to cloud processing. The CTP provides cloud consumers with a way to find out essential pieces of information concerning the compliance, security, privacy, integrity, and operational security history of service elements being performed “in the cloud”. Likewise, the CTP provides a single, flexible method for cloud providers to respond to important, oft-asked questions about the security circumstances of each and every cloud consumer they support without automatically having to defer to “right-to-audit clauses”, untimely (and easily outdated) 3rd party assessments, or related but non-specific assertions and certifications.

For example, information about current configuration, vulnerability status, location, access rights and history, compliance with agreed delivery standards, change management, and event logs and response can be requested and returned via the CTP in a standard delivery model. The answers to these questions about such important characteristics deliver “evidence-based assurance” upon which consumers can make informed information risk management decisions or support their own compliance assertions. Assured of such evidence (through the CTP), cloud consumers become liberated to bring more sensitive and valuable business functions to the cloud, and reap even larger payoffs. Likewise, cloud providers are liberated to improve their security capabilities and “get credit for it” by exhibiting the actual results of such improvements via a standard CTP exchange.

These important pieces of information are known as the “elements of transparency” (EoT) within the CTP definition, and they deliver testimony about essential security configuration and operational characteristics for systems deployed in the cloud. The elements of transparency empower the cloud consumer with the right information to make the right choices about what processing and data to put in the cloud or leave in the cloud, and to decide which cloud is best suited to satisfy processing needs. This is the nature of digital trust, and reinforces again why such reclaimed transparency is so vital to new enterprise value creation. Transparency of certain important elements of information is at the root of digital trust in the cloud, and thus the source of value capture and payoff with cloud services.

However, this focus on broad value capture and payoff for both cloud consumers and providers also means, for example, that neither the CTP itself nor its implementation should insist on any specific cloud service model or deployment model or size or technical interface or access mechanism. This CTP reference architecture model is intended to provide a CTP system organization and design recommendation that will help satisfy this primary objective of cloud service value capture. Using the power of transparency, the CTP provides a flexible anddynamic capabiity to perform “continuous monitoring with a purpose” ... where that “purpose” is the request, collection, and delivery of current cloud service security commitment and operational data that can stand as “evidence based assurance” for information risk management decision making.

The Elements of Transparency

AppendixA of the Precis for the CloudTrust Protocol, V2.0[3]has the current most complete description of the Elements of Transparency (EoT) within the CTP.

There are currently 24defined EoT, with number24 being a placeholder for a protocol extension capability. The EoT are described and categorized in different ways, depending on the purpose of the explanation or elaboration. Figure2, for example, presents the EoT in various categories of protocol intent. According to this categorization, most EoT are “transparency requests”. Other elements are administrative, specifications, or (the single) extension. In some cases, e.g., transparency requests that are assertions of vulnerability data or current configuration data (EoT 3–7) or control capability claims (EoT17), the EoT themselves are based on a lower level protocol (e.g., SCAP, CloudAudit).

Not all cloud service providers will subscribe (or acknowledge) the CTP. Nevertheless, even a partial response or acknowledgement of the protocol can prove useful for information risk management. Furthermore, those cloud service providers who have chosen to use additional parts of the CSA GRC stack (i.e., CCM, CAIQ, CloudAudit) are in an even more preferred position as a secure and trustworthy cloud provider. A full commitment to the CSA GRC stack distinguishes cloud providers (and consumers) as leaders in CSA standards conformance, and sets the pace for other cloud providers to deliver an equivalent level of control and transparency in configuration, operation, and process.

a reference framework for an Implementation of the CTP

An implementation of the CTP, i.e., a Transparency-as-a-Service (TaaS) implementation based on the CTP, is accomplished in four major configuration items as shown in Figure3.

Configuration Items (CIs) #13 are collectively considered the requestor and controller portion of an implementation and are created and operated by the cloud consumer or cloud (transparency) service broker. These CIs are intended to handle multiple consumers and service requests to multiple clouds on behalf of those consumers.

Configuration Item(CI)#4 is identified as a responder portion of an implementation. Each cloud provider that subscribes to all or partof the CTP is responsible for deploying a response engine that acknowledges CTP protocol requests and collects and delivers intended responses. While standardization of configuration and delivery typically bring benefits of efficiency and leveraged assets to cloud service clients, an unyielding devotion to orthodoxy does not. Therefore, in accordance with the scope and flexibility commentary in the Precis for the CTP [See footnote[2]], some implementation decisions are left to the discretion of the cloud provider. This includes the interpretation of the scope of specific EoT requests, as long as the intent of the EoT as described in the “Semantics” section of[2] is preserved and explained. Since each cloud provider may choose to subscribe to different sets of CTP EoTs, and each cloud provider is likely to have a different system architecture and distinct deployment standards, then each cloud provider is free to implement a response engine in the best form possible for their own cloud as long as the syntax and semantics of the CTP are followed.

Configuration Item (CI) Introductions (See Figure 3)

TaaS CloudTrustProtocol U/I and Service Director (CICTUI)

CTUI is the control portion of aTaaS (CTP) implementation. It provides the service user interface, access control, authorization, accounting, and process flow control for the CTP-based TaaS. In addition, CTUI provides a user interface to the CloudTrust Management Base (CTMB) and all of the response and reporting services to authorized cloud consumers. CTUI also has a service interface to the CTMB, a bidirectional connection to the CTP Request and Response Stack (CI), and is the connection point for all “back office” services needed by the CTP service (e.g., reporting, billing, event accounting). [Architecture alert:When CTUI is directly available to a cloud consumer, it can be built as a simple (web) application. However, in its most productive business orientation, CTUI can service multiple cloud consumers. Therefore, CTUI may itself be a RESTful Web Service accessed over HTTP/HTTPS so that clients from any location can access the interface.]

User interface: The specific style of interface for requesting and receiving CTP services via the CTUI is left to the developer. The variety and elegance of screens and presentations that can handle the potential scale of the CTP across multiple clouds while preserving simplicity for the consumer is constrained only by the ingenuity of the developer. However, Figure4 shows a popular metaphor for the CTP effect. In particular, the ability to “turn on the lights” (i.e., specific service EoT’s) that are needed in pursuit of “evidence-based confidence”. Such a metaphor reflects the continuous monitoring function of the CTP with the capacity to request evidencebased confidence whenever it is needed, and receive and return it to the cloud consumer as it is provided.

Moreover, this same metaphor suggests different kinds of business models for a TaaS service. For example, consumers could “subscribe” to different sets of EoT’s for each cloud, and be authorized on an EoTbyEoT basis to request information on a particular EoT. Or, each request for EoT information (a request to “turn on” a specific light) could be metered and be the basis of cost. Various combinations of these two models are possible, as are any number of other schemes based on the creativity of the CTUI developer.

TaaS (CTUI) service authorization and access control: One pair of EoT’s provides the initiation (login) and termination (logout) of a CTP (CloudVision) session (EoT’s #1 and #2). The selection of an identity store and authentication options, as well as the generation of graduated authorizations is currently left to the developer. [See the section of this document entitled “CSA CloudTrust Protocol Research Initiative Decision Agenda” to review a list of CTP design choices and protocol extensions that are being examined and analyzed by the CSA CTP working initiative team.] However, for any identity store selected, the CTP identities that are authorized to invoke transparency services must also connect to a (set of) cloud service identities so that requests are authorized and acknowledged on the cloud service end of the transaction. Alternatively, TaaS/CTUI itself must have an account within each cloud accessed so that requests can be deposited.
Cloud element configuration association/enumeration method: Different clouds name/track cloud service elements with different schemes and terminology. While IP addresses is the most common nomenclature used, the possibility exists for confusing or conflicting or redundant IP addresses across multiple clouds. Since TaaS/CTUIhas to request/respond to multiple clouds, an (internal) identification/enumerations method is likely to be needed in order to keep both the requests and the responses unambiguous. Such a method is currently left to the TaaS/CTUI developer.
Connection to CTP Request & Response Stack CI (CTPR&R): Authorized CTP service requests must be parsed and formed into legitimate CTP request for transmission to the CTP protocol stack implementation. Some requests, e.g., EoT #17, can be directly interpreted and executed via a lower level protocol by CTUI itself without further translation and relay to CTPR&R. In the example cited (EoT#17), direct use of the CloudAudit standard can be applied and a response returned almost immediately. [Such a capability may require knowledge of the implmentation status of CloudAudit standards by each of the popular public cloud service providers.]
Some EoT require prerequisite EoT. For instance, requesting a vulnerability scan data for cloud elements (EoT#5, #6, or#7) before requesting configuration information (EoT#3) would be illogical and must be (gently) refused with explanation. There may well be other combinations or ordering of EoT that are equally illogical, and should be treated as exceptions.
Regardless of the ultimate path of execution, a record of the status of the request must be maintained (in the CTMB) so that returning results (if any) can be associated with the right request and reported to the requestor. Returning data must be interpreted and placed into the CTMB in the right location and format.
The CTP is a very asynchronous protocol, so request responses may not appear until days after the original request. Consequently, requests must also be “timed out” when they exceed and expiration threshold (as set by the authorized TaaS/CTUI user.)
Back office services connection: TaaS/CTUI requires back office services. For example, a CTUI cost model could well apply a subscription charge for each EoT that clients wish to enable for their authorized users (i.e., the light switch for that EoT is enabled for that client), and then a charge for each time that EoT is requested (i.e.,, the light switch is turned “on”). Therefore, some backoffice support to compile and present the running total of costs (“the bill”) is needed. Moreover, clients are likely to insist on an empowerment cost threshold for their authorized users. Consequently, the billing/execution system must be able to check on the running total and alert the user when the (billing) threshold is being approached.
Likewise, CTUI implementations are likely to need access to some cloud orchestration services such as account creation/deletion, virtual data center creation/deletion, and cloud entity creation/deletion (e.g., VM creation/deletion) in order to keep track of account status and the legitimacy of transparency requests for cloud services being provided by a cloud service provider. Such an interface is currently left to the TaaS/CTP developer.
Reporting: CTP reporting services other than the specfic responses to CTP requests are not specified in the CTP itself. However, rich reporting services (including those that can transfer CTP responses to other downstream applications) are attractive and likely to be offered. Each EoT will require at least one report structure, and the larger responses (e.g., EoT #3, #11, #12, #13, #14) may well require multiple reports and reporting formats (even graphical in the case of Eot#3). These decisions are also currently left to the developer. For the CTP itself, design decisions that opt to leave configuration data in whatever structure is reported by the cloud service, without attempting some more elegant presentation, are suitably conformant.

CloudTrust Protocol Request and Response Stack (CI CTPR&R)

CRPR&R is the implementation of the CTP itself, as currently reflected in AppendixA of the Precis on the CloudTrust Protocol V2.0[4]. The basic architecture of CTPR&R is as a RESTful web service accessed over HTTP/HTTPS. The basic protocol payload is based on XML. Some of the EoT questions, specifications, and responses are themselves based on a foundation protocol. For example, EoT#5, #6, and #7 are all configured as the Security Content Automation Protocol (SCAP)[5] or its successors. Like the CSA GRC stack itself, there is already possibility for change in the use of SCAP. Some SCAP extensions are receiving support from various industries and associations. Should the CSA decide to incorporate those extensions as a “best practice”, then the CTP would, no doubt, align itself to those extensions as well, presuming there was no compelling reason to do otherwise.

AppendixA of footnote reference[4], including the example transaction, is the best current description of the CTP v2.0 syntax and semantics. The CSA CTP working group is pursuing the CTP design and integration agenda as shown in “CSA CloudTrust Protocol Research Initiative Decision Agenda”.

CloudTrust Management Base – CTMB (CI CTMB)

The CloudTrust Management Base (CTMB) is the TaaS (CTP) repository for such things as user/account control structure, the account identification and authorization mappings from TaaS/CTP users to specific cloud services, and the collection of transparency information history for TaaS/CTUI users across all clouds for which requests have been authorized. Such information is contributed via automated capture (e.g., EoT requests that are answered with an data stream or file) and via a manual capture (e.g., legal affirmations of location and/or process anchoring). For example, it is the CTMB that keeps track of request status and expiry; it is the CTMB that holds the client-provided specifications (e.g., requested configurations, alerting thresholds); and it is the CTMB that provides the responses when the “last good response” information is all that is needed. Today, the structure of the CTMB is left to the developer. Subsequent versions of the CTP are expected to include a CTMB description/schema and interface specification.