RFI ISF SOO Draft 70RSAT24RFI000020.pdf

RFI 70RSAT24RFI000020

DEPARTMENT OF HOMELAND SECURITY (DHS)

STATEMENT OF OBJECTIVES (SOO) FOR A PROOF OF CONCEPT

TO DESIGN, DEVELOP, TEST, AND IMPLEMENT THE INTEGRATION LAYER OF THE

INFORMATION SHARING FRAMEWORK AS A SERVICE PLATFORM

BACKGROUND. Currently, deployment of secure and prioritized emergency communications services on 4G/5G networks is highly beneficial to National Security or Emergency Preparedness (NS/EP) 1, public safety, and critical infrastructure personnel.

However, during emergency incidents, those same personnel need the ability to discover, access, and consume any relevant information on a need-to-know basis, regardless of jurisdiction, affiliation, or location. The exchange of actionable and timely information among NS/EP personnel across agencies and governmental jurisdictional level continues to hinder their ability to meet their missions.

Figure 1. NS/EP user community including public safety and critical infrastructure

The sharing of relevant and timely incident information is particularly challenging during larger scale emergency events (See Figure 2 below), due to the likelihood of interoperability challenges that come with multiple jurisdictions and organizations responding to the same event (e.g., different networks, different equipment brands, and different software applications). To add to the complexity, communications networks may be degraded, and information can be provided and consumed by both human and machine with different needs, bandwidths, and capabilities.

1 “NS/EP personnel” generally refers to individuals who are responsible for maintaining a state of readiness or responding to and managing any event or crisis (local, national, or international), which causes or could cause injury or harm to the population, damage to or loss of property, or degrades or threatens the NS/EP posture of the United States. See https://docs.fcc.gov/public/attachments/FCC-22-36A1.pdf for more information.

https://docs.fcc.gov/public/attachments/FCC-22-36A1.pdf

Figure 2. Incident Scale/Public Preparedness Diagram

The Information Sharing Framework (ISF)2 is a pragmatic approach to this diversity by envisioning an “integration layer” that will consume, standardize, prioritize, and analyze data from a variety of sources and publish the appropriate information to end users in the necessary format with the right priority in a near real time manner. The ISF looks at this data exchange wholistically from the data source/owner to the end user. The ISF is envisioned to be a collection of standards, policies, and technologies that enable the exchange of information among different NS/EP, including public safety and critical infrastructure systems.

The concept is a “layered” approach, depicted in Figure 3 below, for disparate data to be transported via networks to an integration layer that performs five functions: data discovery, data secure access, data exchange, data analytics and data transport. Of these five functions, discovery, access, exchange and transport are common/standards-based methodologies and solutions. The analytics function may be custom/proprietary. The vision of this technical POC is to integrate technologies via interoperable interfaces on a service platform that enable seamless data flow between disparate sources and end users across a variety of networks with the appropriate content and priority. Phase 1 of the ISF Proof of Concept will focus on the Discovery, Data Exchange, and Identity Management (common functions) of the integration layer. Phase 2 will focus on analytics (custom function) of the integration layer. Both phases will address the transport function as it relates to the relevant functions of each phase.

Figure 3. Information Sharing Framework Diagram with 5 Functions

2 For additional information, please see CISA’s “Approach for Developing an Interoperable Information Sharing Framework” report. https://www.cisa.gov/sites/default/files/video/21_0929_cisa_approachfordeveloping_isf_v3_508_0.pdf https://www.cisa.gov/sites/default/files/video/21_0929_cisa_approachfordeveloping_isf_v3_508_0.pdf

SCOPE. The scope of this effort is defined in 2 Phases, detailed later in this document. , A high-level summary of the holistic effort is to:

1. Prove the concept of the ISF approach is technically feasible first in a laboratory setting (laboratory NOT provided by Government), then into a relevant (operation like) environment. The approach shall encompass all 5 functions of the integration layer and transport information to and from the other layers. The approach shall also incorporate both physical and cybersecurity, network priority, and interoperability. Additionally, the approach shall represent stakeholders, infrastructure, and data types. Finally, the approach should consider ease of use and be intuitive from user point-of-view. The users will be National Security and Emergency Preparedness (NSEP) personnel3 including public safety and critical infrastructure personnel at various levels of government as shown in Figure xx below.

2. Assess the necessary scale of such an integration layer capability or demonstrate a dynamic approach to scalability. The capability must scale to the magnitude of the incident or event. DHS has established a tiered, 4-level event scale: Local Event (0-2 Hours to resolution), Regional Event (2-24 Hours to resolution), Statewide Event (Days for resolution), and National Event (Weeks for resolution). As a result, the service platform needs to be able to scale up to, and be accessible, nationwide.

3. Define the potential roles of the 5G ecosystem participants in the ISF approach including telecommunications infrastructure service providers, cloud providers, application platform providers, and data harvesters.

4. Define the potential role of a trusted interconnection in secure data exchange in a software defined-wide area network (SD-WAN) capability implementation.

5. Demonstrate how the ISF approach can be operationalized as a service platform with Key Performance Parameters (KPPs) and identify those potential KPP’s and specify values.

6. Demonstrate the ability to monitor and track KPPs in the capability from end-to-end between emergency communications users on different broadband service provider and cloud partner networks and infrastructure end-to-end.

7. Determine if and how the approach can be adopted, scaled, and deployed by the industry participants.

8. Determine resources required by users to access, utilize, and share information via the service platform with other users in separate organizations.

9. Determine how the service platform can be intuitively accessed and utilized by users with the ability to request/pull data into their presentation layer device in a timely and accurate manner.

10. Compile findings and document the ISF approach and capability in a technical report with appropriate sections/appendices to address the various components.

PERFORMANCE OBJECTIVES. The ISF is intended to provide secure, prioritized, and interoperable exchange of information (including disparate data sets and applications) for NS/EP personnel including during emergency events. As the name implies, the ISF is a framework that should be able to be applied in a variety of settings to facilitate information flows for NS/EP personnel by assembling the right set of technological resources for the types of data content that already resides at various agencies and entities.

The requirement is not necessarily to develop new custom applications and solutions. The envisioned capability developed under this proof of concept is about leveraging existing standards, interfaces, data dictionaries, and technologies, whenever possible, to facilitate information sharing during emergencies. It may also require the assembly of a collaborative team of proposal partners who bring the requisite integration layer capabilities along with a sufficient laboratory environment to develop and test the capability.

4 For more information on Trustmark, please visit https://trustmarkinitiative.org/specifications/trustmark-framework/ https://trustmarkinitiative.org/specifications/trustmark-framework/

PROJECT OBJECTIVES.

Certain project level objectives apply to all phases of the effort. To keep this SOO concise, these objectives are listed once, instead of repeating them in each of the phase objective sections. The following objectives are applicable to all phases of the ISF Proof of Concept.

The ISF integration layer service platform solution must:

1. Always be available for use, with little to no down-time, and resilient to failures/outages.

2. Be able to handle a high volume of traffic and maintain high performance, even under peak load conditions.

3. Be able to support high-speed, low latency “real-time” data transfer.

4. Implement appropriate security measures to prevent cyberattacks and unauthorized access to sensitive information.

5. Comply with the current versions of NIST 800-53, NIST 800-55, NIST 800-171, NIST Risk Management

Framework, DHS Policy Directive 4300A, and other applicable standards.

6. Protect the confidentiality, integrity, and availability of the information exchanged.

7. Be secure and protect sensitive information from unauthorized access, modification, and disclosure.

8. Protect the privacy of individuals and ensure that personal information is only used for authorized purposes.

9. Allow agencies to share information with each other, even if the agencies use different networks, systems, technologies, or are in different jurisdictions, such as different cities, counties, and states.

10. Be able to access the information sharing framework from mobile devices/IoT, such as smartphones and tablets, as well as laptop and desktop computers.

11. Be standards-based by complying to recognized and widely adopted standards and protocols, such as 3GPP, NG911, NENA i3, NIEM, etc.

12. Consider innovation in the in-scope development and execution of the ISF proof of concept and must report to the government requirements that current limit such innovation.

13. Work in concert with existing and future priority services provided by wireline and wireless broadband service providers for voice, data services, video services, and information services as defined in Figure 4 below.

Figure 4. NS/EP prioritized Data, Video, and Information Services (DV&IS)

14. Work in concert nationwide across the conceptual architecture shown below in Figure 5 for NS/EP personnel.

Figure 5. NS/EP priority services architecture conceptual view

The ISF solution should also be:

1. Able to integrate with other IP-enabled NSEP, including public safety and critical infrastructure, systems such as GIS, video, computer-aided dispatch (CAD), records management systems (RMS), and NG-911 call centers systems.

2. User-centric and user-driven, considering the needs, preferences, and feedback of the end-users, and involves them in the design, development, testing, and evaluation of the ISF capability. The ISF must also be easy and intuitive to use for the user.

3. Modular, flexible, and scalable, such that it can be adapted to accommodate future technologies, innovations, and requirements as well as adapt to different levels of complexity, functionality, and interoperability, depending on the needs and capabilities of the users.

4. Able to collect and aggregate data from various sources, such as sensors, devices, applications, databases, etc., and provide a common data model and format for information exchange.

5. Able to disseminate and visualize the processed data using various methods, such as dashboards, maps, reports, etc., and provide a user-friendly interface for accessing and interacting with the information.

6. Able to establish and enforce rules and policies for data ownership, quality, retention, sharing, etc., and ensure accountability and transparency for data usage.

7. Cost-effective and sustainable, such that it can leverage existing COTS solutions, infrastructure, and resources, that will minimize duplication and redundancy, and maximize return on investment, and ensures long-term maintenance and support.

8. Able to enforce minimum performance requirements regarding jitter, delay, retransmission attempts or other similar transport layer requirements for users with limited bandwidth entry points.

9. Architected and built such that, to the extent possible, it is a “plug and play” platform with a variety of data sources and presentation applications.

BASE PERIOD (PHASE 1) OBJECTIVES (24 months) The base period (Phase 1) of the ISF Proof of Concept will focus on the Discovery, Data Exchange, and Identity Management common functions of the integration layer, as well as the transport function as it relates to the other common functions. The following objectives are specific to Phase 1.

1. Establish lab or provide existing lab or labs that adequately represent challenges of interoperability among various stakeholders, infrastructure, carrier service priority, and data types of potential ISF service platform users including differences in service providers, cloud providers, platform providers, and software instances.

a. Service provider is defined as a nationwide wireless broadband service provider providing commercially available priority mobile voice, video, data services and access to the internet via wireless access technologies including 4G, 5G, and Wi-Fi.

b. Cloud provider is defined as an IT company partnered with a service provider as described above and providing on-demand, scalable computing resources like computing power, data storage, or applications over the internet.

All nationwide wireless broadband service providers in moving towards greater virtualization and cloud computing in their networks as they deploy stand-alone 5G cores are partnering with cloud providers.

c. Platform provider is defined as a cloud provider offering Platform as a Service (PaaS) such as virtual servers or could be an IT hardware and software provider upon which the ISF service platform can be based upon and deployed in hybrid service provider and cloud provider networks and between networks (for example in an SD- WAN topology).

2. Define potential roles of 5G ecosystem players (SP, cloud, and platform) detailed in the Operating Constraints section below.

3. Document the ISF lab architecture and various components.

4. Establish role of trusted interconnection in secure data exchange in an SD-WAN implementation—see NS/EP priority services architecture conceptual view in Figure 5 in Purpose section of SOO.

5. Define the baseline of configuration of the ISF service platform proof of concept and iteratively re-baseline as additional capabilities and functional areas are added.

a. Initial Baseline at integration of Data Discovery Integration Layer function

b. Re-baseline at integration of Data Exchange Integration Layer function

c. Re-baseline at integration of Identity Management Integration Layer function. Integration of the Identity

Management Integration Layer function should include use of a federated identity, credential, and access management (ICAM) and consider leveraging of existing development like Trustmark4 5 6 for public safety use.

6. Successfully test baseline configuration for interoperability, functionality, and performance of the ISF capability with each re-baselining.

7. Successfully test between service providers and cloud partners for high bandwidth content such as video and low latency content potentially via federated network slicing

8. Successfully test ISF service platform architecture to ensure it meets the Operating Constraints section below.

9. Demonstrate potential blueprint for a clear ISF service platform governance structure including hypothetical representatives from all stakeholder roles and how tools or suite of tools would be utilized by users.

10. Demonstrate system controls that incorporates potential policies and procedures that would be in place to govern the use of an operational ISF service platform, addressing such issues as data ownership, data retention, and privacy and what tools would be needed for users to address these issues.

11. Monitor and track KPPs end-to-end between users on different hybrid service provider and cloud provider networks.

12. Recommend priority marking methodology of content, such as application-layer “priority marker” (e.g., HTTP/HTTP 2.0) in non-IMS-based networks for interoperability and Differentiated Services Code Point (DSCP) configuration, for transport function across cloud infrastructure.

13. Foster commercial wireless service provider adoption and scalability as part of existing interoperable and prioritized voice, data, video, and information services.

14. The contractor shall provide Project Management support services to ensure that required reporting is submitted and that the contract tasks are successfully completed.

4 For more information on Trustmark, please visit https://trustmarkinitiative.org/specifications/trustmark-framework/ 5 More information about Trustmark development and pilots by the Georgia Tech Research Institute (GTRI) can be found at https://trustmark.gtri.gatech.edu/technical-framework/ 6 To access the Trustmark code, please visit https://github.com/Trustmark-Initiative https://trustmarkinitiative.org/specifications/trustmark-framework/ https://trustmark.gtri.gatech.edu/technical-framework/ https://github.com/Trustmark-Initiative

OPTION PERIOD (PHASE 2) OBJECTIVES. (12 months)

1. Maintain operation of lab or labs that adequately represent challenges of interoperability among various stakeholders, infrastructure, carrier service priority, and data types of potential ISF users including differences in service providers, cloud providers, platform providers, and software instances.

2. Develop and deploy analytics integration layer function into the ISF service platform proof of concept.

a. Reconcile disparate data sets and making information interoperable from different sources and deploying these capabilities as a service platform with security, priority, and interoperability between users on different service provider networks.

b. Transform raw data in actionable, presentable material (e.g., manipulation from integration to presentation layers).

c. various layers of data integration, as well as capabilities regarding data cleaning, filtering, aggregation, and manipulation.

d. data at rest, pass through transport services, LE sensitive data, etc.

3. Re-baseline of configuration of the ISF proof of concept at integration of Analytics Integration Layer function.

4. Determine where cloud computing and virtual functions reside in a hybrid wireless 4G/5G service provider and cloud provider architecture to enable interoperable data exchange.

5. Determination feasibility of ISF service platform deployable architecture-as-service or as service and tools or suite of tools provided to users.

6. Define the role of Artificial Intelligence (AI) in the analytics integration layer function.

a. Consider processing and analyzing the collected data using artificial intelligence, machine learning, analytics, etc., and provide actionable insights, alerts, recommendations, etc., to the users.

b. Provide what data was used to train the AI and what method was used to verify the validity, accuracy, and relevance to NSEP users.

7. The contractor shall provide Project Management support services to ensure that required reporting is submitted and that the contract tasks are successfully completed.

OPERATING CONSTRAINTS.

• To prove technical feasibility, the ISF Proof of Concept shall meet the following constraints:

o At least 1 lab or operational environment with connections to two or more service provider production labs which adequately represent an operational ISF scenario - see NS/EP priority services architecture conceptual view in Figure 5.

laboratory is interconnected with two or more wireless 4G/5G broadband and cloud partner service provider labs staged with production ready infrastructure mirroring the architecture, configuration, and topology (at reduced scale) which is deployed in the service provider(s) network(s).

o At least two (2) nationwide wireless 4G/5G broadband service providers o At least two (2) cloud providers which are partnered with above two (2) broadband service providers.

o At least one (1) platform provider product or service which can be deployed with selected service providers and cloud providers.

o At least two (2) data providers of information on two (2) different nationwide wireless 4G/5G broadband service providers.

o At least two (2) data consumers/users of information on two (2) different nationwide wireless 4G/5G broadband service providers. Each of these data consumers/users must be able to view the data in at least two (2) situational awareness applications and on both a smartphone and laptop.

o At a minimum, two (2) disparate data sets from each of the type of data types shall be received from the data layer and published to the presentation layer. Examples of commonly used data type formats are in Figure 6 below.

Figure 6. Common Formats by Data Type Category o Consumable data must be published into the presentation layer in two or more situational awareness applications and in at least three standardized formats.

o Leverage existing standards, technologies, and infrastructure, including, but not limited to, 3rd Generation Partnership Project (3GPP), Next Generation 911 (NG911), National Emergency Number Association (NENA) i3, National Information Exchange Model (NIEM), IEEE, etc.

DELIVERABLES.

Objective Deliverable/Milestone Description Completion Date

PHASE I (BASE PERIOD)

1. Establish lab setup or provide existing lab

1.1 Kickoff Meeting Establish lab or provide

existing lab or labs that adequately represent challenges of interoperability among various stakeholders, infrastructure, carrier service priority, and data types of potential ISF service platform users including differences in service providers, cloud providers, platform providers, and software instances.

2 weeks from date of award

1.2 Develop project plan

and schedule.

2 months award

1.3 Identify and establish

lab setup.

3 months from date of award

2. Roles of 5G Ecosystem Players

2.1 Report identifying

roles / responsibilities of 5G ecosystem players.

Define potential roles of 5G ecosystem players (SP, cloud, and platform) detailed in the Operating Constraints section below.

12 months award

3. ISF Lab Architecture

3.1 System Architecture

Design Document.

Document the ISF lab architecture and various components.

24 months from date of award

4. Role of trusted interconnection in secure data exchange in an SD-WAN implementation

4.1 Production Readiness

Review ensuring trusted interconnection is secure.

Establish role of trusted interconnection in secure data exchange in an SD-WAN implementation.

24 months award

5. Baseline configuration definition ISF service platform PoC

5.1 Lab configuration

report and connectivity to service provider lab

Define the baseline of configuration of the ISF service platform proof of concept and iteratively re-baseline as additional capabilities and functional areas are added.

12 months award

Video Audio Image Geographic Sensor Text-based Database

H.264 MPEG-3 PNG ArcGIS JSON JSON NIEM

MPEG-4 WAV GIF ? XML XML EIDO

6. Test configuration for interoperability, functionality, and performance of the ISF capability

6.1 Test & Evaluation

(T&E) Document containing test Plans with test cases, KPPs, and pass/fail criteria.

Successfully test baseline configuration for interoperability, functionality, and performance of the ISF capability with each re-baselining.

Throughout

6.2 Test Results Report

7. Conduct testing between service providers and cloud partners

7.1 Test & Evaluation

(T&E) Document containing test Plans with test cases, KPPs, and pass/fail criteria.

Successfully test between service providers and cloud partners for high bandwidth content such as video and low latency content potentially via federated network slicing.

award

7.2 Test Results Report

8. Conduct Testing of ISF service platform to validate operating constraints

8.1 Test & Evaluation

(T&E) Document containing test Plans with test cases, KPPs, and pass/fail criteria.

Successfully test ISF service platform architecture to ensure it meets the Operating Constraints section below.

24 months from date of award

8.2 Test Results Report

9. Develop and demonstrate ISF Service Platform Blueprint

9.1 Deliver ISF technical

blueprint that examines utilization of ISF service platform by end users.

Demonstrate potential blueprint for a clear ISF service platform governance structure including hypothetical representatives from all stakeholder roles and how tools or suite of tools would be utilized by users.

award

9.2 Demonstration and

Operational Readiness Assessment.

10. Demonstrate system controls

10.1 Integration &

Deployment Plan outlining plan of action for implementing security controls.

Demonstrate system controls that incorporates potential policies and procedures that would be in place to govern the use of an operational ISF service platform, addressing such issues as data ownership, data retention, and privacy and what tools would be needed for users to address these issues.

award 10.2 Privacy Compliance Report detailing constraints & limitations of the information exchanged.

11. Monitor & Track KPPs end-to-end

11.1 Test & Evaluation

(T&E) Document containing test Plans with test cases, KPPs, and pass/fail criteria.

Monitor and track KPPs end-to-end between users on different hybrid service provider and cloud provider networks.

11.2 Test Results Report.

12. Recommend priority marking methodology

12.1 Report detailing

recommended priority marking methodology.

Recommend priority marking methodology of content, such as application-layer “priority marker” (e.g., HTTP/HTTP 2.0) in non-IMS-based networks for interoperability and Differentiated Services Code Point (DSCP) configuration, for transport function across cloud infrastructure.

award

13. Encourage adoption and scalability of ISF service platform

13.1 Final Technical

Report (Phase I).

Foster commercial wireless service provider adoption and scalability as part of existing interoperable and prioritized voice, data, video, and information services.

award 13.2 Recommendations and transition plan to industry.

• Next Steps

• ISF as a Service Platform

• Tools required to work with ISF service platform.

• Standards / Governing organizations

14. Program Management

14.1 Develop project plan

and schedule.

The contractor shall provide Project Management support services to ensure that required reporting is submitted and that the contract tasks are successfully completed.

14.2 Monthly Status

Meeting and Report.

Objective Deliverable/Milestone Description Completion

Date

PHASE II (OPTION PERIOD)

1. Maintain Lab Operations

1.1 Update the project

plan and schedule.

(Option Period)

Maintain operation of lab or labs that adequately represent challenges of interoperability among various stakeholders, infrastructure, carrier service priority, and data types of potential ISF users including differences in service providers, cloud providers, platform providers, and software instances.

Ongoing

2. Develop and deploy analytics integration layer

2.1 Updated the

Integration & Deployment Plan outlining deployment of integration layer function into ISF PoC.

Develop and deploy analytics integration layer function into the ISF service platform proof of concept:

a. Reconcile disparate data sets and making information interoperable from

TBD

2.2 Re-Demonstration

and Operational Readiness Assessment of integration layer function.

different sources and deploying these capabilities as a service platform with security, priority, and interoperability between users on different service provider networks.

b. Transform raw data in actionable, presentable material (e.g., manipulation from integration to presentation layers).

c. Various layers of data integration, as well as capabilities regarding data cleaning, filtering, aggregation, and manipulation.

D. Data at rest, pass through transport services, LE sensitive data, etc.

3. Re-baseline configuration of ISF PoC

3.1 Updated

Configuration report assessing Analytics Integration Layer Function.

Re-baseline of configuration of the ISF proof of concept at integration of Analytics Integration Layer function.

4. Cloud provider architecture analysis

4.1 4G/5G/Cloud Service Provider Architecture Design Document.

Determine where cloud computing and virtual functions reside in a hybrid wireless 4G/5G service provider and cloud provider architecture to enable interoperable data exchange.

4.2 Updated Report on

Recommendations and findings specifying where cloud computing and virtual functions reside in a hybrid wireless 4G/5G service provider.

5. Feasibility Determination

5.1 Test reports proving

technical feasibility of

ISF.

Determination of feasibility of ISF service platform deployable architecture-as-service or as service and tools or suite of tools provided to users.

5.2 Final Technical

Report (Phase II) assessing feasibility of ISF service platform deployable architecture.

6. Define role of AI in analytics integration layer function

6.1 Final Technical

Report (Phase II).

Define the role of Artificial Intelligence (AI) in the analytics integration layer function.

a. Consider processing and analyzing the collected data using artificial intelligence, machine learning, analytics, etc., and provide actionable insights, alerts, recommendations, etc., to the users.

6.2 Recommendations

and transition plan to industry (Phase II):

• Next Steps

• ISF as a Service Platform

• Tools required to work with ISF service platform.

• Standards / Governing organizations

b. Provide what data was used to train the AI and what method was used to verify the validity, accuracy, and relevance to NSEP users.

7. Project Management

7.1 Update project plan

and schedule.

The contractor shall provide Project Management support services to ensure that required reporting is submitted and that the contract tasks are successfully completed.

Throughout

7.2 Monthly Status

Meeting and Report.

PERIOD OF PERFORMANCE. The anticipated base period of performance for this statement of objectives is 24 months. There is an additional option period of 12 months.

PLACE OF PERFORMANCE. Work under this project shall be performed within the contiguous United States (CONUS) unless the prior written approval of the Contracting Officer is sought and obtained by the performer.

GOVERNMENT FURNISHED PROPERTY. No government furnished property will be provided for this project unless expressly stated in contract. In such instances, DHS will maintain property records. It is expected that the selected team will have the necessary laboratory equipment to adequately design, develop, and test the capability.

Before purchasing any individual item equal to or exceeding $5,000 that is required to support technical tasks performed pursuant to this effort, the performer shall obtain the DHS S&T Contracting Officer’s prior written consent. If the DHS S&T Contracting Officer consents to such purchase, such item shall become the property of DHS. The performer will maintain any such items according to currently existing property accountability procedures. The DHS S&T Contracting Officer will determine the final disposition of any such items in writing.

S&T Privacy Compliance.

The Department has determined that contractor and/or subcontractor access to CUI shall be limited to U.S. citizens and lawful permanent residents. No foreign nationals shall be allowed unescorted access to a Government facility, access to CUI, or access to DHS information systems without a favorable EOD decision or Contractor fitness (suitability) determination by the DHS Office of Security.

The goal of the ISF is to facilitate exchange of relevant data from various sources for uses such as identifying a person, their location, or other information during an emergency incident. Given this context, a fully operational ISF would most certainly handle PII including, but is not limited to, name, address, vehicle information, or other personal information that may contribute to a more effective emergency response by first responders. That information is required for first responders to address the needs of the call more effectively.

As a proof of concept, this R&D procurement effort will utilize test/dummy PII to prove the technical feasibility of the ISF service platform. To prove the technical feasibility of the ISF proof of concept, the contractor will be transporting synthetic data through the ISF. This will test that the ISF works as intended, and that the proper capabilities exist to address needs during various emergency situations. This work will be conducted in a laboratory setting with operational features and constraints, and then a prototype in an operational environment. The use of dummy PII aligns with generally accepted industry practices for dev and test environments. As such, DHS S&T does not intend to or anticipate contractor(s) and/or consultant(s) to require access to any IT systems needed to input, store, process, output, and/or transmit sensitive information or PII nor does it intend to utilize PII at this time.

There exists potential for the performer to utilize real PII as this capability is further developed. In the event the use of actual PII is necessary, the contractor employees shall safeguard this information against unauthorized disclosure or dissemination in accordance with the law and Government policy and regulation, as well as contact S&T’s privacy office.

Currently, DHS does not require the contractor to retain CUI for the Government. However, should this change, DHS will monitor and ensure contractor compliance with the retention and security requirements identified in the acquisition.

CONTRACT STAFFING

As mentioned earlier, the holistic scope of the ISF service platform will require solutions from software and hardware platform providers, wireless broadband service providers, and cloud computing services providers. In addition, personnel from various disciplines such as IT, cellular, AI/ML, and cybersecurity will be required. As a result, teaming agreements are highly encouraged including with universities/interoperability institutes and system integrators that may already be operating labs with provider infrastructure or with connectivity to provider production labs.

KEY PERSONNEL.

The performer shall provide qualified personnel to perform all objectives specified in this SOO. Certain roles of this effort are critical to its success, and therefore, have been designated as Key by the Government. The performer shall provide the name and qualifications of proposed Key personnel as part of their response to this SOO.

Personnel provided by the respondents will have the skills and technical background necessary to successfully complete the tasks described in this plan. The respondents shall implement and manage the technical approach, organizational resources, management, and quality controls to be employed to meet the cost, performance, and schedule requirements throughout task order execution.

The following personnel are designated as Key for this effort; however, the Government reserve the right to designate additional personnel roles as Key after award.

1. Program Manager

a. Absorb, organize, and communicate large quantities of information in a fast-paced environment in a clear, concise, and accurate manner.

b. Keep informed of the mission, organizational structure, key personnel, current activities, status of current projects, and any issues affecting the organization.

c. Communicate with senior staff, customers, and other staff in a manner that is clear, concise, succinct, and professional.

d. Manage a variety of functions simultaneously and with flexibility to work under competing demands and deadlines.

e. Operate independently and work collaboratively in a team environment.

f. Proficiency in Microsoft Office products including Microsoft Teams and PowerPoint

2. Technical Lead/System Architect

a. Network architecture design

b. Cellular/wireless broadband technology expertise

c. Cloud computing

d. Standards

e. Test and evaluation

Before replacing any individual designated as Key by the Government, the performer shall notify the Contracting Officer no less than 14 business days in advance, submit written justification for replacement, and provide the name and qualifications of any proposed substitute(s). All proposed substitutes shall possess qualifications equal to or superior to those of the Key person being replaced, unless otherwise approved by the Contracting Officer. The performer shall not replace Key personnel without approval from the Contracting Officer.

APPLICABLE DOCUMENTS OR REFERENCES.

1. CISA’s Approach for Developing an Interoperable Information Sharing Framework7

2. SAFECOM’s Interoperability Continuum8

3. SAFECOM Resources9

4. NCSWIC 2023 Strategic Plan10

5. NIST: Public Safety Use Cases11

6. Trustmark12 13 14 Documentation

7. NENA i3

8. National Information Exchange Model

9. NIST 800-53

10. NIST 800-55

11. NIST 800-171

12. NIST Risk Management Framework

13. DHS Policy Directive 4300A

INTELLECTUAL PROPERTY.

All deliverables for this contract should be treated as the intellectual property of the Department of Homeland Security, unless otherwise informed by the Contracting Officer and/or Contracting Officer Representative.

PROPERTY DISPOSAL.

Before purchasing any individual item equal to or exceeding $5,000 that is required to support technical tasks performed pursuant to this SOO, the performer shall obtain the DHS S&T Contracting Officer’s prior written consent. Property associated or purchased for this contract shall be the property of DHS but be managed and maintained by the performer (where applicable) following DHS property accountability regulations. The DHS S&T Contracting Officer will determine the final disposition of any such items in writing. For the non-accountable property acquired under this contract material may be disposed of in place with the vendor at the discretion of the DHS S&T Contracting Officer.

7 CISA’s “Approach for Developing an Interoperable Information Sharing Framework” report can be found here:

https://www.cisa.gov/sites/default/files/video/21_0929_cisa_approachfordeveloping_isf_v3_508_0.pdf

8 SAFECOM’s Interoperability Continuum can be found here: https://www.cisa.gov/sites/default/files/2022- 12/21_0615_cisa_safecom_interoperability_continuum_brochure_final.pdf 9 SAFECOM Resources can be found here: https://www.cisa.gov/safecom/resources 10 NCSWIC 2023 Strategic Plan can be found here: https://www.cisa.gov/sites/default/files/2023-05/23_0406_ncswic_2023_ncswic-strategic-plan_20230324_508C.pdf 11 NIST’s Public Safety Use Cases can be found here: https://pages.nist.gov/PublicSafetyUseCases/introduction.html 12 For more information on Trustmark, please visit https://trustmarkinitiative.org/specifications/trustmark-framework/ 13 More information about Trustmark development and pilots by the Georgia Tech Research Institute (GTRI) can be found at https://trustmark.gtri.gatech.edu/technical-framework/ 14 To access the Trustmark code, please visit https://github.com/Trustmark-Initiative https://www.cisa.gov/safecom/resources https://www.cisa.gov/sites/default/files/2023-05/23_0406_ncswic_2023_ncswic-strategic-plan_20230324_508C.pdf https://www.cisa.gov/sites/default/files/2023-05/23_0406_ncswic_2023_ncswic-strategic-plan_20230324_508C.pdf https://pages.nist.gov/PublicSafetyUseCases/introduction.html https://trustmarkinitiative.org/specifications/trustmark-framework/ https://trustmark.gtri.gatech.edu/technical-framework/ https://github.com/Trustmark-Initiative

ENTERPRISE ARCHITECTURE (EA) COMPLIANCE.

All solutions and services shall meet DHS Enterprise Architecture policies, standards, and procedures. Specifically, the performer shall comply with the following HLS EA requirements:

• All developed solutions and requirements shall be compliant with the HLS EA.

• All IT hardware and software shall be compliant with the HLS EA Technical Reference Model (TRM) Standards and Products Profile.

• Description information for all data assets, information exchanges and data standards, whether adopted or developed, shall be submitted to the Enterprise Architecture Division (EAD) for review, approval and insertion into the DHS Data Reference Model and Mobius.

• Development of data assets, information exchanges and data standards will comply with the DHS Data Management Policy MD 103-01 and all data-related artifacts will be developed and validated according to DHS data management architectural guidelines.

• Applicability of Internet Protocol Version 6 (IPv6) to DHS-related components (networks, infrastructure, and applications) specific to individual acquisitions shall be in accordance with the DHS Enterprise Architecture (per OMB Memorandum M-05-22, August 2, 2005) regardless of whether the acquisition is for modification, upgrade, or replacement. All EA-related component acquisitions shall be IPv6 compliant as defined in the U.S. Government Version 6 (USGv6) Profile (National Institute of Standards and Technology (NIST) Special Publication 500-267) and the corresponding declarations of conformance defined in the USGv6 Test Program.

CYBER SUPPLY CHAIN RISK MANAGEMENT (C-SCRM).

a. Definitions

i. End-of-Life (EOL): means that an ICT product has reached the final stage of the product life cycle in which that version of the ICT product will no longer be supported nor manufactured (e.g., no patches will be developed, no security improvements will be made, and, sometimes, no troubleshooting technical assistance will be offered).

ii. ii. End-of-Support (EOS): means that an ICT product will no longer be supported (e.g., no patches will be developed, no security improvements will be made, and, sometimes, no troubleshooting technical assistance will be offered).

iii. Information and communications technology (ICT): encompasses the capture, storage, retrieval, processing, display, representation, presentation, organization, management, security, transfer, and interchange of data and information; includes all categories of ubiquitous technology used for the gathering, storing, transmitting, retrieving, or processing of information (e.g., microelectronics, printed circuit boards, computing systems, software, signal processors, mobile telephony, satellite communications, and networks).

iv. Product: part of the equipment (hardware, software and materials) for which usability is to be specified or evaluated.

b. The Offeror understands and agrees that the Government retains the right to cancel or terminate the Contract, if the Government determines that continuing this solicitation presents an unacceptable risk to national security.

c. “Gray-Market” Equipment

i. The Offeror shall provide only new equipment unless otherwise expressly approved, in writing, by the DHS

Contracting Officer. Offerors shall provide only Original Equipment Manufacturer (OEM) parts to the Government. In the event that a shipped OEM part fails, all replacement parts must be OEM parts.

ii. The Offeror shall be excused from using new OEM (i.e., "gray market”, "previously used”) components only with formal Government approval, in writing, from the DHS Contracting Officer. Such components shall be procured from their original source and shipped only from the manufacturer’s authorized shipment points.

iii. All equipment obtained by the Offeror on behalf of the Government will need to be provided to OIG OCIO for review to validate requirements and approved Contractors by DHS.

d. Hardware and Software Requests

i. The contractors supply the Government hardware and software will provide the manufacturer’s name, address, state, and/or domain of registration, and the DUNS number for all components comprising the hardware and software. If subcontractors or subcomponents are used, the name, address, state, and/or domain of registration and DUNS number of those suppliers must be provided.

ii. Subcontractors are subject to the same general requirements and standards as prime contractors. Contractors employing subcontractors will perform due diligence to ensure that these standards are met.

iii. The Government shall be notified when a new contractor/subcontractor/service provider is introduced to the supply chain, or when suppliers of parts or subcomponents are changed.

1. For software products, the Offeror shall provide all OEM software updates to correct defects for the life of the product (i.e., until the “End of Life (EoL)"). Software updates and patches shall be either: made available to the government for all products procured under this Contract, replaced upon End of Support (EoS) is reached, or formally waived (in writing) by the DHS Contracting Officer.

e. Supply-Chain Transport

i. Offerors shall employ formal and accountable transit, storage, and delivery procedures (i.e., the possession of the component is documented at all times from initial shipping point to final destination, and every transfer of the component from one custodian to another is fully documented and accountable) for all shipments to fulfill Contract obligations with the Government.

ii. All records pertaining to the transit, storage, and delivery will be maintained and available for inspection for the lessor of the term of the Contract, the period of performance, or one calendar year from the date the activity occurred.

iii. This transit process shall minimize the number of times in route components undergo a change of custody and make use of tamper-proof or tamper-evident packaging for all shipments. The supplier, at the Government's request, shall be able to provide shipping status at any time during transit.

iv. All records pertaining to the transit, storage, and delivery shall be readily available for inspection by any agent designated by the U.S. Government as having the authority to examine them.

v. The Offeror is fully liable for all damage, deterioration, or losses incurred during shipping and handling, unless the damage, deterioration, or loss is due to the Government.

vi. The Offeror shall provide a packing slip which shall accompany each container or package with the information identifying this solicitation number, the order number, a description of the hardware/software enclosed (Manufacturer name, model number, serial number), and the customer point of contact.

vii. The Offeror shall send a shipping notification to the intended government recipient; with a copy transmitted via email to the Contracting Officer, or designated representative. This shipping notification shall be sent electronically and will state this solicitation number, the order number, a description of the hardware/software being ship (manufacturer name, model number, serial number), initial shipper, shipping date and identifying (tracking) number.

f. Notifications

i. The Offeror shall notify DHS Contracting Officer, COR and the Office of the Chief Information Officer and the DHS component Chief Information Officer through the Enterprise Security Operations Center (ESOC) directly of any suspected or potential violations of Section 889 of the National Defense Authorization Act (NDAA) for Information Communications Technology (ICT) at NDAA_Incidents@hq.dhs.gov.

g. Foreign Equities

i. The Offeror shall immediately notify the DHS Contracting Officer, COR that will report to the Office of the

Chief Security Officer (OCSO) or cognizant component personnel security office regarding any changes to corporate foreign ownership, control, or influence.

ARTIFICIAL INTELLIGENCE / MACHINE LEARNING REQUIREMENTS.

a. Definitions:

i. Artificial Intelligence (AI) includes the following: (1) Any artificial system that performs tasks under varying and unpredictable circumstances without significant human oversight, or that can learn from experience and improve performance when exposed to data sets. (2) An artificial system developed in computer software, physical hardware, or other context that solves tasks requiring human-like perception, cognition, planning, learning, communication, or physical action. (3) An artificial system designed to think or act like a human, including cognitive architectures and neural networks. (4) A set of techniques, including machine learning, that is designed to approximate a cognitive task. (5) An artificial system designed to act rationally, including an intelligent software agent or embodied robot that achieves goals using perception, planning, reasoning, learning, communicating, decision making, and acting.

b. Requirements

i. The 2019 National Defense Authorization Act (NDAA) and Executive Order (EO) 13960 require that AI used in the Federal Government foster public trust and confidence while protecting privacy, civil rights, civil liberties, and American values. All federal employees, contractors, and subcontractors, when designing, developing, acquiring, and/or using AI for or within DHS, will adhere to the following 9 principles.

1. Lawful and respectful of our Nation's values:

Agencies shall design, develop, acquire, and use AI in a manner that exhibits due respect for our Nation's values and is consistent with the Constitution and all other applicable laws and policies, including those addressing privacy, civil rights, and civil liberties.

2. Purposeful and performance-driven:

Agencies shall seek opportunities for designing, developing, acquiring, and using AI, where the benefits of doing so significantly outweigh the risks, and the risks can be assessed and managed.

3. Accurate, reliable, and effective:

Agencies shall ensure that their application of AI is consistent with the use cases for which that AI was trained, and such use is accurate, reliable, and effective.

4. Safe, secure, and resilient:

Agencies shall ensure the safety, security, and resiliency of their AI applications, including resilience when confronted with systematic vulnerabilities, adversarial manipulation, and other malicious exploitation.

5. Understandable:

Agencies shall ensure that the operations and outcomes of their AI applications…