m2P1_DRAFT_PWS_for_posting_23_May_2016.doc

PERFORMANCE WORK STATEMENT (PWS)

milCloud 2.0 Phase 1 (m2P1) Acquisition Sensitive: DRAFT dated May 23, 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

76.1.1 Infrastructure Services Detailed Facilities Analysis

76.1.2 Compute Requirements.

96.1.3 Storage Requirements.

106.1.4 Provisioning Requirements.

106.1.5 Documentation Requirements.

116.1.6 Supported Guest Operating System Requirements.

116.1.7 Network and Transport Requirements.

136.1.8 Security Requirements.

156.1.9 Architecture Requirements.

156.1.10 Support and Service Level Requirements

176.1.11 Monitoring, Alerting, and Logging Requirements.

196.1.12. Price and Billing Requirements.

196.1.13 Associated Services Requirements.

206.1.14 Accreditation Requirements.

216.2 Task 1, Subtask 1.2 - Infrastructure Service Requirements For SIPRnet-Connected Workloads and Data

216.3 Task2, Subtask 2.1, Workload Transition Support

216.3.1 Technical Engineering Activities.

226.3.2 Technical Intermediation.

236.4 Task2, Subtask 2.2, Program Management Support

236.4.1 Program Administration.

236.4.2 Program Office Support.

246.5 Task2, Subtask 2.3, Closeout

257. Cyber Threat Security Plan.

268. Performance Standards.

269. Incentives.

2610. Place of Performance.

2711. Period of Performance.

2712. Delivery Schedule.

2813. Security Requirements.

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

3115. Other Pertinent Information or Special Considerations.

3316. Section 508 Accessibility Standards.

PERFORMANCE WORK STATEMENT (PWS)

as of 5/20/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 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 approved mission partners.

In October of 2014, DISA released a Request For Information (RFI) focusing on two models for providing contemporary commercial cloud ecosystem services to the Department. The RFI asked for industry input regarding an integration model allowing the vendor to directly use the DoD data center floor space. DISA received significant feedback from industry indicating that a competitive marketplace exists for infrastructure services deployed in this private deployment model, and that many firms had comprehensive technical infrastructure solutions available to the DoD. A follow-on RFI in February of 2016 explored many of the business issues involved with using a cloud service model inside the DoD facilities.

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

This capability will be reviewed and 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) 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 mission partners for a variety of highly protected workloads;

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 50 workloads successfully between both sites.

5. Scope.

The milCloud 2.0 Phase 1 (m2P1) is a single award competition to bring commercial infrastructure services into DoD facilities, connected to DoD networks in a private deployment model for use by the DoD community. 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 in this PWS. The DoD anticipates that infrastructure services will need to be capable of scaling from a small initial implementation of approximately 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 mission 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. 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.

Statements that use the term “shall” are firm requirements of the Contractor. The RFP’s requirements have been divided into two 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 – exercised on KO direction.]

· 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 both task areas.

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.

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 to support the installation of the Contractor’s cloud IaaS. The Contractor shall examine all issues that impact a successful site implementation of their cloud infrastructure solution including, but not limited to:

· Physical requirements of the Contractor solution;

· 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 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 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.

6.1.1.2 Installation Plan and Timeline. Two weeks after contract award, the contractor shall deliver an initial report detailing a plan for infrastructure service installation at the two sites, and any issues with implementation of their solution in the two DoD facilities along with recommended mitigations. A final version of the report shall be delivered four weeks after contract award. While developing the report, the Contractor will meet with and formally present any discovered risks 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. Installation of at least one site shall be completed no later than eight weeks after contract award and second site no later than twelve 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 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 and an organizational affiliation.

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 MicrosoftTM and Red HatTM guest operating systems releases within 30 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 operating system (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 Government 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 optionally automatically migrate and restart instances on a healthy host if the original physical host fails. The failure detection for participating 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.16 The compute service shall support the execution and operation of software container technologies.

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 major 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 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 Customers must be able to choose explicit performance target or performance tier on block storage volumes, such as a certain number of I/O operations per second (IOPS), or Mbps of throughput.

6.1.3.10 The contractor shall provide a high IOPS service offering to high transaction volume systems.

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.

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 Application Programming Interface (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.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) Government program management and contracting points of contact information

(6) Infrastructure ecosystem application programming interfaces (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 (OS’s):

(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 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.6.4 The Contractor shall track and report on the guest operating systems in use by the DoD Consumers and their licenses. This licensing data shall be available for viewing or reporting in the infrastructure services portal.

6.1.7 Network and Transport Requirements.

6.1.7.1 The Contractor’s infrastructure solution shall connect directly to the DODIN at the Defense Enterprise Computing Center (DECC) gateway boundary. (e.g., the premise router) The Contractor shall support all Cloud Computing SRG and FEDRAMP+ network protection, security and reporting requirements for the enclave within that perimeter.

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 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

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 8. 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 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 government 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 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. 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.11Contractor shall not force Consumers to shut down, reboot or redeploy any Consumer infrastructure involved in the change of a network security ACL or group.

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 AO (DISA).

6.1.8.2 The Contractor shall provide secure remote access connectivity into compute instances (e.g., Secure Shell [SSH], Remote Desktop Protocol [RDP]) 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 under review.

6.1.8.4 The Contractor shall document 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 Department of Defense (DoD) 522022-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). 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.

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 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 HMAC-based one-time password (HOTP; hash message authentication code [HMAC]-based, 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;

b. Apply and maintain STIGs applicable to the infrastructure’s hypervisors;

c. Ensure vulnerability compliance using the DISA Assured Compliance Assessment Solution (ACAS);

d. Upload vulnerability scans to the Continuous Monitoring and Risk Scoring System (CMRS) portal. Remediate scanned results and repeat as needed.

(2) Privileged Accounts. The Contractor shall:

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

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 (i.e., System Authorization Access Request Navy 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 Computer Network Defense (CND). IAW the 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 Capability Owner.

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.

c. As noted in Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B, 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. 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.

(5) The contractor shall have documented high availability and disaster recovery capabilities 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).

6.1.9 Architecture Requirements.

These requirements focus on infrastructure service architecture.

6.1.9.1 Published architecture transparency. In order to assess the risk of using the infrastructure services, including impacts of migration, compliance, licensing, configuration and performance, the Contractor shall provide the following infrastructure details:

(1) Physical requirements of their solution including rack requirements (size, rack U, power usage)

(2) Configurations for power, cooling and network heat evacuation and cooling

(3) The underlying hypervisor product/technology

(4) The current physical CPU processor architecture series and life cycle strategy

(5) The Contractor’s approach to delivering an ever-greening technology cycle where equipment is added or removed to support usage requirements and technology refreshment

(6) A description of the configuration details of what constitutes a vCPU in the Contractor environment

(7) A description of the performance characteristics of the storage environment being offered in terms of resiliency, responsiveness, and expected availability. This will include at a minimum how often data is replicated and protected by the Contractor automatically on behalf of the Consumer

6.1.9.2 Published reference architecture. The Contractor shall maintain a published list of reference architecture diagrams and descriptions on the infrastructure service portal. This material shall include, but not be limited to a set of recommended patterns that Consumers can emulate when deploying common scenarios. Furthermore, the Contractor shall have reference architecture examples, and the examples shall be inclusive and illustrative of combining multiple services (e.g., compute, storage and networking) to solve a common Consumer’s problem with the service.

6.1.10 Support and Service Level Requirements

6.1.10.1 Infrastructure Service Availabilities. The Contractor shall deliver the following minimum infrastructure service level availabilities:

(1) Service Availability Definition. Service Availability shall be defined as (Total Uptime Hours / Total Hours within the Month) displayed as a percentage of availability up to two-tenths of a percent (e.g. 99.95%).

(2) Infrastructure service availability SLA. Each infrastructure service shall offer an availability of 99.95%, calculated monthly. At a minimum the Contractor will monitor and report on the Compute services, the Object and Block Storage services, the infrastructure service portal, and the provisioning capabilities.

(3) Within a month of a major outage occurrence resulting in greater than 1-hour of unscheduled downtime, the Contractor shall describe the outage including description of root-cause and the fix.

6.1.10.2 SLA versioning and revision history. The Contractor shall make the infrastructure service SLAs accessible for review in the infrastructure portal at any time and include SLA version control, as well as revision history of SLA changes for auditing.

6.1.10.3 SLA history: The Contractor shall offer a dashboard of service health and SLA status history in the portal for Consumers to view at any time. The dashboard shall contain at least one year of trailing infrastructure service health history.

6.1.10.4 Service credits/refunds. During the time that a service is unavailable, Consumers shall not be charged by the Contractor for the use of that service. SLA penalties shall be in the form of service credits or refunds, and shall cap at 100% of the Consumers next bill.

6.1.10.5 Technology Refresh. The Contractor will need to maintain the defined SLAsif the need arises to perform internal technology refresh tasks.

6.1.10.6 Support Services. The Contractor shall open, manage, and resolve Incidents and Service Requests in accordance with the SLA. These management capabilities include, but are not limited to the following:

(1) Integrated system and subsystem status reporting and incident correlation to assess incident impact on multiple systems, services, programs and users, and to facilitate proactive communication with Consumers, organizations and programs;

(2) Prioritized queue of incidents and service requests by severity, with expected time to fix based upon demonstrated performance;

(3) Repository of Reason for Outage (RFO) and Duration of Outage (DOO) information to support trend analysis and continual improvement efforts;

(4) Correlation of complaints to incidents;

(5) Charting for incidents per day, week and/or month over selected time period;

(6) Integration with e-mail alerts for incident volumes exceeding preset thresholds.

6.1.10.7 The Contractor shall offer the following support services:

(1) Incident reporting and management system. The Contractor shall offer an incident management system for identifying, submitting and tracking service incidents. The incident management system shall include the capability to submit incidents and track incident status.

(2) Severity 1 Issues. The Contractor shall provide 24/7 support, 30-minute response to Severity 1 issues. A Severity 1 issue is defined as a severe problem preventing a Consumer from performing business or mission functions including data loss or data unavailability for a production workload. The Contractor shall respond to critical incidents in 30 minutes or less, while providing 24/7 support to the infrastructure services.

(3) Severity 2 Issues. The Contractor shall provide 24/7 support, 4 hour response to Severity 2 issues. A Severity 2 issue is defined as a severe performance degradation that impedes the completion of mission or business functionality.

(4) Severity 3 Issues. The Contractor shall provide 5/10 support, 3 local business hours to Severity 3 issues. Severity 3 issues are defined as having some impact to the infrastructure services but not a work stoppage.

(5) Severity 4 Issues. The Contractor shall provide 5/10 support, 8 local business hours to Severity 4 issues. Severity 4 issues include questions, feature requests, and billing inquiries.

(6) Live support offering. The Contractor shall offer live support in English via chat and voice.

(7) Online self-service support. The Contractor shall offer online self-service support that includes FAQs, a knowledge base and discussion forums through the portal. The discussion forums shall have evidence of regular, timely participation and moderation from the Contractor support staff.

(8) Online error/bug reporting: The Contractor shall offer Consumers an online-based mechanism for reporting errors or bugs with the infrastructure services. Bugs shall be tracked and fixed in a reasonable timeframe.

(9) Parallel support for API changes. In the event of an API retirement, substantial upgrade or change, the Contractor shall have at least three months of parallel support for both the old and new APIs. The Government COR may waive this requirement in written communication in order to accelerate fielding of new capabilities.

6.1.10.8 Published DR plan and test results. The Contractor shall conduct at least one infrastructure DR test annually and document the results for the Government.

6.1.10.9 Off-boarding support. The Contractor shall offer the ability to completely sever all existing deployments and budget expenditures for any individual or group with the Contractor. This shall be a process that terminates all cost-accrual given one request and ensures the delivery of government data back to the designated point of contact. The Contractor will use a workflow approval to confirm that this action is valid through a phone or email confirmation.

6.1.10.10 Capacity Management. The Contractor shall manage the physical capacity of the infrastructure to ensure that SLA performance measures are met or exceeded continuously. The Contractor shall ensure that sufficient capacity is available within the infrastructure to meet anticipated growth based on workload trend analysis and planned workload increases identified by the Government. The Contractor shall maintain an amount of available compute and storage capacity to support unanticipated surge workload due to emergency operational requirements, and shall identify to the Government what this available surge capacity is as a percentage of consumed capacity. The Contractor shall provide sufficient available capacity to support critical workloads from the alternate operating site in the event of a failure or loss of the alternate site.