19. FRCS-VRA Ver 2.0.docx

Facility Related Control Systems – Vendor Risk Assessment Questionnaire

(FRCS-VRA)

Version 2.0

To ascertain security compliance that is in agreement with United States Federal Government (USFG), Department of Defense (DoD), and Defense Health Agency (DHA) policies and directives, the DHA Facilities Related Control System (FRCS) PMO requires the vendor complete the following FRCS Vendor Risk Assessment (FRCS-VRA).

All FRCS Systems/Devices are required to meet DoD cybersecurity and National Institute of Standards and Technology (NIST) standards. The information provided below will be used as a pre-procurement selection tool used to support all stakeholders working to achieve a Risk Management Framework (RMF) Authorization. Failure to disclose all required information, or misrepresentation of the proposed system’s capabilities, will result in the system being ineligible for purchase, or result in a breach of contract and cancellation of contract if discovered after award.

The information provided below which includes data processing capabilities, current security posture, and level of compliance with the cybersecurity principles of Confidentiality, Integrity, and Availability will be used to identify the technical characteristics of the FRCS System/Device and determine the level of effort and potential actions required prior to and during an RMF Assessment process, from a cybersecurity standpoint.

Revision History

READ BEFORE PROCEEDING:

THIS FACILITIES RELATED CONTROL SYSTEMS VENDOR RISK ASSESSMENT (FRCS-VRA) QUESTIONNAIRE IS TO BE COMPLETED BY THE COMMERCIAL VENDOR IN ITS ENTIRETY AS PART OF THE FRCS DEVICE/SYSTEM REQUEST FOR INFORMATION (RFI) PROCESS. THEREFORE, ALL INFORMATION FIELDS MUST BE ADDRESSED. REFERENCES TO EXTERNAL DOCUMENTS OR PRODUCT LITERATURE ARE NOT ACCEPTABLE.

ONCE COMPLETED, SUBMIT THE FRCS-VRA TO THE DESIGNATED POINT OF CONTACT (POC).

COMPLETION OF THIS QUESTIONNAIRE IS APPLICABLE TO FACILITIES RELATED CONTROL SYSTEMS THAT OPERATE IN A HEALTHCARE SETTING.

PRIMARY VENDOR POINT OF CONTACT (POC) INFORMATION (Vendor Account Manager)

Name:

Job Title:

Company:

Business Address:

E-Mail Address:

Phone Number:

Web page Address:

POC Signature and Date:

(Signature indicates acceptance that all provided information is accurate, and that no information has been omitted. Failure to sign document renders the document incomplete/invalid and cannot be used as a part of evaluations.)

DATE:

VENDOR TECHNICAL POINT OF CONTACT (POC) INFORMATION (Technical POC Responsible for conducting RMF Activities)

Name:

Job Title:

Company:

Business Address:

E-Mail Address:

Phone Number:

Web page Address:

Technical POC Signature and Date:

(Signature indicates acceptance that all provided information is accurate, and that no information has been omitted. Failure to sign document renders the document incomplete/invalid and cannot be used as a part of evaluations.)

DATE:

Section 1: System Identification SYSTEM AND DEVICE EQUIPMENT IDENTIFICATION – Technical and Regulatory

1.0 Device Description:

Provide a brief technical description of the System/device intended use/capability.

1.1 System/Device Nomenclature:

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

1.1a System/Device Model:

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

Release Date:

EOL Date:

1.2 Mode of Operation:

Select the mode of operation of the System/device.

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

|_| Stand-alone Information System (SIS) – 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.

|_| Operates in isolation SIS (not connected to NIPR, Med-COI, etc.)

|_| Operates connected to network (not Med-COI)

|_| Operates connected to the DHA Med-COI network

|_| 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.

|_| Operates in isolation SIS (not connected to NIPR, Med-COI, etc.)

|_| Operates connected to network (not Med-COI)

|_| Operates connected to the DHA Med-COI network

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

|_| Operates in isolation SIS (not connected to NIPR, Med-COI, etc.)

|_| Operates connected to network (not Med-COI)

|_| Operates connected to the DHA Med-COI network

If Connected to network (not Med-COI) provide network description:

1.3 Method of Implementation:

Select the method of implementation of the System/device.

|_| System/device 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 vendor provided virtual environment)

|_| System is Software Only in a Virtual Environment (requires GOV provided virtual environment)

1.4 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.5 Connected Systems

Describe each system this solution will connect to, or communicate with and describe the connection type

1.6 Food and Drug Administration (FDA 510K)/other Regulatory Certification, or Premarket Authorization identifier, if applicable: Provide the number associated with the FRCS device/equipment, if applicable

1.7 Baseline physical testing location: Indicate whether an instance of the FRCS System/device is installed at the manufacturer’s facility is available for RMF Assessment. If such a system is available, provide the location.

SYSTEM IDENTIFICATION – RMF Authorization

1.8 Department of Defense (DoD)/Defense Health Agency (DHA) Authorization: State whether the proposed System/device 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).

eMASS Record ID:

ATD:

Section 2: Technical Information

SYSTEM HARDWARE DETAIL

List all components required for the operation and functionality of the device, to include all servers, workstations, routers, switches, etc. Include quantities of each hardware component identified in comments.

OPERATING SYSTEMS/FIRMWARE DETAIL

For each Component Listed in Section 2.0, List the Operating System (OS) or Firmware: 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)

Yes

Ex: Field Equipment Controller (FEC), (BACnet, MS/TP, N2, other)

No

Ex: Network Sensors (Discharge Air, Flow, other)

No

Ex: Smart Meters (power, water, gas, other)

INSTALLED APPLICATIONS DETAIL

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.

Individually Identifiable User Accounts:

For each Component Listed in Section 2.0, describe the account types that are required for the System/device to operate. Are individual accounts for technicians required for the application?

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

SYSTEM ARCHITECTURE DRAWING:

Device Architecture Diagram: Provide a block diagram depicting all subsystems and components of the System/device as configured in your environment. Include connection specifications such as: Ethernet Connection, Wi-Fi Connection, Wireless Connection, Bluetooth Connection, and/or Serial Connections. Also include FRCS connection specification such as: BACnet, Lon-Works and Modbus. Identify any connections (digital or serial) to other FRCS Systems that are required for the functional solution. If possible, include an embedded Microsoft Visio diagram with your submission.

MIGRATION PATH

For any Application, Operating System, or Firmware listed above with less than 24 months of support/extended support, identify if there is a migration plan or upgrade path.

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 that can be installed on the proposed System/device. (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 supporting End Point Protection?

a. Answer:

b. Answer:

c. Answer

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

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)

VULNERABILITY SCANNING POLICY

System/device can be scanned in a test/vendor lab environment (provide detail below):

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

System/device can be scanned in an operational environment:

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

If the System/device 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 safety, etc.)

VULNERABILITY MANAGEMENT/PATCHING POLICY

Provide a summary describing the plan for providing validated software updates and patches throughout the life cycle of the System/device. 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 facilities personnel at the healthcare organization to install.) The vendor should also specify the frequency of product updates.

2.9 REMOTE ACCESS

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

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

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

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

Has a DHA Business to Business (B2B) connection been established for remote support?

If there is remote access to the system for support and maintenance, provide the procedure (DHA B2B, etc.):

WIRELESS CAPABILITIES

(IEEE 802.11)

Does the system employ wireless communication?

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

Wireless Mode of Operation infrastructure? (Device connects to a LAN Environment)

Wireless Authentication Method (PKI, Username/Password, Token):

Wireless Encryption Method (eg. AES-256 CCMP):

IEEE 802.15 BLUETOOTH

(Wireless Personal Area Network – WPAN)

Does the system employ 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.)

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 FRCS 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 FRCS 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.

|_| 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.

|_| None of the above

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 FRCS, 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 FRCS, and what data elements leave the FRCS. Indicate how data is processed and, or changed by the FRCS.

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)

Appendix

APPENDIX 1

FRCS Systems Identified in MILSTD 1691

Facility Related Control Systems:

Type

Type

Type

Type

Type

Type

Type

Type

FRCS-vRA DHA FE rISK aSSESSMENT ver 1.0

UNCLASSIFIED//FOR OFFICIAL USE ONLY WHEN COMPLETED

image1.wmf