m2P1_PWS_FINAL_8JUL16.doc

PERFORMANCE WORK STATEMENT (PWS)

milCloud 2.0 Phase 1 (m2P1)

Date: July 8, 2016 Table of Contents

41. Contracting Officer’s Representative (COR).

42. Contract Title.

43. Background.

54. Objectives.

55. Scope.

76. Performance Requirements.

76.1 – Task1, Subtask 1.1 - Infrastructure Service Requirements for Unclassified Workloads and Data (CLIN 0001)

76.1.1 Infrastructure Services Detailed Facilities Analysis

86.1.2 Compute Requirements.

96.1.3 Storage Requirements.

106.1.4 Provisioning Requirements.

116.1.5 Documentation Requirements.

116.1.6 Supported Guest Operating System Requirements.

126.1.7 Network and Transport Requirements.

136.1.8 Security Requirements.

186.1.9 Architecture Requirements.

196.1.10 Support and Service Level Requirements

236.1.12. Price and Billing Requirements.

236.1.13 Associated Services Requirements.

246.1.14 Accreditation Requirements.

256.2 Task Area 1, Subtask 1.2 - Infrastructure Service Requirements For SIPRNet-Connected Workloads and Data

256.3 Task Area 1, Subtask 1.3 – Other Services

266.4 Task Area 2, Subtask 2.1, Workload Transition Support

266.4.1 Technical Engineering Activities.

266.4.2 Technical Intermediation.

276.5 Task Area 2, Subtask 2.2, Program Management Support

276.5.1 Program Administration.

286.5.2 Program Office Support.

296.6 Task Area 2, Subtask 2.3, Closeout

297. Cyber Threat Security Plan.

318. Performance Standards.

319. Incentives.

3110. Place of Performance.

3111. Period of Performance.

3112. Delivery Schedule.

3313. Security Requirements.

3614. Government-Furnished Equipment (GFE) / Information (GFI).

3615. Other Pertinent Information or Special Considerations.

4016. Section 508 Accessibility Standards.

PERFORMANCE WORK STATEMENT (PWS)

as of 7/8/2016

1. Contracting Officer’s Representative (COR).

a. Primary COR.

Organization:

Department of Defense Activity Address Code (DoDAAC):

HC1047

Phone Number:

Fax Number:

E-Mail Address:

b. Alternate COR.

Organization:

Phone Number:

Fax Number:

E-Mail Address:

2. Contract Title.

milCloud 2.0 Phase 1 (m2P1)

3. Background.

The Department of Defense (DoD) has a requirement for cloud infrastructure services in its data center facilities. These commercially-developed infrastructure services are to be available within DoD networks, implemented as a “private cloud” service deployment, with the single tenant being the DoD community and DoD partners.

This effort is being undertaken to leverage the substantial ongoing and persistent commercial investment into high density multi-tenant computing environments at lower total cost of ownership than traditional DoD efforts. The goal is to improve the on boarding efficiencies for DoD consumers, reduce cost, increase efficiency of computing platforms and increase the IT security posture of the U.S. government.

This capability will be accredited according to the Risk Management Framework (DoDI 8510.01) via the Defense Information System Agency (DISA), using the list of security controls from the Cloud Computing Security Requirements Guide (SRG) Level 5.

DISA will act as the Authorizing Official (AO) for all risk review or adjudication concerns.

The DoD has applications and data distributed across the United States. This deployment will exist within the DoD Wide Area Network (WAN) and will directly connect to the Department of Defense Information Network (DoDIN) Non-Secure Internet Protocol Router Network (NIPRNet).

4. Objectives.

The DoD’s objectives for the Phase 1 commercial infrastructure services are as follows:

a) Provide robust and resilient infrastructure services to DoD consumers and DoD partners for a variety of highly protected workloads (workload – a virtual machine, virtual server, or machine image);

b) Improve availability, performance, and flexibility of datacenter services;

c) Reduce DoD’s Total Cost of Ownership (TCO) of delivering infrastructure services;

d) Prove out a set of essential business processes for later broader use in the DoD IT cloud portfolio including: infrastructure service contracting, billing, metering, and automated provisioning;

e) Provide interoperable solutions that enable portability across hosting models and service Contractors;

f) Ensure applicable cybersecurity and privacy regulations are maintained and adhered to;

g) Enable scaling of infrastructure and application resources to meet evolving application and user demand;

h) Promote the use of Green IT by reducing the overall energy and real estate footprint of DoD datacenters, and implementing effective recycling and reuse of programs;

i) Operate up to 5,000 workloads successfully between both sites for Full Operational Capability (FOC), with ability for growth.

5. Scope.

The milCloud 2.0 Phase 1 (m2P1) is a full and open competition to bring commercial infrastructure services into DoD facilities, connected to DoD networks in a private deployment model for use by the DoD community and DoD partners. The Contractor will also provide workload transition engineering services to support the movement of workloads onto this service infrastructure. The anticipated contract will have fixed prices for each type of unit of service for the defined cloud infrastructure services and labor services defined in this PWS. The DoD anticipates that infrastructure services will need to be capable of scaling from a small initial implementation up to 50 workloads at Initial Operational Capability (IOC) to a target state supporting approximately 5,000 workloads at Full Operational Capability (FOC), with the ability to scale beyond this target state if supported by DoD consumer demand. The infrastructure services will operate from two DoD physical sites, referenced in Section 10.

This PWS defines the requirements for commercial infrastructure services to be placed in DoD facilities for use by the DoD community and DoD partners. The general goal of this effort is to bring the best cloud infrastructure ecosystems inside the DoD perimeter, and leverage the substantial commercial investment and progress in industry, while still protecting the highest level DoD workloads, data, and applications. The Contractor is encouraged to provide the latest cloud technology to DoD by refreshing the provided technology as available especially if the refresh provides cost efficiency or improved performance. This PWS defines requirements for the Contractor, operating as an Infrastructure as a Service (IaaS) service provider for the DoD community.

The infrastructure services requested of the Contractor cloud ecosystem in this PWS include:

• Workload/Virtual Machine (VM) compute services – being able to start, stop, clone, preserve and restore workloads.

• Object storage – being able to create, update, read, and delete objects and files.

• Block storage – binary level storage to support workloads and VMs.

• Other support services – assorted integrated Contractor services that support the primary services in the ecosystem above, such as provisioning, metering, billing, networking, identity, and resource management services.

When directed, the Contractor will also support transitioning workloads to this IaaS environment. Transition and program management support includes a number of engineering activities and can include tasks such as:

• Planning, engineering, and executing the transition of workloads and supporting data

• Virtualizing workloads for operation in this IaaS environment

• Testing the operation of transitioned workloads

• Performance optimization of transitioned workloads in the target environment

• Publication of lessons learned, best practices, and engineering approaches to the DoD Community, to save resources during future transitions

DoD Consumer infrastructure resource requests will be fulfilled by m2P1. After award, a Contractor-provided online ordering and provisioning mechanism will be available to submit Consumer infrastructure resource requests to the Contractor for a Service Level Agreement (SLA) compliant infrastructure service deployment. Additionally, Consumer requests for additional workload transition engineering support will be submitted via this mechanism.

Figure 5.1: Overview of milCloud 2.0

Figure 5.1 depicts m2P1 and its envisioned support for DoD Consumers. Consumers from a wide range of IT programs will bring their server and data storage needs to be fulfilled by milCloud 2.0. Consumers can be DoD IT programs, application owners, and development teams, supporting any of the missions of DoD. Typical Consumers may currently have physical machines/servers or may have already virtualized the servers in their IT portfolios. The selected m2P1 Contractor will use DoD data center floor space, in two locations for Phase 1, to offer their commercial cloud infrastructure services to the DoD Consumers. The Contractor will also support the transition of Consumer workloads and data to the m2P1 infrastructure servers. DISA Facilities will host the Contractor hardware and software solution in two locations, providing services such as power, HVAC, and network transport. The inside network perimeter will be the Internal Cloud Access Point (ICAP). The network services provided by DISA will be the wide area transport.

The RFP’s requirements have been divided into three distinct task areas:

Task Area 1: Infrastructure Services Deployment and Operations

Subtask 1.1: Infrastructure Services For Unclassified Workloads and Data

Subtask 1.2: Infrastructure Services For SIPRNet-connected Workloads and Data [Optional CLIN] Subtask 1.3: Other Services [Optional CLIN] Task Area 2: Transition Services and Program Management Support

Subtask 2.1: Workload Transition Support

Subtask 2.2: Program Management Support

Subtask 2.3: Closeout

The Contractor shall provide Task Area 1 subtask 1.1 and Task Area 2

6. Performance Requirements.

The following subsections define the performance requirements for m2P1.

6.1 – Task1, Subtask 1.1 - Infrastructure Service Requirements for Unclassified Workloads and Data (CLIN 0001) This section provides the infrastructure service requirements for unclassified workload and data, including the compute and storage requirements of the commercial service provider.

The government shall retain ownership of all user created/loaded data and applications hosted on Contractor infrastructure. The government retains the right to request full copies of these workloads and data at any time. The data that is requested and provided by the Contractor must be presented in a readable format back to the government (decrypting Consumer data will be the Consumer’s responsibility).

6.1.1 Infrastructure Services Detailed Facilities Analysis

6.1.1.1 The Contractor shall provide data center subject matter expertise to assess the two selected DoD facility sites within 14 calendar days of contract award to support the installation of the Contractor’s cloud IaaS. The Contractor shall identify any facilities coordination requests that impact a successful site implementation of their cloud infrastructure solution including, but not limited to:

· Physical requirements of the Contractor solution; to include rack height and cable conveyance;

· Floor space currently available for the initial infrastructure implementation and room for growth;

· Space for Contractor on-DoD-premises staff and hardware spares and tools;

· HVAC capacity currently available for the initial infrastructure implementation and room for growth;

· Power and cooling requirements per rack and zone;

· Power capacity currently available for the initial infrastructure implementation and room for growth;

· Power provider diversity and automatic power backup failover;

· Network capacity currently available for the initial infrastructure implementation and room for growth;

· Integration requirement for NIPRNet and Secret Internet Protocol Router Network (SIPRNet) access (Note that the initial deployment for m2P1 is for the NIPRNet);

· DISN network connection diversity, redundant connections;

· Fire sensor alert mechanisms and integration with facility alerts.

The facilities analysis report will be included in the Installation Plan and adhere to the timelines listed below in Section 6.1.1.2.

6.1.1.2 Installation Plan and Timeline. Four weeks after contract award, the contractor shall deliver an initial report detailing a plan for infrastructure service installation at the two sites, and any risk/issues identified with implementation of their solution in the two DoD facilities along with recommended mitigations. A final version of the report as part of the IMS (section 6.5.1.1) shall be delivered six weeks after contract award. While developing the report, the Contractor will meet with and formally present all facilities coordination requests to the COR and immediately work with the COR to rapidly resolve any known risks to a successful physical implementation at the DoD facility. Having been informed of all identified issues, the COR may choose to accept some risks and proceed with the installation. The vendor will provide hardware delivery for all hardware required for IOC no later than 8 weeks after contract for the first site. Hardware delivery for the second site will be no later than 12 weeks after contract award. Installation and set-up of the hardware and software required for IOC for the first site will occur no later than 12 weeks after contract award. Installation and set-up of the hardware and software required for IOC for the second site will occur no later than 16 weeks after contract award.

6.1.2 Compute Requirements.

6.1.2.1 The compute services shall allow the Consumer to manage Workloads/Virtual Machines (VMs) including provisioning, starting, stopping, copying, cloning, saving and restoring VMs on demand.

6.1.2.2 The compute services shall allow the Consumer to choose their initial VM configuration from a government-approved set of operating systems (OSs) and machine configurations. The Contractor will define pre-packaged VMs for consumer use, with pre-defined configurations of memory, storage, and processing resources. (e.g., small, medium, large VMs).

6.1.2.3 The compute services shall require the Consumer’s identity to be associated to any VM that the Consumer provisions. The identity information shall include the personal identity of the Consumer’s system administrator and their organizational affiliation tied to their billing code.

6.1.2.4 The compute services shall allow for the provisioning of multiple VMs of the same configuration for a Consumer.

6.1.2.5 The Contractor will provide methods to migrate workloads from existing DoD virtualized infrastructure (V2V), and from legacy physical servers (P2V). The Contractor shall provide a mechanism for migration of operational workloads between the two m2P1 data center sites.

6.1.2.6 The Contractor shall provide rapid, self-service provisioning which includes, at a minimum:

(1) The provisioning service shall offer self-service initiation of provisioning actions through a programmatic interface (both an Application Programming Interface (API) and a command line interface (CLI)) or through a management console. Workflow approval processes shall be required regardless of the method used to initiate the provisioning action.

(2) The Contractor's self-service interface shall be able to provision multiple compute instances for multiple Consumers at the same time, without dependencies between those provisioning jobs.

(3) Provisioning shall initially utilize DISA-provided “Gold Images” as approved baseline machine images, but allow for consumers to store customized images built on the core images.

(4) The compute service shall allow the Consumer to bring their own workload machine images for importation. Image conversions may be required during importation.

(5) The compute service shall support the import and export of workload machine images to enable future hybrid or multi-vendor infrastructure approaches. The Contractor shall be able to support the importation of Open Virtualization Format (OVF), Virtual Machine Disk Format (VMDK) or virtual hard disk (VHD)-based images. Image conversions may be required during importation.

6.1.2.7 The compute service shall support metering of workload usage. Metering shall include how many workloads each Consumer is running; what type they are; and how long they are operated. Workload reporting will support a number of management activities including chargeback for resources used, planning for future infrastructure growth, guest operating system license management, or assessing which organizations are using what portion of the infrastructure resources.

6.1.2.8 The Contractor’s infrastructure services shall support guest OSs releases within 30business days of general availability in the marketplace. DISA intends to provide a gold image of new releases for Consumers as soon as practicable.

6.1.2.9 The Contractor shall support the Consumer’s ability to resize VM resources, including processors, memory, disk and network configurations.

(1) The Contractor shall not force Consumers to re-provision new workload instances with new characteristics.

(2) The Contractor shall offer this functionality in a granular manner, with controls for each resource, or through pre-bundled "sizes" of instances in the service catalog.

(3) Some guest OS families may require a guest OS reboot for changes to take effect.

(4) Adding or removing resources should be performed via online management tool and shall support a workflow in order for the DoD partner to review and approve the changes in resources before they are implemented.

6.1.2.10 The infrastructure services shall be architected to avoid VM outages or downtime when the Contractor is performing hardware or service maintenance. This includes avoiding network access interruptions for production, data or control networks.

6.1.2.11 The infrastructure services shall support the automated failover of workloads between the two physical sites to support Continuity Of Operations (COOP), if applicable to the Consumer.

6.1.2.12 The infrastructure services shall be architected in such a way to automatically migrate and restart instances on a healthy host if the original physical host fails. The failure detection for workloads shall occur within five minutes.

6.1.2.13 The Contractor shall provide VM maintenance/failure notifications. If a compute resilience event occurs (such as live migration, instance restart or memory preserving maintenance), the infrastructure services must support the ability for Consumers, DISA, and identified reporting/monitoring bodies to be notified that such an event occurred. Performance standards are as follows:

(1) At a minimum, an option for email notification shall exist.

(2) The Consumer shall be able to opt in or out of this communication via self-service means.

6.1.2.14 The Contractor shall provide VM restart flexibility. In the event where infrastructure maintenance must occur and a VM restart is necessary, the Contractor shall offer the Consumer flexibility in selecting restart scheduling windows per VM.

6.1.2.15 The Contractor shall provide instance anti-affinity which allows Consumers to adhere to higher degrees of application availability by ensuring that a single physical failure event does not take all instances offline. The anti-affinity setting shall be set by the Consumer in a self-service fashion.

6.1.2.17 The Contractor shall stand up a pre-production environment that connects to the DoDIN but is separated from the production environment and data. The Contractor will be responsible for ensuring that any changes and/or upgrades to the milCloud infrastructure are properly tested in the pre-production environment prior to being released to Production. Prior to releasing to production, the contractor will be required to submit a test report validating all upgrades are operationally ready for production and that the security posture of the infrastructure has not been compromised by the upgrades.

6.1.3 Storage Requirements.

For the purposes of this PWS, the following definitions apply:

Block storage service: Instance-independent block storage whereby the Consumer can obtain block storage volumes that are network-attached and independent of any specific compute instance. The Consumer can then mount this storage volume on a compute instance.

Object storage service: Internet-accessible storage offering whereby the Consumer can upload, download and interact with files and objects.

6.1.3.1 The Contractor shall offer object and block storage services as part of the infrastructure services.

6.1.3.2 The Contractor shall provide a block storage service with the following criteria:

(1) The block storage service shall be a scalable, VM-independent service.

(2) The block storage service shall allow the overall capacity of the storage service to be logically unlimited per Consumer.

(3) The storage service shall support a point-in-time copy of a storage volume, known as a snapshot.

(4) The Consumer shall be able to create a snapshot of any storage volume through self-service means.

(5) Snapshots shall be able to be used as a machine image for the purpose of self-service provisioning new compute instances.

6.1.3.3 The Consumer shall be able to increase/decrease the size of an existing block storage volume. Updated sizes and durations will be reported under the chargeback and billing capabilities.

6.1.3.4 The Contractor shall provide object storage service with the following criteria:

(1) The Contractor shall provide an object storage service where objects (e.g., individual files) can be stored and retrieved via a REST API.

(2) The storage service must be able to support at least 1 TB object/file sizes.

6.1.3.5 The Contractor shall provide the ability to automatically replicate objects across multiple data centers.

6.1.3.6 The Contractor shall offer the capability for Consumers to choose to log, and be able to audit, every administrative object storage service request, including at a minimum logging of create, read, write, copy and delete events.

6.1.3.7 The Contractor shall offer a bulk data import and export service for moving large amounts of data, greater than 1 TB, both into and out of the infrastructure services. The Contractor shall post specifications for the bulk data import and export service on the infrastructure portal, to include hardware and software interfaces or relevant processes.

6.1.3.8 The object storage services must offer Consumers the self-service ability to opt into native encryption on the storage services, such as server side encryption (SSE) for objects or object hierarchies within the storage service. Consumers shall be able to manage their own encryption keys and encrypt their own data prior to uploading and storing within the Contractor’s storage service.

6.1.3.9 Consumers must be able to choose explicit performance target or performance tier on block storage volumes, such as a certain number of Input/Output (I/O) operations per second Input/Output Operations per Second (IOPS), or Mbps of throughput, per 6.1.10.1.

6.1.3.10 The contractor shall provide a high IOPS service offering to high transaction volume systems, per Section 6.1.10.1.

6.1.4 Provisioning Requirements.

The requirements for supporting the provisioning of infrastructure resources are as follows:

6.1.4.1 The Contractor shall provide access to a browser-based management functionality for government approval to conduct provisioning, configuring, and termination of compute and storage infrastructure resources.

6.1.4.2 The Contractor’s solution shall support automated provisioning of infrastructure resources, without requiring human coordination between the Contractor and the government. The provisioning and de-provisioning of infrastructure services shall be within 30 minutes (calculated as the average time taken).

6.1.4.3 The Contractor’s solution shall provide the ability to provision, modify and terminate virtual machines, storage and bandwidth dynamically, as requested via online portal or API.

6.1.4.4 The provisioning service shall enable a check for an approved funding source before provisioning is complete. The provisioning process shall include a workflow capability for designated government staff to approve requested resources (e.g., VMs), and associated contract charges, prior to instantiation. The workflow shall clearly identify unit costs associated with the resources being requested and record the Consumer and the approver of the provisioning request.

6.1.4.5 The provisioning service shall enforce that provisioning actions are performed by approved individuals in an organization. The workflow shall support the identification and designation of one or more approvers and the appropriate sequence of approvals required for each consumer organization. The workflow shall be tailorable in self-service manner for each consumer organization, with role based limitations for who may modify the workflow.

6.1.4.6 Provisioning Templates. The Contractor shall offer Consumers the ability to create infrastructure templates. A template is a blueprint, or build manifest, that allows a collection of different resources to be provisioned together, such as compute instances, storage volumes, network elements, monitoring configurations and security configurations. The Consumer shall be able to create, store and provision from templates. The templates must be able to utilize DISA-provided, Contractor-provided or Consumer-provided VM images.

6.1.4.7 The provisioning service shall offer Consumers the ability to choose their site location, specifically to fulfill their COOP requirements.

6.1.4.8 The Government will provide lines of accounting (LOAs) for billing purposes on the task order and advise those authorized to place orders against the specific LOA. Contractor will be required to monitor available funding and provide advanced notice when additional funds are required IAW FAR 252.232-7007, Limitation of Government’s Obligation.

6.1.5 Documentation Requirements.

As DoD Consumers consider the Contractor’s service offerings, they will seek information on attributes of the infrastructure services such as service level agreements, standards compliance, connectivity and example uses. Providing a rich resource of on-line content with government concurrence can be immensely helpful to DoD Consumers, program managers and support contractors. The online content will also have the effect of reducing technical risks and costs for migrating Consumers to the infrastructure services. The Contractor shall provide the following types of online content in a consolidated infrastructure service portal hosted on NIPRNet:

(1) Self-help materials including ‘How to get started’ guides to aid new service Consumers

(2) Frequently asked questions (FAQs)

(3) Service costs and billing information

(4) Help desk and technical support contact information

(5) Program management and contracting points of contact information

(6) Infrastructure ecosystem APIs and their usage

(7) Infrastructure service SLAs and maintenance windows

(8) Instructions for operational support tools

(9) Integration instructions for identity management services

(10) Sample code and software development kits (SDKs)

(11) Articles and tutorials as appropriate

6.1.6 Supported Guest Operating System Requirements.

6.1.6.1 At a minimum the Contractor’s infrastructure service solution must support the following guest operating systems (OSs):

(1) Windows 7, 8, 10, Basic, Enterprise, and Pro

(2) Windows Server 2016

(3) Windows Server 2012 Enterprise Edition, Data Center Edition, Standard Edition

(4) Windows Server 2008 Enterprise Edition, Data Center Edition, Standard Edition, Business Server, Web Edition

(5) CentOS 6.x, 7.x

(6) Red Hat Enterprise Linux 6.x, 7.x

The infrastructure services are not limited to these OS’s. Additional guest operating systems offered by the contractor may be supported as well.

DISA will provide operating system images to the Contractor for use in the infrastructure services catalog in accordance with the Security Technical Implementation Guide (STIG) process.

6.1.6.2 The infrastructure services shall allow Consumers to maintain a catalog of machine images to include gold “STIG’ed” images.

6.1.6.3 The Contractor shall incorporate the cost of the operating systems licenses into the unit pricing for the compute services. The government will not have additional costs for guest operating system licenses.

6.1.7 Network and Transport Requirements.

6.1.7.1 The Contractor’s infrastructure solution shall connect to the DoDIN at the ICAP. The Contractor shall support all Cloud Computing SRG and FEDRAMP+ network protection, security and reporting requirements for the enclave within that perimeter. The contractor shall support the DoD Internet-NIPRNet DMZ Technology Security Technical Implementation Guide (STIG) and the Network Infrastructure STIG for network architecture requirements.

6.1.7.2 The Contractor shall provide Consumer-defined LAN topology, which includes, but is not limited to:

(1) Allows Consumers the ability to automate the implementation of a hierarchical network infrastructure in the hosting environment and choose their Internet Protocol (IP) addressing scheme without dependency on the infrastructure provider.

(2) Allows Consumers the ability to design the following network components and layouts prior to deploying any compute instances:

• Subnet or VLANs

• VPN

• Load balancing

(3) The infrastructure services shall provide isolation between Consumers in accordance with DoD guidance and SRG. Virtual/Logical separation will ensure deny-by-default blocking of all ports, protocols and services between Consumers unless explicitly allowed by the Consumer.

(4) The contractor shall provide all network and network security capabilities/equipment needed to comply with STIGs referenced above.

6.1.7.3 Contractor shall offer the ability to connect instances, as allowed by the guest OS, and in accordance with the Applicable Documents in Section 15(g). At a minimum:

(1) Provide two different virtual network interface cards (NICs) and routing networks simultaneously.

(2) Support at least two network segments.

6.1.7.4 The Contractor shall provide static IPs and support Network Address Translation (NAT). Specifically; the Contractor shall support the following capabilities:

(1) If a VM is dynamically assigned an IP address that address shall remain the same across the lifetime of the VM (unless the Consumer requests a change).

(2) The Consumer shall be able to obtain an IP address from the Contractor that can be assigned to a VM or load-balancing pool, that can be moved between VMs or load-balancing pools and that persists as long as the Consumer wants.

6.1.7.5 Consumers must have the ability to choose or define a customized IP address space within the infrastructure service environment.

6.1.7.6 The Contractor shall enable Consumers to build multiple, defined internal networks in the form of network segments (for example, IP subnets) at the hosting environment that can span two or more physical data centers.

6.1.7.7 Contractor shall support the ability to load-balance front-end (external-facing) instances and back-end instances. The load balancing functions must support health checks (e.g., avoid sending requests to nonresponsive compute instances) and round robin, weighted or metrics-driven algorithms. Furthermore, the service shall support at least one of the two following algorithms:

(1) Latency-based request routing: Where the request is directed to the endpoint with the lowest latency between the requestor and the location.

(2) Geographic request routing: Where the request is directed to the endpoint based on the location of the request origination.

6.1.7.8 The Contractor shall provide a self-service capability to configure global load balancing where requests are directed to endpoints that may be located in different data centers.

6.1.7.9 External network security Access Control Lists (ACLs)/firewall. The Contractor shall offer Consumers the ability to allow and deny external network traffic based on source and destination address, port, and protocol within their area of responsibility. Consumers shall also be able to group infrastructure elements and assign a set of ACLs to the group rather than to individual instances one at a time. The service shall be stateful.

6.1.7.10 Internal network security ACLs/firewall. The Contractor shall offer Consumers the ability to allow and deny internal network traffic (within the Consumer’s instance deployments) based on source and destination address and port. Consumers must also be able to group infrastructure elements and assign a set of ACLs to the group rather than to individual instances one at a time. The service must be stateful.

6.1.7.11 Contractor shall not force Consumers to shut down, reboot or redeploy any Consumer infrastructure involved in the change of a network security ACL or group in normal operations..

6.1.7.12 The Contractor shall allow Layer 2 connectivity to DISA approved external subnets in order to allow a hybrid environment including co-located physical servers and appliances.

6.1.7.13 The Contractor shall allow connectivity to allow a consumer environment to connect to a Community of Interest Network (COIN) or Lobe Extension to an off-premises Consumer enclave.

6.1.7.14 The contractor shall permit Consumer connectivity to DISA approved external services including Storage as a Service offerings that are available on the DoDIN.

6.1.8 Security Requirements.

6.1.8.1 The Contractor shall ensure that each individual Service Offering is supported by an accreditation package submitted to the designated Authorizing Official (DISA).

6.1.8.2 The Contractor shall provide secure remote access connectivity into compute instances (e.g., Secure Shell, Remote Desktop Protocol) for the Consumer in accordance with DoD security requirements.

6.1.8.3 The contractor shall implement and maintain the infrastructure in accordance with all applicable DoD processes, policies, and procedures as they are updated and/or newly implemented. All DoD/DISA STIGs and Security Requirements Guides, checklists, and other implementation guidance applicable to applications, systems, and infrastructures.

6.1.8.4 The Contractor shall document information assurance (IA) control expectations and the division of responsibility between the Contractor, the facility provider, and the Consumer, with concurrence from the government. These shall include, at a minimum, operational controls and security risk controls that the Consumer must employ. These may be provided in the form of a checklist or documented in a shared responsibility model.

6.1.8.5 The Contractor shall have documented evidence that it adheres to the DoD 5220.22-M or National Institute of Standards and Technology Special Publication (NIST SP) 800-88 processes for data sanitization and disposal when the Contractor retires or otherwise disposes of physical storage devices (such as disks and arrays), found in section 15(g). This policy shall apply to all storage services.

6.1.8.6 Consumer data ownership. Although the Contractor owns the rights to the overall service and physical infrastructure, the general terms of service and enterprise agreements shall specify that ownership rights to all data, inputs and outputs of consuming the service are retained by the government. The data and Consumer application ownership shall be retained by the Consumer under all circumstances. Consumer data will not be replicated or sold.

6.1.8.7 Secure instance access credentials. The default administrative access for every deployed instance must be automatically generated or chosen at the point of provisioning by the Consumer. If automatically generated, the access credentials must be communicated to the service administrator either through a secure API service call or visually in the management console. Passwords shall not be emailed or otherwise communicated in an unsecured fashion.

6.1.8.8 Transport Layer Security (TLS) -secured API endpoints: Contractor shall offer API endpoints that are secured with TLS.

6.1.8.9 Multiple API keys per Consumer. Contractor shall allow Consumers to generate and own multiple API keys per Consumer. API keys must be securely stored.

6.1.8.10 Local identity management and granular role-based authorizations. The Contractor shall include local accounts with granular role-based authorization for compute services in both the service interfaces and management console.

(1) Compute. At a minimum, the role-based authorization must support assigning authorization based on individual users and groups of users and must support, as applicable, delineation of the following granular actions: create, delete, restart/reboot, shutdown, startup and back up/snapshot.

(2) Storage. At a minimum, the role-based authorization must support assigning authorization based on individual users and groups of users and must support, as applicable, delineation of the following granular actions: object create, read, update, and delete.

(3) Network services. At a minimum, the role-based authorization must support assigning authorization based on individual users and groups of users, and delineation must be assignable per firewall, load balancer, IP address and network segment and support, as applicable, the following granular actions: create, delete and configure.

6.1.8.11 Define User Roles and Support User Authorization Workflows. The Contractor shall provide a browser-based management functionality which shall be controlled via configurable role-based user accounts. Furthermore, these accounts shall be customizable including, at a minimum the following access rights:

(1) Restricting access to each major component of the console (e.g., restricting who can provision resources or view reports).

(2) Defining access rights for accessible components (e.g., scope of access, read-only versus read-write access).

(3) Supporting administrator roles with the ability to create, modify, delete, and configure user accounts, profiles and permissions.

(4) Supporting an administrator capability to create authorization workflows with resource provisioning approval capabilities.

6.1.8.12 Access to image catalog. The Contractor shall offer basic role-based authorization into the machine image catalog so that granular rights (e.g., create, deploy, delete) can be assigned.

6.1.8.13 Federated SSO to management console. The Contractor shall offer single-sign on (SSO) login access to the graphical user interface (GUI) management console through Security Assertion Markup Language (SAML) assertions. All management consoles and capabilities including browser, RESTful and API based access must be protected by TLS.

6.1.8.14 MFA administrative access control (root and admin). Contractor shall offer Consumers the ability to control root (that is, parent- or master-level) administrative access to the infrastructure services through multifactor authentication (MFA). Examples of satisfactory multifactor authentication include hardware- or software-based secure tokens based on the hash message authentication code (HMAC)-based one-time password (HOTP); (HMAC-based, Request for Comments (RFC) 4226 or time-based one-time password (TOTP); time-based, RFC 6238) algorithm.

6.1.8.15 Cybersecurity Requirements.

(1) Vulnerability Management. The Contractor shall:

a. Apply and maintain STIGs applicable to the management plane of the environment and any supporting operating systems or applications on the management infrastructure, per the Information Assurance Support Environment (IASE) website (http://iase.disa.mil);

b. Apply and maintain STIGs applicable to the infrastructure’s hypervisors, per the Information Assurance Support Environment (IASE) website (http://iase.disa.mil);

c. Ensure vulnerability compliance using the DISA Assured Compliance Assessment Solution (ACAS), per the DISA website (http://www.disa.mil/cybersecurity);

d. Upload vulnerability scans to the Continuous Monitoring and Risk Scoring System (CMRS) portal, the DISA website (http://www.disa.mil/cybersecurity);Remediate scanned results and repeat as needed.

(2) Privileged Accounts. The Contractor shall:

a. Create Common Vulnerabilities and Exposures (CVE) administrator accounts as needed;

b. Modify CVE administrator accounts;

c. Enforce Common Access Card (CAC) authentication for CVE administrator accounts;

d. Track CVE administrator accounts' compliance with the requisite information system access authorization documentation (e.g., System Authorization Access Request and Privileged Access Agreement forms);

e. Create passive administrative accounts to monitor resources; and

f. Perform password resets.

(3) Security Auditing Management

a. Provide an event log aggregation service;

b. Provide an event log correlation service;

c. Collect CVE event audit logs; and

d. Generate on demand CVE event audit reports.

(4) The infrastructure services shall interface to a DoD-provided Computer Network Defense Service.

a. In addition, Computer Network Defense (CND) is described in DoDI O-8530.2, Support to CND. In accordance with (IAW) the Cloud Computing (CC) SRG (Sections 5.10.5 and 5.10.6) every capability must be aligned with an accredited Computer Network Defense Service Provider (CNDSP) that provides protection, detection, and response. This DoD requirement is the responsibility of the Consumer.

b. The Contractor shall cooperate with United States Law Enforcement (LE) and Counter intelligence (CI) personnel engaged in the conduct of LE and/or CI investigations. If an incident or data breach occurs in the offering environment that is within the capability authorization boundary and requires forensic investigation only on components/resources within the Consumer’s control, it is the responsibility of the Consumer to conduct applicable forensics, communicate awareness, and to engage the Contractor as required and specified in the task order (TO) and DoD Cloud CND concept of operations (CONOPS).

If an incident or data breach occurs in the offering environment that is within or directly affects the capability authorization boundary but requires forensics on components/resources outside the Consumer’s control, the Contractor shall allow forensic investigations for both LE/CI and non-LE/CI purposes in the physical/logical CSP boundary. The Contractor shall, as specified in the TO and DoD Cloud CND CONOPS, support these forensic investigations without affecting data integrity and with assistance but not interference with the forensic investigation. (For example, the CSP may logically separate respective data and store in a FedRAMP compliant environment with access limited to authorized government personnel so forensic evaluations can be conducted.)

c. As noted in Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B (Located in section 15(g)), cyber reportable events or incidents that may lead to criminal or disciplinary investigations require notification and reporting to LE/CI. At such time, data from the incident will be preserved in a forensically sound manner to enable possible criminal prosecution or LE/CI operations (e.g., forensic evidence is collected for suspected and/or known access violation, theft, and/or damage caused by trusted insiders where further prosecutorial investigation is considered).

d. IAW Committee on National Security Systems Instruction (CNSSI) 4009 (Located in section 15(g)), the Committee on National Security Systems (CNSS) Glossary defines spillage as a “security incident that results in the transfer of classified information onto an information system not authorized to store or process that information.” In alignment with this definition, the DoD Cloud CND CONOPS states that spillage/unauthorized disclosure in the cloud includes but is not limited to transfer of information from a higher Impact Level to a lower one (e.g., Impact Level 4 data on an Impact Level 2 CSP offering) or posting of information to an Impact Level 2 cloud offering that has not been approved for public or unclassified private release (e.g., International Traffic and Arms Regulations, Personally Identifiable Information, etc.). Upon written notification or discovery of a spillage by the government or Contractor, the Contractor shall work with the Contracting Officer, COR, and Consumer to correct the spillage IAW with the CC SRG (Section 5.7 and Appendix D).

If spillage occurs in the offering environment on components/resources within the government’s control and was triggered (deliberately or via negligence) by the government (upon notification or discovery by the government or CSP), it is the responsibility of the government to respond/report; communicate awareness; and engage the Contractor to resolve as applicable and specified in the TO.

If spillage occurs in the offering environment on components/resources within the government’s control but was triggered by the CSP (upon notification or discovery by the government or CSP), the Contractor shall, as specified in the TO, work with the government to respond/report (including providing specific timeframes for resolution), maintain the level of security required by the government; communicate awareness; and work with the government to resolve.

If spillage occurs in the offering environment on components/resources NOT within the government’s control (only the CSP’s upon notification or discovery by the government or CSP), the Contractor shall respond/report (including providing specific timeframes for resolution), maintain the level of security required by the government, communicate awareness, and engage the government to resolve as applicable and specified in the TO.

The DoD Cloud CND CONOPS outlines these procedures in more detail (which is located at the DoD Cloud Computing Security site - http://iase.disa.mil/cloud_security/Pages/index.aspx).

(5) The contractor shall have documented high availability and Disaster Recovery (DR) capabilities to support the performance levels defined in the SLA and procedures between the two physically separated and hosted infrastructure locations. This includes data backup and restore functions.

(6) When Contractor personnel have access to Privacy Information, the Contractor personnel shall adhere to the Privacy Act of 1974. The Contractor shall meet the privacy requirements identified in CNSSI 1253, Security Categorization and Control Selection for National Security Systems, and privacy overlay IAW the CC SRG (Section 5.1.2). All referenced documents are listed in Section 15(g).

(7) Misuse of government Data and Metadata. The Contractor shall not access, use, or disclose government data or metadata unless specifically authorized by contract/TO terms. If authorized by the terms of the contract/TO, any access to, or use or disclosure of, government data shall only be for purposes specified in the contract/TO. The Contractor shall ensure that its employees are subject to all such access, use, and disclosure prohibitions and obligations. These access, use, and disclosure prohibitions and obligations shall survive the expiration or termination of the contract/TO.

The Contractor shall use government-related data only to manage the operational environment that supports the government data and for no other purpose unless otherwise permitted with the prior written approval of the Contracting Officer.

A breach of the obligations or restrictions may subject the Contractor to criminal, civil, administrative, and contractual actions in law and equity for penalties, damages, and any other appropriate remedies by any party adversely affected by the breach.

(8) Use of Sub-Contractors. The Contractor(s) shall retain operational configuration and control of data repository systems used to process and store government data to include any remote work for Information Impact Levels 4 and 5.

(9) Records. The DoD is required to maintain and produce records per the Federal Records Act, the Freedom of Information Act (FOIA), and the Federal Rules of Civil Procedure. Records shall be maintained in compliance with the government’s disposition schedule as specified in the contract. The government will work with the Contractor to ensure that all government records and CSP government data records are kept in accordance with the government’s records’ schedules. When the government requires delivery of records, the Contractor shall deliver the records in standard commercial format.

(10) Indemnification. The Contractor shall indemnify the government and its officers, agents, and employees acting for the government against any liability arising out of the performance of this contract, including costs and expenses, incurred as the result of the Contractor’s:

(a) Unauthorized introduction of copyrighted material, information subject to a right of privacy, and any libelous or other unlawful matter into government data.

(b) Unauthorized disclosure of trade secrets, copyrights, Contractor bid or proposal information, source selection information, classified information, material marked “For Official Use Only”, information subject to a right of privacy or publicity, personally identifiable information as defined in Office of Management and Budget Memorandum (OMB M)-07-19, FY 2007 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, or any record as defined in 5 U.S.C. § 552a; or (ii) the Contractor’s unauthorized introduction of any libelous or other unlawful matter into government data.

(c) The Contractor agrees to waive any and all defenses that may be asserted for its benefit, including without limitation the government Contractors Defense.

(d) In the event of any claim or suit against the government on account of any alleged unauthorized disclosure or introduction of data or information arising out of the performance of any…