Amendment_0004_m2P1_Atch_J-1_PWS.pdf

PERFORMANCE WORK STATEMENT (PWS)

milCloud 2.0 Phase 1 (m2P1)

Revised as of Amendment 0004 Dated: August 19, 2016

Table of Contents

1. CONTRACTING OFFICER’S REPRESENTATIVE (COR)

2. CONTRACT TITLE

3. BACKGROUND

4. OBJECTIVES

5. SCOPE

6. PERFORMANCE REQUIREMENTS

6.1 – Task1, Subtask 1.1 - Infrastructure Service Requirements for Unclassified Workloads and Data

6.1.1 Infrastructure Services Detailed Facilities Analysis

6.1.2 Compute Requirements

6.1.3 Storage Requirements

6.1.4 Provisioning Requirements

6.1.5 Documentation Requirements

6.1.6 Supported Guest Operating System Requirements

6.1.7 Network and Transport Requirements

6.1.8 Security Requirements

6.1.9 Architecture Requirements

6.1.10 Support and Service Level Requirements

6.1.12. Price and Billing Requirements

6.1.13 Associated Services Requirements

6.1.14 Accreditation Requirements

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

6.3 Task Area 1, Subtask 1.3 – Other Services

6.4 Task Area 2, Subtask 2.1, Workload Transition Support

6.4.1 Technical Engineering Activities

6.4.2 Technical Intermediation

6.5 Task Area 2, Subtask 2.2, Program Management Support

6.5.1 Program Administration

6.5.2 Program Office Support

6.6 Task Area 2, Subtask 2.3, Closeout

7. CYBER THREAT SECURITY PLAN

8. PERFORMANCE STANDARDS

9. INCENTIVES

10. PLACE OF PERFORMANCE

11. PERIOD OF PERFORMANCE

12. DELIVERY SCHEDULE

13. SECURITY REQUIREMENTS

14. GOVERNMENT-FURNISHED EQUIPMENT (GFE) / INFORMATION (GFI)

15. OTHER PERTINENT INFORMATION OR SPECIAL CONSIDERATIONS

16. SECTION 508 ACCESSIBILITY STANDARDS

17. GLOSSARY

18. MILCLOUD 2.0 INDUSTRY DAY SCRIPT

PERFORMANCE WORK STATEMENT (PWS)

Revised per Amendment 0004 as of 8/XX/2016

Contract Number: (completed by the KO at time of contract or TO award) Task Order Number: N/A Tracking Number: (completed by the KO when complete package is received) Follow-on to Previous Contract and Task Order Number:

N/A

1. Contracting Officer’s Representative (COR).

a. Primary COR.

Name: TBD (to be completed after award) Organization:

Department of Defense Activity Address Code (DoDAAC): HC1047

Address: ( physical mailing address) Phone Number:

Fax Number:

E-Mail Address:

b. Alternate COR.

Name: TBD (to be completed after award) Organization:

DoDAAC: HC1047 Address: ( physical mailing address) 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 (DoD and Federal organizations requiring up-to SRG 5 level secure environments).

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.1 DISA will act as the Authorizing Official (AO) for all risk review or adjudication concerns.

1 http://iase.disa.mil/cloud_security/Pages/index.aspx http://iase.disa.mil/cloud_security/Pages/index.aspx

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 – hereinafter: 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 at 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 of up to 50 workloads at Initial Operational Capability (IOC) to a target state supporting approximately 5,000 workloads at Full Operational Capability (FOC) or 24 months after IOC, with the ability to scale beyond this target state if supported by DoD consumer demand. The Contractor will capitalize the initial implementation of up to 50 workloads pre- IOC. Workloads are estimates and not guaranteed. Post-IOC, the consumers will pay for the unit of services utilized. IOC is defined further in this document in Section 6.5.1.1.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 continually provide the optimal computing environment and offer the latest cloud technology within the price and scope of milCloud 2.0, especially if it provides improved cost efficiency or 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

The Contractor may elect to propose Other Services for the consumers in order to support the operations, maintenance and sustainment of their virtual environment once it is stood up in milCloud 2.0. This is an optional service that the Contractor may want to propose in order to provide ongoing support for the Consumers. Examples of Other services can include tasks such as: OS security, vulnerability management, database services, application health monitoring, application security, system administration, network support, and workflow services.

DoD Consumer infrastructure resource requests will be fulfilled by a milCloud 2.0 graphical user interface (GUI)..

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 and other services (if Cloud Service Provider (CSP) elects to propose such services) 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

Subtask 1.3: Other Services

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

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

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 Preliminary information regarding the conditions at the proposed sites were communicated to prospective offerors during the site visit conducted at the DECC Montgomery on June 14, 2016. This document was posted to FBO and can be found in Section 18 for convenience. The Contractor shall perform an in-depth site survey with appropriate 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 solution in accordance with the parameters provided in Section 18 to include 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 Contractor shall review their facilities analysis and identify and submit requests for resolution to the COR for any issues that may impact successful implementation of their cloud infrastructure. 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 facilityThe vendor will provide hardware delivery for all hardware required for IOC for the first site no later than 8 weeks after contract 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 into the two m2P1 data center sites. The Contractor shall also 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 30 business days of general availability in the marketplace. Thereafter, 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, hereinafter understood to mean a live system (not test environment). 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:

(a) 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, often described as server side encryption (SSE) for objects or object hierarchies within the storage service. The SSE shall work either with infrastructure provider-generated keys, or Consumer-generated keys.

For infrastructure provider-generated keys, the infrastructure provider shall generate unique keys and encrypt objects at rest in the storage services, and use those same keys to provide the Consumer with unencrypted objects, when the objects are requested from the storage service by the Consumer.

For Consumer-generated keys, the infrastructure provider shall provide interfaces to submit the keys and encrypt/decrypt objects at rest in the storage services using those provided keys for the Consumer.

The Consumer shall have the configuration option to determine if their storage needs will utilize SSE, and if SSE is chosen, the Consumer shall have the option to use infrastructure provider-generated keys or Consumer-generated keys. The Consumer may also instead choose to use client-side encryption, which does not involve the infrastructure provider.

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 that exceed or exceed the tier I IOPS 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 browser-based functionality 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, including government or DISA 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 indicate that a system or systems must be implemented at an alternate milCloud 2.0 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 and SIPRNet if the option is exercised:

(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 OSs. 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.2

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.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, found in Section 15 g. (Applicable Documentation) of this PWS.

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 SRGas found in Section 15 g. (Applicable Documentation). Virtual/Logical separation will ensure deny-

2 DoD currently maintains documentation on the STIG process, which explains how to create DoD-compliant server images for many guest OSes. (e.g., Gold images which have gone through the STIG process.) The STIGs contain technical guidance to "lock down" information systems/software that might otherwise be vulnerable to a malicious computer attack. [http://iase.disa.mil/stigs/os/Pages/index.aspx] 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, hereinafter understood to mean a service that keeps track of the state of interation and stores the information.

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 DISA Authorizing Official.

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, found in Section 15 g.

(Applicable Documentation).

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, found in Section 15 g. (Applicable Documentation)..

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 to be developed during the DoD PA Level 5 process, jointly developed by the Contractor and the Government.

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. (Applicable Documentation).. 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, found in Section 15 g. (Applicable Documentation)) 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). STIGs are regularly updated, the IASE website is the reference site for al STIGs and updates.

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 http://iase.disa.mil/ http://www.disa.mil/cybersecurity

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) found in Section 15g.

(Applicable Documentation), 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 6 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.