<?xml version="1.0" encoding="UTF-8"?>
<StrategicPlan xsi:schemaLocation="http://www.stratml.net  http://xml.gov/stratml/references/StrategicPlan.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.stratml.net"><id/><Name>US Government Cloud Computing Technology Roadmap: High-Priority Requirements to  Further USG Agency Cloud  Computing Adoption</Name><Description>This document is intended to serve as:
* A vehicle to define and communicate high-priority strategic and tactical security, interoperability, and 
portability requirements; these must be met for USG agencies to further adopt the cloud computing 
model to meet the Federal Cloud Computing Strategy goals;
* A vehicle to define and communicate the relevant standards, guidance, and technology that must be in 
place to satisfy these requirements;
* A vehicle to define and communicate a list of candidate Priority Action Plans (PAPs) to be developed 
to support security, interoperability, and portability standards, guidance, and technology
requirements;
* The mechanism to integrate and present analysis, findings, and useful technical artifacts generated 
through the NIST Cloud Computing program public working groups, internal NIST Cloud 
Computing and related projects, and the NIST chaired Federal Cloud Computing Standards and 
Technology Working Group, along with referenced related and complementary work that was 
reviewed and considered in the roadmap generation process;
* The mechanism to focus discussion on the proposed "technology roadmap" steps to move federal IT 
from its current early-cloud state ("point A") to a cloud-based foundation ("point B") and to fully 
execute the US Federal Cloud Computing Strategy); and
* The basis to assess and plan the NIST Cloud Computing program and the Federal Cloud Computing 
Standards and Technology Working Group efforts going forward.
</Description><OtherInformation>Special Publication 500-293 (Draft) Volume I Release 1.0 (Draft)</OtherInformation><StrategicPlanCore><Organization><Name>Cloud Computing Program Information Technology Laboratory</Name><Acronym>CCPITL</Acronym><Identifier>_573c432e-5ec5-11e4-9e95-a47c99ef03e0</Identifier><Description/><Stakeholder><Name>Information Technology Laboratory</Name><Description>The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. This Special Publication 500-series reports on ITL's research, guidance, and outreach efforts in Information Technology and its collaborative activities with industry, government, and academic organizations.</Description></Stakeholder><Stakeholder><Name>National Institute of Standards and Technology</Name><Description>The National Institute of Standards and Technology (NIST), consistent with its mission, has a technology leadership role in support of United States Government (USG) secure and effective adoption of the Cloud Computing model to reduce costs and improve services. This role is described in the 2011 Federal Cloud Computing Strategy as -- ... a central one in defining and advancing standards, and collaborating with USG Agency CIOs, private sector experts, and international bodies to identify and reach consensus on cloud computing technology &amp; standardization priorities.</Description></Stakeholder><Stakeholder><Name>U.S. Department of Commerce </Name><Description/></Stakeholder><Stakeholder><Name>Industry Organizations</Name><Description/></Stakeholder><Stakeholder><Name>Government Organizations</Name><Description/></Stakeholder><Stakeholder><Name>Academic Organizations</Name><Description/></Stakeholder><Stakeholder><Name>Knowcean Consulting Incorporated</Name><Description>The authors, David Bernstein, Jian Mao, and Jin Tong, of Knowcean Consulting Incorporated (under contract through the Federal Integrated Product Team, Space &amp; Naval Warfare [SPAWAR] Systems Center Atlantic), Frederic de Vaulx of Prometheus Computing LLC (under contract), Lee Badger, Robert Bohn, Mike Hogan, John Messina, Kevin Mills, Annie Sokol, Fred Whiteside, and Dawn Leaf of the National Institute of Standards and Technology (NIST), gratefully acknowledge and appreciate the broad contributions from members of the NIST Cloud Computing USG Target Business Use Case, Reference Architecture and Taxonomy, Standards Acceleration to Jumpstart the Adoption of Cloud Computing (SAJACC), Security, and Standards working groups.
We especially acknowledge Lisa Carnahan, Romayne Hines, Michaela Iorga, Mary Saunders, Terry Schwarzhoff, and James St. Pierre of NIST for providing editorial review and support.</Description></Stakeholder><Stakeholder><Name>David Bernstein</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Jian Mao</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Jin Tong</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>SPAWAR</Name><Description>Space &amp; Naval Warfare Systems Center Atlantic</Description></Stakeholder><Stakeholder><Name>Prometheus Computing LLC</Name><Description/></Stakeholder><Stakeholder><Name>Frederic de Vaulx</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Lee Badger</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Robert Bohn</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Mike Hogan</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>John Messina</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Kevin Mills</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Annie Sokol</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Fred Whiteside</Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Dawn Leaf </Name><Description>Co-Author</Description></Stakeholder><Stakeholder><Name>Lisa Carnahan</Name><Description>Editorial Reviewer
</Description></Stakeholder><Stakeholder><Name>Romayne Hines</Name><Description>Editorial Reviewer</Description></Stakeholder><Stakeholder><Name>Michaela Iorga</Name><Description>Editorial Reviewer</Description></Stakeholder><Stakeholder><Name>Mary Saunders</Name><Description>Editorial Reviewer</Description></Stakeholder><Stakeholder><Name>Terry Schwarzhoff</Name><Description>Editorial Reviewer</Description></Stakeholder><Stakeholder><Name>James St. Pierre</Name><Description>Editorial Reviewer</Description></Stakeholder><Stakeholder><Name>Earl Crane</Name><Description>We especially acknowledge Earl Crane, of the Department of Homeland Security and Information Security and Identity Management Committee (ISIMC), whose advice and technical insight assisted this effort. 
</Description></Stakeholder><Stakeholder><Name>Homeland Security and Information Security and Identity Management Committee</Name><Description/></Stakeholder><Stakeholder><Name>Federal Cloud Computing Standards and Technology Working Group</Name><Description>We also wish to acknowledge the members of the Federal Cloud Computing Standards and Technology Working Group and other interagency contributors, listed in Appendix A of this document.</Description></Stakeholder><Stakeholder><Name>US Policy Makers</Name><Description>This publication is intended for a diverse audience:
* US Policy Makers, US Federal CIO Council, and those with key roles identified in the Federal Cloud Computing Strategy -- as a technology-oriented reference to inform policy and planning;
* USG Agencies – as a tool in the context of the USG Federal Cloud Computing Strategy risk-based management "Decision Framework for Cloud Migration"; and
* Cloud Computing Stakeholders (Academia, Government, Industry, Standards Developing Organizations) -- as a consolidated presentation of USG cloud computing technology perspectives, including a list of candidate Priority Action Plans which are recommended for voluntary self-tasking and which present opportunities to leverage stakeholder efforts to further cloud computing. </Description></Stakeholder><Stakeholder><Name>US Federal CIO Council</Name><Description/></Stakeholder><Stakeholder><Name>USG Agencies</Name><Description/></Stakeholder><Stakeholder><Name>Cloud Computing Stakeholders</Name><Description/></Stakeholder><Stakeholder><Name>USG Interagency Contributors</Name><Description/></Stakeholder><Stakeholder><Name>Bruce Beckwith</Name><Description>Department of Energy</Description></Stakeholder><Stakeholder><Name>Kathy Conrad</Name><Description>Principal Deputy Associate Administrator, General Services Administration</Description></Stakeholder><Stakeholder><Name>Earl Crane</Name><Description>Department of Homeland Security, Information Security and Identity Management Committee (ISIMC)</Description></Stakeholder><Stakeholder><Name>Dominic Gomes</Name><Description>Office of the Chief Information Officer, Department of Health and Human Services</Description></Stakeholder><Stakeholder><Name>Lon D. Gowen, Ph.D.</Name><Description>National Aeronautics and Space Administration (NASA), Goddard Space Flight Center</Description></Stakeholder><Stakeholder><Name>Audrey M. Hogan</Name><Description>Tennessee Valley Authority</Description></Stakeholder><Stakeholder><Name>Dr. Prabha N Kumar</Name><Description>Special Assistant, Department of Defense, OCIO</Description></Stakeholder><Stakeholder><Name>Festus C. Onyegbula</Name><Description>Office of Information Technology, National Institute of Food and Agriculture, U.S. Department of Agriculture</Description></Stakeholder><Stakeholder><Name>James Ramskill</Name><Description>Office of the Director of National Intelligence</Description></Stakeholder><Stakeholder><Name>David Raw</Name><Description>Office of the Chief Information Officer (OCIO), Department of Homeland Security</Description></Stakeholder><Stakeholder><Name>Lew Sanford Jr.</Name><Description>DCS-OESAE, Social Security Administration (with other SSA participants)</Description></Stakeholder><Stakeholder><Name>Charles Santangelo</Name><Description>Senior IT Budget Manager, Capital Planning and Governance, OCIO, Office of the CIO, NASA</Description></Stakeholder><Stakeholder><Name>Param Soni</Name><Description>Environmental Protection Agency</Description></Stakeholder><Stakeholder><Name>Gerald L. Smith</Name><Description>Department of Defense and OASIS</Description></Stakeholder><Stakeholder><Name>Peter Tseronis</Name><Description>Chief Technology Officer, Department of Energy</Description></Stakeholder></Organization><Vision><Description>... USG agencies will be able to easily locate desired IT services in a mature and competitive marketplace, rapidly procure access to these services, and use them to deliver innovative mission solutions. Cloud services will be secure, interoperable, and reliable. Agencies will be able to switch between providers easily and with minimal 
cost, and receive equal or superior services.
</Description><Identifier>_573c47f2-5ec5-11e4-9e95-a47c99ef03e0</Identifier></Vision><Mission><Description>To foster adoption of cloud computing by federal agencies and support the private sector; reduce uncertainty by improving the information available to decision makers; and facilitate the further development of the cloud computing model.
</Description><Identifier>_573c49b4-5ec5-11e4-9e95-a47c99ef03e0</Identifier></Mission><Value><Name>Standards</Name><Description>While there are a large number of cloud community stakeholders accomplishing valuable work in advancing cloud computing standards, guidance, and technology, the rapid pace of cloud computing evolution (which has been characterized as "building the plane while we are flying it") is such that the community needs to work even harder to explicitly leverage our efforts and get ahead of the curve.
</Description></Value><Value><Name>Guidance</Name><Description/></Value><Value><Name>Technology</Name><Description/></Value><Value><Name>Leverage</Name><Description/></Value><Value><Name>Consensus</Name><Description>For example, there are many approaches to cloud computing standards. In some cases, standards are being developed in consensus-driven working groups, but are not being applied in implementations. In other cases, nonstandardized implementations evolve in parallel, but do not transition to the point where the work is leveraged through formal Standards Developing Organizations. One example of a general benefit that would ensue from aggressively pursuing cloud computing standards is that US government agencies procuring services would be positioned to specify standards, as opposed to specific cloud provider services or products. This would improve cost-effectiveness for the taxpayer and level the playing field for the private sector consumers and service providers. </Description></Value><Value><Name>Implementation</Name><Description/></Value><Value><Name>Collaboration</Name><Description>Collaboration is a productive, but unstructured process that is often driven from the bottom up in the sense that developers and adopters have individual mission, schedule, and resource objectives and constraints. Despite these differences, it is clear that there is much convergence in principle. International technical exchanges and reports illustrate this point. Priorities defined explicitly through recent international conferences hosted by the European Commission and standards organizations, but not exclusively there, include: standards, a level playing field that supports technical innovation, interoperability and open interfaces, a desire to harness the power of cloud to improve public services, a need for improved understanding of cloud computing by policy makers, guidance to architects and engineers, and conformity assessments and testing. An example of a practical collaboration is a mapping exercise that was completed by the EC Standards and Interoperability for Einfrastructure Implementation Initiative (sienna) project to look for commonality and synergism between the NIST technical use cases and Cloud Usage Scenarios with European eScience developments.</Description></Value><Goal><Name>Standards</Name><Description>International voluntary consensus-based interoperability, portability, and security standards (interoperability, portability, and security standards)</Description><Identifier>_573c4afe-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Government, industry, and other stakeholders need to define requirements, develop international voluntary consensus-based interoperability, portability and security standards, and implement them in products, processes and services. (interoperability, portability, and security standards)
Why: Standards-based products, processes, and services are essential for USG agencies to ensure that: 
a) potentially large, public investments do not become prematurely technologically obsolete, b) government agencies are able to easily change cloud service providers that can support their missions most cost-effectively and flexibly, and c) the US government is supporting a level economic playing field for service providers.
Illustrative example of why this requirement is not considered to be fully met at present: While data, software, and infrastructure components that enable cloud computing (e.g., virtual machines) can currently be ported from selected providers to other providers, the process requires an interim step of manually moving the data, software, and components to a non-cloud platform and/or conversion from one proprietary format to another.</OtherInformation><Objective><Name>Initial Set </Name><Description>Develop an initial set of international consensus-based interoperability, portability, and security standards.</Description><Identifier>_573c4c70-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>1.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012-2015</OtherInformation></Objective><Objective><Name>Test Tools</Name><Description>Encourage test tool development to support cloud standards development.</Description><Identifier>_573c4e50-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>1.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012-2015</OtherInformation></Objective><Objective><Name>Conformity Assessment</Name><Description>Encourage standards conformity assessment practices through procurement.</Description><Identifier>_573c4fae-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>1.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012-2013</OtherInformation></Objective><Objective><Name>Recognition Arrangements</Name><Description>Define mutual recognition arrangements to allow test reports to be used widely by providers to compete in global markets.</Description><Identifier>_573c50f8-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>1.4</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012-2014</OtherInformation></Objective><Objective><Name>Use Cases</Name><Description>Develop additional technical use cases focusing on multi-cloud scenarios.</Description><Identifier>_573c5242-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>1.5</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012-2014</OtherInformation></Objective></Goal><Goal><Name>Solutions</Name><Description>Solutions for high-priority Security Requirements (security technology)</Description><Identifier>_573c5418-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>As a general requirement, solutions need to be defined to address specific USG high-priority security requirements.
Why: There is a need to demonstrate that the required level of protection of federal data can be provided in the cloud environment in order to inspire confidence and trust to a level where security is not perceived to be an impediment to the adoption of cloud computing. 
Illustrative example of why this requirement is not considered to be fully met at present: While cloud computing security requirements are not unique in their entirety or separate from general IT security requirements, the cloud computing environment presents unique security challenges. The architecture, potential scale, reliance on networking, degree of outsourcing, and shared resource aspects of the cloud computing model make it prudent to reexamine current security controls. Multi-tenancy is an example of an inherent characteristic of the cloud environment which intuitively raises a security concern that one consumer may impact the operations or access data of other tenants running on the same cloud.
Moreover, while it is generally recognized that there are multiple cloud service and deployment models, these have not been sufficiently explored. In the absence of information, to date the focus has been polarized -- largely split between commodity and outward-facing low security impact applications in the context of commercial cloud services, and alternately private cloud implementations. For these, as well as hybrid and community deployment models, additional risk and trade-off analysis is needed for the various software, platform, and infrastructure service models.</OtherInformation><Objective><Name>Priorities</Name><Description>Identify Priority Requirements</Description><Identifier>_573c5562-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>2.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Continue to list top security concerns of the federal, state, and local government CIO and program community.
2012-quarterly</OtherInformation></Objective><Objective><Name>Mitigations</Name><Description>Identify existing mitigations related to these requirements and assess the extent to which risk can be mitigated through existing and emerging security controls and guidance, such as roles and responsibility analysis and guidance.</Description><Identifier>_573c56ac-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>2.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012-periodically </OtherInformation></Objective><Objective><Name>Gaps &amp; Modifications</Name><Description>Identify gaps and modify existing controls and monitoring capabilities to address 
requirements and reduce risks to acceptable levels.</Description><Identifier>_573c57e2-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>2.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012-periodically</OtherInformation></Objective></Goal><Goal><Name>Technical Specifications</Name><Description>Technical specifications to enable development of consistent, high-quality Service-Level Agreements (interoperability, portability, and security
standards and guidance)</Description><Identifier>_573c5990-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Industry and USG need to develop and adopt consistent technical specifications, of high quality and completeness, to enable the creation and practical evaluation of Service-Level Agreements (SLAs) between customers and cloud providers (interoperability, portability, and security guidance and technology)
Why: Cloud SLAs represent a negotiated service contract between two parties that specifies, in measurable terms, what cloud service will be provided to the customer. This requirement must be met to ensure that: a) key elements required for cloud services (warranties, guarantees, performance metrics, etc.) are not left out of the SLA and therefore rendered unenforceable, b) common terms and definitions are used within the SLAs to avoid costly misunderstandings between parties, and c) to create an environment which allows agencies to objectively compare competing services. 
Illustrative example of why this requirement is not considered to be fully met at present: The concept of reliability is a key cloud computing element addressed by practically every provider’s SLAs, but how it is defined, what is being measured, and the associated guarantees vary widely. Customers are faced with evaluating different SLAs with cloud providers defining reliability using different terms (uptime, resilience, or availability), covering different resources (servers, HVAC systems, customer support), covering different time periods (hours, days, years), and using different guarantees (response time versus resolution time). SLA ambiguities leave the customer at risk.</OtherInformation><Objective><Name>Controlled Vocabulary</Name><Description>Develop a controlled and standardized vocabulary of cloud SLA terms and 
definitions.</Description><Identifier>_573c5ada-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>3.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 – update periodically</OtherInformation></Objective><Objective><Name>Guidance &amp; Policy</Name><Description>Ensure consistency in guidance and policy regarding SLA relevant terms and 
definitions.</Description><Identifier>_573c5c1a-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>3.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 – update periodically</OtherInformation></Objective><Objective><Name>SLA Taxonomy</Name><Description>Develop a cloud SLA Taxonomy to ensure the complete specification of key cloud computing elements that need to appear in an SLA.</Description><Identifier>_573c5d82-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>3.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 – update periodically</OtherInformation></Objective></Goal><Goal><Name>Service Categorization</Name><Description>Clearly and consistently categorized cloud services (interoperability and portability guidance and technology)</Description><Identifier>_573c6016-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 4</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Industry needs to clearly and consistently categorize cloud services. (interoperability and portability guidance and technology)
Why: This requirement must be met to ensure that: a) customers will understand the intricacies of different types of cloud services and will be better able to select cloud services suitable to meet their business objectives, b) customers will be able to objectively evaluate, compare, and select between products from cloud vendors, and c) providers will have clear guidance where interoperability and portability must exist within similar categories of cloud services.
Illustrative example of why this requirement is not considered to be fully met at present: The NIST cloud computing definition has identified three distinct categories of cloud service models: Software as a Service, Platform as a Service, and Infrastructure as a Service. Currently, consumers must seek to understand cloud services through the customized view presented by each service provider. Moreover, while many vendors seek to establish new categories of service, which would improve their market positioning, it is not clear that any proposed categories are unique and not included in the existing three primary services. Examples of proposed additions include Data as a Service, Network as a Service, Service as a Service, and more. The result is a confusing landscape of possible cloud services.</OtherInformation><Objective><Name>Reference Architecture</Name><Description>Encourage adoption of the NIST Reference Architecture by ISO/IEC JTC1, or an 
alternate neutral reference architecture through an international consensus-based standards body.</Description><Identifier>_573c6246-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>4.1</SequenceIndicator><Stakeholder><Name>ISO/IEC JTC1</Name><Description/></Stakeholder><OtherInformation>2012 - 2013</OtherInformation></Objective><Objective><Name>Product Categorization</Name><Description>Categorize products using the NIST Reference Architecture to provide a consistent view of cloud services to USG agencies.</Description><Identifier>_573c63c2-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>4.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 – update periodically</OtherInformation></Objective><Objective><Name>Consistency</Name><Description>Encourage suppliers to categorize services consistently.</Description><Identifier>_573c6516-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>4.3</SequenceIndicator><Stakeholder><Name>Cloud Service Suppliers</Name><Description/></Stakeholder><OtherInformation>2012</OtherInformation></Objective></Goal><Goal><Name>Implementation Frameworks</Name><Description>Frameworks to support seamless implementation of federated community cloud environments (interoperability and portability guidance and technology)</Description><Identifier>_573c666a-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 5</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Industry and the USG need to develop frameworks to support seamless implementation of federated community cloud environments. (interoperability and portability guidance and technology)
Why: In a Community Cloud deployment, infrastructure is shared by several organizations that have common interests (e.g., mission, security requirements, and policy). In the case where a Community Cloud deployment model is not implemented in one (private cloud or public) environment which accommodates the entire community of interest, there is a need to clearly define and implement mechanisms to support the governance and processes which enable federation and interoperability between different cloud service provider environments to form a general or mission-specific federated Community Cloud. 
Illustrated Example of why this requirement is not considered to be fully met at present: In the case of a Community Cloud deployed by a single Cloud Provider, the cloud PaaS layer can be used by developers to create applications. As long as the developers establish common technical policies and credentials within that Community Cloud, they can use tools and management systems from different vendors, and connect parts of one application to parts of another application using common PaaS facilities. However, in a federated multi-cloud environment with diverse cloud implementations and policies, the modules may need manual intervention to function together. Technical policies, credentials, namespaces, and trust infrastructure must be harmonized to support a Community Cloud that spans multiple service providers’ physical environments. </OtherInformation><Objective><Name>Requirements &amp; Scenarios</Name><Description>Define federated Community cloud requirements and scenarios.</Description><Identifier>_573c67f0-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>5.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2014</OtherInformation></Objective><Objective><Name>Hybrid Cloud &amp; Cloud Broker</Name><Description>Identify how Hybrid Cloud and Cloud Broker elements described in the cloud 
Reference Architecture can be leveraged and harmonized.</Description><Identifier>_573c694e-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>5.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2013</OtherInformation></Objective><Objective><Name>GRID Communities</Name><Description>Present analysis of GRID communities' applicability to federated cloud communities, including technology, trust infrastructure, &amp; governance.</Description><Identifier>_573c6bc4-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>5.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2013</OtherInformation></Objective><Objective><Name>Intercloud Efforts</Name><Description>Assess Intercloud efforts for applicability.</Description><Identifier>_573c6d54-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>5.4</SequenceIndicator><Stakeholder><Name>Standards Developing Organizations</Name><Description/></Stakeholder><OtherInformation>All stakeholders
2012 - 2013</OtherInformation></Objective></Goal><Goal><Name>Technical Security</Name><Description>Technical security solutions which are de-coupled from organizational policy decisions (security guidance, standards, and technology)</Description><Identifier>_573c6ee4-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 6</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Industry needs to define and develop technical security solutions which support, but are abstracted from (and therefore separate from), the decisions required by diverse sovereign, legal, business, or other authoritative policy rules. (security standards and technology) Consumers need to adopt consensus technical standards to interoperate with diverse policy rules and authorities. (security guidance) 
Why: In the absence of mechanisms to allow differing policies to coexist side by side in a global environment irrespective of geographical location and sovereignty, large-scale interoperability and portability for cloud workloads may not be feasible. Additionally, the ability to bridge policy differences is essential for maintaining service while policies evolve. Security requirements and their associated technical controls, which are essential to ensuring privacy rights and global Ecommerce, will not be universally adopted if they are prescriptively tied to sovereign privacy and security decisions. 
Illustrative example of why this requirement is not considered to be fully met at present: International government representatives to the World Economic Forum Cloud Computing workshop held in November 2010 identified cases in point -- for example, that where one nation considers birth records to be public, and another considers birth records to be subject to strict privacy control. In an EU-US Cloud Computing Technical Seminar, July 2011, representatives discussed the need to support differing EU members’ privacy requirements. The TechAmerica Foundation issued recommendations in July 2011 that called for a "technology-neutral privacy framework…,""Security and Assurance Frameworks… which are international..." and "…U.S. government …willingness to trust cloud computing environments in other countries for appropriate government workloads." 
</OtherInformation><Objective><Name>Profiles, Attributes &amp; Criteria</Name><Description>Develop neutral cloud security profiles, technical security attributes, and a test criteria that addresses the USG cloud "security requirements" list.</Description><Identifier>_573c70d8-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>6.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2014</OtherInformation></Objective><Objective><Name>Conformity Assessment</Name><Description>Define an international standards-based conformity assessment system approach.</Description><Identifier>_573c7272-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>6.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2013 - 2014</OtherInformation></Objective></Goal><Goal><Name>Requirements, Gaps &amp; Solutions</Name><Description>Defined unique government regulatory requirements, technology gaps, and solutions (interoperability, portability, and security technology)</Description><Identifier>_573c7470-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 7</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Why: In addition to policy related to cloud services adoption, USG agencies are subject to policy and regulatory requirements, which are unique to government agencies. Government agencies must ensure that cloud services and products meet these policy and compliance requirements as well as mission functionality. Although agencies use commercial services to complete key elements of their mission, USG agencies cannot delegate inherently governmental federal authorities and public trust responsibilities to the private sector. USG institutions cannot mitigate risk through commercial means (e.g., financial penalties, insurance, litigation) to the same degree as private sector organizations. Failure to recognize and address government constraints may slow the adoption of cloud services.
Illustrative example of why this requirement is not considered to be fully met at present: OMB memo M-11-117 reaffirmed the importance of the implementation of Homeland Security Presidential Directive (HSPD)-128 and the need to move quickly to an authentication and access control mechanism which is defined and used government wide. USG agency systems that are not “national security 
systems” as defined by 44 U.S.C 3542(b)(2) should be required to use Personal Identification Verification (PIV) cards as a way of authentication.
This is an example of a requirement where it is necessary to identify and address technology gaps in order for USG agencies to authorize use of cloud ervices.
</OtherInformation><Objective><Name>Regulatory Factors</Name><Description>Identify regulatory factors that could affect cloud requirements, those which if unmet will prevent adoption by USG agencies, and cloud-based system features that satisfy these regulatory requirements.</Description><Identifier>_573c765a-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>7.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 – ongoing</OtherInformation></Objective><Objective><Name>Technology &amp; Products</Name><Description>Develop technology and products to fill the gaps.</Description><Identifier>_573c786c-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>7.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - ongoing</OtherInformation></Objective></Goal><Goal><Name>Development Initiatives</Name><Description>Collaborative parallel strategic “future cloud” development initiatives (interoperability, portability, and security technology)</Description><Identifier>_573c79e8-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 8</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Academia, industry, and USG need to initiate parallel "future cloud" development initiatives.  (interoperability, portability, and scalability technology)
Why: To date, innovation and technology for deploying Web-scale (nation-scale) clouds has been developed by industry. Much of the construction know-how is therefore not available in the public domain; the technology is considered to be intellectual property. USG agencies have legislated, and public trust authorities and responsibilities that cannot be outsourced to private companies, including but not limited to, responsibilities for ensuring that moderate and high security impact systems and data are protected, and that emergency and critical infrastructure public services are provided on a massive scale.  Development of a demonstrable and practical technology knowledge base focused on state-of-the-art, nation-size clouds which are scalable and capable, and development of accessible standards and technologies, is needed to solve these nation-scale challenges. A defined baseline of interconnected cloud systems would support additional research and more rapidly lead to world-class cloud advancements that can effectively and securely support critical national priorities and citizen services.
Illustrative example of why this requirement is not considered to be fully met at present: Cloud construction and operation, where the number of servers can exceed 100,000 spanning multiple data centers, pose challenges in network design not found in smaller clouds. For example, classic L2 switching (bridging) algorithms, such as spanning trees, do not function at this scale. New L2 techniques which allow for network virtualization are used. Use of L3 (routing) network partitioning techniques introduces routing delays in the middle of distributed caches, streams, or storage pools. Unavoidable speed-of-light delays across geographic distances yield high latency on high-bandwidth links connecting logically joined data centers, making Transmission Control Protocol TCP inefficient. This requirement will create standards and technologies solving these nation-scale challenges.</OtherInformation><Objective><Name>Scenarios</Name><Description>Define scenarios to support testing of state-of-the-art, interoperable, nation-size 
clouds.</Description><Identifier>_573c7b64-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>8.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2016</OtherInformation></Objective><Objective><Name>Project Concepts</Name><Description>Define project concepts.</Description><Identifier>_573c7d26-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>8.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Identify likely technical and standards challenges. 2012 - 2017</OtherInformation></Objective><Objective><Name>Research Strategy</Name><Description>Define conceptual research strategy.</Description><Identifier>_573c7ea2-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>8.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2013 - 2015</OtherInformation></Objective></Goal><Goal><Name>Reliability Goals</Name><Description>Defined and implemented reliability design goals (interoperability, portability, and security technology)</Description><Identifier>_573c81a4-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 9</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Industry needs to define and implement reliability design goals, best practices, and related measurement and reporting processes. (interoperability, portability, and security technology) 
Why: As USG agencies increase their use of cloud computing to provide essential public services, it is essential that industry be able to ensure that design flaws do not result in catastrophic failures or significant outages over large regions or for extended periods of time.
Illustrative examples of why this requirement is not considered to be fully met at present: Cloud Builders create mechanisms to compensate for component failures and deliver High Availability, but the news has highlighted major cloud provider outages. In several cases, cloud providers suffered failures or design flaws which affected the accessibility of cloud-based services for many subscribers. In April 2011, an erroneous network reconfiguration triggered a failure, followed by a cascade of recovery events and 
subsequent failures, and a lengthy outage. In May 2011, a sequence of cloud outages and software errors led to email delays. During June and July 2011, the same cloud provider suffered outages that disabled services. In August 2011, an intense lightning storm overloaded a power transformer; cloud services were unavailable for hours. In August 2011, a cleanup software bug resulted in customers losing backup data. </OtherInformation><Objective><Name>Reliability</Name><Description>Formulate and publish best practices on achieving reliability.</Description><Identifier>_573c835c-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>9.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2014</OtherInformation></Objective><Objective><Name>Measurement &amp; Reporting</Name><Description>Develop a consensus process to measure and report industry-wide cloud reliability information to assess current and future cloud reliability.</Description><Identifier>_573c84ec-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>9.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2017</OtherInformation></Objective><Objective><Name>Measurement &amp; Monitoring</Name><Description>Define research methods for real-time measurement and monitoring to predict onset of catastrophic failure in cloud systems, and tools to identify failure vulnerabilities.</Description><Identifier>_573c867c-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>9.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2015</OtherInformation></Objective></Goal><Goal><Name>Service Metrics</Name><Description>Defined and implemented cloud service metrics (interoperability and portability standards)</Description><Identifier>_573c8906-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>Requirement 10</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Industry needs to establish Cloud Service Metrics, including Standardized Units of Measurement for Cloud Resources. (interoperability standards)
Why: In utility industries, the notion of units of measurement is fundamental to buying and selling service. Benchmarking is used in traditional computing system operations to determine the performance of system infrastructure such as hardware and operating systems, and for key application platform elements such as database servers and Web servers. However, in the case of cloud computing service delivery, which uses a utility model, IT resources are supplied as abstracted services, often characterized as Infrastructure as a Service or Platform as a Service. For example, networking and storage are often provided as abstracted services. Abstracted services can be set to run fast or slow, to be small or large, and to be as reliable as desired (subject to underlying technology constraints). Service consumers pay for a "quantity" and a "quality" of the service, which is metered by a cloud computing system. Consumers need to be able to precisely specify and receive services. 
Illustrative example of why this requirement is not fully met at present: In contrast to the precision with which we categorize units of measurement in electricity, light, or fuels, cloud computing measurements are relatively imprecise. Furthermore, there is no common collection of vendor agreed-upon specific terms. For example, while one provider uses an informal “Elastic Compute Unit,” it is imprecise and does not account for workload mix or speed to memory. The characteristics of storage and access to storage over a network vary. Service providers have not defined and applied standardized units of measurement that can be specified in Service-Level Agreements and interoperability exchanges.  Therefore, consumers cannot determine and request cloud services as a utility with a high degree of predictability, and cannot achieve maximum cost-effectiveness in cloud computing service application.</OtherInformation><Objective><Name>Units of Measurement</Name><Description>Specify and Standardize the Units of Measurement for cloud services, seeking public comment and collaboration.</Description><Identifier>_573c8a96-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>10.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2013</OtherInformation></Objective><Objective><Name>Service-Level Agreements</Name><Description>In parallel, incorporate Cloud Service Units of Measurement consistently in Service-Level Agreements.</Description><Identifier>_573c8ce4-5ec5-11e4-9e95-a47c99ef03e0</Identifier><SequenceIndicator>10.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>2012 - 2013</OtherInformation></Objective></Goal></StrategicPlanCore><AdministrativeInformation><StartDate/><EndDate/><PublicationDate>2014-10-28</PublicationDate><Source>http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/Documents/DRAFT_SP_500_293_volume_I.pdf</Source><Submitter><FirstName>Owen</FirstName><LastName>Ambur</LastName><PhoneNumber/><EmailAddress>Owen.Ambur@verizon.net</EmailAddress></Submitter></AdministrativeInformation></StrategicPlan>