SOO Appendix B PoCs ICAM Use Cases.pdf

Appendix B: ICAM Modernization Proof of Concepts (PoCs) Instructions & Use Cases

NIH Center for Information Technology ICAM Modernization

Contents

POC Environment(s) & Expectations

Authentication

Directory Services

Secure Access Service Edge

Supplement A – InCommon Metadata

Supplement B – RAS

Prerequisites

Available API endpoints

Available Identity Providers (IdP)

Compliance and Security FAQs

Testing Considerations

Development

Production

Appendix B: Page 1 National Institutes of Health

POC Environment(s) & Expectations NIH expects selected original equipment manufacturers (OEMs) providers to support the following throughout the milestones outlined in the Statement of Objectives (SOO):

1) Develop a test and configuration plan detailing overall approach for executing use cases.

2) Provide needed trial licenses/subscriptions.

3) Work collaboratively with NIH to establish test environments.

a. Software as a Service (SaaS) providers shall be responsible for setting up a tenant and working with NIH stakeholders to configure a cloud environment to execute use cases and requirements.

b. If vendors do not offer SaaS options, NIH may select to work with such vendors to configure trial licenses/subscriptions in a Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) alternative. 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.

4) Work collaboratively with NIH to provide technical support, conduct testing, and offer configuration and integration to ensure the completion of necessary use cases.

5) Communicate clearly and proactively with NIH with questions, concerns, and risks throughout the duration of the Proof of Concepts (PoCs).

6) Help NIH test each technical category across the capability areas (Authentication, Directory, and

Secure Access Service Edge (SASE)) by establishing necessary test data. Technical subject matter experts suggested conducting use cases with a sample size of approximately 200 internal and

200 external users. However, NIH shall collaborate with vendors if a larger sample size is necessary to execute critical requirements and use cases effectively.

Note: Certain use cases may operate in a production environment with real data / accounts, while others may reside in a test environment. Use cases shall only occur in a production environment if essential requirements have no other means to assure functionality.

7) Provide reports detailing use cases evaluated, summary of techniques used, results, and insights throughout the duration of PoCs.

Authentication Authentication services verify that a user is who they say they are. NIH requires a flexible authentication solution that can conditionally verify users in various environments, across applications, including through federated identities.

Appendix B: Page 2 National Institutes of Health

The following describes NIH’s desired use cases broken down by category and includes high‐level evaluation criteria. NIH shall further define test scripts and evaluation specificity for vendors introduced to Milestone 3 to execute the required use cases. Each use case shall 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.

Table 1: Authentication Services – Use Cases & Evaluation Criteria

Test ID # Use Case Description Evaluation Criteria (0‐2)

Authentication / Single Sign‐On (SSO)

SSO (1) Simple Authentication Use Case A

SAML, OIDC, OAuth, Header‐based

RTM Requirement Association: AUT‐TP‐01

Vendors shall demonstrate the ability to authenticate into systems using Security Assertion Markup Language (SAML), OpenID Connect (OIDC), OAuth, and Header‐based Authentication from various platforms.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

SSO (2) Simple Authentication Use Case B

Federation & REFEDS

Association: AUT‐OP‐11, AUT‐OP‐12

Vendors shall demonstrate the ability to support InCommon Federation with external identity providers in a manner that complies with Research and Education Federations group [REFEDS] framework) to allow InCommon federated users to access NIH Login1 protected applications as well as NIH users to access the resources of federated partners (e.g., academic institutions). NIH Service Provider (NIH Login) metadata shall specify in InCommon, the five (5) following mandatory attributes: (First Name, Last Name, User Principal Name (EPPN), Email Address, Configuration / Integration level of effort (LoE)

Completely offers technical functionality

1 NIH’s Access Control System, NIH-Login, manages and executes both the design-time and run-time access processes which include access policy administration, access entitlement management, access provisioning, authentication, and authorization. NIH-Login gives CIT IAM the capability to create and maintain the rule sets that govern access to protected resources; establish and maintain the authoritative access permissions for an individual or entity; link and unlink access permissions for an individual or entity to a protected resource; verify that a claimed identity is genuine based on valid credentials; and grant or deny access requests to protected resources based on a policy determination. NIH-Login provides various benefits that enhance the user’s experience by reducing the number of usernames and passwords users need to memorize, supports multiple authentication methods (e.g., password, PIV card, etc.), limits exchange/proliferation of user credentials, and enables a consistent program-wide authentication service.

Appendix B: Page 3 National Institutes of Health

Organization Name). The following attributes shall be provisioned in the NIH federation repository, upon successful researcher login: (email, company, givenName, sn, IAL, AAL userprincipalname, displayname, samaccountname, and Organization Name). Finally, InCommon metadata shall abide by the practices provided in this link (in the event that the link no longer functions correctly, please see Appendix A).

SSO (3) Simple Authentication Use Case C

Kerberos & Radius

Association: AUT‐TP‐02

Vendors shall demonstrate the ability to authenticate into systems using network authentication methods such as Kerberos and RADIUS.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

SSO (4) Simple Authentication Use Case D

Identity Providers

Association: AUT‐TI‐13

Vendors shall demonstrate the ability to integrate with identity providers (IdPs) including Login.gov, ID.me, InCommon, and Google among other third party IdPs.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

SSO (5) Simple Authentication Use Case E

Self‐Service (Application Onboarding)

Association: AUT‐TI‐07

Vendors shall demonstrate capabilities to support self‐service features to streamline application onboarding with the authentication / SSO provider and reduce time‐to‐ delivery.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

SSO (6) Simple Authentication Use Case F

Researcher Auth Service

Association: AUT‐OP‐05

Vendors shall demonstrate the ability to integrate with NIH RAS to enable authentication and SSO. For further details on RAS, please reference this link (in the event that the link no longer functions correctly, please see Appendix B).

Configuration / Integration level of effort (LoE)

Appendix B: Page 4 National Institutes of Health

SSO (7) Simple Authentication Use Case G

Command‐Line Interface

Association: AUT‐TI‐19, AUT‐TI‐21

Vendors shall demonstrate support for authentication from CLI including federated MFA.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Multi‐Factor Authentication (MFA)

MFA (1) MFA Use Case A

Phishing Resistant Authentication Options

Association: AUT‐OP‐08, AUT‐TI‐15

Vendors shall demonstrate the configuration and performance of its various MFA options that are considered phishing resistant (e.g., biometrics, Yubikey, passwordless). The vendor shall expect to show options in compatibility with an NIH system.

Configuration / Integration level of effort (LoE) for various methods

Completely offers technical functionality

MFA (2) MFA Use Case B

Phishing Resistant

Association: AUT‐TI‐32

Vendors shall demonstrate the ability to support phishing‐ resistant authentication alternatives for logical access to workstations/servers if PIV cards and device‐based certificates are not operational (e.g., expired certs, lost credentials).

Configuration / Integration level of effort (LoE) for various methods

Completely offers technical functionality

MFA (3) MFA Use Case C

Windows Hello for Business

Association: AUT‐TI‐44

Vendors shall demonstrate the ability to support Windows Hello for Business, allowing Azure Multifactor services to be used for logical access to workstations, servers, and web applications/services.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

MFA (4) MFA Use Case D

Additional

Association: AUT‐OP‐06

Vendors shall demonstrate the configuration and performance of its various MFA options, including options that are not necessarily phishing resistant (e.g., OTP, TOTP). The vendor shall expect to show these options using an NIH system.

Configuration / Integration level of effort (LoE) for various methods

Completely offers technical functionality

Appendix B: Page 5 National Institutes of Health

MFA (5) MFA Use Case E

PIV Interoperability

Association: AUT‐TI‐26

Vendors shall demonstrate support for smart‐card authentication (e.g., PIV, CAC) for federal government agencies through testing cards from multiple agencies against an NIH system.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Adaptive Authentication / Step‐Up Authentication

Adaptive Authentication (1)

Adaptive Authentication / Step‐ Up Authentication Use Case A

Static Step‐Up Authentication

Association: AUT‐TI‐17

Vendors shall demonstrate support for Step‐Up Authentication by moving from an application with a lower identity assurance level(IAL)/ authentication assurance level (AAL) to an application with a higher IAL/ AAL.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Adaptive Authentication (2)

Adaptive Authentication / Step‐ Up Authentication Use Case B

Anomalies and Risk Triggers

Association: AUT‐TI‐14, AUT‐TI‐09

Vendors shall demonstrate the ability to leverage device trust and provide support for adaptive/risk‐ based authentication based on criteria such as geo‐location, device, IP address, and posture in a use case that provides anomalous data or risk triggers. As part of this use case, the vendor shall also demonstrate its ability to integrate with MobileIron and Intune to collect device data.

Configuration / Integration level of effort (LoE) for various risk signals

Completely offers technical functionality

Adaptive Authentication (3)

Adaptive Authentication / Step‐ Up Authentication Use Case C

Azure AD Conditional Access Signal

Association: AUT‐TI‐37

Vendors shall demonstrate integration with Azure AD for MFA and conditional access signals to enforce security policies.

Configuration / Integration level of effort (LoE) for various risk signals

Completely offers technical

Non‐Standard Integrations and Processes

Appendix B: Page 6 National Institutes of Health

Non‐Standard Integrations (1)

Non‐Standard Integrations & Processes Use Case A

Operational Technology API Support

Association: AUT‐TI‐36

Vendors shall demonstrate the ability to provide API web services that integrate with NIH Operational Technology (OT) systems (sensitive tenants such as Industrial Control System [ICS], Video Surveillance Systems hosted on Facilities network [FACNet] environment). The vendor’s solution shall demonstrate its ability to integrate and enable authentication into NIH’s OT environment.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Non‐Standard Integrations (2)

Non‐Standard Integrations & Processes Use Case B

Cross Domain Cookies

Association: AUT‐TI‐41

Vendors shall demonstrate the ability to offer cross‐domain cookie support for service providers such as Grant Solutions.

Specifically, any domain value (grantsolutions.gov, cancer.gov, genome.gov) are all considered cross‐domain cookie support as the single sign‐on needs to work for all other domains along with the "nih.gov" domain.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Non‐Standard Integrations (3)

Non‐Standard Integrations & Processes Use Case C

AWS Federation

Association: AUT‐TI‐25

Vendors shall demonstrate the ability to support AWS federation.

The vendor shall be able to get the correct set of data for a given AWS ID and then populate the SAML assertion with the respective AD group and role information for AWS to honor the request.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Non‐Standard Integrations (4)

Non‐Standard Integrations & Processes Use Case D

Session Timeout Variation

Association: AUT‐UX‐01

The vendor shall demonstrate the ability to adapt session timeout values based on variable system requirements. For example, some systems at NIH require a 60‐ minute session timeout value, while others require 30 minutes.

Configuration / Integration level of effort (LoE)

Completely offers technical

Operations, Reporting, and Resilience

Appendix B: Page 7 National Institutes of Health

Operations, Reporting, and Resilience (1)

Operations, Reporting, and Resilience Use Case A

Authentication Chaining

Association: AUT‐TI‐38

Vendors shall demonstrate authentication chaining as a failover mechanism and support alternative authentication methods in case of primary authentication mechanism failure.

Completely offers technical functionality

Operations, Reporting, and Resilience (2)

Operations, Reporting, and Resilience Use Case B

Lost Connection to Service Provider

Association: AUT‐TI‐38

Vendors shall demonstrate their approach to recover and help NIH maintain operations if NIH loses connection to the Authentication Service Provider. A simulated scenario shall be provided to test this capability.

Completely offers technical functionality

Backup plan is sufficient and within NIH’s acceptable risk tolerance

Operations, Reporting, and Resilience (3)

Operations, Reporting, and Resilience Use Case C

Reporting Metrics

Association: AUT‐OP‐05

Vendors shall demonstrate the ability to provide APIs for returning component/feature status to report metrics of components (e.g., successful authentications, failed attempts, password expirations, etc.).

Additionally, vendors shall demonstrate out‐of‐the‐box reporting capabilities while demonstrating this use case.

Completely offers technical functionality

Directory Services Directory Services store and maintain information about NIH users and resources. Many organizations such as NIH require virtual directories to support hybrid IT environments and to aggregate information from on‐premises and cloud‐based sources, in real time. NIH requires a solution that shall store data and provide features for managing users, groups, and objects to support authentication and authorization.

The following describes NIH’s desired use cases broken down by category and includes high‐level evaluation criteria. NIH shall further define test scripts and evaluation specificity for vendors introduced to Milestone 3 to execute the required use cases. Each use case shall 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.

Table 2: Directory Services – Use Cases & Evaluation Criteria

Appendix B: Page 8 National Institutes of Health

Test ID# Use Case Description Evaluation Criteria (0‐2)

Directory Services

Directory Services (1)

Directory Services Use Case A

Identity Lifecycle Management

Association: DIR‐

SEC‐01

Vendors shall demonstrate the ability to automatically provision identities to directory with mandatory attributes and birthright entitlements.

Additionally, the vendor shall demonstrate its ability to support identity lifecycle management using Create, Read, Update, and Delete (CRUD) operations based on the stored identity data.

Attributes supported include the following: First Name, Last Name, User Principal Name (EPPN), Email Address, Organization Name, samaccountname, and others to be provided during testing.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Directory Services (2)

Directory Services Use Case B

LDAP / Non‐LDAP & Web Service APIs

Association: DIR‐TP‐

02, DIR‐TI‐11

Vendors shall demonstrate the ability to integrate with LDAP and non‐LDAP identity data repositories as well as the ability to respond to web service calls via APIs.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Replication & Synchronization

Replication & Synchronization (1)

Replication & Synchronization Use Case A

Real Time Replication

Association: DIR‐TI‐

10, DIR‐TI‐39

Vendors shall demonstrate the capability to replicate and synchronize data in near real‐ time from services of stored identity data with other data repositories, applications, services, and CSPs (e.g., LDAP directories, databases, applications, and web services).

Configuration / Integration level of effort (LoE)

Appendix B: Page 9 National Institutes of Health

Replication & Synchronization (2)

Replication & Synchronization Use Case B

Account linking

02, DIR‐TI‐03

Vendors shall demonstrate the account linking capabilities to automate linking of an identity to multiple personas from a single/multiple domains.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Replication & Synchronization (3)

Replication & Synchronization Use Case C

Account linking

RTM Requirement Association: DIR‐TI‐

02, DIR‐TI‐03

RTM Requirement Association: DIR‐TI‐

02, DIR‐TI‐03

Vendors shall demonstrate the ability to compare two identity repositories / sources, generate discrepancy reports, and resync sources to link identities and accounts.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Authoritative Data Store

Authoritative Data Store (1)

Authoritative Data Store Use Case A

ABAC Support

SEC‐04

Vendors shall demonstrate the ability to support Attribute‐ Based Access Control (ABAC) by serving as an authoritative source that integrates with access management services and uses various identity and biometric attributes to inform access decisions.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Authoritative Data Store (2)

Authoritative Data Store Use Case B

Temporary Access Support

SEC‐09

Vendors shall demonstrate the ability to assign temporary group membership for secure access to requested resources and automatically remove privileges afterward.

Configuration / Integration level of effort (LoE) for various risk signals

Appendix B: Page 10 National Institutes of Health

Authoritative Data Store (3)

Authoritative Data Store Use Case C

Admin Access Review Support

RTM Requirement Association: DIR‐

SEC‐01

Vendor shall demonstrate the ability to offer an admin view of identities and their roles/permissions/attributes to enable access reviews.

Configuration / Integration level of effort (LoE) for various risk signals

Completely offers technical functionality

Ease of Use (UX / UI)

Support for Cloud Applications and Service Providers

Support for Cloud Applications and Service Providers (1)

Support for Cloud Applications and Service Providers

Use Case A

Integration with Cloud Applications

SEC‐06

Vendors shall demonstrate the ability to support directory services (including automated lifecycle management) for cloud applications, such as Microsoft / Office 365, required for authentication into those environments.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Support for Cloud Applications and Service Providers (2)

Support for Cloud Applications and Service Providers

Use Case B

On‐Premises User Authentication (Cloud Service Providers)

27, DIR‐TI‐28

Vendors shall demonstrate the ability to provide directory services needed to support the authentication of on‐premises users into cloud service providers/resources (line‐of‐ business).

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Additional Integration Testing

Additional Integration Testing (1)

Additional Integration Use Case A

CyberArk Integration ability to maintain integration capabilities with CyberArk to authenticate privileged tasks that require privileged accounts vaulted in CyberArk.

Configuration / Integration level of effort (LoE)

Appendix B: Page 11 National Institutes of Health

Association: DIR‐TI‐

Additional Integration Testing (2)

Additional Integration Use Case B

MDM Integration

Vendors shall demonstrate the ability to integrate with Intune (MDM) and MobileIron to provide device signals to conditional access scenarios.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Additional Integration Testing (3)

Additional Integration Use Case C

AD Integration

Vendors shall demonstrate the ability to support bi‐directional data integration with NIH directory services such as Active Directory and RadiantLogic.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Operations, Reporting, and Resilience

Operations, Reporting, and Resilience (1)

Operations, Reporting, and Resilience Use Case A

AD Remediation / SOAR Integration

Vendors shall demonstrate the ability to integrate with NIH Enterprise support solutions [e.g., Security Orchestration, Automation, and Response (SOAR) data] for AD remediation and security response.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Operations, Reporting, and Resilience (2)

Operations, Reporting, and Resilience Use Case B

Trouble Shooting & Lookups ability to offer direct access to active directory audit logs for application troubleshooting purposes and the ability to support attribute indexing capabilities to optimize lookup operations to handle queries.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Administrative ease of Use

(UX)

Appendix B: Page 12 National Institutes of Health

Association: DIR‐

OP‐04, DIR‐OP‐08

Operations, Reporting, and Resilience (3)

Operations, Reporting, and Resilience Use Case C

Persistent Cache Refresh

OP‐07

Vendors shall demonstrate support for persistent cache refresh mechanism to improve performance.

Configuration / Integration level of effort (LoE)

Secure Access Service Edge Secure Access Service Edge (SASE) refers to the suite offering various network and security products such as Software‐Defined Wide Area Network (SD‐WAN), Firewall as a Service (FWaaS), Secure Web

Gateway (SWG), Cloud Access Security Broker (CASB), and Zero Trust Network Access (ZTNA). These offerings and capabilities enable users to securely access their resources from anywhere in the world while maintaining optimal performance. It also supports the foundational pillars of Zero Trust by providing more granular, adaptive, and risk‐based access controls and greater visibility into the enterprise’s overall security posture. The selected SASE solution is expected to replace legacy VPN services to enable hybrid work.

The following describes NIH’s desired use cases broken down by category and includes high‐level evaluation criteria. NIH shall further define test scripts and evaluation specificity for vendors introduced to Milestone 3 to execute the required use cases. Each use case shall 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.

Table 3: SASE – Use Cases & Evaluation Criteria

Test ID# Use Case Description Evaluation Criteria (0‐2)

Networking Services & Performance

Networking Services & Performance (1)

Networking Services Use Case A

Vendors shall demonstrate the network performance and user experience of SASE solutions by

Configuration / Integration level of effort (LoE)

Appendix B: Page 13 National Institutes of Health

Performance and User Experience (UX)

Association: S‐UX‐01, S‐UX‐02 demonstrating how a user would connect to an NIH cloud environment and an on‐premises environment.

NIH wants to understand ease of use when accessing target data, applications, or services, the required verification steps, and overall network performance (e.g., latency).

Completely offers technical functionality

Ease of use (UX)

Network performance

Networking Services & Performance (2)

Networking Services Use Case B

SD‐WAN

Association: S‐OP‐07, S‐OP‐08, S‐OP‐23

Vendors shall demonstrate the ability to prioritize / steer network traffic and apply quality‐of‐service policies based on packet types in a test environment. NIH wants to test the solution's ability to differentiate traffic to determine which traffic needs security inspection and which requires higher throughput, such as voice‐ over internet traffic.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Ease of use (UX)

Network performance

Networking Services & Performance (3)

Networking Services Use Case C

Content Distributed Network / Points of Prescence

Association: S‐TI‐03

Vendors shall demonstrate how SASE solutions use distributed points of presence to connect NIH remote users to NIH resources most efficiently.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Ease of use (UX)

Network performance

Networking Services & Performance (4)

Networking Services Use Case D

Virtual Private Network (VPN) Alternative)

Association: S‐OP‐10, S‐TP‐01

Vendors shall demonstrate the ability to connect to two NIH test systems (One cloud, one on‐ premises) without having to use traditional VPN.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

Ease of use (UX)

Network performance

Appendix B: Page 14 National Institutes of Health

CASB

CASB (1) CASB Use Case A

Consistent Policy Across Multiple Cloud Platforms

Association: S‐OP‐17, S‐TI‐02, Vendors shall demonstrate their ability to configure consistent inspection and security policies across multiple cloud environments.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

CASB (2) CASB Use Case B

DLP

Association: S‐OP‐22

Vendors shall demonstrate the ability to provide Data Loss Prevention (DLP) capabilities by discovering and tagging test data and demonstrating functionality and options upon policy violations (e.g., access, exfiltration, etc.).

Configuration / Integration level of effort (LoE) for various methods

Completely offers technical functionality

CASB (3) CASB Use Case C

Cloud Application Discovery

RTM Requirement Association: S‐CI‐01

Vendors shall demonstrate the ability to provide application discovery of cloud‐hosted applications in a sample / test environment.

Configuration / Integration level of effort (LoE) for various methods

Completely offers technical functionality

CASB (4) CASB Use Case D

CASB Integration / Interoperability

RTM Requirement Association: S‐CI‐01

Vendors shall demonstrate the ability to either integrate with the existing NIH CASB solution or operate

Configuration / Integration level of effort (LoE) for various methods

Completely offers technical functionality

FWaaS

FWaaS (1) FWaaS Use Case A

Traditional Firewall

Association: S‐SEC‐01

Vendors shall demonstrate the ability to filter / prevent undesired network traffic.

Configuration / Integration level of effort (LoE)

Appendix B: Page 15 National Institutes of Health

FWaaS (2) FWaaS Use Case B

Application‐Level Firewalls /

Association: S‐TP‐03

Vendors shall demonstrate the ability to filter / prevent unwanted traffic at the application level.

Additionally, vendors shall offer delegated control for app owners who need to apply specific security controls required for various IC systems and applications.

Configuration / Integration level of effort (LoE) for various risk signals

Completely offers technical functionality

FWaaS (3) FWaaS Use Case C

Intrusion Detection / Prevention

Association: S‐SEC‐01, S‐TP‐03, S‐SEC‐09, S‐

SEC‐14

Vendors shall demonstrate the ability to detect and prevent anomalous traffic in a simulated scenario.

Configuration / Integration level of effort (LoE) for various risk signals

Completely offers technical functionality

SWG

SWG (1) SWG Use Case A

Malware Detection, Phishing Attempts, & Sandboxing

Association: S‐OP‐02, S‐OP‐05, S‐SEC‐10

Vendors shall demonstrate the ability to sandbox and scan for malware and phishing attempts in a simulated scenario.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

SWG (2) SWG Use Case B

DDoS Prevention

Association: S‐OP‐11

Vendor shall demonstrate the ability to detect and prevent Distributed Denial of Service (DDoS) attacks by monitoring various SASE service modules to detect and mitigate DDoS attempts. The Vendor and NIH shall collaboratively perform stress testing to evaluate this use case.

Configuration / Integration level of effort (LoE)

Appendix B: Page 16 National Institutes of Health

SWG (3) SWG Use Case C

URL Filtering

Association: S‐OP‐16, S‐SEC‐06, S‐SEC‐07, S‐

OP‐03,

Vendors shall demonstrate solution support for web content filtering, SSL inspection, and DNS filtering to show their ability to protect against threats deriving from websites and associated malicious content.

Configuration / Integration level of effort (LoE)

Completely offers technical functionality

ZTNA

ZTNA (1) ZTNA Use Case A

MFA / Access Management Integration

Association: S‐CR‐03, S‐CR‐11, S‐CR‐12

Vendors shall demonstrate the ability to enforce MFA as a condition for gaining access to a remote environment. As part of this use case, the vendor shall be able to integrate with NIH’s authentication provider.

Completely offers technical functionality

Configuration / Integration level of effort (LoE)

ZTNA (2) ZTNA Use Case B

Managed and Bring your own Device (BYOD) Security

RTM Requirement Association: S‐OP‐21, S‐CR‐16, S‐SEC‐13, S‐

OP‐12

Vendors shall demonstrate the ability to enable access from managed devices and BYOD securely using device posture checks as a condition for gaining access to an environment.

Completely offers technical functionality

Configuration / Integration level of effort (LoE)

ZTNA (3) ZTNA Use Case C

Risk Aware Security Capabilities

Association: S‐CR‐07

Vendors shall demonstrate the ability to calculate risk scores against multiple points of telemetry, such as device posture/behavior, identity/user behavior, file type, and additional points of telemetry (if possible) to trigger access revocations, step‐up authentication, and other security enforcement actions.

Completely offers technical functionality

Configuration / Integration

Additional Integration Testing

Appendix B: Page 17 National Institutes of Health

Additional Integration Testing (1)

Integration Use Case A

Service Management Tools

Association: S‐TI‐05

Vendor shall demonstrate the ability to integrate with IT Service Management (ITSM) tools such as ServiceNow and Jira to trigger and automate responses required to detect and remediate violations in security policies.

Completely offers technical functionality

Configuration / Integration level of effort (LoE)

Additional Integration Testing (2)

Integration Use Case B

Security Operations & Threat Discovery Tools

Association: S‐TI‐09

Vendor shall demonstrate integration with security operations tools such as dynamic threat discovery and vulnerability management solutions (e.g., Microsoft Defender for Cloud).

Completely offers technical functionality

Configuration / Integration level of effort (LoE)

Additional Integration Testing (3)

Integration Use Case C

Access Management Tools

Association: S‐CR‐11, S‐CR‐12

The vendor shall demonstrate integration with enterprise Identity and Access Management (IAM) services, including privileged access management/secrets management (CyberArk) to provide authentication.

Completely offers technical functionality

Configuration / Integration level of effort (LoE)

Operations, Reporting, and Resilience

Operations, Reporting, and Resilience (1)

Operations, Reporting, and Resilience Use Case A

Lost Connection to Service Provider

Association: S‐OP‐01

Vendors shall demonstrate their approach to recover and help NIH maintain operations if NIH loses connection to the SASE Service Provider. A simulated scenario shall be shown to confirm this functionality.

Completely offers technical functionality

Backup plan is sufficient and within NIH’s acceptable risk tolerance

Operations, Reporting, and Resilience (2)

Operations, Reporting, and Resilience Use Case B

Component Failure their approach to recover and help NIH maintain operations if any integrated components fail (e.g., Access

Completely offers technical functionality

Backup plan is sufficient and within NIH’s acceptable risk tolerance

Appendix B: Page 18 National Institutes of Health

Association: S‐OP‐01

Management, Endpoint Management System). A simulated scenario shall be shown to confirm this functionality.

Operations, Reporting, and Resilience (3)

Operations, Reporting, and Resilience Use Case C

Reporting Metrics

Association: S‐CR‐06

Vendor shall demonstrate reporting performance metrics for sample NIH network, applications, and users. Metrics may include network and server bandwidth to detect and prevent DoS attacks, highest bandwidth utilization, user access list for applications, and failed logins, but NIH would like to see other options and recommendations from vendors to help monitor performance and security as part of the PoC.

Completely offers technical functionality

Administrator User Experience (UX)

Configuration / Integration level of effort (LoE)

Operations, Reporting, and Resilience (4)

Operations, Reporting, and Resilience Use Case D

Trouble Shooting

Association: S‐UX‐02

The vendor shall demonstrate administrator user experience to troubleshoot common scenarios.

Completely offers technical functionality

Administrator User Experience (UX)

Operations, Reporting, and Resilience (5)

Operations, Reporting, and Resilience Use Case E

Splunk Integration & Visibility

Association: S‐TI‐07

The vendor shall demonstrate SASE integration with Logs/Splunk Logs to achieve visibility in the enterprise SIEM tool.

Administrator User Experience (UX)

Configuration / Integration level of effort (LoE)

Operations, Reporting, and Resilience (6)

Operations, Reporting, and Resilience USe Case F

The vendor shall demonstrate the capability to use SASE telemetry data and monitoring to inform

Completely offers technical functionality

Appendix B: Page 19 National Institutes of Health

Security Operations Center (SOC) Playbooks

Association: S‐UX‐02, S‐CR‐10

SOC run playbooks based on events in the SASE cloud environment (i.e.

force device disconnect).

Operations, Reporting, and Resilience (7)

Operations, Reporting, and Resilience Use Case G

TIC 3.0 Log Forwarding

Association: S‐CR‐04 the ability to forward logs in compliance with TIC 3.0 and CISA requirements.

Completely offers technical functionality

Appendix B: Page 20 National Institutes of Health

Supplement A – InCommon Metadata This article describes useful configuration best practices when using InCommon metadata. To learn how to retrieve metadata, visit the InCommon Metadata Service Wiki.

1) Query instead of "download"

a. The new InCommon Metadata Distribution Service (MDQ Service) is based on the

Metadata Query (MDQ) protocol. A metadata consumer can retrieve needed metadata by making a web query in real time. It eliminates the need to download the entire metadata aggregate, thus significantly reduces system resource overhead and reduces start up time. To retrieve metadata using the MDQ‐based Metadata Service, visit the new InCommon Metadata Service Wiki.

2) Verify connection to the Metadata Service

a. To consume InCommon metadata, your IdP or SP must be able to perform HTTPS requests against mdq.incommon.org. The Metadata Service is hosted on cloud infrastructure with dynamic IP assignments. The IP addresses for these services shall change over time. If your organization has egress firewall rules restricting access to outside resources, see Configuring Firewalls to work with the InCommon Metadata

Service.

3) Configure software to consume metadata

a. See InCommon Metadata Service Wiki.

4) Refresh metadata at least daily when using the aggregate

a. While not recommended, the InCommon Metadata Distribution Service does support downloading metadata as an aggregate. If you do use the aggregate, we strongly recommend that all service providers and identity providers refresh and verify metadata at least daily. Daily refresh ensures your service shall have access to the most up‐to‐date keys and other registered metadata information.

b. What happens if I don't refresh metadata frequently?

i. If you don't refresh metadata regularly, your service shall likely fail at some point. An IdP or SP operator may update its metadata at any time. If your service does not have the latest information, it may not be able to connect to the services you integrate with. Further, metadata published through

InCommon carries an expiration date (validUntil) set to expire published metadata approximately every two weeks. NOTE: we advise against relying on the validUntil value to determine refresh interval (ref: IdP or SP may update its metadata anytime). Better yet, use the MDQ query to retrieve metadata on‐ demand, in real time, to eliminate any issues caused by over caching.

c. Validate downloaded metadata

i. Federation metadata has an expiration date, much like an X.509 certificate. It is important that expired metadata not be accepted, otherwise an attacker would be able to substitute expired metadata in conjunction with metadata refresh. In particular, a metadata file should not be accepted if any of the following conditions are true:

Appendix B: Page 21 National Institutes of Health

1. If the metadata file does not have a validUntil XML attribute on the root element.

2. If the validUntil date on the root element is expired.

3. If the validUntil date on the root element is too far into the future.

ii. A metadata refresh process should check each of the above conditions before accepting the metadata. Alternatively, if your SAML implementation is known to ignore/reject expired metadata (a basic correctness requirement), it may be sufficient to ensure that a validUntil attribute exists and its date value is not unexpectedly far into the future.

iii. Federation metadata is signed for integrity and authenticity. Participants are strongly encouraged to verify the XML signature on the metadata file before use; failure to do so shall seriously compromise the security of your SAML deployment.

iv. The InCommon Federation is based on the Explicit Key Trust Model, one of several possible metadata trust models. To bootstrap the trust fabric of the

Federation, participants download and configure an authentic copy of the Metadata signing certificate into their metadata refresh process. The certificate must be obtained securely since all subsequent operations depend on it.

v. Once the certificate file is locally installed, you can use it to verify the signature on the metadata file. For example, you could use the XmlSecTool (or some similar 3rd‐party tool) to verify the signature.

Supplement B – RAS This document explains the authentication, authorization, and logging services available to NIH Institutes and Centers and extramural systems desiring information about users requesting to access NIH’s open and controlled data assets and repositories through the NIH Researcher Auth Service

(RAS).

The intended audience for this document is technical developers and leaders responsible for design and implementation of the integrations with the RAS APIs.

Prerequisites

The following are the recommended prerequisites to using this document:

Familiarize with the OAuth 2.0 Specification, RFC 6749.

Familiarize with the OpenID Connect 1.0 Specifications.

Familiarize with the JSON Web Token (JWT) specification, RFC 7519 and understanding of claims and tokens.

Familiarize with Global Alliance for Genomics & Health (GA4GH) Passport Specifications.

Familiarize with GA4GH Authentication and Authorization Infrastructure.

Appendix B: Page 22 National Institutes of Health

Available API endpoints

The following table illustrates the OAuth 2.0 and Open ID Connect 1.0 endpoints which are available for testing:

API Endpoint Purpose Reference

/auth/oauth/v2/authorize Initiate process to allow resource owner to permit client access

OAuth 2.0

/auth/oauth/v2/authorize/login Prompts resource owner to login before permitting client access

OAuth 2.0

/auth/oauth/v2/authorize/consent Prompts resource owner to allow or deny client access

OAuth 2.0

/auth/oauth/v2/token Processes the token issuance step

OAuth 2.0

/auth/oauth/v2/token/revoke Revokes an issued token OAuth 2.0

/openid/connect/v1/userinfo (deprecated ‐ date 3/31/2022)

If presented with a valid access token, returns claims about the requested user

OIDC 1.0, GA4GH

Passports Spec, GA4GH AAI OIDC

RFC.

/openid/connect/v1.1/userinfo If presented with a valid access token, returns claims about the requested user

OIDC 1.0, GA4GH

Passports Spec, GA4GH AAI OIDC

RFC.

/connect/session/logout Terminates the current Open ID active session

OIDC 1.0

/openid/connect/jwks.json

Used to publish the JWK set public keys used by clients to validate a JSON Web token

(JWT).

OIDC 1.0

/.well‐known/openid‐configuration Used to retrieve metadata about the RAS OpenID Connect configuration.

OIDC 1.0

Available Identity Providers (IdP)

RAS currently offers the following IdPs as authentication sources for researchers accessing an integrated system:

NIH Active Directory

Appendix B: Page 23 National Institutes of Health

Identity Assurance Level (IAL) 3 identity that is authenticated at Authenticator Assurance Level (AAL) 3 when using NIH issued PIV card. First name, last name and email address are available.

eRA Commons IAL1 identity that is authenticated at AAL1. First name, last name and email address are available. Role and affiliation information from eRA is available if needed.

Login.gov Options to require IAL 1 and 2 are available along with various multi factor authentication options. Email address is available at IAL1; first and last name at IAL2.

Requests for RAS to integrate additional IdPs should be included with system integration requirements and shall be considered by the project team.

Note: The different IAL and AAL levels are defined by the National Institute of Standards and Technology in NIST Special Publication 800‐63.

Compliance and Security FAQs

The National Institutes of Health’s (NIH) Office of Data Science Strategy (ODSS) is committed to continuous improvement of partner engagement with the Researcher Auth Service (RAS). The purpose of the FAQ site is to ensure that all RAS partners understand and are applying the appropriate NIH Chief Information Security Officer approved best practice security requirements.

Please refer to this site regularly for updates to frequently asked questions (FAQs) from RAS partner systems. (Last updated: April 6, 2022)

1. Which security and other standards frameworks does RAS follow?

a. RAS is part of the NIH CIT IAM General Support System (GSS) which is a Federal

Information Security Management Act (FISMA) High system. As such, RAS shall adhere to NIST (National Institute of Standards and Technology) 800‐53 and 800‐57 guidelines pertaining to configuration management, least privilege, and cryptographic key establishment & management.

b. For authentication processing, RAS shall comply with the Global Alliance for Genomics and Health (GA4GH) approved specifications for packaging “passport claims” and “passport visas” as detailed in the GA4GH Passports and Authentication and Authorization Infrastructure specifications.

2. Shall all our system users have to log in with RAS?

a. Yes – Once a partner system is using RAS to access NIH controlled access data, their users shall be required to log‐in via RAS with a supported identity provider to access those data.

3. Can we link user accounts from RAS with non‐RAS accounts?

a. No – Partner side linking of non‐RAS IdP accounts to RAS accounts is prohibited.

In order to maintain authentication method and ID proofing security controls, RAS tokens currently can only be released based upon RAS authentication.

4. Can we repackage RAS visas into a non‐RAS passport, and use those passports for access to NIH data?

Appendix B: Page 24 National Institutes of Health

a. No – RAS Visas must not be repackaged into a Passport issued by any other broker. The integrity of the RAS passport, and the ability to validate passport‐ level claims and visa tokens, are critical aspects of the overall RAS security model.

5. How can we trust an external system that requests data using a RAS passport?

a. Trust is established with NIH Approved third party Certificate Authority (CA) certifications that facilitate client/server mutual authentication in order to securely exchange the RAS passport.

6. How do we know that we’ve been presented with a real RAS passport?

a. A RAS Clearinghouse verifies the Passport being presented is a real RAS Passport by verifying that the issuer is NIH and that it has been signed by NIH RAS.

Currently, existing and new partners create their own RAS Clearinghouses using NIH‐supplied instructions in the Interconnection Security Agreement (ISA).

These RAS Clearinghouses shall be subject to testing and ongoing inspection to ensure NIH contractual compliance.

Testing Considerations Development

To engage in development testing with NIH RAS, the following steps must be adhered to:

1. When using the authorize request, the scope parameter must include “openid” in order to get an ID Token returned.

2. ID Tokens returned from RAS should be checked to ensure secure delivery and validity.

3. Profile, phone, and email information should be retrieved via the “userinfo” request.

4. To comply with GA4GH, only the following signing algorithm shall be supported: RS256.

5. Only the following encryption algorithm shall be supported: RSA.

Production

The following steps should have been completed prior to promoting an integration with RAS into Production:

1. ServiceNow request was raised for the integration in a non‐production environment

2. Integration was successfully implemented in the lower environment

3. End‐to‐end testing was successfully completed

4. Documented test results or summary was provided to the IAM OIDC team showing successful

Integration and User Acceptance Testing

5. A ServiceNow request was raised for the Production deployment

6. Production deployment planning activities (date/time of rollout, shakeout activities and responsibilities and production support plan) were discussed and agreed to with the IAM OIDC team at least a week prior to the planned go‐live date.