Attachment_L-8_PWS-SOO_Crosswalk_Matrix.xlsx
XLSX spreadsheet 37 KB Posted
- Attached to
- JEDI Cloud RFP Federal contract opportunity
- Solicitation number
- HQ003418R0077_JEDI_CLOUD_RFP
- Issued by
- DOD Washington Headquarters Service
About this file
Attachment L-8 : PWS/SOO & Factor Crosswalk Matrix
View the file
Other files for this federal contract opportunity
Show all 50
JEDI Cloud RFP has more files on GovTribe.
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Master Crosswalk
| Offeror Name: | ||||
| JEDI Cloud | ||||
| Attachment L-8: PWS/SOO Crosswalk | ||||
| SOO Description (Paraphrased for Brevity) | SOO Reference | PWS Reference | CLIN | Evaluation Factor |
| Performance Requirements | Section 3 | N/A | N/A | N/A |
| Cyber Security Plan Compliance | 3.0 | |||
| Unclassified | 3.0 | |||
| Secret | 3.0 | |||
| Top Secret, SCI, SAP | 3.0 | |||
| DD-254 requirements | 3.0 | |||
| Provide computing, networking, and storage IaaS and PaaS offerings. | 3.1 | |||
| Provide a user interface for provisioning and deploying of cloud-based computing, networking, and storage services, including provisioning of pre-configured machine images, and a simple mechanism to deprovision any deployed service. | 3.1.1 | |||
| Provisioning a new account, user, or service offering, or deploying said offerings within JEDI Cloud, must not take any longer than the level of service that is provided in the Offeror’s publicly-available Commercial Cloud assuming that the offerings have been authorized for use in JEDI Cloud. | 3.1.2 | |||
| The DoD must have a mechanism for activating and deactivating any cloud service offering for particular accounts or all accounts under the JEDI Cloud contract. | 3.1.3 | |||
| Provide a mechanism to deploy cloud-based computing and storage services based on standardized, pre-made configurations and security policies, where appropriate, and a simple mechanism to deprovision any service. | 3.1.4 | |||
| When an authorized user requests a cloud resource within the Offeror’s portal, or via an API, the response time for when the portal confirms that resource deployment has begun must be on the order of seconds. | 3.1.5 | |||
| The time required to go from power off to receiving and processing user instructions (less any operating system boot time) for an individual IaaS compute instance must be on the order of seconds. | 3.1.6 | |||
| Provide processing unit architectures, system memory, storage capabilities, and networking options that are optimized for specific compute-based IaaS activities. | 3.1.7 | |||
| Provide an API Gateway service that allows JEDI Cloud users the ability to develop, deploy, secure and scale their APIs as needed. | 3.1.8 | |||
| Provide the ability to remotely connect to a virtual desktop environment that has access to persistent storage | 3.1.9 | |||
| Provide the ability for JEDI Cloud to scale globally. Scalability improves computing and storage capacity, in an efficient and rapid manner, to meet mission requirements. | 3.2 | |||
| Infrastructure and networks supporting at the classified services must be physically separate from the infrastructure and networks supporting unclassified services | 3.2.1 | |||
| The Offeror shall provide redundant and globally distributed points of presence available on all continents (except Antarctica) through two or more connections providing a total bandwidth capacity of at least 40 Gigabits per second. | 3.2.2 | |||
| Meet all requirements outlined in the JEDI Cloud Cyber Security Plan. | 3.3 | |||
| The Offeror must provide encryption and logical isolation for the unclassified and classified offerings. | 3.4 | |||
| The Offeror must provide the ability to encrypt data at rest and data in transit, such that users can choose to require the implementation of up to two layers of NSA-approved encryption using algorithms and procedures specified in Committee on National Security Systems Policy (CNSSP) 15. Users must be able to specify encryption at rest and in transit as a default configuration. | 3.4.1 | |||
| The Offeror must provide logical separation with cryptographic certainty of processing between tenants within the virtualized environment to include the implementation and configuration of the hypervisor. | 3.4.2 | |||
| Encryption keys will be managed by either the JEDI Cloud user or Offeror at the discretion of the user. | 3.4.3 | |||
| The Offeror must provide secure data transfer capability with the attributes described below. | 3.5 | |||
| Secure and highly deterministic one-way data transfer capability between logical enclaves and tenants within the cloud offering, to external destinations, including multi-tenant peering gateways, and across classification levels, while limiting any additional threats. | 3.5.1 | |||
| Protect enclaves from cyber threats, including malware and virus transfer, and prevent penetration by external sources. | 3.5.2 | |||
| Allow specific role-based accounts to overrule automated security measures to securely transfer information that may be flagged as malicious. | 3.5.3 | |||
| Mitigate the risk of the transfer capability as a covert channel. | 3.5.4 | |||
| Enforce technical policies controlling how data transfer capabilities can be used including gaining the appropriate role-based approval for use. | 3.5.5 | |||
| The ability to configure secure network fabrics as needed for their applications to work and interact with each other and services outside of JEDI Cloud. | 3.5.6 | |||
| The Offeror must provide automated information security and access control tools with the attributes described below. | 3.6 | |||
| Auditability of both the physical location and logical isolation of any hosted service to ensure compliance with security policy. | 3.6.1 | |||
| Automated breach identification. | 3.6.2 | |||
| Self-service and automated tools for handling data spills of classified or other controlled information. | 3.6.3 | |||
| Ability to erase data in both unclassified and classified environments. | 3.6.4 | |||
| Ability to purge data in classified environments. | 3.6.5 | |||
| Self-service tools to access data and analysis generated by threat detection systems. | 3.6.6 | |||
| The ability to provide notifications and findings of threats to system owners. | 3.6.7 | |||
| The ability to enable and disable services and restrict parameters within service configurations, in a manner that is easy to use by the majority of users. | 3.6.8 | |||
| Object and resource access control management, including data and resource tagging for billing tracking, access control, and technical policy management. | 3.6.9 | |||
| With respect to authentication, authorization, and identity and access management the Offeror must provide mechanisms for each of the below. | 3.7 | |||
| Highly granular role-based access control (RBAC) configuration within an account to include account administration, provisioning of new cloud services, and management of existing services and the ability to assign permissions to roles in accordance with technical policies. | 3.7.1 | |||
| Securely verify user identity using modern authentication protocols, including multi-factor authentication (MFA) and public key infrastructure (PKI) that work in all JEDI Cloud environments. | 3.7.2 | |||
| Federated identity support wherever the Offeror’s identity management systems are in use (including across all classification levels and at the tactical edge). The Offeror must provide the ability to generate and issue time-limited, role-based authentication tokens that allow a user to assume a set of permissions within a specific account within the cloud environment. | 3.7.3 | |||
| Provide cloud-service usage and billing reports for all accounts under the JEDI Cloud contract and by specified account(s). | 3.8 | |||
| Provide a user interface to track budgets, including spend reports, cost planning and projections, and setting limits based on cloud service usage both for individual accounts and all accounts under the JEDI Cloud contract, including notifications and alerts where appropriate. Provide usage reports that contain service usage for all billable aspects offered by the Offeror. This information must be produced at the account level and for all accounts under the JEDI Cloud contract. | 3.8.1 | |||
| Provide an application program interface (API) with access to service usage, actual user costs, and the ability to set billing limits with notifications for individual accounts and for all accounts under the JEDI Cloud contract. | 3.8.2 | |||
| All billing reports and invoices must identify major categories of actual user cost drivers so that users can determine what variables are impacting consumption of the provisioned offerings and corresponding price consequences. Users must be able to set a threshold such that when spending in the specified account reaches the threshold automated notifications are sent to the user, CCPO, and Task Order Contracting Officer. | 3.8.3 | |||
| The Offeror shall provide an API for the IaaS and PaaS offerings that is capable of creating, reading, updating, and deleting resources as identified below. All areas of the API must be accessible to all JEDI Cloud users provided they have the proper access control authorization. | 3.9 | |||
| The API must provide, at a minimum, the following: | 3.9.1 | |||
| Identity and access management, including account creation and management within the JEDI Cloud contract, token-based and time-limited federated authentication, role-based access control configuration; | 3.9.1.1 | |||
| Provisioning and management of network configuration, compute instances, data and object storage including database management systems, and tools for scaling systems such as application server load balancing; | 3.9.1.2 | |||
| Storage object lifecycle management; | 3.9.1.3 | |||
| Reading usage data and alerts for compute, storage, and network utilization; | 3.9.1.4 | |||
| Reading billing data and pricing data, including by service, by specified account, and under the entire JEDI Cloud contract | 3.9.1.5 | |||
| Setting billing and usage thresholds and adding automated notifications to account owners and the CCPO. | 3.9.1.6 | |||
| The Offeror’s API must be actively maintained, properly versioned, documented, and adhere to modern standards and protocols. Any changes which break backward compatibility must be announced, and JEDI Cloud users notified, at least 30 days prior to the change being put into production. | 3.9.2 | |||
| The Offeror must not bundle any offerings for storage, compute, and network IaaS, with any particular PaaS or SaaS product. For purposes of this requirement, any PaaS that uses the Offeror’s infrastructure, but which is not invoiced separately and not deployed to user provisioned cloud resources, is not considered “bundled”. | 3.10 | |||
| Generational replacement and upgrading of all hardware (compute, memory, storage, and networking) must have parity with the Offeror’s publicly-available Commercial Cloud. When upgrading hardware, the new generation must have parity with the publicly-available Commercial Cloud in all cases. | 3.11 | |||
| Provide online, nearline, and offline storage options, as well as managed database and noSQL services at the scale and speed to meet mission requirements, including both object storage options and managed databases. | 3.12 | |||
| The Offeror must have more than one online database storage offering that can support data on the order of hundreds of Terabytes and can be queried in under one second. The offering must perform create, read, update, and delete functions on data on the order of hundreds of Terabytes within seconds, excluding network latency between the compute instance issuing the query and the database management system (DBMS). | 3.12.1 | |||
| The Offeror must have at least one online object storage offering that can support data on the order of Petabytes. | 3.12.2 | |||
| The Offeror must offer data storage solutions that include both traditional relational databases and recent alternatives in noSQL approaches such as: Key value, Graph, Document and Tuple. Versions of such database management systems must stay current with all major releases of those DBMSs. | 3.12.3 | |||
| There must be options for “nearline” (versus online/offline) storage solutions. Such options must provide read and write access on the order of minutes. | 3.12.4 | |||
| There must be options for “offline” storage solutions. Such options must provide read and write access within 24 hours. | 3.12.5 | |||
| The Offeror must have processes and rule-sets where required by the Freedom of Information Act, Federal Records Act, Disposal of Records, Executive Order (EO) 12333, EO 13587, the Privacy Act, and the Health Insurance Portability and Accountability Act, and any federal regulations implementing those policies. | 3.13 | |||
| Provide robust network infrastructure, suitable for handling a high volume of traffic globally, in and out of the Offeror’s cloud boundary. | 3.14 | |||
| The Offeror’s networking hardware, including links, network points-of-presence, and pass-throughs, must keep pace with commercially available networking hardware. | 3.14.1 | |||
| Network capacity, as measured by throughput and latency, must keep pace with the Offeror’s publicly-available Commercial Cloud. | 3.14.2 | |||
| Provide dynamic scalability and resiliency through industry standard mechanisms. | 3.15 | |||
| The ability for users to create system configurations, either manually or through APIs, to provide automated redundancy of storage, networking and computing systems in the case of catastrophic data center loss. | 3.15.1 | |||
| There must be no fewer than three physical unclassified data center locations and no fewer than three physical classified data center locations within the Customs Territory of the United States, as defined in FAR 2.101. Each classification level requires at least three data centers, so if an Offeror proposes physically separate classified data centers at different classification levels, each classification level requires at least three data centers. Each data center must be capable of automated failover of computing, network and storage services to one another within a classification level. Geographic dispersion of all data centers within a classification level is such that at least three physical data centers are at least 150 miles from each other. Unclassified and classified data centers may be co-located so long as the classified data center meets the DD Form 254 requirements. | 3.15.2 | |||
| Provide automatic monitoring of resource utilization and events (to include failures and degradation of service) via web interface and documented APIs that are intuitive and easy to use. These APIs must have online documentation that is readily discoverable, including example code. | 3.15.3 | |||
| Portability | 3.16 | |||
| A portability plan must be provided in accordance with the Portability Plan CDRL. (CLIN x005). The portability plan must specifically identify, in the form of user instructions, the complete set of processes and procedures that are necessary to extract all online, nearline, and offline data, including, but not limited to, databases, object and file storage, system configurations, cloud activity logs, source code hosted in a JEDI Cloud code repository, and network configurations such that any JEDI Cloud user can use these instructions to migrate from JEDI Cloud to another environment. Such procedures should be part of a consolidated, single effort versus individual export actions across separate data storage mechanisms, servers, networks, etc. within a cloud account. The portability plan must also include an explanation evidencing the ability to demonstrate successful erasing, purging or destruction of all system components, as appropriate, and an ability to prevent re-instantiation of any removed or destroyed system, capability (software or process), data, or information instances once removed from JEDI Cloud. | 3.16.1 | |||
| Upon notification of the Contracting Officer, the Offeror must demonstrate portability under the Portability Test line items. (CLIN x006). The Offeror must demonstrate migration of an application and data (provided by the Government for this purpose) from JEDI Cloud to a different hosting environment. The demonstration shall validate the Portability Plan and evidence a reasonable ability to successfully migrate off of JEDI Cloud. | 3.16.2 | |||
| Provide data analytics service offerings, for example streaming analytics, predictive analytics, machine learning, and/or eventually artificial intelligence (if not currently available), available in all environments, including classified regions and disconnected environments. Such offerings must be able to operate across multiple datasets in disparate accounts across the JEDI Cloud contract. | 3.17 | |||
| Provide the ability to rapidly and securely deploy CSP and third-party platform and software service offerings from an online marketplace with baseline template configurations where appropriate onto JEDI Cloud infrastructure. Software or platform offerings that cannot be deployed on JEDI Cloud infrastructure are outside the scope of this contract. | 3.18 | |||
| The online marketplace within the JEDI Cloud environment must support the ability for JEDI Cloud users to deploy CSP and third-party service offerings. | 3.18.1 | |||
| For third-party service offerings, the Offeror is only required to make available ones that are free, excluding the cost of IaaS resources, or where the DoD already possesses a license using the bring your own license (BYOL) approach. All free platform and software service offerings that are available in the CSP’s publicly-available commercial cloud environment must also be available in the unclassified JEDI Cloud environment. | 3.18.2 | |||
| For BYOL, DoD will be responsible for negotiating the terms and conditions of the licenses under a separate contracting vehicle. A BYOL deployment must include integrated billing with the JEDI Cloud user’s account. | 3.18.3 | |||
| The Offeror’s marketplace must support security scanning of new and existing services being offered and also include a rapid method to notify customers using any marketplace service that a vulnerability has been discovered. | 3.18.4 | |||
| Deployed third-party platform and software services must include integrated billing. | 3.18.5 | |||
| The CCPO must be able to disable ordering of any marketplace offering for users of the JEDI Cloud contract. | 3.18.6 | |||
| Provide Tactical Edge Devices that are suitable for the full range of military operations. | 3.19 | |||
| The tactical edge computing and storage capabilities must be able to function in totally disconnected or closed loop mode, including provisioning IaaS and PaaS services, locally running containerized applications, data analytics, and processing data. | 3.19.1 | |||
| These capabilities must provide for automated bidirectional synchronization of data storage with the cloud environment when connection is re-established. These capabilities must also provide the ability to control synchronization order and throttle synchronization bandwidth. | 3.19.2 | |||
| These capabilities must also allow users to quantify and control magnitude of electromagnetic emanations. | 3.19.3 | |||
| The proposed solution must provide an ability to replace any tactical edge device in a manner that is suitable for the range of military operations and with minimal mission impact. | 3.19.4 | |||
| Upon Government request, the proposed tactical edge device shall be certified as meeting the MIL-STD-810G. The certification process is at no additional cost to the Government. | 3.19.5 | |||
| Tactical edge devices must include, but are not limited to, a) durable, ruggedized, and portable compute and storage, and b) static, modular, rapidly deployable data centers. To re-emphasize, the tactical edge capabilities should enable JEDI Cloud users to use cloud computing and storage resources across the range of military operations. | 3.19.6 | |||
| Tactical edge capabilities must follow the Cyber Security Plan, including physical and logical separation requirements, except when explicitly stated otherwise in the contract. | 3.19.7 | |||
| All tactical edge capabilities must be remotely configurable and maintainable to the greatest extent possible. | 3.19.8 | |||
| Tactical edge capabilities must support key management both on and off the device at the discretion of the user. | 3.19.9 | |||
| Offeror is responsible for the delivery of tactical edge devices to CONUS locations. Any services and fees associated shall be identified and priced in the relevant catalog. | 3.19.10 | |||
| At a minimum the operating and transporting temperature thresholds for the tactical edge devices are the “Basic Hot” and “Basic Cold” daily cycles identified in Table 1, Part Three of MIL-STD-810G (page: PART THREE-10). | 3.19.11 | |||
| The Offeror must provide prompt notification and follow up reporting on any service incidents and problems. | 3.20 | |||
| The Offeror must provide standard and easy-to-interpret logs, for both humans and machines, for tracking provisioning of services, configuration changes, service access and errors, and any relevant audit trail events. | 3.21 | |||
| All actions in the system, whether by a human or a machine, must be loggable to an external, non-overwritable destination also within the cloud offering. Such logs must be sufficient to provide an audit trail of activities and actions as required in accordance with DoD CIO Memorandum, Department of Defense Cybersecurity Activities Performed for Cloud Service Offerings, dated November 15, 2017. | 3.21.1 | |||
| The Offeror must provide a pricing calculator with realistic, contractually accurate, and easy to perform price modeling and projection. The calculator must be able to make projections to support users’ long-term (in excess of 12 months) planning needs. | 3.22 | |||
| Provide a range of service pricing structures that incorporate both usage-based pricing to incentivize efficient utilization of cloud computing resources and subscription models for reserved resources. | 3.22.1 | |||
| The Offeror must provide easy to understand training materials and documentation using a variety of training modalities that helps users understand how to successfully provision services and provides best practices for using services under the JEDI Cloud contract. (CDRLs A005 and A006). Separate training materials and documentation are required for tactical edge capabilities. | 3.23 | |||
| Provide a catalog of support under the Cloud Support Package line items in the contract to advise and assist with architecture, usage, provisioning, configuration of unclassified and classified IaaS and PaaS offerings, to include homefront to the tactical edge; and advise and assist users on optimizing the use of cloud services under the JEDI Cloud contract. Package services shall also include training on, advising on, and assisting with integration, aggregation, orchestration, and troubleshooting of cloud services. (CDRLs A005 and A006). | 3.24 | |||
| If a Cloud Support Package offering is constrained by the number of hours available to users, then the Offeror must provide a mechanism for users to inquiry how many hours have been consumed (without that request consuming additional hours) within 24 hours of submitting a request. | 3.24.1 | |||
| Provide overarching program management capabilities under the Cloud Computing Program Office (CCPO) Program Management Support line items to oversee all contract activities for the ID/IQ during the entire period of performance of the ID/IQ. One of the purposes of CCPO Program Management Support is to align with the CCPO and provide feedback to ensure the JEDI Cloud contract is being used efficiently and in line with commercial practices. The requirements listed below are in addition to any requirements identified in any CCPO TO for CCPO PM Support. | 3.25 | |||
| Conducting any activities necessary to accredit the unclassified and classified IaaS and PaaS infrastructure and offerings. | 3.25.1 | |||
| Conducting continuous audit assessments and, as needed, management reviews as requested by the CCPO. | 3.25.2 | |||
| Providing reports for all accounts under the JEDI Cloud contract, as needed, on infrastructure hosting JEDI Cloud users’ systems, including specific server hardware, network systems, power infrastructure, cooling systems, etc. and software running on those systems below the virtualization layer. | 3.25.3 | |||
| Delivering to the CCPO and executing the Transition Out Plan IAW Section C3: Transition Out. (CDRL A002). | 3.25.4 | |||
| Advising on CCPO program artifacts including acquisition life cycle documentation in an effort to maintain commercial parity. | 3.25.5 |
| Desired Capabilities | Section 4 | N/A | N/A | N/A |
| Tactical Edge | 4.1 | |||
| Tactical edge capabilities that enhance warfighting advantage. For example, devices that require minimal or no external power and are capable of running for extended periods of time without battery swap or recharging. Other examples include smaller form-factor devices that are human-portable for extended periods of time; or capabilities that are deployable into air or space. | 4.1.1 | |||
| Innovative solutions for overcoming logistics challenges in delivering, maintaining, and/or return shipping tactical edge capabilities. | 4.1.2 | |||
| Security | 4.2 | |||
| Advanced automated security capabilities, for example, the ability to detect and respond to adversaries through artificial intelligence. Advanced automated security capabilities, for example, the ability to detect and respond to adversaries through artificial intelligence. | 4.2.1 | |||
| Cloud Support Package | 4.3 | |||
| Smaller, more incremental levels of support beyond the Offeror’s standard Cloud Support Package offerings. | 4.3.1 | |||
| Includes specialized training support in various modalities, including, but not limited to, classroom, train-the-trainer, certifications, and advising on the development of training packages. | 4.3.2 |
File details come from the government source that posted it.