SOO POCs.pdf

STATEMENT OF OBJECTIVES (SOO)

RFP: 75N97023R00006

Center for Information Technology (CIT) Identity, Credential, Access Management (ICAM) Modernization – Proof of Concepts (PoCs)

1. PURPOSE

The National Institutes of Health (NIH), National Library of Medicine (NLM) and Center for Information Technology (CIT) are seeking original equipment manufacturers (OEMs) to participate in Proofs of Concept (PoCs) of modernized Identity, Credential, and Access Management (ICAM) infrastructure at NIH. The PoCs will provide OEM offerors the opportunity to showcase the viability of the original equipment manufacturers’ solutions and allow NIH to assess the performance characteristics and ability to integrate into the NIH environment. The PoCs will also require that participating OEM offerors set up and conduct tests against various Use Cases (the terms ‘Use Cases’ and ‘Test Cases’ may be used interchangeably) which are based on NIH’s technical needs and requirements. Selected OEMs shall propose their plan to conduct PoCs for the Capability Area or Areas requested by NIH. The Capability Areas are Web Authentication, Directory Services and/or Secure Access Service Edge (SASE), and vendors may respond to one or more areas described below:

1. Web Authentication: Allows users to verify their identity, and access NIH – managed web resources.

2. Directory Services: Allows NIH to store and maintain information about NIH users and resources.

3. Secure Access Service Edge (SASE): Allows NIH to facilitate secure access to cloud and on-premises NIH resources by bundling network and security-as-a-service functions.

The Use Cases are provided in Appendix B and will be used by the government to evaluate performance by assessing technical capability (functionality), user experience (UX), the effectiveness/ease of integrations, and other analysis domains mentioned in Appendix B (Use Cases). Each Use Case will be evaluated on a scale from 0-2, in which ‘0’ demonstrates an inability to meet expectations, ‘1’ indicates partial ability to meet expectations, and ‘2’ reflects the ability to meet the requirement / use case completely. More information about the evaluation process is available in Appendix B.

OEM vendors are instructed to respond to the Requirements Traceability Matrix [RTM] (Appendix A) and questions outlined in "Instructions to Vendors" to demonstrate their feasibility as NIH solution providers and to help NIH test product capabilities in PoCs.

The execution of PoCs will be comprised of four milestones:

Milestone 1 — Startup/Mobilization (completion No Later Than (NLT) 20 days after contract award): NIH and the OEM vendor or its representative) shall organize, schedule, coordinate, and conduct a kick-off meeting to discuss the OEM’s test and configuration plan, necessary resources, and required timeline.

Milestone 2 — Test Readiness (completion NLT 40 days after contract award): NIH has provided use cases (Appendix B), as identified in the solicitation. NIH will also provide additional information about Institutes and Centers (ICs) participating in PoCs.

The OEM vendor shall utilize this information to configure and connect their solution to NIH’s systems/environment in preparation for subsequent testing.

Milestone 3 — Testing and Evaluation (completion NLT 75 days after contract award): OEMs shall perform testing of their solution with the resources in the NIH environment per the use cases described in Appendix B.

Milestone 4 — Documentation and Closeout (completion NLT 90 days after contract award; Ongoing throughout PoCs): NIH will require reports and results from each OEM vendor during and upon completion of the POC testing and evaluation. Required reports and expectations are outlined in Section 3.4.

Vendors should provide NIH the flexibility of conducting meetings and other coordination both on-site and virtually. The PoCs will be conducted in test cloud environment(s) over the course of 90 days.

Software as a Service (SaaS) providers shall be responsible for setting up tenants with trial subscriptions and working with NIH stakeholders to configure a cloud environment to execute use cases (Appendix B – Appendix B PoC ICAM Use Cases) and requirements (Appendix A – Appendix A Requirements Traceability Matrix).

If vendors do not offer SaaS options, a non-SaaS or hybrid solution is acceptable; NIH may select vendors to configure trial licenses/subscriptions in a Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) model. Such vendors are expected to provide technical support and work closely with NIH to configure PaaS/IaaS alternatives with trial licenses/subscriptions to execute use cases and requirements.

NIH requires these environments to be FedRAMP moderate compliant as mandated by organizational policy. If proposed solutions and associated environments are not FedRAMP compliant, NIH reserves the right to approve or reject vendor submissions based on an internal evaluation of acceptable risk tolerance and consultation with security personnel.

2. BACKGROUND

The NIH is the primary agency of the United States government responsible for biomedical and public health research. CIT is one of NIH’s 27 institutes and centers (ICs) focusing in the areas of computational bioscience, engineering, informatics, and statistics to help make biomedical discoveries that protect and improve our nation’s health. The NIH has 50,000 internal staff users and 1.2 million external users that require secure access to NIH resources. CIT is responsible for the ICAM infrastructure at NIH. In addition, CIT is responsible for delivering Network Services (and infrastructure) to the enterprise, and as a part of this modernization effort, CIT seeks to pilot a SASE solution at NIH.

Challenges:

Currently, the majority of the NIH ICAM infrastructure resides on-premises. The COVID-19 pandemic introduced new challenges and, in several ways, exacerbated existing challenges NIH has with its on-prem ICAM infrastructure. A few high-level, current-state challenges are summarized below:

Time-to-deliver is not optimal: A lack of automation during the application integration process makes application onboarding arduous, time-consuming, and often reliant upon custom coding.

High operational costs: NIH’s portfolio includes legacy applications that rely on overly customized web-agents that require significant staff hours and effort to maintain.

Additionally, on-premises infrastructure requires more overhead (upkeep & maintenance) than modern cloud offerings.

Lack of real-time visibility: Operational metrics such as user activity, IAM service status, and platform/service availability are difficult to monitor across the ICs, and reporting capabilities between ICs vary.

Performance issues impacting users: With the significant, rapid increase in NIH’s remote workforce, VPN scalability proved insufficient to efficiently accommodate remote users’ need to access NIH-managed resources.

Mismatch of Service Level Agreements (SLAs): NIH currently has a mismatch between SLAs for on prem ICAM infrastructure and the SLAs of the cloud resources that require ICAM. The cloud resources at NIH become unavailable if on-prem ICAM infrastructure is down even though the cloud resources are still up.

NIH seeks to resolve most, if not all, of these challenges via its modernization effort. To keep pace with modern market offerings and technology trends, NIH desires to modernize its ICAM solution to reduce overhead and support the rollout of next-gen ICAM capabilities in alignment with the Zero Trust principle “never trust, always verify.” ICAM services with greater capabilities and expanded functionality are required to enable NIH users to seamlessly access resources they need from anywhere in the world.

The purpose of this request is to identify OEM vendors to conduct PoCs at NIH within a 90-day performance window. The PoCs will demonstrate vendor solutions in one or multiple Capability Areas outlined above (Authentication Services, Directory Services, SASE). The PoCs are intended to showcase the viability of vendor solutions and assess how the solution will integrate with the existing NIH environment. Results of the POCs will help NIH select solutions for NIH-wide deployment.

3. OBJECTIVES

The Government is pursuing four broad objectives (milestones) for this assessment:

3.1. Milestone 1 – Startup/Mobilization – Firm Fixed Price

The OEM vendor shall engage with NIH technical staff and leadership to discuss its overall strategy. During this effort, NIH and the OEM vendor will establish formal expectations for roles and responsibilities throughout the testing phase and determine additional resources needed for success. In particular, the OEM vendor will discuss products and licenses/subscriptions that are required, as well as roles and responsibilities with the government.

The OEM vendor shall be responsible for coordinating, planning, and scheduling a kickoff meeting with NIH no later than (NLT) 10 calendar days after contract award. The purpose of the kickoff is to align objectives, primary contacts, timelines, and rules of engagement among the parties, planned activities, and dependencies on the government. Additionally, the kickoff is intended to allow vendors opportunity to present their overall approach, verify their understanding of use cases (Appendix B), escalate potential risks, discuss any concerns, and request additional information required to execute Milestone 2 (test readiness). As a result of this meeting, the OEM vendor should come prepared with enough information to move forward into the next steps of PoCs. The OEM vendor is expected to provide a final written project plan with documentation and inventory of the items discussed during the kick-off meeting. These are due no later than 20 calendar days after contract award.

Exit Criteria

Pass: Vendor participates in kickoff, outlines key risks, provides primary points of contact, agrees to rules of engagement, and requests any information needed to move forward with milestone 2. OEM has provided all relevant Deliverables for Milestone 1.

Fail: Vendor does not agree to rules of engagement or participate in the mandatory project kickoff.

3.2. Milestone 2 – Test Readiness – Firm Fixed Price

The OEM vendor shall provision test environments to execute its solution based on a set of pre-defined use cases (listed in the PoC instructions and use case section below as Appendix B). The OEM vendor shall configure and connect the solution to the NIH environment. The OEM vendor shall be responsible for coordinating with NIH personnel and for producing any information required to inform potential security authorizations and provide test and configuration plans and documentation.

Vendors will execute PoCs with multiple systems and integrations. NIH will provide specific data required to fulfill testing and integrations with its environment. The data provided to vendors will include the number of accounts/devices, authentication/integration models, custom integrations (if applicable), and IC specific information (if necessary).

This milestone requires the OEM vendor to demonstrate that the solution can successfully connect to and be configured to systems within the NIH environment. To demonstrate the product’s relevance to the NIH environment, capabilities will be configured to address specific use cases listed in Appendix B.

Exit Criteria

Pass: OEM vendor provides an accepted test and configuration plan(s) and related documentation, provides any information required to inform potential security authorizations, and can connect and configure its solution to perform PoCs within NIH’s testing environment. OEM vendor has provided all relevant Deliverables for Milestone 2.

Fail: OEM vendor cannot connect and configure its solution to perform PoCs within NIH’s testing environment, fails to provide a test and configuration plan and related documentation, or is unable/unwilling to provide information to help inform potential security authorizations.

3.3. Milestone 3 – Testing and Evaluation– Firm Fixed Price

The use cases in Appendix B detail specific needs and nuances unique to NIH in the areas of Authentication, Directory, and SASE. The OEM vendor shall demonstrate how the proposed tools/solutions meet the various needs of NIH with optimal performance, and in alignment with the government’s planned project schedule. NIH will further define test scripts and evaluation specificity for vendors introduced to Milestone 3 to execute the required use cases.

The OEM vendor shall demonstrate (e.g., live demo, system generated report, configuration, logs, etc.) how the tool satisfies and performs the requirements and functions outlined in the use cases, as well as identify which use cases cannot be satisfied, or which ones require compensating measures to reduce the capability gap.

Exit Criteria

Pass: OEM vendor executes use cases and scripts according to the schedule outlined by NIH. Through executing testing, selected vendors will work with NIH to complete tests per the project schedule. OEM has provided all relevant Deliverables for Milestone 3.

Fail: OEM vendor is unable to execute use cases indicated by NIH or cannot execute based on the schedule indicated. Failure to complete at least 80% of use cases will be considered as an indication that the solution may not meet government requirements and may be viewed as an inability to pass this milestone. In such cases the government may consider other exogenous factors (e.g., market share, number of users, longevity, past performance, etc.) in determining Pass/Fail. NIH reserves the right to deliberate internally about the vendor's viability and pass/fail status if the vendor cannot complete over 80% of the required use cases.

3.4. Milestone 4 – Documentation and Closeout –Firm Fixed Price

As the vendor begins to test its solution through PoCs (Sections 3.2 and 3.3), NIH requires continuous communication of results and insights learned. No later than a week after completion of each use case, the vendor shall provide information to the NIH (created in collaboration with NIH technical experts) that can be shared with stakeholders to assess the proposed solution in the form of a status report. The status report must contain:

Description of use cases being tested and procedures being followed, Any issues or risks encountered throughout the testing process, and Summary of results from the use cases being executed.

The OEM vendor will also be expected to submit a final report. That at a minimum shall include:

Description of strategy and techniques used to demonstrate the assigned use cases (e.g., documentation of process, configuration files, etc.).

Description of results and data gathered.

Description of roles/responsibilities of the vendor and NIH throughout the use case process.

Description of any concerns, comments, or risks regarding the NIH environment.

At the conclusion of the PoC, vendors will provide a report focused on next steps in the form of an Enterprise-Wide Adoption Plan. Some suggested data includes:

Description of next steps including types of licensing/subscription arrangements and costs offered by the vendor for NIH-wide rollout (see Section 2 Background for high-level information regarding NIH’s environment). The vendor should detail which products/subscriptions are required and which are optional to fulfill the ICAM modernization needs at NIH.

A High-level Enterprise Deployment Approach that describes how the solution can be implemented widely at NIH. The plan must outline how the solution can be implemented widely, ensuring minimal service disruption to the current work, no service interruptions to mission-critical initiatives and security services, and no service degradation during and after transition using existing tools and processes already in place.

Exit Criteria

Pass: The OEM vendor provides the results of testing as instructed by the government.

The OEM vendor provides information required to determine how its solution can be adopted at the enterprise level such as types of licensing arrangements and costs. OEM vendor has provided all relevant Deliverables for Milestone 4.

Fail: The OEM vendor fails to provide the results of testing as instructed by the government. The OEM vendor doesn’t provide adequate information about the data gathered or how it conducted the use cases identified by NIH. The OEM vendor does not provide information required to determine how its solution can be adopted on an enterprise-wide level.

4. DELIVERABLES

Each of the reports below is a separate report to be submitted to the government:

MILESTONE 1

Project Plan: The OEM is expected to provide a project plan which will contain formal expectations for roles and responsibilities throughout the testing phase and determine additional resources needed for success. In addition, the plan should flag any potential risks or concerns.

MILESTONE 2

Test and Configuration Plan: The test and configuration plan shall contain information about how the OEM vendor will address the specified use cases, resources needed for testing, roles, and responsibilities, and how the OEM vendor will track results.

Notification of configuration & setup completion: The OEM vendor shall provide NIH with a written notification that documents successful configuration & setup. NIH will provide the vendor instructions to submit documentation through a secure NIH communication channel. An example of documentation may include a back-end console screenshot showing active network traffic or connections to systems required for testing.

MILESTONE 3

Notification for completion of required testing: The OEM vendor shall document the completion of required testing and provide this documentation to NIH through a secure communication channel to be provided by NIH during the project kickoff.

Status Reports upon completion of each use case: The status report shall contain information about each use case's results, any risks or issues encountered throughout the testing, and the strategies used to mitigate these risks/issues.

MILESTONE 4

MIL

Final Report: The OEM vendor shall submit a final report containing information, such as description of strategy and techniques used to demonstrate the assigned use cases;

description of results and data gathered; description of roles/responsibilities of the vendor and NIH throughout the use case process; and description of any concerns/ comments about the NIH environment.

Enterprise-Wide Deployment Plan: The OEM vendor shall submit an Enterprise-Wide Deployment Plan, which would describe the next steps, including types of licensing/subscription arrangements and costs offered by the vendor for NIH-wide rollout and a description of how the solution can be implemented widely at NIH. The plan shall outline how the solution can be implemented widely, ensuring minimal service disruption to the current work, no service interruptions to mission-critical initiatives and security services, and no service degradation during and after transition using existing tools and processes already in place.

5. PERIOD OF PERFORMANCE

The period of performance encompasses all four milestones. The performance period will begin during Milestone 1 (Startup/Mobilization) and conclude after Milestone 4 (Documentation and Closeout).

Milestone Deliverables Timeline Milestone 1:

Startup/Mobilization

Kick-off Meeting

NLT 10 calendar days after contract award (Kick-off Meeting)

Milestone Deliverables Timeline

Draft Project Plan

Final Project Plan

NLT 10 calendar days after award presented (Draft Project Plan) in the Kick-Off meeting

NLT 20 calendar days after contract award (Final Project Plan and other documentation identified in the Kickoff)

Milestone 2:

Test Readiness

Test and Configuration Plan

Notification of configuration & setup completion

NLT 40 Calendar days after contract award (both deliverables)

Milestone 3:

Testing and Evaluation

Notification for completion of required testing

Status Reports upon completion of each use case – reports to include Use Case test results, analysis, recommendations, etc.

NLT 75 calendar days after contract award (both deliverables)

Milestone 4:

Documentation and Closeout

Final Report

Enterprise-Wide Deployment Plan

NLT 90 calendar days after contract award (all deliverables, documentation, recovery of licenses)

Appendix A—Requirements Traceability Matrix (RTM)

Please reference and fill out the attached Requirements Traceability Matrix (RTM). Submit it as part of your response with the following file name “Vendor Name-RTM Response.”

Appendix B— PoCs ICAM Use Cases

Please reference Appendix B PoCs ICAM Use Cases.