Standard

This publication provides a catalog of security and privacy controls for federal information systems and organizations and a process for selecting controls to protect organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation from a diverse set of threats including hostile cyber attacks, natural disasters, structural failures, and human errors. The controls are customizable and implemented as part of an organization-wide process that manages information security and privacy risk. The controls address a diverse set of security and privacy requirements across the federal government and critical infrastructure, derived from legislation, Executive Orders, policies, directives, regulations, standards, and/or mission/business needs. The publication also describes how to develop specialized sets of controls, or overlays, tailored for specific types of missions/business functions, technologies, or environments of operation. Finally, the catalog of security controls addresses security from both a functionality perspective (the strength of security functions and mechanisms provided) and an assurance perspective (the measures of confidence in the implemented security capability). Addressing both security functionality and security assurance ensures that information technology products and the information systems built from those products using sound systems and security engineering principles are sufficiently trustworthy.

The purpose of the guide is to discuss the security concerns associated with full virtualization technologies for server and desktop virtualization, and to provide recommendations for addressing these concerns. All forms of virtualization other than server and desktop full virtualization are outside the scope of this document.
 
Most existing recommended security practices remain applicable in virtual environments. The practices described in this document build on and assume the implementation of practices described in other NIST publications.

This document proposes a framework that identifies and characterizes the information and relationships needed to describe and measure properties of cloud services that are representative, accurate and reproducible. This information can be used in a variety of ways including, collection, comparison, gap analysis, and assessment or description of metrics at the technical or business levels. These metrics can connect information intended for decision-making, for the service agreements between provider and customer, for the runtime performance measurement and the underlying properties within the provider’s system.

This document defines a simplified profile of the TOSCA version 1.0 specification in a YAML rendering which is intended to simplify the authoring of TOSCA service templates. This profile defines a less verbose and more human-readable YAML rendering, reduced level of indirection between different modeling artifacts as well as the assumption of a base type system.
 
The TOSCA Simple Profile in YAML specifies a rendering of TOSCA which aims to provide a more accessible syntax as well as a more concise and incremental expressiveness of the TOSCA DSL in order to minimize the learning curve and speed the adoption of the use of TOSCA to portably describe cloud applications.
 
This proposal describes a YAML rendering for TOSCA. YAML is a human friendly data serialization standard (http://yaml.org/) with a syntax much easier to read and edit than XML. As there are a number of DSLs encoded in YAML, a YAML encoding of the TOSCA DSL makes TOSCA more accessible by these communities.
 
This proposal prescribes an isomorphic rendering in YAML of a subset of the TOSCA v1.0 XML specification ensuring that TOSCA semantics are preserved and can be transformed from XML to YAML or from YAML to XML. Additionally, in order to streamline the expression of TOSCA semantics, the YAML rendering is sought to be more concise and compact through the use of the YAML syntax.

This document defines a simplified profile of the TOSCA version 1.0 specification in a YAML rendering which is intended to simplify the authoring of TOSCA service templates. This profile defines a less verbose and more human-readable YAML rendering, reduced level of indirection between different modeling artifacts as well as the assumption of a base type system.
 
The TOSCA Simple Profile in YAML specifies a rendering of TOSCA which aims to provide a more accessible syntax as well as a more concise and incremental expressiveness of the TOSCA DSL in order to minimize the learning curve and speed the adoption of the use of TOSCA to portably describe cloud applications.
 
This proposal describes a YAML rendering for TOSCA. YAML is a human friendly data serialization standard (http://yaml.org/) with a syntax much easier to read and edit than XML. As there are a number of DSLs encoded in YAML, a YAML encoding of the TOSCA DSL makes TOSCA more accessible by these communities.
 
This proposal prescribes an isomorphic rendering in YAML of a subset of the TOSCA v1.0 XML specification ensuring that TOSCA semantics are preserved and can be transformed from XML to YAML or from YAML to XML. Additionally, in order to streamline the expression of TOSCA semantics, the YAML rendering is sought to be more concise and compact through the use of the YAML syntax.

This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
The following is a non-exhaustive list of the use cases which are supported by this specification.

• Building and packaging an application in a local Application Development Environment (ADE)
• Building an application in an ADE running in the cloud
• Importing a Platform Deployment Package into the cloud
• Uploading application artifacts into the cloud
• Run, stop, suspend, snapshot, and patch an application

This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
The following is a non-exhaustive list of the use cases which are supported by this specification.

• Building and packaging an application in a local Application Development Environment (ADE)
• Building an application in an ADE running in the cloud
• Importing a Platform Deployment Package into the cloud
• Uploading application artifacts into the cloud
• Run, stop, suspend, snapshot, and patch an application

This document describes Web Services Agreement Specification (WS-Agreement), a Web Services protocol for establishing agreement between two parties, such as between a service provider and consumer, using an extensible XML language for specifying the nature of the agreement, and agreement templates to facilitate discovery of compatible agreement parties. The specification consists of three parts which may be used in a composable manner: a schema for specifying an agreement, a schema for specifying an agreement template, and a set of port types and operations for managing agreement life-cycle, including creation, expiration, and monitoring of agreement states.
 
The goal of WS-Agreement is to standardize the terminology, concepts, overall agreement structure with types of agreement terms, agreement template with creation constraints and a set of port types and operations for creation, expiration and monitoring of agreements, including WSDL needed to express the message exchanges and resources needed to express the state.
 
During almost three years after the publication as GFD.107 in May 2007 a number of typos and formatting problems have been reported. None of them was affecting the normative part of the specification. This document is a revised version of GFD.107, which fixes all typos in the descriptive part of the document. The changes have been implemented during the GRAAP sessions at OGF 28 in Munich. Oliver Wäldrich, Philipp Wieder and Wolfgang Ziegler have prepared this version of the document.

Draft new Recommendation ITU-T Y.MLaaS-reqts: "Cloud computing- functional requirements for machine learning as a service"

The present document specifies the interfaces supported over the Ve-Vnfm-em and Ve-Vnfm-vnf reference points of the NFV-MANO architectural framework ETSI GS NFV-MAN 001 as well as the information elements exchanged over those interfaces.

The present document develops a set of normative interoperability requirements for the Network Function Virtualisation (NFV) hardware ecosystem and telecommunications physical environment to support NFV deployment. It builds on the work originated in ETSI GS NFV 003.
 
The present document focusses on the development of requirements to enable interoperability of equipment in the telecommunications environment to support NFV deployment. The following areas are examined:

• Operations
• Environmental
• Mechanical
• Cabling
• Maintenance
• Security

The present document identifies the most common design patterns for using SDN in an NFV architectural framework. It also identifies potential recommendations to be fulfilled by the entities that perform the integration.
 
ETSI ISG NFV has defined an NFV architectural framework operating on the basis of the principle of separating network functions from the hardware they run on by using virtual hardware abstraction. The major components in this framework are (From ETSI GS NFV 002):

• Network Functions Virtualisation Infrastructure (NFVI): subsystem which encompasses Compute, Network and Storage resources, i.e. the totality of all hardware and software components that build up the environment in which VNFs are deployed.
• Management and Orchestration (MANO): subsystem which includes the Network Functions Virtualisation Orchestrator (NFVO), the Virtualised Infrastructure Manager (VIM) and Virtual Network Function Manager (VNFM).
• Virtual Network Functions (VNFs): deployed in the NFVI.

The present document provides an overview of SDN in relation to this ETSI NFV architectural framework as well as a summary of current industry work including a comparison of network controllers and PoCs including NFV and SDN.