NOI_SOW.pdf

i

STATEMENT OF WORK

CENTER FOR DEVICES AND RADIOLOGICAL HEALTH (CDRH)

Table of Contents

1 Background

2 Objective

3 Scope

4 Tasks

4.1 Task One: Kickoff Meeting

4.2 Task Two: Dataset Tailoring and Integration

4.2.1 Subtask One: Test Dataset

4.2.2 Subtask One: Final Dataset

4.3 Task Three: Encryption, Automated Push, and Decryption

4.4 Task Four: Package Analysis Requests

5 Deliverables

5.1 Format Of Deliverables

5.2 Deliverables Submission Procedure

5.3 Summary Of Deliverables

6 Contract Type

7 Period Of Performance

8 Place of Performance

9 Holidays & Government Closures

Page #1

1 BACKGROUND

The Food and Drug Administration (FDA) is responsible for protecting the public health by assuring the safety, efficacy, and security of human and veterinary drugs, biological products, medical devices, our nation’s food supply, cosmetics, and products that emit radiation. The FDA is also responsible for advancing the public health by helping to speed innovations that make medicines and foods more effective, safer, and more affordable, and helping the public get the accurate, science-based information they need to use medicines and foods to improve their health.

The mission of the Center for Devices and Radiological Health (CDRH) is to protect and promote the public health. CDRH assure that patients and providers have timely and continued access to safe, effective, and high-quality medical devices and safe radiation-emitting products. We provide consumers, patients, their caregivers, and providers with understandable and accessible science-based information about the products we oversee. We facilitate medical device innovation by advancing regulatory science, providing industry with predictable, consistent, transparent, and efficient regulatory pathways, and assuring consumer confidence in devices marketed in the U.S.

Section 3305 of the Food and Drug Omnibus Reform Act of 2022 (“FDORA”), enacted on December 29, 2022, added section 524B “Ensuring Cybersecurity of Medical Devices” to the Federal Food, Drug, and Cosmetic Act (FD&C Act). Under section 524B(a) of the FD&C Act, a person who submits a 510(k), PMA, PDP, De Novo, or HDE for a device that meets the definition of a cyber device, as defined under section 524B(c) of the FD&C Act, is required to submit information to ensure that cyber devices meet the cybersecurity requirements under section 524B(b) of the FD&C Act, and to submit an associated Software Bill of Materials (SBOM) under section 524B(c) of the FD&C Act. For devices that are not cyber devices that nonetheless may be exposed to cyber risk, FDA recommends that SBOMs be included as part of their premarket submissions to help demonstrate a reasonable assurance of safety and effectiveness. An SBOM is a nested inventory that makes up a full listing of all of the software components (components, packages and libraries) which are part of a medical device (when applicable).

SBOMs are typically provided in a machine-readable format, and will be part of premarket submissions (510(k), premarket approval application (PMA), Product Development Protocol (PDP), De Novo, and Humanitarian Device Exemption (HDE)) for review. It will be imperative for the reviewers to have a way to easily determine if the software components associated with the device present risks that could impact the device’s safety, effectiveness, or cybersecurity, including whether the components have any known vulnerabilities.

Known vulnerabilities, risks, and exploitations are different than more typical anomalies or defects in devices in that they are largely unseen, and they can “appear” at any point in time based on the technology that is being used, including technology that may be added as the device is modified or maintained. The product can work perfectly throughout clinical trials and thereafter, but then tremendous adverse effects can be introduced with the exploitation of a single vulnerability all at once.

This could potentially impact all users of the device at once and cause multitudes of adverse events in a very short period of time.

2 OBJECTIVE

The Medical Device Cybersecurity Team (Cybersecurity Team) within the Food and Drug Administration’s (FDA) Center for Devices and Radiological Health (CDRH) is seeking to develop and implement a new process which will support data analysis and reporting, and provide detailed information on cybersecurity vulnerability, risk, and exploitation, which will inform reviewers and the Cybersecurity team of potential issues within devices that contain or otherwise leverage software, hardware, or firmware.

Page #2

To accomplish this goal, the objective of this requirement is to acquire a data subscription to a service, which reports known vulnerabilities, that can be compared to vulnerabilities discovered within our own data, as well as to determine the severity of said vulnerabilities.

Data on known vulnerabilities, risks, and exploitations are available through multiple sources, and are updated on a timely basis (typically daily) with the latest issues and concerns that have been identified.

These data will need to be integrated into the solution, allowing for the ability to consider risks across the total product lifecycle as well as to be able to accurately identify the software components which are vulnerable both within the vulnerability data as well as the SBOM files which the FDA receive.

3 SCOPE

CRDH seeks a data source which can provide an interconnected dataset to facilitate the automation of the automated SBOM analysis solution that CDRH is developing. This data source must provide an ongoing feedback loop of known vulnerabilities, risks, and exploitations, which are constantly being found (or added) within devices that contain or leverage software, hardware, or firmware. It must also include a comparator file (“alias file”) which the entity has developed. This file must include all the various permutations from predictive as well as logical modeling that a particular software component can be labeled as. Understanding that there are no specific identifiers required in the vulnerability data nor in SBOMs for a particular software component, this file is imperative for the comparisons to accurately occur. An example would be the alias for Windows 11, which can be listed in an SBOM as WIN11, Windows11, Windows 11, WIN 11, WINDWS 11, etc. The file required will create a standardization for each of these variations so the government can accurately identify the correct vulnerability if there is one in the datasets provided and compare it to the incoming SBOMs from manufacturers.

This contract will involve specialized and proprietary data which provides insights into vulnerabilities which exist within software components on a daily basis, as well as information on the severity of said vulnerabilities. Similarly, the alias information will be necessitated to help facilitate the matching protocols that CDRH will be developing.

4 TASKS

The contractor, though online data subscriptions and correspondences with government personnel, shall provide/accomplish the following:

4.1 TASK ONE: KICKOFF MEETING

Within five (5) business days after the effective date of the Order, the Contractor shall participate in a Kick-Off Meeting with the Technical POC, the COR, the CO, and other CDRH Staff. The Contractor shall provide meeting materials and agenda two (2) days prior to the Kick-off meeting.

The Contractor shall prepare summary meeting minutes, detailing the discussion held, and provide a copy of the minutes to the COR and the Technical POC within five (5) business days after the meeting.

4.2 TASK TWO: DATASET TAILORING AND INTEGRATION

The contractor shall begin by creating consumable test files, coordinating with CDRH personnel until they are presented in an acceptable form. Upon acceptance, the contractor shall provide a dataset that shall refresh daily to be delivered to the CDRH at least once every 24 hours.

4.2.1 Subtask One: Test Dataset

The contractor shall extract and transform their data format into a flat relational format consumable by the CDRH. Contractor will work with the CDRH to provide test files to ensure accuracy and reliability of data and react to any issues by rectifying the concerns.

Page #3

4.2.2 Subtask One: Final Dataset

Th contractor shall extract and transform their data format into a flat relational format consumable by CDRH. After CDRH approves test files and contractor finalizes data files a final dataset will be developed.

The final relational data format agreed upon will be refreshed and delivered to the FDA at least once every 24 hours.

4.3 TASK THREE: ENCRYPTION, AUTOMATED PUSH, AND DECRYPTION

An automatic encrypted flat relational database will be delivered to CDRH on a regular schedule (up to once every 24-hour period). An encryption key exchange will also be executed and instructions will be provided to decrypt the encrypted flat relational database for internal use.

4.4 TASK FOUR: PACKAGE ANALYSIS REQUESTS

An anonymous submission endpoint for CDRH to submit package requests for analysis. This analysis will be performed by the Contractor will then include requests subsequently packaged into the next available database update, extraction, encryption, and pushed and decrypted as soon as the analysis is complete.

5 DELIVERABLES

5.1 FORMAT OF DELIVERABLES

Documentation deliverables (both in draft and final versions) shall be provided in hard and soft copy using MS Office products as specified below. Weekly, interim, informal, and working-copy products may be provided by e-mail to the COR. Final soft copies of deliverables shall be developed using the current FDA version of Microsoft Office products and/or other standard application software Final hard copies of deliverables shall be typewritten on 8-1/2"x11" white paper. The Contractor shall not use spiral binding or other binding that interferes with photocopying.

Data deliverables will be delivered in the format as described above in the Tasks via the method agreed upon as detailed.

5.2 DELIVERABLES SUBMISSION PROCEDURE

The Contractor shall submit all documentation deliverables to the COR, unless otherwise stated. The COR will be responsible for the review of all draft and final deliverables to ensure accuracy, functionality, completeness, professional quality, and overall compliance with the guideline’s requirements of the task. The Contractor shall ensure the accuracy and completeness of all deliverables in accordance with referenced policy, regulations, laws, and directives. Reports and presentations shall be concise and clearly written; errors, misleading or unclear statements, incomplete or irrelevant information, and/or excessive rhetoric, repetition, and "padding,” or excessive length if a page limit is imposed, shall be considered deficiencies and will be subject to correction by the Contractor at no additional cost to the government. Unless specified otherwise, the government shall have ten (10) working days to complete the review and approve the deliverables. If deficiencies are found or areas require modification, the Contractor will be notified and shall have five (5) calendar days to correct the deficiencies. Upon re-submission by the Contractor, the government will reapply the same acceptance criteria. If the deliverable does not meet the acceptance criteria a second time, the government may consider the Contractor as having deficient performance with respect to the subject task.

5.3 SUMMARY OF DELIVERABLES

Table 1: Deliverables

Page #4

Task Deliverables Quantity/Frequency Due Date

4.1 Kickoff Meeting Notes Once Within (5) days of Kickoff Meeting

4.2.1 Dataset Tailoring and

Integration – Test Dataset

Recurring

Within (30) days of effective award date Subsequent fixes shall be returned within (10) business days of reported issue.

4.2.2 Dataset Tailoring and

Integration – Final Dataset

At least once every 24 hours

Within (20) business days of acceptance of format

After acceptance, ongoing daily

4.3 Automatic Encrypted Flat

Relational Database Recurring Ongoing

4.4 Package Analysis Recurring Ongoing

6 CONTRACT TYPE

Firm Fixed Price

7 PERIOD OF PERFORMANCE

The anticipated period of performance for this order is one (1) twelve (12) month BASE period with four

(4) twelve (12) month OPTION periods. The anticipated dates of performance are:

8 PLACE OF PERFORMANCE

Services shall be provided both on and off-premises.

9 HOLIDAYS & GOVERNMENT CLOSURES

The Contractor is not required to provide on-site services on the following days that are Federal Holidays or on any other day designated as a Federal holiday, Government closure, or shut-down for the Washington, D.C. area:

New Year's Day Martin Luther King Day President 's Day Memorial Day Juneteenth Independence Day Labor Day Columbus Day Veteran 's Day Thanksgiving Day Christmas Day

The Contractor shall not schedule training during federal holidays or Government closure. As necessary, training scheduled during unexpected Government closures may be rescheduled following coordination with the COR. The contractor shall not bill the Government for any training that the Contractor did not perform due to any Government closures.