SAR / RAR

NIST Cloud Computing Standards Roadmap comprises public domain material from the National Institute of Standards and Technology, U.S. Department of Commerce.

Special Publication 500-291, Version 2 NIST Cloud Computing Standards Roadmap NIST Cloud Computing Standards Roadmap Working Group NIST Cloud Computing Program Information Technology Laboratory NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be ra pidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

Essential Characteristics: On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling. The provider ’s computing resources are pooled to serve multiple consumers using a multi- tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time. Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability 10 at some level of abstraction appropriate to the type of service (e.g., storage, processi ng, bandwidth, active user accounts). Resource usage can be monitored, controlled, audited, and reported, providing transparency for both the provider and consumer of the utilized service. 9 NIST Special Publication 800 -145, NIST Definition of Cloud Computing , September 2011 10 Typically this is done on a pay -per -use or charge -per -use basis. 3 THE NIST DEFINITION OF CLOU D COM PUTING9 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Service Models: Software as a Service (SaaS). The capability provided to the consumer is to use the provider ’s applications running on a cloud infrastructure. 11 The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web -based email) or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilitie s, with the possible exception of limited user - specific application configuration settings.

Platform as a Service (PaaS) . The capability provided to the consumer is to deploy onto the cloud infrastructure consumer -created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. 12 The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application- hosting environment. Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, s torage, and deployed applications, and possibly limited control of select networking components (e.g., host firewalls). Deployment Models: Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises. 11 A cloud infrastructure is the collection of hardware and software that enables the five essential characteristics of cloud computing. The cloud infrastructure can be viewed as containing both a physical layer and an abstraction layer. The physical layer consists of the hardware resources that are necessary to support the cloud services being provided, and typically includes server, storage and network components. The abstraction layer consists of the software deployed across the physical layer, which manifests the essential cloud characteristics. Conceptually the abstraction layer sits above the physical layer. 12 This capability does not necessarily preclude the use of compatible programming languages, libraries, services, and tools from other sources. NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises. Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider. Hybrid cloud. The c loud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability ( e.g., cloud bursting for load balancing between clouds). NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP The NIST cloud computing definition is widely accepted and valuable in providing a clear understanding of cloud computing technologies and cloud services. The NIST cloud computing reference architecture presented in this section is a natural extension to the NIST cloud computing definition.

The NIST cloud computing reference architecture is a generic high -level conceptual model that is a powerful tool for discussing the requirements, structures, and operations of clo ud computing. The model is not tied to any specific vendor products, services, or reference implementation, nor does it define prescriptive solutions that inhibit innovation. It defines a set of actors, activities, and functions that can be used in the process of developing cloud computing architectures, and relates to a companion cloud computing taxonomy. It contains a set of views and descriptions that are the basis for discussing the characteristics, uses, and standards for cloud computing.

The NIST cloud computing reference architecture focuses on the requirements of what cloud service provides, not on a design that defines a solution and its implementation. It is intended to facilitate the understanding of the operational intricacies in cloud comp uting. The reference architecture does not represent the system architecture of a specific cloud computing system; instead, it is a tool for describing, discussing, and developing the system -specific architecture using a common framework of reference. The design of the NIST cloud computing reference architecture serves the objectives to: illustrate and understand various cloud services in the context of an overall cloud computing conceptual model; provide technical references to USG agencies and other consumers to understand, discuss, categorize, and compare cloud services; and communicate and analyze security, interoperability, and portability candidate standards and reference implementations. The Overview of the Reference Architecture describes five major actors with their roles and responsibilities using the newly developing Cloud Computing Taxonomy. The NIST cloud computing reference architecture defines f ive major actors: cloud consumer, cloud provider, cloud auditor, cloud broker, and cloud carrier (See Figure 1: Cloud Actors). These core individuals have key roles in the realm of cloud computing. Each actor is an entity (a person or an organization) that participates in a transaction or process and/or performs tasks in cloud computing. For example, a Cloud Consumer is an individual or organization that acquires and uses cloud products and services.

The purveyor of products and services is the Cloud Provider. Because of the possible service 13 NIST Special Publication 500- 292, NIST Cloud Computing Reference Architecture , September 2011 4 .1 O VER V IE W 4 CLOU D COM PUTING REFERENCE ARCHI TECTURE 13 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP offerings (Software, Platform or Infrastructure) allowed for by the cloud provider, there will be a shift in the level of responsibilities for some aspects of the scope of control, security and configuration. The Cloud Broker acts as the intermediary between consumer and provider and will help consumers through the complexity of cloud service offerings and may also create value-added cloud services. The Cloud Auditor provides a valuable inherent function for the government by conducting the independent performance and security monitoring of cloud services. The Cloud Carrier is the organization which has the responsibility of transferring the data, somewhat akin to the power distributor for the electric grid.

Figure 1 – Cloud Actors briefly lists the five major actors defined in the NIST cloud computing reference architecture. Figure 1 – Cloud Actors NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Figure 2 – Interactions between the Actors in Cloud Computing shows the interactions among the actors in the NIST cloud computing reference architecture. A cloud consumer may request cloud services from a cloud provider directly or via a cloud broker. A cloud auditor conducts independent audits and may contact the others to collect necessary information. The details will be discussed in the following sections and be presented as successive diagrams in increasing levels of detail. Figure 2 – Interactions between the Actors in Cloud Computing NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP The cloud consumer is the ultimate stakeholder that the cloud computing service is created to support. A cloud consumer represents a person or organization that maintains a business relationship with, and uses the service from, a cloud provider. A cloud consumer browses the service catalog from a cloud provider, requests the appropriate service, sets up service contracts with the cloud provider, and uses the service. The cloud consumer may be billed for the service provisioned, and needs to arrange payments accordingly. Depending on the services requested, the activities and usage scenarios can be different among cloud consumers, as shown in Table 1. Some example usage scenarios are listed in Figure 3. Service Models Consumer Activities Provider Activities SaaS Uses application/service for business process operations. Installs, manages, maintains, and supports the software application on a cloud infrastructure. PaaS Develops, tests, deploys, and manages applications hosted in a cloud system. Provisions and manages cloud infrastructure and middleware for the platform consumers; provides development, deployment, and administration tools to platform consumers. IaaS Creates/installs, manages, and monitors services for IT infrastructure operations. Provisions and manages the physical processing, storage, networking, and the hosting environment and cloud infrastructure for IaaS consumers. Table 1 – Cloud Consumer and Cloud Provider 4.2 C LO UD C O NSU M ER NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Figure 3 – Example of Services Available to a Cloud Consumer SaaS applications are usually deployed as hosted services and are accessed via a network connecting SaaS consumers and providers. The SaaS consumers can be organizations that provide their members with access to software applications, end users who directly use software applications, or software application administrators who configure applications for end users. SaaS consumers access and use applications on demand, and can be billed on the number of consumers or the amount of consumed services. The latter can be measured in terms of the time in use, the network bandwidth consumed, or the amount/duration of data stored. NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP For PaaS, cloud consumers employ the tools and execution resources provided by cloud providers for the purpose of developing, testing, deploying, and managing applications hosted in a cloud system. PaaS consumers can be applicatio n developers who design and implement application software, application testers who run and test applications in various cloud systems, application deployers who publish applications into a cloud system, and application administrators who configure and monitor application performance on a platform. PaaS consumers can be billed by the number of consumers, the type of resources consumed by the platform, or the duration of platform usage. For IaaS, consumers are provisioned with the capabilities to access virtual computers, network- accessible storage, network infrastructure components, and other fundamental computing resources, on which consumers can deploy and run arbitrary software. IaaS consumers can be system developers, system administrators, and information technology (IT) managers who are interested in creating, installing, managing and monitoring services for IT infrastructure operations. IaaS consumers are provisioned with the capabilities to access these computing resources, and are billed for the amount of resources consumed. Figure 4 – Cloud Provider: Major Activities 4.3 C LO UD P R O VID ER NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP A cloud provider can be a person, an organization, or an entity responsible for making a service available to cloud consumers. A cloud provider builds the requested software/platform/ infrastructure services, manages the technical infrastructure required for providing the services, provisions the services at agreed -upon service levels, and protects the security and privacy of the services. As illustrated in Figure 4 – Cloud Provider: Major Activities, cloud providers undertake different tasks for the provisioning of the various service models. For SaaS, the cloud provider deploys, configures, maintains, and updates the operation of the software applications on a cloud infrastructure so that the services are provisioned at the expected service levels to cloud consumers. The provider of SaaS assumes most of the responsibilities in managing and controlling the applications and the infrastructure, while the cloud consumers have limited administrative control of the applications. For PaaS, the cloud provider manages the cloud infrastructure for the platform, and provisions tools and execution resources for the platform consumers to develop, test, deploy, and administer applications. Consumers have control over the applications and possibly the hosting environment settings, but cannot access the infrastructure underlying the platform including network, servers, operating systems, or storage. For IaaS, the cloud provider provisions the physical processing, storage, networking, and other fundamental computing resources, as well as manages the hosting environment and cloud infrastructure for IaaS consumers. Cloud consumers deploy and run applications, have mor e control over the hosting environment and operating systems, but do not manage or control the underlying cloud infrastructure (e.g., the physical servers, network, storage, hypervisors, etc.).

The activities of cloud providers can be discussed in greater detail from the perspectives of Service Deployment, Service Orchestration, Cloud Service Management, Security and Privacy.

As identified in the NIST cloud computing definition, a cloud infrastructure may be operated in one of the following deployment models: public cloud, private cloud, community cloud, or hybrid cloud.

For the details related to the controls and management in the cloud, we refer readers to the NIST Special Publication 800- 146, NIST Cloud Computing Synopsis and Recommendations.

A public cloud is one in which the cloud infrastructure and computing resources are made avai lable to the general public over a public network. A public cloud is owned by an organization selling cloud services and serves a diverse pool of clients. For private clouds, the cloud infrastructure is operated exclusively for a single organization. A private cloud gives the organization exclusive access to and usage of the infrastructure and computational resources. It may be managed either by the organization or by a third party, and may 4.3 .1 S E R V IC E DEP LOYME NT NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP be implemented at the organization’s premise (i.e., on-site private clouds ) or outsourced to a hosting company (i.e., outsourced private clouds ).

Similar to private clouds, a community cloud may be managed by the organizations or by a third party, and may be implemented at the customer ’s location (i.e., on-site community cloud) or outsourced to a hosting company (i.e., outsourced community cloud). However, a community cloud serves a set of organizations that have common security, privacy, and compliance considerations, rather than serving a single organization as does a private cloud. A hybrid cloud is a composition of two or more cloud deployment models (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability. As discussed in this section, both private clouds and community clouds can be either implemented on- site or outsourced to a third party. Therefore, each constituent cloud of a hybrid cloud can be one of the five variants. Service orchestration refers to the arrangement, coordination, and management of cloud infrastructure to provide the optimizing capabilities of cloud services, as a cost -effective way of managing IT resources, as dictated by strategic business requirements. Figure 5 shows the general requirements and processes for cloud providers to build each of the three service models. Figure 5 – Cloud Provider: Service Orchestration 4.3 .2 S E R V IC E O RCHE ST R A TIO N NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP A three-layered framework is identified for a generalized cloud system in Figure 5. The top layer is the service layer, where a cloud provider defines and provisions each of the three service models.

This is where cloud consumers consume cloud services through the respective cloud interfaces.

The middle layer is the resource abstraction and control layer. This layer contains the system components that a cloud provider uses to provide and manage access to the physical computing resources through software abstraction. The layer typically includes software elements such as hypervisors, virtual machines, virtual data storage, and other resource abstraction and management components needed to ensure efficient, secure, and reliable usage. While virtual machine technology is commonly used at this layer, other means of providing the necessary software abstractions are not precluded. This layer provides “cloud readiness” with the five characteristics defined in the NIST definition of cloud computing.

The lowest layer in the framework is the physical resource layer, which includes all the physical computing resources. This layer includes hardware resources, such as computers (CPU and memory), networks (routers, firewalls, switches, network links, and interfaces), storage components (hard disks), and other physical computing infrastructure elements. It also includes facilities resources, such as heating, ventilation, and air conditioning (HVAC), power, communications, and other aspects of the physical plant. Note that in this framework, th e horizontal positioning of layers implies a stack in which the upper layer has a dependency on the lower layer. The resource abstraction and control layer build virtual cloud resources on top of the underlying physical resource layer and support the service layer where cloud services interfaces are exposed. The three service models can be built either on top of one another (i.e., SaaS built upon PaaS and PaaS built upon IaaS) or directly upon the underlying cloud infrastructure. For example, a SaaS ap plication can be implemented and hosted on virtual machines from IaaS or directly on top of cloud resources without using IaaS. Cloud Service Management includes all of the service- related functions that are necessary for the management and operation of those services required by or proposed to cloud consumers. As illustrated in Figure 6, cloud service management can be described from the perspective of business support, provisioning and configuration, and from the perspective of portability and interoperability requirements. 4.3 .3 C LO UD S E R V IC E M AN AG EM EN T NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Figure 6 – Cloud Provider: Cloud Service Management “As the Federal Government moves to the cloud, it must be vigilant to ensure the security and proper management of government information to protect the privacy of citizens and national security” (by Vivek Kundra, Feder al Cloud Computing Strategy, February 2011.) In July 2012, the U.S. Department of Defense released a Cloud Computing Strategy, which stated “the Department has specific cloud computing challenges that require careful adoption considerations, especially in areas of cybersecurity, continuity of operations, information assurance (IA), and resilience.” Also, in November 2012, NIST published a White Paper – Challenging Security Requirements for U.S.

Government Cloud Computing Adoption. This document provides an overview of the high -priority security challenges perceived by federal agencies as impediments to the adoption of cloud computing. 4.3 .4 S E C U RIT Y NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Security is a cross-cutting function that spans all layers of the reference architecture (see Figure 12 – The Combined Conceptual Reference Diagram), involving end -to -end security that ranges from physical security to application security, and in general, the responsibility is shared between cloud provider and federal cloud consumer. For example, the protection of the physical resource layer (see Figure 5 – Cloud Provider: Service Orchestration) requires physical security that denies unauthorized access to the building, facility, resource, or stored information. Cloud Providers should ensure that the facility hosting cloud services is secure and that the staff has proper background checks. When data or applications are moved to a cloud, Cloud Consumers ensure that the cloud offering satisfies the security requirements and enforces the compliance rules. Several U.S. government agencies provide computer security guidance, and that the cloud system should support the most up- to-date guidance. It is also important to note that security, compliance, and policy requirements are a function of the legal jurisdiction of the country in which the cloud services are provided and can vary from country to country. An independent audit (see Section 3.4) should be conducted to verify the compliance with regulations or security policies. Cloud providers should protect the assured, proper, and consistent collection, processing, communication, use, and disposition of personal information (PI) and personally identifiable information (PII) in the cloud system. PII is the information that can be used to distinguish or trace an individual’s identity, such as name, social security number, biometric records, etc., alone, or when combined with other personal or identifying information that is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc. The CIO Council – Privacy Committee 14 has identified privacy and protection of collected PII as one of the federal government key business imperatives. Though cloud computing provides a flexible solution for shared resources, software, and information, it also poses additional privacy challenges to consumers using the clouds. The Digital Government Strategy 15 issued by the Federal Chief Information Officer (CIO) on May 23, 2012 sets forth a new vision of how government is to connect with and provide services to the American people, harnessing the power of digital technology and enabling citizens and the federal workforce to securely access government digital information, data, and services anywhere, and 14 https://cio.gov/about/committees/privacy -committee/ 15 Digital Government: Building a 21 st Century Platform to Better Serve the American People (May 23, 2012), (Strategy) http://www.whitehouse.gov/sites/default/files/omb/egov/digital -government/digital -government.html 4 .3 .5 P R IV ACY NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP anytime (Recommendations). 16 The Federal CIO Council released Recommendations for Standardized Implementation of Digital Privacy Controls (Recommendations), which discusses three fundamental privacy controls: PII Inventory, Privacy Impact Assessment (PIA), and Privacy Notice. The Recommendations are that agencies identify and consider all PII that may be collected or otherwise exposed through a particular digital technology, analyze the privacy risks through the data life cycle by conducting and updating a PIA (as needed), and provide notice to individuals of when and how their PII will be collected, used, retained, and disclosed. Furthermore, federal agencies should be aware of the privacy concerns associated with the cloud computing environment where data are stored on a server that is not owned or controlled by the federal government. Privacy impact assessment (PIA) can be conducted, as needed, to measure how well the cloud system conforms to applicable legal, regulatory, and policy requirements regarding privacy. A PIA can help fed eral agencies comply with applicable privacy laws and regulations g overning an individual’s privacy, and to ensure confidentiality, integrity, and availability of an individual’s personal information at every stage of development and operation.

In furthering the milestone action goal of the Digital Government Strategy for addressing digital privacy, records retention, and security issues, the National Archives & Records Administration (NARA) has issued Electronic Records Management (ERM) guidance for digital content created, collected, or maintained by federal agencies 17. NARA also serves as managing partner of the E - Government ERM Initiative, coordinating the development and issuance of enterprise -wide ERM tools and electronic information standards, to support the interoperability of federal agency record systems and improve customer service (e.g., digital records access). 18 16 Recommendations for Standardized Implementation of Digital Privacy Controls (December 2012), https://cio.gov/wp - content/uploads/downloads/2012/12/Standardized_Digital_Privacy_Controls.pdf 17 http://www.archives.gov/records -mgmt/initiatives/erm -guidance.html . 18 http://www.archives.gov/records -mgmt/initiatives/erm -overview.html . 22 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP A cloud auditor is a party that can conduct independent assessment of cloud services, information system operations, performance, and the security of a cloud computing implementation. A cloud auditor can evaluate the services provided by a cloud provider in terms of security controls, privacy impact, performance, and adherence to service level agreement parameters. Auditing is especially important for federal agencies as “agenci es should include a contractual section enabling third parties to assess security controls of cloud providers” (by Vivek Kundra, Federal Cloud Computing Strategy, February 2011). Security controls are the management, operational, and technical safeguards or countermeasures employed within an organizational information system to protect the confidentiality, integrity, and availability of the system and its information. For security auditing, a cloud auditor can make an assessment of the security controls in the information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to the security requirements for the system. The security auditing should include the verification of the compliance with regulation and security policy. The NIST Reference Architecture, SP 500 -292, 19 defines a Cloud Broker as an entity that manages the use, performance, and delivery of cloud services, and negotiates relationships between Cloud Providers and Cloud Consumers. As cloud computing evolves, the integration of cloud services may become too complex for cloud Consumers to manage. In such cases, a Cloud Consumer may request cloud services from a Cloud Broker instead of directly contacting a Cloud Provider. Cloud Brokers provide a single point of entry for managing multiple cloud services. The key defining feature that distinguishes a Cloud Broker from a Cloud Service Provider is the ability to provide a single consistent interface to multiple differing providers, whether the interface is for business or technical purposes. In general, Cloud Brokers provide services in three categories: Intermediation: A Cloud Broker enhances a given service by improving some specific capability and providing value-added services to cloud Consumers. The improvement can be managing access to cloud services, identity management, performance reporting, enhanced security, etc. Aggregation: A Cloud Broker combines and integrates multiple services into one or more new services. The Broker provides data and service integration and ensures the secure data movement between the cloud Consumer and multiple cloud Providers. 19 http://www.cloudcredential.org/images/pdf_files/nist%20reference%20architecture.pdf 4.5 C LO UD B R O K ER 4.4 C LO UD A U DIT O R 23 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Arbitrage: Service arbitrage is similar to service aggregation except that the services being combined/consolidated are not fixed. Service arbitrage means a Broker has the flexibility to choose services from multiple service Providers. A Cloud Broker may provide: 1. Business and relationship support services (business intermediation), and 2. Technical support service (aggregation, arbitrage, and technical intermediation), with a key focus on handling interoperability issues among multiple Providers. A cloud carrier acts as an intermediary that provides connectivity and transport of cloud services between cloud consumers and cloud providers. Cloud carriers provide access to consumers through network, telecommunication, and other access devices. For example, cloud consumers can obtain cloud services through network access devices, such as computers, laptops, mobile phones, mobile Internet devices (MIDs), etc. The distribution of cloud services is normally provided by network and telecommunication carriers or a transport agent , where a transport agent refers to a business organization that provides physical transport of storage media such as high -capacity hard drives.

Note that a cloud provider will set up service level agreements (SLAs) 20 with a cloud carrier to provide services consistent with the level of SLAs offered to cloud consumers, and may require the cloud carrier to provide dedicated and encrypted connections between c loud consumers and cloud providers. 20 SLAs are agreements under the umbrella of the overall cloud computing contract between a CSP and a cloud consumer. SLAs define acceptable service levels to be provided by the CSP to its customers in measurable terms. The ability of a CSP to perform at acceptable levels is consistent among SLAs, but the definition, measurement and enforcement of this performance varies widely among CSPs. A cloud consumer should ensure that CSP performance is clearly specified in all SLAs, and that all such agreements are fully incorporated, either by full text or by reference, into the CSP contract. [Source: Creating Effective Cloud Computing Contracts for the Federal Government – Best Practices for Acquiring IT as a Service https://cio.gov/wp- content/uploads/downloads/2012/09/cloudbestpractices.pdf 4.6 C LO UD C A RR IE R 24 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Cloud computing use cases describe the consumer goals and actions for using cloud computing service offerings. Analyzing business and technical cloud computing use cases and the applicable standards provides an intuitive, utility -centric perspective for identifying requirements for all actors in the use case. This section leverages the business and technical use case outputs from other NIST Cloud Computing Program Working Groups. Section 8 presents an analysis regarding whether existing cloud- related standards fulfill key aspects of the use case for USG cloud consumers and highlights where the gaps for standardizations exist. The Target Business Use Case Working Group produced a template for documenting specific use cases. This template includes a section titled “ Concept of Operations ” in which “Current System” and “Desired Cloud Implementation” states are described. The template also gathers information about integration with other systems, security requirements, and both local and remote network access considerations. A set of business use cases was collected describing candidate USG agency cloud deployments. The stories captured in these business use cases help to identify business drivers behind the adoption of cloud computing in USG agencies, provide background information on the relevant usage context, and expose general agenc y consumer concerns and issues through specific scenarios. These use cases thus helped to document key technical requirements for USG cloud- related standards in the areas of security, interoperability, and portability studied for the formulation of this r oadmap. Efforts are now underway to document similar requirements with respect to other key considerations, such as accessibility and performance of federal cloud -based business systems and services. The “Cloud First” 21 directive provided by the Federal CIO is a more general expansion of this analysis to multiple interacting current systems and cloud implementations. This expansion is intended to support evolving business processes as further cloud deployments are implemented. 21 25 Point Implementation Plan to Reform Federal Information Technology Management http://www.dhs.gov/sites/default/files/publications/digital -strategy/25 -point -implementation -plan -to -reform -federal - it.pdf 5 .1 B U SIN ESS U SE C A SE S 5 CLOU D COM PUTING USE CASES 25 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP The SAJACC Working Group has analyzed the output of the Business Use Case group, along with other community -provided documents and inputs, and produced a set of detailed cloud computing technical use case scenarios. These technical use cases captured and describe in detail the requirements, inputs, outputs, and failure and success conditions of cloud operations. They provide descriptions of how users or groups of users, called “actors,” interact with one or more cloud computing resource systems to achieve specific goals, such as “how to copy data objects into a cloud,” or “instantiate a virtual machine within a specific security context.” The mapping from the high -level business use cases to the SAJACC technical use cases allows a detailed understanding of ways in which the business operational stories of specific agency consumers identify specific technical requirements. Such requirements, as expressed in SAJACC technical use cases, are then well suited to demonstrat e the applicability of cloud computing software or standards. For example, the business use case of an agency consumer’s move of its virtualized computing infrastructure to an IaaS cloud vendor identifies “Virtual Machine (VM) control: manage virtual machine instance state ” as a technical requirement to be met.

The SAJACC group has gathered detailed examples from U.S. federal agencies and analyzed them in terms of these technical use case scenarios. The results from this effort, along with demonstrations presented to the SAJACC group meetings, have been used to elucidate applicability of standards and the presence of standardization gaps in this current document. The rest of this section drives through the high- level business use cases to the general technical requirements expressed and analyzes where cloud standards help address these requirements. The “Cloud First” business use case requires more complex interactions between USG agency cloud consumer and cloud providers. There are three generic scenarios from which interaction scenarios are derived, as shown in Figure 7. 5.3 D EPL O YM EN T SC ENA RIO P E R SP E C TIV E 5.2 T EC H NIC A L U SE CAS ES 26 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Single Cloud System Figure 7 – High -Level Generic Scenarios Scenario 1: Deployment on a single cloud s ystem Scenario 2: Manage resources on a single cloud system Scenario 3: Interface enterprise systems to a single cloud system Scenario 4: Enterprise systems migrated or replaced on a single cloud system Multiple Cloud Systems (serially, one at a time) Scenario 5: Migration between cloud systems Scenario 6: Interface across multiple cl oud systems 27 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Scenario 7: Work with a selected cloud system 28 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Multiple Cloud Systems – (simultaneously, more than one at a time) Scenario 8: Operate across multiple cloud systems These technical use cases must also be analyzed in the context of their deployment models and the resultant way cloud actors must interact. These considerations identify two fundamental dimensions to the spectrum of cloud computing use cases: • Centralized vs. Distributed, and • Within vs. Crossing Trust Boundaries These deployment cases will drive the requirements for cloud standards. They can be identified through the following matrix: a.) Within Trust Boundary b.) Crossing Trust Boundary 1.) Centralized i.e., one administrative cloud domain Deployment Case 1A Deployment Case 1B 2.) Distributed, i.e., crossing administrative cloud domains Deployment Case 2A Deployment Case 2B Table 2 – Deployment Cases for High Level Scenarios Deployment Case 1: In the centralized deployment cases, there is one cloud provider under consideration at a time. Each cloud provider may service multiple cloud consumers. Each cloud consumer has a simple client -provider interaction with the provider. Deployment Case 1A: This deployment case is typically a private cloud within a single administrative domain and trust boundary wherein policy and governance can be enforced by nontechnical means. Use cases within this deployment case may require standards to support the following basic technical requirements: • Simple, consumer -provider authentication; • VM management; • Storage management; • SLAs and performance/energy monitoring; • Service discovery; • Workflow management; 29 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP • Auditing; and • Virtual organizations in support of community cloud use cases. Deployment Case 1B: This deployment case is typically (commercial) public cloud within a single administrative domain but is outside of any trust boundary that a client could use to enforce policy and governance. Clients must rely on the cloud provider to enforce policy and governance through technical means that are "baked into" the infrastructure. Use cases within this deployment case may require standards to support the following additional technical requirements: • SLAs in support of governance requirements, e.g., national or regional regulatory compliance; • Stronger authentication mechanisms, e.g., Public Key Infrastructure (PKI) Certificates, etc.; • Certification of VM isolation through hardware and hypervisor support; • Certification of storage isolation throug h hardware support; and • Data encryption. Deployment Case 2: In the distributed deployment cases, a single cloud consumer has an application that may be distributed across two or more cloud providers and administrative domains simultaneously. While the cloud consumer may have simple consumer -provider interactions with their application and the providers, more complicated Peer -to -Peer (“P2P”) interactions may be required -- between both the consumer and provider and also between the providers themselves. Deployment Case 2A: This deployment case is typically a federated cloud of two or more administrative cloud domains, but where the cloud providers can agree "out of band" how to mutually enforce policy and governance -- essentially establishing a common trust boundary. Use cases within this deployment case may require standards to support the following basic technical requirements: • P2P service discovery; • P2P SLA and performance monitoring; • P2P workflow management; • P2P auditing; • P2P security mechanisms for authentication, authorization; and • P2P virtual organization management. Deployment Case 2B: This deployment case is typically a hybrid cloud where applications cross a private -public trust boundary, or even span multiple public clouds, where both administrative domains and trust boundaries are crossed. Consumers must rely on the cloud provider to enforce policy and governance through technical means that are "baked into" the infrastructure.

Applications and services may be distributed and need to operate in a P2P manner. Use cases within 30 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP this deployment case will require all the standards of the other deployment cases, in addition to the following more extensive technical requirements: • P2P SLAs in support of governance requirements. The use cases presented in this section will be analyzed with regards to their possible deployment scenarios to determine their requirements for standards. This analysis will subsequently be used to evaluate the likelihood of each of these deployment cases. Clearly the expected deployment of these use cases across the different deployment cases will not be uniform. This non- uniformity will assist in producing a prioritized roadmap for cloud standards. Likewise, in reviewing existing standards, these us e cases – in conjunction with their possible deployment cases – will be used to identify and prioritize gaps in available standards. Based on this analysis, note that Scenarios 1 through 4 could, in fact, be deployed on either a private cloud or a public cloud. Hence, the different standards noted in deployment cases 1A and 1B will be required. Scenarios 5, 6, and 7 (below) all involve the notion of the serial use of multiple clouds.

Presumably these different clouds, used serially, could be either private or public. Hence, deployment cases 1A and 1B would also apply, but there are additional requirements to achieve portability, e.g., Application Programming Interface (API) commonality. Finally, Scenario 8 could involve a federated/community cloud or a hybr id cloud. Hence, deployment cases 2A and 2B would apply here. 31 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP To summarize the detailed technical use cases for this analysis, the following areas of technical requirements are common across all scenarios: Scenarios Technical Requirements 1. Creating, accessing, updating, deleting data objects in cloud systems; 2. Moving VMs and virtual appliances between cloud systems; 3. Selecting the best IaaS vendor for private externally hosted cloud s ystem; 4. Tools for monitoring and managing multiple cloud systems; 5. Migrating data between cloud systems; 6. Single sign -on access to multiple cloud systems; 7. Orchestrated processes across cloud systems; 8. Discovering cloud resources; 9. Evaluating SLAs and penalties; and 10. Auditing cloud systems. Table 3 – Scenarios and Technical Requirements 32 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Standards are already available in support of many of the functions and requirements for cloud computing described in Section 3 and Section 4. While many of these standards were developed in support of pre -cloud computing technologies, such as those designed for web services and the Internet, they also support the functions and requirements of cloud computing. Other standards are now being developed in specific support of cloud computing functions and requirements , such as virtualization. To assess the state of standardization in support of cloud computing, the NIST Cloud Computing Standards Roadmap Working Group has compiled an Inventory of Standards Relevant to Cloud Computing http://collaborate.nist.gov/twiki- cloud- computing/bin/view/CloudComputing/StandardsInventory .

Figure 8 is a high -level conceptualization of ways in which IT standards are developed and methods by which standards -based IT products, processes, and services are deployed. This figure is not meant to imply that these processes occur sequentially. Many of the processes illustrated can and should occur concurrently. Some of these processes (e.g., reference implementations, product / process / service / test tools development, testing, deployment) can and usually do als o occur outside of the SDO process. These processes provide input and feedback to improve the standards, profiles, test tools, and associated stages of product development.

Cloud computing development has been characterized by its emergence during a period in which extremely interconnected and fast -moving product cycles have led to an explosion of innovation that strains the conventional SDO- based standards development process. While this is a rapidly changing area, cloud computing is not unique in this respect, and several other examples exist in history of similar periods of rapid change followed by standardization. In the long run, the processes that drive IT standards development are likely to follow historical precedent as over -arching requirements begin to become clear, and as standards emerge from such processes to fill these requirements. We therefore expect conformance testing, conformity assessment, and other processes related to the maturity and adoption of standards to emerge. Some evidence of this maturity is already starting to become manifest in the cloud standards landscape. 6.1 INF ORM ATION AND COM M UN ICA TI ON TE CHNOLOGIES (IT) STAN DARDS LIF E CY CLE 6 CLOU D COM PUTING STANDARDS 33 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Figure 8 – IT Standards Life Cycle Conformity assessment activities form a vital link between standards, which define necessary characteristics or requirements, and the products, services, and systems. Conformity assessment enables buyers, sellers, consumers, and regulators to have confidence that products, processes, and systems sourced in the global market meet specific requirements. It is the demonstration that specified requirements relating to a product, process, or system are fulfilled. The charact eristics of cloud computing including on -demand, self -service, and resource pooling among multiple tenants need to be considered when establishing conformance regimes for cloud services. For example, conformance testing may need to be done online against a production system 6.2 T H E R O LE O F C O NFO RMI TY A SSE SSM EN T T O S T A NDA RD S 34 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP that includes data and applications owned and controlled by other tenants. But privacy may preclude inspection of system logs, and it may not be possible to inspect the source code or run debugging tools. Test harnesses may not be able to be built into the service but may need to be run as a client 35 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP to the cloud service. It may be necessary to establish an account in order to access the service for testing. Conformity assessment procedures provide a means of ensuring that the products, services, systems, persons, or bodies have certain required characteristics, and that these characteristics are consistent from product to product, service to service, system to system, etc. Conformity assessment can include: supplier's declaration of conformity, sampling and testing, inspection, certification, management system assessment and registration, the accreditation of the competence of those activities, and recognition of an accreditation program's capability. A specific conformity assessment scheme or program may include one or more conformity assessment activities. While each of these activities is a distinct operation, they are closely interrelated. Conformity assessment activities can be performed by many types of organizations or individuals.

Conformity assessment can be conducted by: (1) a first party, which is generally the supplier or manufactur er; (2) a second party, which is generally the purchaser or user of the product; (3) a third party, which is an independent entity that is generally distinct from the first or second party and has no interest in transactions between the two parties; and (4 ) the government, which has a unique role in conformity assessment activities related to regulatory requirements. Attestation consists of the issuance of a statement, based on a decision following review, that fulfillment of specified requirements has been demonstrated. First -party and third- party attestation activities are distinguished by the terms declaration (first party), certification (third party), and accreditation (third party). A supplier’s declaration of conformity is a first party (e.g., supplier) attestation that a product, process, service, etc., conforms to specified requirements. These requirements may include normative documents such as standards, guides, technical specifications, laws, and regulations. The supplier may conduct the te sting or contract with a third party to do the testing. The test results are evaluated by the supplier, and when all requirements are met, the supplier issues a formal statement that the product is in conformance to the requirements. A statement that the product meets specific requirements can be included in the product documentation or other appropriate location, and the test results and other supporting documentation can be made available when requested.

Certification is a third -party attestation related to products, services, systems, etc. Accreditation is a third -party attestation related to a conformity assessment body conveying formal demonstration of its competence to carry out specific conformity assessment tasks. Testing laboratory accreditation pr ovides formal recognition that a laboratory is competent to carry out specific tests or calibrations or types of tests or calibrations. Rapidly advancing technology and increased international competition make it essential that suppliers have an opportuni ty to utilize all available options to minimize costs and ensure that the time to bring a product to market is at a minimum. Conformity assessment is an important aspect in 6.2 .1 C O NFO RM IT Y A SSE SSME NT A CTIV IT IE S 36 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP the development of product, processes and services, but this assessment does add costs and time to the development cycle. Federal conformity -assessment activities are a means of providing confidence that the products, services, systems, etc. regulated or purchased by federal agencies, or that are the subject of federal assistance programs, have the required characteristics and/or perform in a specified manner. The NTTAA directs NIST to coordinate federal, state, and local government standards and conformity assessment activities with those of the private sector, with the goal of eliminating unnecessary duplication and complexity in the development and promulgation of conformity assessment requirements and measures. Conformity assessment that leverages existing private -sector programs can help lower the cost of implementation for agencies, and also provide added impetus for innovation and competitiveness. Numerous federal agencies are engaged in conformity assessment activities. In addition, as part of its role mandated by the NTTAA, many federal programs utilize NIST support to help design and implement appropriate and effective conformity assessment programs. 6.2 .2 GOV ER NM EN T U SE O F C O NFO RM IT Y A SSE SSMEN T S Y ST EM S 37 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Figure 9 – Conformity Assessment Infrastructure provides an overview of the range of activities that can occur in conformity assessment and the relationships between them.

Figure 9 – Conformity Assessment Infrastructure 6.2.3 VISUAL IZATION OF CONFO RMITY ASSESSMENT PROCESSES 38 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Figure 10 – Accreditation Process shows the relationships for the laboratory accreditation process.

The key aspect of the process is the identification of the standards, test methods, test tools, and other technical requirements by the procurement agency as they apply to the products, services, systems, etc., to be tested. Figure 10 – Accreditation Process 39 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP An example of a conformity assessment system using accredited testing laboratories and certification is provided in Figure 11 – Assessment Process. The process starts with the submission by the supplier of the product, service, or system to a third- party accredited testing laboratory. The laboratory tests the product in accordance with t he requirements and forwards the test results to the supplier. If the results are satisfactory to the supplier, they will be forwarded by the laboratory to the validation authority designated by the procurement agency in coordination with the qualified pro ducts list (QPL) owner. These experts will review the test reports and will make a recommendation as to their acceptance to the QPL owner. If the QPL owner agrees with the recommendations, the product, service, or system will be listed. Figure 11 – Assessment Process As described elsewhere in this document, standards specific to cloud computing are beginning to emerge, and several aspects of the conformance testing and conformity assessment processes described above are also starting to take place, conducted by a variety of organizations. In some cases, such as the CDMI, OCCI, OVF, and CIMI standards discussed below, industry -sponsored testing events and “plug -fests” are being advertised and conducted wit h participation from a variety of vendors and open source projects and community -based developers. In other cases, either the standards are not yet mature enough to permit such testing, or the participants have not yet exposed the conformity assessment processes to public view. 6.2 .4 C U RREN T S T A TE O F C O N FO RM IT Y A SS E SSM EN T I N C LO UD C OM PUTIN G 40 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Innovation in IT means that IT standards are constantly being developed, approved, and maintained.

Revisions to previous editions of standards may or may not be backward -compatible. Table 4 – Standards Maturity Model provides an indication of the maturity level of a standard. Some SDOs require two or more implementations before final approval of a standard. Such implementations may or may not be commercially available products or services. In other cases, an SDO may b e developing standards while commercial products or services are already being sold that conform to early drafts. (In such cases, companies take on the risk of creating products or services that may not conform to the final standard.) Maturity Level Definition No Standard SDOs have not initiated any standard development projects. Under Development SDOs have initiated standard development projects.

Open source projects have been initiated. Approved Standard SDO -approved standard is available to public. Some SDOs require multiple implementations before final designation as a “standard.” Technically Stable The standard is stable and its technical content is mature. No major revisions or amendments are in progress that will affect backward compatibility with the original standard. Reference Implementation Reference implementation is available. Testing Test tools are available. Testing and test reports are available. Commercial Availability Several products/services from different vendors exist on the market to implement this standard. Market Acceptance Widespread use by many groups. De facto or de jure market acceptance of standards -based products/services. Sunset Newer standards (revisions or replacements) are under development. Table 4 – Standards Maturity Model 6.3 C A TEG ORIZ IN G T H E S T A TU S O F S T A N DAR DS 41 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Cloud platforms should make it possible to securely and efficiently move data in, out, and among cloud providers and to make it possible to port applications from one cloud platform to another.

Data may be transient or persistent, structured or unstructured and may be stored in a file system, cache, relational or non -relational database. Cloud interoperability means that data can be processed by different services on different cloud systems through common specifications. Cloud portability means that data can be moved from one cloud system to another and that applications can be ported and run on different cloud systems at an acceptable cost. The migration path to cloud computing should preserve existing investments in technologies which are appropriate to the cloud system, and that enables the coexistence and interoperability of on- premises software and cloud services. Additionally, the migration to a cloud system should enable various multiple cloud platforms seamless access between and among various cloud services, to optimize the cloud consumer expectations and experience.

Cloud interoperability allows seamless exchange and use of data and services among various cloud infrastructure offerings and to use the data and services exchanged to enable them to operate effectively together. Cloud portability allows two or more kinds of cloud infrastructures to seamlessly use data and services from one cloud system and be used for other cloud systems.

For example, a financial application might use a petabyte of data, but that data might be securely housed in a single cloud database, making it relatively easy to port. On the other hand, a customer relationship management (CRM) application running in the cloud system might process only a terabyte of data but which is shared among thousands of users; moving the CRM application – and all its distributed data – from one cloud system to another would be more challenging. Overall, functionality of cloud interoperability is prefer able.

Interoperability may be assessed in terms of the NIST Cloud Computing Reference Architecture at the IaaS, PaaS, and SaaS levels. Each of these levels, which may be combined in any particular cloud service or product in practice, presents special considerations, and as a result, the standards landscape is intrinsically unique and specific to each level. At the IaaS level, two published standard sets exist that are applicable, the Open Cloud Computing Interface (OCCI) spe cification set from Open Grid Forum and the Cloud Infrastructure Management Interface (CIMI) set from the Distributed Management Task Force (DMTF). OCCI, published in early 2011, is slightly more general in formulation and presents a generic boundary - level protocol for achieving RESTful control of a target infrastructure within the given boundary. It has been applied to virtual machine instantiation and control, provision and discovery of network 6.4 .1 C LO UD S T A N DARD S F O R I N TER O PE R A BIL IT Y 6.4 C LO UD C O M PU TIN G S T A N DARD S F O R I N TER OPE R A BIL IT Y A ND P O RTA BIL ITY 42 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP features and other internal features, and has an extensible, self -describing feature set. CIMI, more recently developed and published in late 2012, has a tightly described calling sequence and also provides features that conform to DMTF’s C ommon Information Model (CIM). Each of these standard sets has seen significant uptake, and several available cloud system products either already implement or plan to implement at least one of them. While these IaaS standard sets are so far separate, OGF and DMTF have stated that they have a work register in place and that they continue to discuss the possibility of merging these efforts in the future. In PaaS applications, an extensive ecosystem of vendor -specific products that are not interchangeable h as emerged. A recent effort to produce a PaaS -specific standard 22 has been started by the OASIS Cloud Application Management Protocol (CAMP) technical committee, with support from several industry participants, and is making rapid progress towards producing a workable specification. In the case where a SaaS application is consumed through a web browser, there may be many standards that are used to achieve interoperability between what is essentially a web server and the user ’s browser, such as IP (v4, v6), TCP, HTTP, SSL/TLS, HTML, XML, REST, Atom, AtomPub, RSS, and JavaScript/JSON. None of these web standards are cloud- specific, and these same standards are being used in many web browser -based management interfaces. Where data is acted on by multiple services, cloud or otherwise, there are various standards that enable interoperability. Also important are interoperability standards for distributed applications such as SOAP, WS -* and ebXML. Other standards that can be used for interoperability between cloud services include OpenID, Odata, CDMI, AMQP, and XMPP. Most important for interoperability are canonical data content formats, typically today expressed using XML standards.

Such standard canonical formats include “nouns,” i.e., the data objec ts being acted on, but also (implicitly or explicitly) the “verbs,” i.e., the actions that a receiving service may or should take on such a data object (e.g., Sync, Process, Get, Show, etc.). While “verbs” may be somewhat generic, such canonical formats are in general specific to a particular domain. Various standards exist corresponding to different application domains (e.g., OAGi BODs for business documents or ODF and OOXML for office productivity documents). Also important is the stack of interoperabi lity standards for interfaces, packaging, and transport such as SOAP, WS -* and ebXML. Since the SaaS area is so wide- ranging, cloud-based SaaS products are likely to continue to exercise and to explore the full range of Internet protocols for their communi cation and interfaces. It is more likely that data formats and metadata -based interchange methods will be standardized in cloud system products rather than having SaaS interfaces themselves converge. Examples of such 22 ID Cloud -PaaS https://www.oasis -open.org/committees/download.../IDCloud- paa s-v1c.odt 43 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP data format description standardization include the Data Format Description Language (DFDL) from OGF and the Cloud Data Management Interface (CDMI) data- container metadata model of the Storage Networking Industry Association (SNIA). As the cloud computing landscape is currently heavily populated by vendor -specific formats, such general -purpose standardization efforts may be crucial to achieving interoperability at the SaaS level. As appropriate, some of these interfaces will be tested and analyzed by NIST to validate their capabilities against the list of cloud computing use cases. Opportunities will also be m ade available for the vendor and open source community to demonstrate the applicability of standards and APIs to the defined NIST SAJACC cloud computing technical use cases. Over the last year, much progress has been made on new standards in this area. Open Virtualization Format (OVF) from the Distributed Management Task Force (DMTF), for example, was developed to address portability concerns between various virtualization platforms. It consists of metadata about a virtual machine image or groups of images that can be deployed as a unit. It provides a mechanism to package and deploy services as either a virtual appliance or used within an enterprise to prepackage known configurations of a virtual machine image or images. It may contain information regarding the number of CPUs, memory required to run effectively, and network configuration information. It also can contain digital signatures to ensure the integrity of the machine images being deployed along with licensing information in the form of a machine- readable EULA (End User License Agreement) so that it can be understood before the image(s) is deployed. Significant progress has also been made in the creation of new standards focused on portability concerns at higher levels of abstraction such as the cloud service and application. Topology and Orchestration Services for Applications (TOSCA) from OASIS, for example, was developed to address portability concerns between services and applications that may be required to be deployed on different cloud providers and platforms due to reasons such as regulatory concerns, changing business and market factors, or evolving technical requirements. TOSCA provides a machine - readable language to describe the relationships between components, requirements, and capabilities.

The intent is to facilitate service and life cycle management of services and applications in Iaa S, PaaS, and SaaS environments while enabling the specification of life cycle operations at that level of abstraction, e.g., deploy, patch, shutdown, in a cloud platform and provider independent fashion.

As of February 2013, the TOSCA specification had completed a 30- day public review. A primer, which includes a chapter on the relationship between OVF and TOSCA is under development. A future direction of workloads data and metadata standardization is to help improve the automation of inter -cloud system workload deployment. Concepts such as standardized SLAs, sophisticated inter -virtual machine network configuration and switching information, and software license information regarding all of the various components that make up the workload are possibilities. 6.4 .2 C LO UD C OM PU TIN G S T A N DARD S FO R PO RTA BIL IT Y 44 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Another aspect of portability in the cloud system is that of storage and data (including metadata) portability between cloud systems, for example, between storage cloud services and between compatible application services in SaaS and PaaS layers. Cloud storage services may be seen as a special class of application service, where the storage metadata (as distinct from the stored data content) is the application data that a receiving cloud system must be able to process. For cloud storage services, as much of the actual data movement needs to be done in bulk moves of massive numbers of objects, retaining the data organization (into containers, for example) and retaining the associated metadata are main portability requirements. Data portability between cloud application services requires standard formats and protocols. The canonical data formats commonly involved in portability scenarios may be focused on widely used application categories, for example, email or of fice productivity, or on specific formats used by particular domains of use, for example, science or medical domains. Popular methods for interchange of data in cloud systems generally leverage representations in either JSON or XML formats, and are often customized to particular fields of use through standards.

Standards are key to achieving portability. Building on existing standards and specifications that are known to work and are in widespread use and documenting how the standards are implemented, all ows developers to continue to use their chosen development languages and tools as they build for cloud systems. This keeps migration costs and risks low by enabling organizations to leverage their IT staff’s current skills, and by providing a secure migrat ion path that preserves existing investments. Examples of languages, tools, and standards that are common in the cloud system include programming languages such as Java, C#, PHP, Python and Ruby; Internet protocols for service access such as REST, SOAP, and XML; federated identity standards for service authentication such as SAML and OAuth; and standards for managing virtualized environments.

Standards continue to rapidly evolve in step with technology. Hence, cloud standards may be at different stages of maturity and levels of acceptance. OVF, for example, is an open standard for packaging and distributing virtual appliances. Originally offered as a proprietary format to the DMTF, OVF was first published in March 2009, and subsequently adopted in August 2010 as a national standard by the American National Standards Institute (ANSI). When a provider claims conformance with any other standard, it should cite the specific version and publish implementation, errata, and testing notes. This will provide the transparency necessary for informed consumer choice, as well as ensure reasonably seamless technical interoperability between on- premises and cloud virtualized systems.

Substantial progress has been made by SDOs to develop standards that meet specific cloud computing requirements and use cases. There are now existing standards that support cloud service interoperability and data portability but gaps remain in the standards, specifically in the PaaS area, 6.4 .3 S U MMA RY O N IN TER OP ER A BIL IT Y AN D P O RTA BIL IT Y 45 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP and current development efforts still need to mature. As cloud standards evolve, they will need to describe how services intero perate and how data can be readily ported between cloud offerings. As cloud standards and IT standards that support cloud implementations change and evolve, the issues of governance and orchestration of cloud architectures will become more prevalent and simultaneously, how to ‘standardize ’ a governance model will need to be updated. Governance of the cloud is analogous to the governance of Internet but rather than standardizing on packets of data, it is standardizing on how data and services are shared. Cloud standards will need to describe how services and data can be readily ported or interoperate between cloud offerings as seamless, efficient access to data and services across cloud providers will become the demand signal from customers. The SAJACC gr oup has received and has begun analyzing input from several SDOs and from federal agencies with regard to this topic, including the area of service agreements and SLAs that is explored further in Section 6.6, “Cloud Standards for Performance”. As noted in SP 800- 146, “the term cloud computing encompasses a variety of systems and technologies as well as service and deployment models, and business models”. Cloud computing’s unique attributes such as elasticity, rapid provisioning and releasing, resource pooling, multi- tenancy, broad -network accessibility, and ubiquity bring many benefits to cloud adopters, but also entails specific security risks associated with the type of adopted cloud and deployment mode. To accelerate the adoption of cloud computing, and to advance the deployment of cloud services, solutions coping with cloud security threats need to be addressed. Many of the threats that cloud providers and consumers face can be dealt with through traditional security processes and mechanisms such as security policies, cryptography, identity management, intrusion detection/prevention systems, and supply chain vulnerability analysis. However, risk management activities must be undertaken to determine how to mitigate the threats specific to different cloud models and to analyze existing standards for gaps that need to be addressed. Securing the information systems and ensuring the confidentiality, integrity, and availability of information and information being processed, stored, and transmitted are particularly relevant as these are the high -priority concerns and present a higher risk of being compromised in a cloud computing system. Cloud computing implementations are subject to local physical threats as well as remote, external threats. Consistent with other applications of IT, the threat sources include accidents, natural disasters that induce external loss of service, hostile governments, criminal organizations, terrorist groups, and malicious or unintentional vulnerabilities exploited through internal, external, authorized, or unauthorized access to the system. The complexity of the cloud computing architecture supporting three service types and four deployment models, and the cloud characteristics, specifically multi- tenancy, heighten the need to consider data and systems protection in the context of logical, physical boundaries and data flow separation. 6.5 C LO UD C O M PU TIN G S T A N DARD S F O R S E C U RIT Y 46 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Possible types of security challenges for cloud computing services include the following: • Compromises to the confidentiality and integrity of data in transit to and from a cloud provider and at rest; • Attacks which take advantage of the homogeneity and power of cloud computing systems to rapidly scale and increase the magnitude of the attack; • A consumer’s unauthorized access (through improper authentication or authorization, or exploit of vulnerabilities introduced maliciously or unintentionally) to software, data, and resources provisioned to, and owned by another authorized cloud consumer; • Increased levels of network -based attacks that exploit software not designed for an Internet -based model and vulnerabilities existing in resources formerly accessed through private networks; • Limited ability to encrypt data at rest in a multi- tenancy environment; • Portability constraints resulting from the lack of standardization of cloud services application programming interfaces (APIs) that preclude cloud consumers to easily migrate to a new cloud service provider when availability requirements are not met; • Attacks that exploit the physical abstraction of cloud resources and exploit a lack of transparency in audit procedures or records; • Attacks that take advantage of known, older vulnerabilities in virtual machines that have not been properly updated and patched; • Attacks that exploit inconsistencies in global privacy policies and regulations; • Attacks that exploit cloud computing supply chain vulnerabilities to include those that occur while cloud computing components are in transit from the supplier to the cloud service provider; • Insider abuse of their privileges, especially cloud provider’s personnel in high risk roles (e.g. system administrators; and • Interception of data in transit (man -in -the -middle attacks). 47 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Some of the main security objectives for a cloud computing implementer should include:

• Protect consumers’ data from unauthorized access, disclosure, modification or monitoring. This includes supporting identity management and access control policies for authorized users accessing cloud services. This includes the ability of a customer to make access to its data selectively available to other users. • Prevent unauthorized access to cloud computing infrastructure resources. This includes implementing security domains that have logical separation between computing resources (e.g. logical separation of customer workloads running on the same physical server by VM monitors [hypervisors] in a multi- tenant environment) and using secure- by -default configurations. • Deploy in the cloud web applications designed and implemented for an Internet threat model. • Challenges to prevent Internet browsers using cloud computing from attacks to mitigate end -user security vulnerabilities. This includes taking measures to protect internet - connected personal computing devices by applying security software, personal firewalls, and patch maintenance. • Include access control and intrusion detection and prevention solutions in cloud computing implementations and conduct an independent assessment to verify that the solutions are installed and functional. This includes traditional perimeter security measures in combination with the domain security model. Traditional perimeter security includes restricting physical access to network and devices; protecting individual components from exploitation through security patch deployment; setting as default most secure configurations; disabling all unused ports and services; using role -based access control; monitori ng audit trails; minimizing privileges to minimum necessary; using antivirus software; and encrypting communications. • Define trust boundaries between cloud provider(s) and consumers to ensure that the responsibilities to implement security controls are clearly identified. • Implement standardized APIs for interoperability and portability to support easy migration of consumers’ data to other cloud providers when necessary.

48 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP There are numerous reasons why cloud computing standards for performance are needed in today’s market. Consumers need to be able to objectively determine the costs and benefits of moving to cloud services; to validate c laims of performance by cloud providers; and to objectively compare services from multiple providers in order to better meet a specific need. Determining performance involves establishing a set of metrics that will provide a clear picture of how a given cloud service performs. This is complex due to the fact that specific metrics and standards will be needed for not only specific categories of services, but also due to the domains in which they are needed. For example, dealing with private healthcare data will need performance standards relating to both privacy and security. Standards might be needed for attributes that are associated with the service such as network performance. Additionally, standards are needed that measure attributes specific to cloud service such as virtual machine performance.

While not an exhaustive list, other potential performance aspects relevant to the cloud include:

• Management performance • Benchmark performance • Cloud service life cycle elements:

o Negotiation performance o Instantiation performance o Termination performance • Performance testing o Monitoring o Auditing In the end, these performance standards will be of interest to many of the stakeholders involved in cloud computing. Cloud consumers and providers will use these standards and metrics as a basis for creating measurable and enforceable service level agreement contracts. Auditors will be able to measure performance for their customers. Cloud brokers will need these standards to ensure that their cust omer’s specific needs are met. Cloud providers will be performing self -evaluations on their own offerings.

6.6 C LO UD C O M PU TIN G S T A N DARD S F O R P E R FO RM ANC E 49 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP The topic of performance includes considerations related to monitoring, reporting, measuring, scaling, and right -sizing cloud resources to meet the expected or experienced demand. This area deserves careful consideration, as it relates directly to the factors that control the potential cost savings to the government from the use of cloud computing.

Performance can potentially be scaled to meet condit ions of anticipated or real-world demand, within the parameters of a cloud service agreement. It is therefore crucial that such agreements contain all necessary parameters that relate to the conditions for delivery of the associated cloud service or product. Only by careful measurement and by proper anticipation of peak workload conditions, backed by appropriate service remedies, credits, or penalties and appropriate fallback arrangements, can true cost savings be realized with proper delivery of serv ices. Agencies using cloud services should be careful to include suitable performance, monitoring, and emergency metrics and conditions into the cloud service master agreement and associated SLA.

These elements, reflecting the agencies given mission and goals, will help to ensure that each agency will pay only for needed services.

Cloud services are particularly well suited to deployment of automated terms and conditions for the delivery of these services. While the basic parameters, legal, and cost controls for cloud services require agency approval and human- mediated review, automated tools should be deployed where appropriate to ensure conditions such as failover in the event of cloud service component failure or compromise, and scaling to meet emergent needs or to grow or shrink service delivery according to cost and/or demand, and other relevant features. Wherever possible, standards -based methods for monitoring, measuring, and scaling d elivery of the resources to meet agency missions should be pursued.

At the moment, most cloud service agreements are expressed in human- readable terms for review by legal staff and management. Tools are increasingly available, however, for expression of service agreement conditions, remedies, and provisions that can be expressed in machine- readable terms and that can even serve as the basis for service templates that can be provisioned automatically, directly from the service agreement template. Examples of these methods can be seen in several open source products based on the WS - Agreement and WS -Agreement -Negotiation specifications from OGF. Recent work from an inter- SDO joint task force led by TM Forum has also produced a white paper 23 describing the 23 https://www.tmforum.org/WhitePapers/CloudMonetization/47730/article.html 6.6 .1 C LO UD S T A N DARD S F O R S E R V IC E A G REE M EN TS 50 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP considerations for end-to -end service agreement management specifically oriented towards management of multiple cloud service SLAs. The possibility of “ TOSCA service template extension to support SLA management and possible mapping to SID informatio n framework,” is also discussed. The TM Forum has developed a set of standards to help in the implementation and management of services that span multiple partners in a “multi- cloud” system. Organized as "packs", these standards focus on managing service l evel agreements between partners, and ensure consistency in the management of information across aggregated services with particular emphasis where these services cross multi- company boundaries. There are Business, Technical, and Accelerator Packs that have been published; these documents augment the Cloud Service Level Agreement Handbook (GB917) that was published by the TM Forum in April 2012. The TM Forum has also developed a series of documents working primarily with large -scale enterprises and ensur ing that their best practice needs are met in the delivery of cloud services. The situation with regard to cloud service monitoring is less well developed than for other areas due to the multiplicity of underlying products and the lack of a single set of well -defined monitoring and metric terms. To address this need, the NIST Cloud Computing Reference Architecture and Taxonomy group is developing a set of terms related to monitoring and metrics for service agreements, including SLAs. The input from this group and from the TM Forum -led joint cross -SDO report discussed above will be used by the Business Use Case and SAJACC groups to develop use case scenarios that can be used to identify appropriate standards and standards gaps in this area. ITU-T’s establishment of a cloud computing resource management area of study, a roadmap for the area of study and the initiation of related supporting standards, is beginning to address the closure of some of the standards gaps in cloud computing monitoring. The roadmap outlines the standards that are needed in order to monitor the health, QoS, and reliability of cloud services that are based on the aggregation of services from one or more cloud service providers. Accessibility is relevant to cloud computing services at the application level where a human interacts with an application. This is where accessibility is measured. Therefore, many of the existing accessibility standard s for ICT applications are relevant to cloud computing applications. The U.S. Access Board is an independent federal agency devoted to accessibility for people with disabilities. The Access Board develops and maintains design criteria for the built environment, transit vehicles, telecommunications equipment, and for electronic and information technology. It 6 .7 C LO UD C O M PU TIN G S T A ND ARD S F O R A CC ESS IBILI TY 6.6 .2 C LO UD S T A N DARD S F O R M ONIT O RIN G 51 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP also provides technical assistance and training on these requirements and on accessible design and enforces accessibility standards that cover federally funded facilities. Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d), requires that Federal employees with disabilities have access to and use of information and data that are comparable to the access and use by federal employees who are not individuals with disabilities. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a federal agency, have access to and use of information and data that are comparable to that provided to the public who are not individuals with disabilities. Both of these requirements must be met unless an undue burden would be imposed on the agency. Section 508 standards that would be applicable for many cloud computing applications are:

Subpart B -- Technical Standards 1194.21 Software applications and operating systems; § 1194.22 Web -based intranet and internet information and applications; and 1194.23 Telecommunications products. The Access Board is in the process of revising the Section 508 standards. This is the first major revision since the standards were initially published in 2001. The initial product oriented approach to requirements is bei ng replaced with a more functional approach. The Access Board plans to reference the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0 ( http://www.w3.org/TR/WCAG20/ ), which is an international voluntary consensus guideline. Additional voluntary consensus standards that may be applicable to cloud computing applications are: ISO 9241- 20:2008, Ergonomics of human- system interaction -- Part 20: Accessibility guidelines for information/communication technology (ICT) equipment and services; ISO 9241- 171:2008, Ergonomics of human- system interaction -- Part 171: Guidance on software accessibility; ANSI/HFES 200 Human Factors Engineering of Software User Interfaces (Parts 1, 2, and 3); and ISO/IEC 24751- 1:2008, Information technology -- Individualized adaptability and accessibility in e- learning, education and training -- Part 1: Framework and reference model.

The White House released a memorandum Strategy Plan for Improving Management of Section 508 of the Rehabilitation Act, January 24, 2013 24. The strategic plan provides a comprehensive and structured approach to further improve agencies’ management of th e requirements of Section 508.

The objective is to ensure that all electronic and information technology (EIT) that is developed, procured, maintained, or used by the federal government is accessible, as required by Section 508 of the Rehabilitation Act of 1973. 24 www.whitehouse.gov/sites/default/files/omb/procurement/memo/strategi -plan -508 -compliance.pdf 52 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP One approach to cloud computing standards mapping is to map relevant standards using the conceptual model and the cloud computing taxonomy from the NIST Cloud Computing Reference Architecture and Taxonomy Working Group. As presented in Figure 12, the cloud computing conceptual model is depicted as an integrated diagram of system, organizational, and process components. The cloud computing taxonomy produced by the same working group has provided further categorizations fo r the security, interoperability, and portability aspects for cloud computing.

While many standards are generally relevant to these cloud computing areas, the following sections will map those specifically relevant cloud standards and capture their standard maturity status in a tabular format. The online cloud standards inventory (as described in Section 5) will be the place to maintain and track other relevant standards. Some standards may apply to more than one category from the cloud taxonomy and therefore may be listed more than once. 0 Figure 12 – The Combined Conceptual Reference Diagram 7 CLOU D COM PUTING STANDARDS M APPING 53 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP The following tables map security standards to various security categories and list the status (ref:

Section 6.3/ Table 4 – Standards Maturity Model). Some of the listed standards apply to more than one category and are therefore listed more than once. Categorization Available Standards SDO Status Authentication & Authorization RFC 5246 Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) IETF Approved Standard Market Acceptance RFC 3820: X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile IETF Approved Standard Market Acceptance RFC5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile IETF Approved Standard Market Acceptance RFC 5849 OAuth (Open Authorization Protocol) IETF Approved Standard Market Acceptance ISO/IEC 9594 -8:2008 | X.509 Information technology -- Open Systems Interconnection -- The Directory: Public - key and attribute certificate frameworks ISO/IEC & ITU - T Approved Standard Market Acceptance ISO/IEC 29115 | X.1254 Information technology -- Security techniques -- Entity authentication assurance framework ISO/IEC & ITU - T Approved Standard FIPS 181 Automated Password Generator NIST Approved Standard Market Acceptance FIPS 190 Guideline for the Use of Advanced Authentication Technology Alternatives NIST Approved Standard Market Acceptance FIPS 196 Entity Authentication Using Public Key Cryptography NIST Approved Standard Market Acceptance OpenID Authentication OpenID Approved Standard Market Acceptance eXtensible Access Control Markup Language (XACML) OASIS Approved Standard Market Acceptance Security Assertion Markup Language (SAML) OASIS Approved Standard Market Acceptance Table 5 – Security Standards: Authentication and Authorization 7.1 S E C U RIT Y S T A N DA RD S M APP IN G 54 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Categorization Available Standards SDO Status Confidentiality RFC 5246 Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) IETF Approved Standard Market Acceptance Key Management Interoperability Protocol (KMIP) OASIS Approved Standard Market Acceptance XML Encryption Syntax and Processing W3C Approved Standard Market Acceptance FIPS 140- 2 Security Requirements for Cryptographic Modules NIST Approved Standard Testing Market Acceptance FIPS 185 Escrowed Encryption Standard (EES) NIST Approved Standard Market Acceptance FIPS 197 Advanced Encryption Standard (AES) NIST Approved Standard Testing Market Acceptance FIPS 188 Standard Security Label for Information Transfer NIST Approved Standard Market Acceptance Table 6 – Security Standards: Confidentiality Categorization Available Standards SDO Status Integrity XML signature (XMLDSig) W3C Approved Standard Market Acceptance FIPS 180 -4 Secure Hash Standard (SHS) NIST Approved Standard Market Acceptance FIPS 186 -4 Digital Signature Standard (DSS) NIST Approved Standard Market Acceptance FIPS 198 -1 The Keyed-Hash Message Authentication Code (HMAC) NIST Approved Standard Market Acceptance Table 7 – Security Standards: Integrity 55 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Categorization Available Standards SDO Status Identity Management X.idmcc Requirement of IdM in Cloud Computing ITU -T Under Development FIPS 201 -1 Personal Identity Verification (PIV) of Federal Employees and Contractors NIST Approved Standard Market Acceptance Service Provisioning Markup Language (SPML) OASIS Approved Standard Web Services Federation Language (WS - Federation) Version 1.2 OASIS Approved Standard WS -Trust 1.3 OASIS Approved Standard Security Assertion Markup Language (SAML) OASIS Approved Standard Market Acceptance OpenID Authentication 1.1 OpenID Foundation Approved Standard Market Acceptance Table 8 – Security Standards: Identity Management 56 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Categorization Available Standards SDO Status Security Monitoring & Incident Response ISO/IEC WD 27035 -1 Information technology -- Security techniques -- Information security incident management -- Part 1: Principles of incident management ISO/IEC Under Development ISO/IEC WD 27035 -3 Information technology -- Security techniques -- Information security incident management -- Part 3: Guidelines for CSIRT operations ISO/IEC Under Development ISO/IEC WD 27039; Information technology -- Security techniques -- Selection, deployment and operations of intrusion detection systems ISO/IEC Under Development ISO/IEC 18180 Information technology - Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.2 (NIST IR 7275) ISO/IEC Approved Standard Market Acceptance X.1500 Cybersecurity information exchange techniques ITU -T Approved Standard Market Acceptance X.1520: Common vulnerabilities and exposures ITU -T Approved Standard X.1521 Common Vulnerability Scoring System ITU -T Approved Standard PCI Data Security Standard PCI Approved Standard Market Acceptance FIPS 191 Guideline for the Analysis of Local Area Network Security NIST Approved Standard Market Acceptance Table 9 – Security Standards: Security Monitoring & Incident Response 57 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Categorization Available Standards SDO Status Security Controls Cloud Controls Matrix Version 1.3 CSA Approved Standard ISO/IEC 27001:2005 Information Technology – Security Techniques Information Security Management Systems Requirements ISO/IEC Approved Standard ISO/IEC WD TS 27017 Information technology -- Security techniques -- Information security management - Guidelines on information security controls for the use of cloud computing services based on ISO/IEC 27002 ISO/IEC Under Development ISO/IEC 27018 Code of Practice for Data Protection Controls for Public Cloud Computing Services ISO/IEC Under Development ISO/IEC 1 st WD 27036 -4 Information technology – Security techniques – Information security for supplier relationships – Part 4: Guidelines for security of cloud services ISO/IEC Under Development Table 10 – Security Standards: Security Controls 58 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Categorization Available Standards SDO Status Security Policy Management ATIS-02000008 Trusted Information Exchange (TIE) ATIS Approved Standard Commercially Available FIPS 199 Standards for Security Categorization of Federal Information and Information Systems NIST Approved Standard Testing Market Acceptance FIPS 200 Minimum Security Requirements for Federal Information and Information Systems NIST Approved Standard Testing Market Acceptance ISO/IEC 27002 Code of practice for information security management ISO/IEC Approved Standard Market Acceptance eXtensible Access Control Markup Language (XACML) OASIS Approved Standard Market Acceptance Table 11 – Security Standards: Security Policy Management Categorization Available Standards SDO Status Availability ATIS -02000009 Cloud Services Lifecycle Checklist ATIS Approved Standard ISO/PAS 22399:2007 Societal security - Guideline for incident preparedness and operational continuity management ISO Approved Standard Market Acceptance Table 12 – Security Standards: Availability 59 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP As discussed in Section 6.3, the interoperability of cloud services can be categorized by the management and functional interfaces of the cloud services. Many existing IT standards contribute to the interoperability between cloud consumer applications and cloud services, and between cloud services themselves. There are standardization efforts that are specifically initiated to address the interoperability issues in the cloud system. These cloud specific standards are listed in Table 13 – Interoperability Standards .

Categorization Available Standards SDO Status Service Interoperability Cloud Infrastructure Management Interface (CIMI) DMTF Approved Standard IEEE P2301, Draft Guide for Cloud Portability and Interoperability Profiles (CPIP) IEEE Under Development IEEE P2302, Draft Standard for Intercloud Interoperability and Federation (SIIF) IEEE Under Development Y.3520 Cloud computing framework for end to end resource management. ITU -T Approved Standard Cloud Application Management Platform (CAMP) OASIS Under Development Open Cloud Computing Interface (OCCI) OGF Approved Standard Data Format Description Language (DFDL) OGF Approved Standard Topology and Orchestration Specification or Cloud Applications (TOSCA),Version 1.0 Committee Specification Draft 06 / Public Review Draft 01 OASIS Under Development Cloud Data Management Interface (CDMI) [Also approved as ISO/IEC 17826:2012, Information technology – Cloud Data Management Interface (CDMI)] SNIA Approved Standard Market Acceptance Commercially Available Table 13 – Interoperability Standards 7.2 I N TER O PE RA BIL IT Y S T A N DARD S M APP IN G 60 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP As discussed in Section 6.4, portability issues in the cloud system include workload and data portability. While some of the cloud computing workload portability issues are new, many of existing data and metadata standards were developed before the cloud computing era. The following table focuses on cloud- specific portability standards. Categorization Available Standards SDO Status Data Portability Cloud Data Management Interface (CDMI) SNIA Approved Standard Market Acceptance Commercially Available System Portability Open Virtualization Format (OVF), OVF 1.0 [Also approved as INCITS 469- 2010 & ISO/IEC 17203: 2011] DMTF Approved Standard Market Acceptance Commercial Availability Open Virtualization Format (OVF), OVF 2.0 DMTF Approved Standard IEEE P2301 Draft Guide for Cloud Portability and Interoperability Profiles (CPIP) IEEE Under Development Topology and Orchestration Specification for Cloud Applications (TOSCA),Version 1.0 Committee Specification Draft 06 / Public Review Draft 01 OASIS Under Development Table 14 – Portability Standards 7.3 P O RTA BILI TY S T A ND ARD S M APP IN G 61 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP As discussed in Section 6.6, performance standards are needed for cloud service agreements and for cloud service monitoring, Table 15 – Performance Standards provides a list of current standards that may be considered. Categorization Available Standards SDO Status Service Agreements Topology and Orchestration Specification for Cloud Applications (TOSCA),Version 1.0 Committee Specification Draft 06 / Public Review Draft 01 OASIS Under Development GB917 SLA Management Handbook, Release 3.1 TM Forum Approved Standard GB963 Cloud SLA Application Note, Version 1.2 TM Forum Approved Standard TR178 Enabling End- to-End Cloud SLA Management, Version 0.4 TM Forum Approved Standard TR194 Multi-Cloud Service Management Accelerator Pack - Introduction, Release 1.0 TM Forum Approved Standard TR195 Multi-Cloud Service Management Pack - Business Guide, Release 1.0 TM Forum Approved Standard TR196 Multi-Cloud Service Management Pack - Technical Guide, Release 1.0 TM Forum Approved Standard TR197 Multi-Cloud Service Management Pack – SLA Business Blueprint TM Forum Approved Standard TR198 Multi-Cloud Service Management Pack – Developer Primer TM Forum Approved Standard Table 15 – Performance Standards 7.4 P E R FO RM AN CE S T ANDAR DS M AP PIN G 62 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP As discussed in Section 6.7, adherence to Section 508 accessibility standards would be required for many federal cloud computing applications. The Section 508 standards are being revised and are incorporating international voluntary consensus standards. The following table lists accessibility standards, which may be relevant for federal cloud computing applications.

Categorization Available Standards SDO Status Accessibility Section 508 standards (Technical Standards 1194.21 Software applications and operating systems; § 1194.22 Web- based intranet and internet information and applications; and 1194.23 Telecommunications products) US Access Board Approved Standard Market Acceptance Under Revision W3C Web Content Accessibility Guidelines (WCAG) 2.0 W3C Approved Standard Market Acceptance ISO 9241 -20:2008, Ergonomics of human - system interaction -- Part 20: Accessibility guidelines for information/communication technology (ICT) equipment and services ISO/IEC Approved Standard ISO 9241 -171:2008, Ergonomics of human - system interaction -- Part 171: Guidance on software accessibility ISO/IEC Approved Standard ISO/IEC 24751 -1:2008, Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 1: Framework and reference model ISO/IEC Approved Standard ANSI/HFES 200 Human Factors Engineering of Software User Interfaces (Parts 1, 2, and 3) ANSI Approved Standard Table 16 – Accessibility Standards 7.5 ACC ESS IB ILI TY S T AND ARDS M AP PIN G 63 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP There are several facets of cloud service interfaces that are candidates for standardization including: • Management APIs; • Data Exchange Formats; • Federated Identity and Security Policy APIs; • Resource Descriptions; and • Data Storage APIs. With these candidate areas in mind, the following business use cases can be analyzed with regard to their possible deployment modes (as discussed in Section 4.3) to identify required standards. This analysis, in conjunction with the NIST Cloud Standards Inventory, enables the availability of relevant existing and emerging standards to be evaluated. Where no suitable standards of any kind exist, this is a gap. The priority of the standards or requirements in question is also identified.

Benefits: Cross -cloud system applications Deployment Mode Considerations: Basic Create- Read-Update -Delete (CRUD) operations on data objects will primarily be done between a single client and provider, and should observe any required standards for authentication and authorization.

Standardization Needed: Standard interfaces to metadata and data objects Possible Standards: CDMI from SNIA 8.1 USE CASE: CREATI NG, ACCESSING, UPD ATING, DELET ING DATA OB JECTS IN CLOUD SYS TEM S 8 ANALYZING USE CASES TO IDENT IFY STANDA RDS GAPS 64 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Benefits: Migration, Hybrid Clouds, Disaster Recovery, Cloudbursting Deployment Mode Considerations: When moving a VM out of one cloud system and into another as two separate actions, conceivably two different ID management systems could be used. When moving VMs in a truly hybrid cloud, however, federated ID management standards will be needed. Standardization Needed: Common VM description format, common service and application description format Possible Standar ds: OVF from DMTF, TOSCA from OASIS, OpenID, Oauth Benefits: Provide cost -effective reliable deployments Deployment Mode Considerations: When considering hybrid or distributed (inter)cloud deployments, uniform and consistent resource, performance, and policy descriptions are needed.

Standardization Needed: Resource and performance requirements description languages. Possible Standards: For basic resource descriptions, DMTF CIM and OGF GLUE are candidates.

Other, more extensive description languages for performance or policy enforcement are to be determined. For Master Service Agreements and Service Level Agreements, WS -Agreement and WS -Agreement -Negotiation (WS -AG, WS -AN) from OGF; for cloud application and service level description of attributes, relationships, requirements, and capabilities, TOSCA from OASIS. Benefits: Simplifies operations as opposed to individual tools for each cloud Deployment Mode Considerations: Monitoring and managing are separate but closely related tasks.

The standards required will differ depending on whether the monitoring and managing must be done across trust boundaries or across distributed environments.

Standardization Needed: Standard monitoring and management interfaces to IaaS resources 8.4 USE CASE: PORTABLE TOOLS FOR M ONITORING AND M ANAGING CLOUD SYSTEM S 8.3 U SE C ASE : S E LE C TIN G T H E B EST I A AS C LO UD V END OR, PU BLI C O R P R IV A TE 8.2 USE CASE: M OVING VM S, VIRTUAL AP PLI AN CES, SERVICES, AND AP PLIANC ES BE TW EEN CLOUDS 65 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Possible Standards: Cloud IaaS management standards include CIMI from DMTF and OCCI from OGF; OCCI has also been successfully applied to management of aggregated federated cloud systems. PaaS APIs vary widely, but CAMP from OASIS has begun standardization work in this area. SaaS standardization on data formats and exchange protocols may be possible. Basic monitoring standards exist, such as the Syslog Protocol (IETF RFC 5424), which can be used with the Transport Layer Security (TLS) Transport Mapping for Syslog (IETF RFC 5425). Basic management standards include the Cloud Management WG from DMTF, and OCCI from OGF. • An Overview of the IETF Network Management Standards (IETF RFC 6632) • Simple Network Management Protocol or SNMP (IETF RFC 3411) • IP Flow Information eXport or IPFIX (IETF RFC 5101) • Network Configuration Protocol or NETCONF (IETF RFC 6241) • WS -AG and WS -AN for expression of service agreement monitoring parameters and units and for expression of remedy terms and negotiation parameters. Benefits: Migration between cloud systems, cross -cloud application, and B2B integration Deployment Mode Considerations: Migrating data from one cloud system to another in two separate moves through the client is a simp ler case. Migrating data directly from one cloud system to another will require standards for federated identity, delegation of trust, and secure third- part y data transfers. Standardization Needed: Standard metadata/data formats for movement between cloud systems Standardized query languages (e.g., for NoSQL for IaaS) Possible Standards: AS4, OAGIS, NoSQL, GridFTP, DFDL, CDMI 8.5 U SE C ASE : M OVIN G D ATA BETW EEN C LO UD S Y ST EM S 66 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Benefits: Simplified access, cross -cloud applications Deployment Mode Considerations: Single sign -on can mean using the same credentials to access different cloud systems independently at different times. Single sign -on to access an inter -cloud application that spans multiple cloud systems will require federated identity management, delegation of trust, and virtual organizations.

Standardization Needed: Federated identity, authorization, and virtual organizations Possible Standards: OpenID, OAuth, SAML, WS -Federation and WS -Trust, CSA outputs; Virtual Organization Management System (VOMS) from OGF. Benefits: Direct support for necessarily distributed systems Deployment Mode Considerations: This use case is inherently distributed and across trust boundaries. This can be generally termed federated resource management and is a central concept in the grid computing community. The term inter -cloud can also be used to denote this concept. Standardizations Needed: To address this use case completely, an entire set of capabilities need to be standardized, e.g.:

• Infrastructure services; • Execution Management services; • Data services; • Resource Management services; • Security services; • Self -management services; and • Information services. 8.7 USE CASE: ORC HESTRA TED PR OCESS ES ACR OSS CLOUD SYSTEM S AN D ENTERPRISE SYS TE M S 8.6 U SE C ASE : S IN GL E S IGN -O N ACC ESS T O M ULT IP L E C LO UD S YS TEM S 67 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Possible Standards: SOA standards (such as WS -I) and grid standards (such as the OGSA WSRF Basic Profile, OGF GFD -R -P.072) exist that cover these areas, but issues around stateful resources, callbacks/notifications, and remote content lifetime management has caused these to be eclipsed by the si mplicity of Representational State Transfer (REST). Hence, standard, REST -based versions of these capabilities must be developed. Such work is being done in several organizations, including the IEEE. DMTF and OGF. The OGF Distributed Computing Infrastructure Federations Working Group (DCI Federal [DCIfed] -WG) is addressing two usage scenarios: (1) delegation of workload from one domain into the other, covering job description, submission, and monitoring; and (2) leasing of resources, including resource definition, provisioning, and monitoring. Existing standards to support this include WS -Agreement, Job Submission Description Language, GLUE, OGSA Basic Execution Service, OCCI, and Usage Record. Specific business application data formats may be supported by OASIS. Workflow and workflow engines will also need standardization and adoption in the cloud arena.

BPEL is one existing standard but extensions might be needed to efficiently support scientific and engineering workflows. Benefits: Selection of appropriate cloud systems for applications Deployment Mode Considerations: To support inter -cloud resource discovery, secure federated catalog standards are needed.

Standardization Needed: Description languages for available resources, Catalogue interfaces Possible Standards: This use case addresses two areas of standardization: (1) description languages for the resources to be discovered, and (2) the discovery APIs for the discovery proces s itself. Some existing standards and tools cover both areas. RDF is a standard formalism for describing resources as triples consisting of subject -predicate- object. The Dublin Core is a small fundamental set of text elements for describing resources of all types. It is commonly expressed in RDF. Since the Dublin Core is a “core” set, it is intended to be extensible for a broad range of application domains.

Such work is being pursued by the Dublin Core Metadata Initiative. ebXML Registry Information Mode l (ebRIM) actually defines both a description language and a discovery method, ebXML Registry Services (ebRS). ID-WSF also defines both a discovery information model and discovery services that cover federated identity and access management. LDAP is an existing standard that has been used to build catalogue and discovery services, but issues might occur with regards to read vs. write optimization.

UDDI is another existing standard from OASIS. A third existing standard is CSW from OGC that 8.8 U SE C ASE : D IS C O VER IN G C LO UD R ESO URC ES 68 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP uses ebRIM. While this was originally developed to support geospatial applications, it is widely used in distributed catalogues that include services. All of these existing standards need to be evaluated for suitability for cataloguing and discovery of cloud resources and services.

Benefits: Selection of appropriate cloud resources Deployment Mode Considerations: SLAs will be primarily established between a single client and provider, and should observe any required standards for authentication, authorization, and non- repudiation. The need for SLAs between a single client but across multiple providers will be much less common. The difficulty in effectively implementing distributed SLAs will also discourage their development. Standardization Need ed: SLA description language Possible Standards: WS -Agreement (GFD.107) defines a language and a protocol for advertising the capabilities of service providers and creating agreements based on creational offers, and for monitoring agreement compliance at runtime. This is supported by WS -AgreementNegotiation (OGF), which defines a protocol for automated negotiation of offers, counter offers, and terms of agreements defined under WS -Agreement -based service agreements.

8 . 1 0 U S E C A S E : A U D I T I N G C L O U D S Y S T E M S Benefits: Ensure regulatory compliance. Verify information assurance.

Deployment Mode Considerations: Auditing will be done primarily between a single client and provider, and should observe any required standards for authentication, authorization, integrity, and non- repudiation. Standardization Needed: Auditing standards and verification check lists Possible Standards: CSA Cloud Audit. Relevant informational work can be found in Guidelines for Auditing Grid Certifica te Authorities (OGF GFD.169).

8 .9 U SE C ASE : E V A LUA TIN G S L A S AND P E N A LTI ES 69 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP 8 . 1 1 E N D - TO - E N D : C L O U D R E S O U R C E M A N A G E M E N T U S E C A S E Benefits: Supports customer service in a multi- cloud service provider environment.

Deployment/Management Mode Considerations: This use case involves the management of end -to - end health and QoS of the services offered by a cloud service provider that involves the integration of several base services offered by multiple cloud service providers, forming composite cloud services and applications.

Standardizations Needed: A framework for multi -cloud resource and service management that support the manageability for a single cloud service as well as for multiple cloud services Possible Standards: In order for the composite cloud computing services to work effectively, all the prerequisite services within the multi- cloud service system must function properly, and when a problem occurs, the service must be restored rapidly and easily. In this use case, there are the two types of connection paths, namely Service Delivery Path and Service Management Path. When the cloud consumer is experiencing a problem with an application service and contacts a cloud service provider support center, the cloud service provider should have visibility into the health and welfare of the cloud service provider application service, its underlying cloud infrastructure, as well as the local service provider’s network management systems relevant to the voice application service (i.e., end -to -end cloud resource management). Standards are needed that would offer ways to build such end -to -end and manageable multi -cloud solutions.

70 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Cloud computing is the result of evolutions of distributed computing technologies, enabled by advances in fast and low -cost networks, commoditized faster hardware, practical high -performance virtualization technologies, and maturing interactive web technologies. Cloud computing continues to leverage the maturity of these underlying technologies, including many standard -based technologies and system architecture components. As the previous sections of the cloud computing standards survey show, the majority of cloud system relevant standards are from these pre -cloud era technologies.

In the meantime, there are emerging challenges in some areas in cloud computing that have been addressed by technology vendors and service providers ’ unique innovations. New service model interactions and the distributed nature in resource control and ownership in cloud computing have resulted in new standards gaps. Some of these gaps are introduced by new service model interactions and the distributed nature of resource control and ownership in cloud computing and some are pre- cloud computing era technology standardization gaps that are now brought to the forefront. In this section, first, we use the cloud computing conceptual model from NIST Cloud Computing Reference Architecture and Taxonomy Working Group as described in Chapter 3 as the framework of reference to identify these gaps in need of standardization. Secondly, we use a broad set of USG business use cases as described in previous sections and from the NIST Cloud Computing Target Business Use Case Working Group, to identify priorities of standardization that will maximize the benefits and meet the more urgent needs of federal government consumers. As the cloud computing conceptual model indicates, cloud computing consumers do not have direct visibility into the physical computing resources. Instead, consumers interact with service providers through three service model interfaces, IaaS, PaaS, and SaaS, to gain a view of the abstracted computing resource they are using. As described in Chapter 5, Cloud Computing Standards, these interaction interfaces can be categorized into two types: (1) functional interfaces that expose the primary function of the service, and (2) management interfaces that let the consumers manage the rented computing resources. The following areas of standardization gaps are observed through the standards inventory. 9.1 A R EA S O F S T A N DARD IZ A TIO N G AP S 9 USG PRIORITIE S TO FILL CLOU D COM PUTING STANDARDS GAPS 71 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP The varieties of the SaaS applications determine what can be consumed by the SaaS consumer.

There are varying degrees of functional standardization. SaaS applications are mainly available by using a web browser, and som e are consumed as a web service using other application clients, such as standalone desktop applications and mobile applications. Even as most SaaS applications are using web and web service standards to deliver these application capabilities, application -specific data and metadata standards remain standardization gaps in portability and interoperability. For example, email and office productivity application data format standards and interfaces are required to achieve interoperability and porta bility for migrating from existing systems to cloud systems. Another important area for standardization is the metadata format and interfaces, in particular, to support compliance needs. For example, standard metadata format and APIs to describe and generate e- discovery metadata for emails, document management systems, financial account systems, etc., will help government consumers to leverage commercial off- the-shelf (COTS) and government off -the -shelf (GOTS) software products to meet e -discovery requirements. This is especially important when email messaging systems, content management systems, or Enterprise Resource Planning (ERP) financial systems migrate to a SaaS model.

Due to the diverse domain and functional differences among SaaS offerings, the management interfaces used for the consumers to administer and customize the application functionalities are als o very diverse. However, certain management functionalities are common, such as those related to user account and credential management. These common management functionalities represent candidates for interoperability standardization.

PaaS functional interfaces encompass the runtime environment with supporting libraries and system components for developers to develop and deploy SaaS applications. Standard- based APIs are often part of a PaaS offering such that the PaaS provider can enable existing development for a cloud- based hosting system. However, data format for backup and migration of application workload, including database serialization/de -serialization, need further standardization to support portability. In cloud service management areas, the importance of standard data formats and interfaces to describe service-level agreement (SLA) and quality of service (QoS) in traditional IT systems is high. While standards do exist for SLA negotiation and automated service condition matching, the application of these to the fine level of detail expected for large -scale cloud use cases is just developing. Computing resource description and discovery are also in need of standardization as consumers transition from buying and managing resources to renting resources in a cloud system. 9.1 .4 B U SIN ESS S U PP ORT, P R O VIS ION IN G AN D C O NFIGU RA TIO N 9.1 .3 P AA S F U NCTIO N AL I N TE R FA CES 9.1 .2 S AA S S E LF-S E R V IC E M AN AGEM EN T I N TER FA CES 9.1 .1 S AA S F U NCTIO N AL I N TE R FA CES 72 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP This is limited not only to raw computing resources such as virtualized processing, storage, and networking resources, but also includes higher -level abstractions of application processing resources. A standardization gap identified in a related area is metering and billing of service consumptions; data formats and management interfaces are used to report, deliver, and communi cate this usage information.

As cloud systems are typically external components in a consumer organization ’s overall IT system, especially in the outsourced (off -site) deployment models, the need to have seamless security integration calls for interoperable standard interfaces for authentication, authorization, and communication protections. The challenges of identity and access management across different network and administration domains are more prominent in the cloud system as the implementation of these capabilities within the cloud systems are often not the same organization as consumer organization where the identity information originates. Standardization in areas such as identity provisioning, management, secure and efficient replicatio n across different systems, and identity federation will greatly help to improve the identity management capabilities in cloud systems. A related area with specifically wide government usage that can benefit from standardization is single sign -on interface and protocols that support strong authentication.

Government IT systems have strong auditing and compliance needs. In many cases, these requirements must be in place before a system can be approved for operation. The standardization gap in this area exacerbates as the consumer organizations typically do not own or control the underlying system resources that implement the system capabilities. Standardization in policies, processes, and technical controls that support the security auditing requirements , regulations, and law compliance needs to consider the collaboration process between the cloud consumers and providers, their roles, and the sharing of the responsibilities in implementing the system capabilities.

A standardized “framework” for exchanging an individual’s accessibility requirements does not presently exist. A standardized method for automatic recognitio n of a user’s requirements for acc essibility would automatically identify the need for having an accessibility requirement known after the first request, for example, captioning for all subsequent video. (Note: Such automatic recognition features can trigger privacy issues depending how the information is used.) 9.1 .6 A CCESSIB IL IT Y 9.1 .5 S E C U RIT Y 73 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP As described in the Federal Cloud Computing Strategy, some cloud computing business use cases have higher priorities than others. The requirements expressed in these high- priority target business use cases can be used to prioritize the standardization gaps. For example, various USG groups have identified data center consolidation using virtualization technologies as one of the primary goals in the next few years. Migrating collaboration applications, including email mes saging (email, contacts, and calendars) and online office productivity application, to the cloud system is also quoted as an early target of government cloud operation.

By analyzing the USG cloud computing target business use cases with their specific technical requirements, one can point out the following basic drivers that can be used to prioritize cloud computing standard gaps:

• The focus on supporting migration of system workload, including data, metadata and processing logic of existing in -house IT systems, to cloud- based systems to ensure continuous operation; this focus is centered on portability standards. • The need to have interoperability between existing in -house IT systems and cloud- based systems, as cloud -deployed systems will be only a part of the overall enterprise system; this need is centered on interoperability standards, including security standards. • The need to help government consumers to choose and buy the most cost-effective solutions. If a cloud solution is not as economical as an in -house traditional IT system, there is no financial incentive to move the system to the cloud system. Based on these understandings, the following areas of standardization gaps in cloud computing are of higher priority for USG cloud consumers:

Data format standards for auditing, compliance data and metadata are needed. Standard interfaces to retrieve and manage these data and metadata assets are also required to be integrated with existing tools and processes. In addition, policy, process and technical control standards are needed to support more manageable assessment and accreditation processes, which are often a prerequisite before a system is put in operation. 9.2 .1 S E C U RIT Y A U DIT IN G A N D C OM PL IAN CE 9.2 STANDARDIZATION PRIORITI ES BASED ON USG CLOUD COM PU TING AD OPTION PR IORITI ES 74 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP As described earlier, security integration of a cloud system into existing enterprise security infrastructure is a must for the majority of government systems with moderate and greater impact.

Existing practices of external cloud- based components in identity and access management is often based on proprietary and custom integration solutions. Constant and standard ways of provisioning identity data, managing identity data, and replicating to -and -from cloud system components, are needed to ensure that consumer organizations’ short -term and long -terms needs are met.

Many government systems are required to have strong authentication, such as two -factor authentication implemented in an Internet -deployed system. Standa rds in supporting single sign -on and strong authentication are a must for these types of systems. To support the urgent need to migrate certain applications to the cloud system, application-specific data and metadata format standards are required. This is an area where a lot of SaaS providers currently help consumer organizations to migrate their existing system by offering custom conversion and migration support. However, without standards in data and metadata format for these applications, the potential danger exists of creating non- interoperable islands of cloud solutions and vendor lock- in. For example, some SaaS email solutions may not be fully interoperable with in- house email and calendaring solutions. There are specific email working groups 25 in the federal cloud computing initiative that are looking into putting forward specific metadata standardization requirements for email security, privacy, and record management. Other SaaS functional areas, such as document management and financial systems, are also among the high -priority areas where standards in dat a and metadata are needed. Description and discovery of computing resources needs are usually the first steps for consumers to take to start using cloud computing. Standard methods to describe resources will facilitate programmatically interoperable cloud applications to discover and use cloud computing resources such as computing resources, storage resources, or application resources. To establish private or community cloud computing as a way to implement data center consolidation, standards for these areas are important to avoid the implementation of vendor -specific interfaces, and also helps to increase the dynamic provisioning capabilities of the solution and utility of the computing resources. 25 https://www.fbo.gov/utils/view?id=4c4e37f4f1bcd2cb8d0a16f0e1b0ddbe 9.2 .4 R ESO U RCE D ESC RIP T IO N AN D D IS C OV ER Y 9.2 .3 S AA S A PP L IC A TIO N S P E CIF IC D ATA AN D M ET AD ATA 9.2 .2 I DEN TIT Y AN D A CC ESS M AN AGEM EN T 75 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP The following table summarizes the areas of standardization gaps and standardization priorities based on USG cloud computing adoption requirements. Table 17 – Areas of Standardization Gaps and Standardization Priorities provides a mapping of present standards gaps and how they relate to USG high priorities. Area of Standardization Gaps High Priorities for Standardization Based On USG Requirements SaaS Functional Interfaces ( 9.1.1 / page 70 ), e.g., - Data format and interface standards for email and office productivity - Metadata format and interface standards for e -discovery High standardization priorities on: - SaaS application specific data and metadata format standards to support interoperability and portability requirement when migrating high - value, low -risk applications to SaaS (Sec tion 9.2.3 ). SaaS Self -Service Management Interfaces (Sec tion 9.1.2), e.g., - Interface standards related to user account and credential management Not a high standardization priority at this time PaaS Functional Interfaces (Section 9.1.3 ), e.g., - Standards of data format to support database serialization and de - serialization Not a high standardization priority at this time Business Support, Provisioning and Configuration (Section 9.1.4), e.g., - Standards for describing cloud service- level agreement and quality of services - Standards for describing and discovering cloud service resources - Standards for metering and billing of service consumptions and usage High standardization priorities on: - Resource description and discovery standards to support data center consolidation using private and community IaaS cloud systems (Sec tion 9.2.4) 9.2 .5 S U MMA RY O F S T A NDA RD IZ A TIO N G APS AN D S T AN DARD IZ A TIO N P R IO RIT IE S 76 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP Area of Standardization Gaps High Priorities for Standardization Based On USG Requirements Security (Section 9.1.5), e.g., - Standards for identity provisioning and management across different network and administration domains - Standards for secure and efficient replication of identity and access policy information across systems - Single Sign -On interface and protocol standards that support strong authentication - Standards in policies, processes, and technical controls in supporting the security auditing, regulation, and law compliance needs High standardization priorities on: - Security auditing and compliance standards to support secure deployment, assess, and accreditation process for c loud- specific deployment (Sec tion 9.2.1) - Identity and access management standards to support secure integration of cloud systems into existing enterprise security infrastructure (Sec tion 9.2.2) Accessibility (Section 9.1.6), e.g. - Standardized framewor for exchanging an individua s accessibility requirements Not a high standardization priority at this time Table 17 – Areas of Standardization Gaps and Standardization Priorities 77 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP 1 0 . 1 C O N C L U S I O N S Cloud computing can enable USG agencies to achieve cost savings and increased ability to quickly create and deploy enterprise applications. While cloud computing technology challenges many traditional approaches to data center and enterprise application design and management, requirements for accessibility, interoperability, performance, portability, and security remain critically important for successful deployments. Technically sound and timely standards are instrumental to ensuring that requirements for interoperability, portability, and security are met. There is a fast -changing landscape of cloud computing -relevant standardization under way in a number of SDOs. While there are onl y a few approved cloud computing-specific standards at present, USG agencies should be encouraged to participate in specific cloud computing standards development projects that support their priorities in cloud computing services. USG laws and policies encourage federal agency participation in the development and use of voluntary consensus standards and in conformity assessment activities. The following recommendations provide further guidance on how agencies can help to accelerate the development and use of cloud computing standards. Recommendation 1 – Contribute Agency Requirements Agencies should coordinate and contribute clear and comprehensive user requirements for cloud computing standards projects. Recommendation 2 – Participate in Standards Development Agencies should actively participate and coordinate in cloud computing standards development projects that are of high priority to their agency missions. The January 17, 2012, White House Memorandum, M -12- 08, lists five fundamental strategic objectives for federal government agencies whenever engaging in standards development: • Produce timely, effective standards and efficient conformity assessment schemes that are essential to addressing an identified need; • Achieve cost -efficient, timely, and effective solutions to legitimate regulatory, procurement, and policy objectives; 10.2 REC O MM EDA TIO N TO U SG A GE NCIE S TO HE LP A CC ELE RA TE TH E D EV ELO PM EN T A ND U SE O F C LO UD C O M PU TIN G S T A ND AR DS 10 CONCLUSIONS AND RECOMM ENDATIONS 78 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP • Promote standards and standardization systems that promote and sustain innovation and foster competition; • Enhance U.S. growth and competitiveness and ensure non- discrimination, consistent with international obligations; and • Facilitate international trade and avoid the creation of unnecessary obstacles to trade. Recommendation 3 – Encourage Testing to Accelerate Technically Sound Standards -Based Deployments Agencies should support the concurrent development of conformity and interoperability assessment schemes to accelerate the development and use of technically sound cloud computing standar ds and standards -based products, processes, and services. Agencies should also include consideration of conformity assessment approaches currently in place that take account of elements from international systems, to minimize duplicative testing and encourage private sector support. Recommendation 4 – Specify Cloud Computing Standards Agencies should specify cloud computing standards in their procurements and grant guidance when multiple vendors offer standards -based implementations and there is evidence of successful interoperability testing. Recommendation 5 – USG- Wide Use of Cloud Computing Standards To support USG requirements for accessibility, interoperability, performance, portability, and security in cloud computing, the Federal Cloud Computing Standards and Technology Working Group, in coordination with the Federal CIO Council Cloud Computing Executive Steering Committee (CCESC) and the Cloud First Task Force, should recommend specific cloud computing standards and best practices for USG-wide use. 79 NI ST CLOUD COMPU TI NG STANDA RDS ROA DM AP 80