Appendix A - Cybersecurity Evaluation Example Questions.pdf

Appendix A – Cybersecurity Evaluation Example Questions

The following is sample information typically needed for the Government’s cybersecurity assessment. Note many sections may be not applicable to your offering. The following example is for reference only to assist the offeror in understanding the types of information that the Government will require to successfully complete its cybersecurity evaluation as part of test and evaluation. You are not required to complete this information at the time of proposal.

Section 1: System Identification

MEDICAL DEVICE AND EQUIPMENT IDENTIFICATION – Technical and Regulatory

1.0 Medical Device/Equipment Title/Version:

Provide the naming convention for the medical device/equipment and primary application version.

1.1 Medical Device Description:

Provide a brief technical description of the medical device’s/equipment intended use/capability. If applicable, the FDA 510K

Summary Description should be used for accuracy.

1.2 Medical Device/Equipment Model:

List all devices/equipment and versions covered under this review (e.g. family of systems)

1.3 Product Suite/Family of Products

Indicate whether the medical device/equipment is marketed by any other model, brand names, trademark, or product suite/family. (e.g. Resellers)

1.4 Medical Device/Equipment Category:

Recommend use of ECRI Institute’s Universal

Medical Device Nomenclature System (UMDNS).

1.5 Primary Software Application Release/EOL

Date: Provide the software release and expected End of Life (EOL) dates of the Primary Software

Application. Also, indicate whether Extended

Support for the Primary Software Application is provided by the manufacturer. See DHA CyberLOG

Cybersecurity Acquisition Language

Release Date: EOL Date:

1.6 Food and Drug Administration (FDA

510K)/other Regulatory Certification, or

Premarket Authorization identifier, if applicable:

Provide the number associated with the medical device/equipment, if applicable.

https://www.ecri.org/

1.7 Department of Defense (DoD)/Defense Health

Agency (DHA) Authorization: State whether the proposed medical device/equipment has been or is currently undergoing the DoD/DHA Risk

Management Framework (RMF) Authorization process, and the corresponding eMASS record identifier. State the originating office conducting the

RMF efforts, as well as the Authorization

Termination Date (ATD).

ATD:

1.8 Baseline physical testing location: Indicate

whether an instance of the MDE installed at the manufacturer’s facility is available for RMF

Assessment. If such a system is available, provide complete street address.

1.9 Intended Mode of Operation:

Select the intended mode of operation of the medical device/equipment.

Standalone – Operates in complete isolation and thus does not require the use of networking protocols.

Peer to Peer – Operates in complete isolation but requires the use of networking protocols.

Client/Server – Operates as a distributed application that partitions task or workloads between the service requester (client) and the service provider (server) through the use of networking protocols.

Web-based – Operates as a distributed application that requires the use of a browser to access the primary application. There is no client software installed on the client workstation.

Host-based – Operates as a passive subsystem which requires connection a host computer to produce information. It may require the use of networking protocols.

Cloud-based – Operates within a cloud-service environment

Government Cloud Service Provider (e.g.

DISA, SPAWAR)

Commercial Cloud Service Provider (e.g.

Amazon Web Service)

1.10 Intended Method of Implementation:

Select the intended method of implementation of the proposed medical device/equipment.

System comprises Hardware + Software + Firmware

(traditional configuration)

System is Software Only in a Physical Environment

(requires hardware provided by the GOV)

System is Software Only in a Virtual Environment

(requires virtual environment)

Virtual Environment must be provided by the

Government

Government must provide all Operating

System/Database/Application Virtual

Servers.

Virtual Environment provided by the Vendor

1.11 Interfaces

Describe how the device connects to the network, or the intended mode for communications.

CONNECTION TYPE:

Serial over RS-232 RJ-45 Networked Serial to

RJ-45 Connection 802.11 Wireless

Other (Specify Connection Type Below)

1.12 Connected Systems

Describe the types of systems this will connect to, or communicate with. (i.e. PACS, Networked patient monitors, Stand Alone, EHR, etc.)

Section 2: Technical Information

2.0 SYSTEM HARDWARE/FIRMWARE

List all components required for the operation and clinical functionality of the device, to include all servers, workstations, routers, switches, etc.

SYSTEM CONFIGURATION MUST BE DESCRIBED IN ITS ENTIRETY. FAILURE TO DISCLOSE ALL

INFORMATION MAY CAUSE A BREACH OF CONTRACT.

Component Purpose Comments

Ex: Console Ex: Primary user interface Ex: Connected to the DoD Network

Ex: Switch

Ex: Internal switch to connect Console to other components Ex: Non-routable, not on DoD Network.

Ex: Reconstruction

Unit Ex: Reconstructs raw data, Ex: Not on DoD Network, connects to console over fiber.

Ex: Bore Ex: It’s a BIG magnet. Ex: Magnet that generates images.

2.1 OPERATING SYSTEMS

For each Component Listed in Section 2.0, List the Operating System (OS): Make sure to identify all instances regardless of platform (i.e. server, client, peer, standalone, and portable peripheral end point device), End of Life (EOL) date and intended operational environment (i.e., physical, virtual)

EACH COMPONENT FROM SECTION 2.0 MUST BE LISTED. FAILURE TO DISCLOSE ALL

INFORMATION MAY CAUSE A BREACH OF CONTRACT.

Component Operating System Service Pack

Level

End of Life

Date

Extended

Support

Virtualize d

Ex: Console Windows 10 No

Ex: Switch Cisco IOS No

Ex:

Reconstructio n Unit

Proprietary OS – Based on SUSE Linux No

Ex: Bore N/A – It’s a Magnet N/A N/A N/A N/A

2.2 INSTALLED APPLICATIONS

For each Component Listed in Section 2.0, List the Applications required for the System to operate/meet clinical requirements. Make sure to identify all instances regardless of platform (i.e. server, client, peer, standalone, and portable peripheral end point device), End of Life (EOL) date and why the software is required.

EACH COMPONENT FROM SECTION 2.1 MUST BE LISTED. FAILURE TO DISCLOSE ALL

INFORMATION MAY CAUSE A BREACH OF CONTRACT.

Component Application Versi on

End of

Life

Date

Purpose

Ex: Console

Primary

Application 1

04-

2022 Primary Application used for patient care.

Ex: Console SQL Express 1

10-

DB used to temporarily store images, no DBMS associated.

Ex: Switch N/A – Only IOS 1

02-

2008 N/A

Ex: Reconstruction

Unit

Reconstruction software 1

08-

2019 Application used to construct images

Ex: Bore N/A N/A N/A

2.3 Individually Identifiable User Accounts:

For each Component Listed in Section 2.0, describe the account types that are required for the system to operate. Are individual accounts for clinicians required for the application.

EACH COMPONENT FROM SECTION 2.1 MUST BE LISTED. FAILURE TO DISCLOSE ALL

INFORMATION MAY CAUSE A BREACH OF CONTRACT.

Describe how accounts are created (site setup accounts, vs vendor default) List all account types in the table below:

Component Account Type Admin

Account?

Application, OS, or DB?

Authentication

Method (PKI, UN/PWD, etc.)

Purpose

Ex: Console Clinician Account No Application Username/password

Individual accounts for each clinician setup by the site upon deployment

Ex: Console Admin Account Yes Application USB Token

Used by BMET to configure the devices

SYSTEM ARCHITECTURE DRAWING:

2.4 Medical Device Architecture Diagram: Provide a block diagram depicting all subsystems and components of the proposed medical system/device as configured in your proposal. Include connection specifications such as:

Ethernet Connection, Wireless Connection or Bluetooth Connection. You may include an embedded Microsoft

Visio diagram with your submission.

2.5: MIGRATION PATH

For any application, or Operating System listed above, with less than 24 months of support/extended support, describe the migration plan, or upgrade path to maintain compliance.

2.6 END POINT PROTECTION - ANTI-VIRUS / HOST BASED SECURITY SYSTEM (HBSS) / HOST-

BASED INTRUSION PREVENTION SYSTEM (HIPS)

a. Provide a summary describing if 3rd party/Government Furnished applications can be installed on the proposed medical device/equipment. (i.e. Antivirus, HBSS, monitoring agents (SPLUNK, TANIUM, etc.)

b. If validation is required prior to installation, describe the validation process.

c. If the system does not support these applications, does the system utilize a native White Listing program (or other technology) to effectively mitigate the vulnerabilities associated with not suppoting End Point Protection?

a.

b.

c.

Anti-virus/Anti-malware recommended best practices (if available) *List items which must be excluded from scanning below.

YES

NO

Antivirus/Antimalware Heuristics scanning supported?

Does the system provide notification of malware detection in the device user interface or through other mechanism (describe below)?

Does the system automatically update malicious code protection mechanisms? (If no, describe below how malicious code protection mechanisms are updated)

2.7 – VULNERABILITY SCANNING POLICY

Indicate limitations for the ability to run vulnerability scans (i.e. Nessus/ACAS scans) against the device.

MDE can be scanned in a test/vendor lab environment only.

No scanning capability at all (Serial/no networking capability)

MDE can be scanned in a live environment

Provide a summary describing if Network Vulnerability scans can be run against the device while in a live environment, and any limitations to the ability to scan the device in real time. (i.e. restrictions on running scans while conducting a study, system must be “de-hardened” and coordinated with the vendor prior to scanning, etc.).

If the MDE cannot be scanned in a live environment, but can be scanned in a vendor test lab, describe in detail the limitations to scanning within the live environment. (Impact to patient safety, etc.)

Are admin account passwords made available to the local IT departments to facilitate Fully

Credentialed Scans?

YES

NO

2.8 - VULNERABILITY MANAGEMENT/PATCHING POLICY

Provide a summary describing the plan for providing validated software updates and patches throughout the life cycle of the medical device/equipment. Include timeframes to approve patches, if critical OS patches can be installed without vendor permission. The summary should describe how the security patch is validated and then installed (e.g. remote installation by the vendor or distribution by the vendor for biomedical personnel at the healthcare organization to install.) The vendor should also specify the frequency of product updates.

2.9 REMOTE ACCESS

The software that provides the remote access capability must be included in the Application

Inventory. Examples of remote desktop software applications are Microsoft Remote Desktop

(MSRDP) and Secure Shell (SSH)

Yes No

Can the medical device be serviced remotely (i.e., through the use of a secure point to point encrypted network connection)

Can the device be configured to require the local use to accept or initiate remote access?

Does the device provide an explicit indication of use to users physically present at collaborative computing devices?

Does the device require unrestricted access to the Internet in order to provide remote access?

2.10 WIRELESS CAPABILITIES

(IEEE 802.11)

State whether the medical system/device employs any form of wireless communication, either standards-based and/or proprietary to facilitate the transmission/reception of data between system components and/or other systems?

Yes No

Does the system employ wireless communication?

Wireless Mode of Operation ad hoc? (e.g. Device connects internally to another wireless system component)

Wireless Mode of Operation infrastructure? (e.g. Device connects to a LAN

Environment)

Wireless Authentication Method (e.g. PKI, User-name/Password, Token)

Wireless Encryption Method (eg. AES-

256 CCMP)

IEEE 802.15 BLUETOOTH

(Wireless Personal Area Network – WPAN)

Use FIPS 140-2 validated cryptographic modules for data in transit, including digital voice communications.

Bluetooth Discovery Mode Turned Off by default.

WIRELESS – Other

(Describe any other wireless capabilities, i.e. Ultrawide band, Zigbee, etc.)

Wireless Technology Range (ft.)

(indoor/outdoor) Throughput (Mbps) Purpose

2.11 – MASS STORAGE

Provide a summary describing if the use of USB Thumb Drives/External Hard Drives is required for the operation of the system. Are drives required for use by the operator, or administrative in nature? Please detail what information is stored on the drives, how information on the drives is protected, and alternatives to using the drives.

Section 3: Data Processing Capabilities

SYSTEM IDENTIFICATION – Data Processing, Electronic Protected Health Information/RMF Authorization

3.0 Data Processing Capabilities:

Does the proposed medical device/equipment perform any of the following data processing functions? (check all that apply)

Receive Process Store Transmit

Display

3.1 Electronic Protected Health

Information/Personally Identifiable Information

(ePHI/PII):

(as defined by HIPAA Security Rule, 45 CFR Part

164) Indicate whether the proposed medical device acquires, processes, stores, displays/routes ePHI.

Yes No

3.2 Non ePHI/PII information

Define any data processed that is not ePHI/PII information.

3.3 Electronic Protected Health

Information/Personally Identifiable Information

(ePHI/PII) Elements: (as defined by HIPAA Security

Rule, 45 CFR Part 164) Identify each and all applicable ePHI elements.

Address

Dates of Birth, Admission, Discharge, Death, and all ages over 89 [and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age

90 or older]

Social Security Number

Telephone numbers

Fax number

E-Mail address

Medical Record Number

Health Plan beneficiary number

Account number

Certificate/License number

Any vehicle or other device serial number

Device identifier or serial numbers

Web Uniform Resource Locator (URL)

IP address

Finger or voice prints

Photographic/Radiographic images

Test Results

Physiologic data with identifying characteristics

Biometric data

Personal Financial Data

Any other unique identifying number, characteristic, or code.

SYSTEM IDENTIFICATION – Data Processing, Electronic Protected Health Information/RMF Authorization

3.4 DoD Information Persistence/Electronic

Protected Health Information/Personally

Identifiable Information (ePHI/PII) storage method:

Describe the persistence of the DoD Information processed/stored/transmitted on or by the system.

Permanently

Temporarily

Describe the method in which data is removed from the MDE, and amount of time for data storage. (i.e., First in

First Out, removed upon system reset, manually removed, etc.)

3.5 Data Input Method

Describe the data input method. Distinguish between manual versus "prescribed" (automated/programmed) data input methods.

3.6 Data Workflow

Indicate what data elements enter the MDE, and what data elements leave the MDE. Indicate how data is processed and, or changed by the MDE.

3.7 Data At Rest Encryption Capabilities

Describe any capability to encrypt data at rest. Include

Encryption method and key strength (i.e. Bitlocker, AES-256)

3.8 Data in Transit Encryption Capabilities

Describe any capability to encrypt DoD

Information/ePHI/PII while in transit. Include

Encryption method and key strength (i.e. AES-256)