Medical_Device_Cybersecurity_Assessment_-_version_2.0_-_20150603RX.pdf

FOR OFFICIAL USE ONLY (FOUO) WHEN COMPLETED

MEDICAL DEVICE RISK ASSESSMENT 1 of 22 Version 2.0

Naval Medical Logistics Command (NMLC) Medical Device Risk Assessment (MDRA)

The information provided below will be used to identify the technical characteristics, of an information technology (IT)-based medical device, such as data processing capabilities, current security posture, and level of compliance with the Cybersecurity principles of Confidentiality, Integrity, Availability, and Non-Repudiation.

BLUE SECTION – ALL FIELDS MUST BE ADDRESSED; THEREFORE NO RESPONSES, N/A, OR

REFERENCES TO EXTERNAL DOCUMENTS ARE NOT ACCEPTABLE.

PREP ARE R I DE NT IF ICA TIO N I N FORM A TIO N

Date:

Name:

Title:

Company Name and Address:

Phone Number:

E-Mail Address:

SY STEM IDE N TI FIC AT ION

1.1 Medical Device Name/Title:

(System Name – Provide the naming convention for the system name and associated acronym (if any).

For example “ACME Computed Tomography Scanner model 200E (US200)”

1.1a Medical Device Acronym: Provide the commercial acronym associated with the proposed medical device, if applicable.

1.1b Food and Drug Administration (FDA 510K) Premarket Authorization letter number, if applicable.

1.2 Medical Device Description:

(System Description – Provide a brief description of the system architecture). For example: The ACME Computer Tomography scanner is a radiographic system used on hospitals, clinics, and medical practices. It enables radiographic and tomographic exposures of the whole body including: skull, chest, abdomen, and extremities. The ACME Computer Tomography system converts x-rays to electronic signals.

MEDICAL DEVICE RISK ASSESSMENT 2 of 22 Version 2.0

SY STEM IDE N TI FIC AT ION

1.2a Electronic Protected Health Information (ePHI):

(Indicate whether the proposed medical device collects, maintains, and/or communicates ePHI. If so, please indicate which items considered ePHI the system processes, either temporarily or permanently.) ePHI identifiers are:

• Name

• Address

• Dates of Birth, Admission, Discharge, death, exact age if over 89

• 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 images

• Any other unique identifying number, characteristic, or code.

Does the system collect, maintain or communicate ePHI? (If yes, list below)

Yes No

In addition to the ePHI question on the left, does the proposed medical device process/store Social Security numbers (SSN) regardless of format/notation?

1.3 Department of Defense (DoD) Certification &

Accreditation Status:

(Certification & Accreditation (C&A) Status – If known, state whether the proposed medical device has been or is currently undergoing the DoD Certification & Accreditation Process

(DIACAP/PIT/CON)

1.4 Data Processing Capabilities:

(Data processing capabilities – With regards to data processing, does the proposed medical device perform any of the following functions?

Receive Process Store Route Display None

(check all that apply)

If none of the capabilities are provided by the proposed medical device described above, completion of the Medical Device Risk Assessment Questionnaire is NOT required beyond this point.

MEDICAL DEVICE RISK ASSESSMENT 3 of 22 Version 2.0

SYSTEM IDENTIFICATION

1.5 Operating System (OS):

Operating System (OS) – Select each and all instances of operating systems used throughout the proposed medical device. Make sure to identify all instances regardless of platform (i.e. server, client, peer, standalone, portable, peripheral end point device), and mode of operation (physical, virtual).

(SELECT ALL THAT APPLY)

Microsoft Operating Systems Service Pack

Microsoft Windows 2012 Server Microsoft Windows 2008 R2 Server Microsoft Windows 2008 Server Microsoft Windows 2003 R2 Server Microsoft Windows 2003 Server Microsoft Windows 2000 Server Microsoft Windows 8/8.1 Microsoft Windows 7 Ultimate Microsoft Windows 7 Professional Microsoft Windows Vista Ultimate Microsoft Windows Vista Business Microsoft Windows XP Professional Microsoft Windows XP Home Microsoft Windows XP Tablet Microsoft Windows XP Media Center Microsoft Windows 2000 Professional Microsoft Windows ME Microsoft Windows 98/98 SE Microsoft Windows 95 Microsoft Windows CE 6.0 Microsoft Windows 2013 Mobile Microsoft DOS 6.22/6.0/5.0

Microsoft Embedded Operating Systems Service Pack

Microsoft Windows 8.1 Professional Embedded Microsoft Windows 8 Standard Embedded Microsoft Windows 8.1 Handheld Embedded Microsoft Windows 8.1 Industry Enterprise Embedded Microsoft Windows 8.1 Industry Professional Embedded Microsoft Windows 7 Ultimate for Embedded Systems Microsoft Windows 7 Professional for Embedded Systems Microsoft Windows XP Embedded Microsoft Windows XP Point of Service Microsoft Windows CE 6.0 Embedded Windows Embedded Compact 2013 Windows Embedded Compact 7 Windows Embedded Handheld 6.5 Windows Storage Server 2008 Workgroup Embedded Windows Storage Server 2008 Standard Embedded Windows Storage Server 2008 Enterprise Embedded Windows Storage Server 2008 Basic Embedded 32-bit Windows Storage Server 2008 Basic Embedded Windows Server 2012 R2 for Embedded Systems Windows Server 2012 for Embedded Systems Microsoft Windows NT Embedded 4.0 Windows Embedded Standard 2009 Microsoft Embedded Other

LINUX/UNIX Kernel version

Red Hat Fedora SUSE Linux Enterprise openSUSE Linux Debian Ubuntu

BSD

Knoppix Mandriva Oracle Solaris CentOS Google Chromium Android OS

QNX

MEDICAL DEVICE RISK ASSESSMENT 4 of 22 Version 2.0

Apple OS Apple IOS Cisco IOS Cisco NX Juniper JUNOS VMware ESX/ESXi, vSphere Wind River - VxWorks RTOS

Manufacturer Proprietary Operating Systems Version

1.6 Relational Database Management System

(RDMS), if applicable:

Specify title, version, and service pack/release number of each database engine used by the proposed medical device.

RDBMS Title Version

1.7 Ports & Protocols:

(Ports, Protocols and Services (PPS) – List all Ports, Protocols, and Services used by the proposed medical device. Include for each Port Number: Data Service, Protocol, Purpose, Source and Destination). For example, Hypertext Transport Protocol over Secure Socket Layer (HTTPS/SSL) TCP port 443.

1.8 Antimalware:

Antimalware – Indicate whether the proposed medical device supports the use of Antimalware applications. If so, indicate which products, including title, version and build number have been validated.

For example, Symantec Endpoint Protection version 1.0

1.9 Public Internet:

Public Internet – Does the proposed medical device require connectivity (permanent, temporary) to the public Internet in order to operate?

1.9b Operating System (OS) Lifecycle Support:

Describe the licensing method of the operating system, including its anticipated End of Life (EOL) date and provisions for Extended support once the operating system is no longer supported by the manufacturer.

1.10 IPv6 Capability:

Is the proposed medical device IPv6 Capable? IPv6 ‘capable’ is defined as a system or product capable of receiving, processing, and forwarding IPv6 packets and/or interfacing with other systems and protocols in a manner similar to IPv4.

MEDICAL DEVICE RISK ASSESSMENT 5 of 22 Version 2.0

SYSTEM IDENTIFICATION

1.11a Medical Device Architecture Diagram (simple topology)

Provide a block diagram depicting all subsystems and components of the proposed medical device as configured in your proposal. The sample diagram shown below may be used as a template for simple topology architectures. You may include an embedded Microsoft Visio diagram with your submission.

MEDICAL DEVICE RISK ASSESSMENT 6 of 22 Version 2.0

SYSTEM IDENTIFICATION

1.11b Medical Device Architecture Diagram (complex topology)

Provide a block diagram depicting all subsystems and components of the proposed medical device as configured in your proposal. The sample diagram shown below may be used as a template for complex topology architectures. You may include an embedded Microsoft Visio diagram with your submission.

MEDICAL DEVICE RISK ASSESSMENT 7 of 22 Version 2.0

GOLD SECTION – THE SECTION THAT FOLLOWS CONTAINS A SERIES OF QUESTIONS REQUIRING A HIGH DEGREE OF FAMILIARITY WITH CONCEPTS AND TERMINOLOGY USED IN INFORMATION TECHNOLOGY.

THEREFORE COMPLETION OF THIS SECTION OF THE MEDICAL DEVICE RISK ASSESSMENT QUESTIONNAIRE BY TECHNICAL PERSONNEL IS REQUIRED. YOU MAY PROVIDE ADDITIONAL PAGES CONTAINING NON-

APPLICABLE RESPONSE JUSTIFICATIONS.

GOLD SECTION PREPARER IDENTIFICATION INFORMATION

Date:

Name:

Title:

Company Name and Address:

Phone Number:

E-Mail Address:

SY STEM IDE N TI FIC AT ION QUE ST ION S

2.1 How does the proposed medical system/device ensure Confidentiality?

(Describe how the system/device prevents the disclosure of information to unauthorized individuals and/or systems.)

2.2 How does the proposed medical system/device ensure Integrity?

(Describe how the system/device prevents the modification of data by unauthorized individuals and/or systems.)

2.3 How does the proposed medical system/device ensure Availability?

(Describe how the system/device ensures that the information is available to authorized individuals and/or systems.)

2.4 How does the proposed medical system/device ensure Non-Repudiation?

(Describe how the system/device ensures transactions are properly recorded and contain traceable information for auditing purposes.)

2.5 How does the proposed medical system/device protect Data at Rest (DAR)?

(Describe how the system/device protects data at rest, for example encryption.)

2.6 How does the proposed medical system/device protect Data in Transit (DIT)?

(Describe how the system/device protects data in transit, for example encryption.)

MEDICAL DEVICE RISK ASSESSMENT 8 of 22 Version 2.0

2.7 Does the proposed medical system/device include a test environment instance (physical/virtual)?, if so describe (The purpose of a test environment instance is to allow for the validation and testing of new system components prior to deployment on a production host. These may include software security updates and patches affecting the operating system, primary application, third-party software, database engine, and configuration files). A test environment instance can be physically implemented by using a dedicated (non-production) host, or virtually using a hypervisor.

2 .9 O PER AT IN G SY STEM I NVE N TORY

At te n t io n: T h e i nfo rma t io n re q ui re d i n t h is s ect io n can b e ge n era t ed b y us i ng th e au toma te d sc r i pt s l i s t ed i n Ap p e nd i x A. I f th is i nfo rm at io n ha s b ee n co l l ect e d t hro ug h t he u s e o f au toma te d scr i pt s , com p le t io n o f th is s ec t io n i s no t r e q ui re d. P l ea se e n su r e ho wev er t ha t t h e re s ul t i n g f i l e s a re i nc l u d ed w it h yo ur s u bm is s ion an d e ncry pte d , a s an o pt io n yo u ca n u se t h e AMR DEC S A FE S i te (h tt p s:/ /saf e. amr d ec .a rmy .mi l/ saf e/W elcom e. as p x) . P l ea se en s ur e th at th e R e qu ir e CA C fo r P ick- u p (a l l r ec i p ie n ts w i l l n e ed to lo g in w i th a C A C to do wnloa d f i le ( s ) ) op t io n i s e na bl e d.

Title Version Expected End of Life (EOL)

Service Pack/Release Level (SP)

32/64-bit Capable

IPv6 Capable

2.10 PR IM A RY A PPLIC A TIO N

2.10a Primary Software Application:

(Primary Software Application – Provide the title, version, build number and service pack/release number of the primary software application. List all add-ons required by the application, if applicable, such as Virtual Machines, and application software frameworks. For example, ACME Inc. Medical Instrumentation Management System (MIMS) version 3.10 Service Release 2 utilizing Microsoft .NET 3.5 framework.)

2.10b Virtualization:

State whether the proposed medical system/device utilizes virtualization technologies. These may include the following:

• Operating System virtualization

• Application/Workspace

• Virtual Desktop Interfaces (VDI)

• Storage virtualization

• OSI Layer 2/3 switching/routing appliances https://safe.amrdec.army.mil/safe/Welcome.aspx

MEDICAL DEVICE RISK ASSESSMENT 9 of 22 Version 2.0

2.10c Web Server:

(Web Server – if the proposed medical device/system includes one or more web server components, indicate the title and version of the web server engine, for example Microsoft IIS 7.1 or Apache 2.4.10)

2.10c Browsers:

(Browsers – If the proposed system requires the use of a browser as the primary application user interface, indicate which versions are supported, for example; Microsoft Internet Explorer 11)

2.10d Backward Compatibility:

(Backward compatibility– Describe in detail to what level, does the proposed medical device/system support the operation, interfacing, and exchange of information with regards to previous versions/releases of the same system.)

2.10e Distribution method of Security Updates:

(If the distribution of Updates/Fixes requires access to a web portal, please provide its URL).

2.10f Primary Application Licensing method:

Describe the licensing method of the primary application, including its anticipated End of Life (EOL) date and provisions for Extended support once the primary application is no longer supported by the manufacturer. You may include the anticipated release dates of future versions of the same application if known.

2.10g Network Addressing/Data Communication Protocols:

(Network Addressing/Data communication protocol customization: Describe components of the system, if any which rely on the use of TCP/IP addresses and Ports that are hardcoded and cannot be modified without a complete rewrite of the application software.)

2.10h Network Time Protocol (NTP):

requires the use of a built-in Network Time Protocol source. If so, indicate if this setting can be permanently disabled so as to receive NTP information from the Local Authoritative NTP host provided by the hosting enclave over TCP/UDP port 123.

2.10i Database Engine:

(Databases (DB) – List all instances of Database engines including Relational Database Management Systems (RDBMS), and/or flat file based. Include Database title, version, Service Pack/Release. For example, Microsoft SQL Server 2005 Service Pack 2.

Describe database authentication method, for example; SQL authentication/Active Directory Integrated authentication, or Mixed Mode authentication.)

MEDICAL DEVICE RISK ASSESSMENT 10 of 22 Version 2.0

2.10j DNS Realm/Domain Integration:

(If the proposed medical system/device, per design specifications, requires the exchange of data using the TCP/IP protocol, can the system integrate with a DNS Realm/Domain using the LDAP protocol? State whether all or some instances of IP addressable hosts can support this integration. For example;

Application Server integrates with Microsoft Active Directory.)

2.10k Automation support:

(Does the medical system/device support the creation/customization of scripts designed to automate frequent tasks?)

2.10l Compilers on production systems:

includes source code compilers/interpreters on production systems and whether they can be removed without affecting the operation of the system. Examples of compilers are:

Msc.exe, msvc.exe, Python.exe, javac.exe, Lcc-win32.exe, Microsoft SQL Studio, Microsoft Visual Studio, etc.

2.10m Administrator Account:

requires the use of the built-in “Administrator” (Microsoft Windows) or “root” (UNIX/Linux) accounts to provide authentication to either users and/or services. If so, state whether the medical system/device supports the renaming of these accounts without disrupting its functionality. You may also state whether the authentication of services can be assigned to accounts other than Administrator and/or root.

2.10n User interface protection:

(Describe how the system/device protects direct access to the Operating System interface by unauthorized users.)

2.10o Other platforms supported:

(Describe whether the primary application is commercially available for other platforms (Mac, Linux, Solaris, Android))

2.10p Mobile Code:

(Describe whether the proposed medical system/device uses mobile code technologies. If so, state if all mobile code can be signed with DoD approved PKI.)

2.10q OS/DB/WEB Server/Application separation:

(Describe whether the proposed medical system/device supports the physical or logical separation of the Primary Application and the Database Engine, if applicable. Physical separation is accomplished through the utilization of separate disk drives, whereas logical separation is accomplished through the use of separate disk volumes implemented on a single disk drive.

MEDICAL DEVICE RISK ASSESSMENT 11 of 22 Version 2.0

2.10r Instant Messaging:

(Does the proposed medical system/device support any type of Instant Messaging (IM), if so describe.)

2.10s Network Resources & Shares (SMB/CIFS, NFS, and AFP):

(Upon connecting to the Local Area Network, does the medical system/device make its file system available to other systems? If so, please indicate their purpose, default ACL/permissions, and access method (for example, UNC)

2.10t SHA-256 Cryptographic & Hash Algorithm support:

(If applicable, state whether the proposed medical system/device supports the use of SHA-256 Cryptographic and Hash algorithms in support of functions such as - Crypto Logon, reading digitally signed e-mail messages, digitally signing/encrypting data, and client-side PKI based authentication to web-based hosts)

2 .11 A PPL IC A TIO N DEVEL OPMENT EN VI RO NMEN T ( no n-we b ba sed ap p l ic at io ns )

Programming Language(s) Target Applications

2 .12 A PPL IC A TIO N DEVEL OPMENT EN VI RO NMEN T – (we b bro wser bas ed ap p l ic at i ons )

Programming Language(s) Target Applications

2 .13 MEDIC AL DE VICE H AR DW ARE / FIRM WA RE I N VE N TORY

At te n t io n: T h e i nfo rma t io n re q ui re d i n t h is s ect io n can b e ge n era t ed b y us i ng th e sc r i pt s an d co mma n d s l i s t e d i n Ap p e nd i x A. I f th is i nfo rm at io n ha s b ee n co l l ect e d t hro ug h t he u s e o f au toma t io n, com pl e t io n o f t h i s se ct io n i s no t re q ui re d. P l ea se e n s ur e h o weve r th at t he r es u l t in g f i l e s a re i nc lu d ed wi th yo ur s u bmi s s io n an d e ncr yp t ed, a s a n o pt io n you ca n u se t he A MRDEC S A FE S i t e ( ht tp s: // saf e.a mr de c .a rmy. mi l/ saf e/W elcom e. as p x) . P l ea se en s ur e th at th e R e qu ir e CA C fo r P ick- u p (a l l r ec i p ie n ts w i l l n e ed to lo g in w i th a C A C to do wnloa d f i le ( s ) ) op t io n i s e na bl e d.

Title Version Purpose

MEDICAL DEVICE RISK ASSESSMENT 12 of 22 Version 2.0

2.14 M EDIC AL DE VICE SO F TW ARE IN VE NTO RY

Attention: The information required in this section can be generated by using the scripts and commands listed in Appendix A. If this information has been collected through the use of automation, completion of this section is not required. Please ensure however that the resulting files are included with your submission and encrypted, as an option you can use the AMRDEC SAFE Site (https://safe.amrdec.army.mil/safe/Welcome.aspx).

Please ensure that the Require CAC for Pick-up (all recipients will need to log in with a CAC to download file(s)) option is enabled.

Title Version Purpose

MEDICAL DEVICE RISK ASSESSMENT 13 of 22 Version 2.0

2.15 PHYSICAL/LOGICAL TOPOLOGY DIAGRAM WITH EXTERNAL INTERFACES AND DATA FLOW

Provide a block diagram depicting all interfaces used by the proposed medical system/device. Ensure that for each interface the direction of data flow is clearly shown. You may include an embedded Microsoft Visio diagram with your submission.

Data acquisition device

Control Module

Data Processing subsystem

Workstations

Hardcopy device

Archive

Sy ste m data flo w exa mple

MEDICAL DEVICE RISK ASSESSMENT 14 of 22 Version 2.0

2.16 ES SE NT IAL SE R VICE S

Attention: The information required in this section can be generated by using the automated scripts listed in Appendix A. If this information has been collected through the use of automated scripts, completion of this section is not required. Please ensure however that the resulting files are included with your submission and encrypted, as an option you can use the AMRDEC SAFE Site (https://safe.amrdec.army.mil/safe/Welcome.aspx).

Please ensure that the Require CAC for Pick-up (all recipients will need to log in with a CAC to download file(s)) option is enabled.

Name Authentication Purpose

2 .17 ES SE NT IAL PO RT S/ PR OTOCOL S

( In dic at e w he t he r por t t u nn e l i n g i s u se d) Attention: The information required in this section can be generated by using the automated scripts listed in Appendix A. If this information has been collected through the use of automated scripts, completion of this section is not required. Please ensure however that the resulting files are included with your submission and encrypted, as an option you can use the AMRDEC SAFE Site (https://safe.amrdec.army.mil/safe/Welcome.aspx).

Please ensure that the Require CAC for Pick-up (all recipients will need to log in with a CAC to download file(s)) option is enabled.

Port Protocol Data Service Source Destination Purpose

2 .18 ES SE NT IAL P ROCES SE S S

Attention: The information required in this section can be generated by using the automated scripts listed in Appendix A. If this information has been collected through the use of automated scripts, completion of this section is not required. Please ensure however that the resulting files are included with your submission and encrypted, as an option you can use the AMRDEC SAFE Site (https://safe.amrdec.army.mil/safe/Welcome.aspx).

Please ensure that the Require CAC for Pick-up (all recipients will need to log in with a CAC to download file(s)) option is enabled.

Name Object Purpose

2 .19 F ILE SY STEM

L is t a l l ex tern al i n te r fac e s th at s u ppo rt f i le s ys t ems (USB , IEEE1 394, S D, S I M) . Do no t inc l ud e sof twar e l i c e ns e/ac t i vat io n to ke n s.

System Purpose Required?

MEDICAL DEVICE RISK ASSESSMENT 15 of 22 Version 2.0

2.20 Group Policy Objects (GPO) Microsoft Windows Operating Systems Only:

(Group Policy Objects – applies to Microsoft Operating Systems only). Describe whether the proposed Microsoft Windows based medical system/device can accept Domain level issued Group Policy Objects without negatively impacting the confidentiality, integrity and availability of the system upon joining the production Domain.)

Group Policy Object (GPO) Rule: Supported?

Minimum password length of 15 characters Yes No

Password must meet complexity requirements Yes No

Store passwords using reversible encryption Yes No

Audit account management – Success, Failure Yes No

Audit directory service access – Success, Failure Yes No

Audit object access – Success, Failure Yes No

Audit policy change – Success, Failure Yes No

Allow users to select new root certification authorities (CAs) to trust Yes No

Client computers can trust the following certificate stores – Third Party Root CAs and Enterprise Root CAs Yes No

Perform certificate-based authentication of users and computers, CAs must meet the following criteria – Registered in AD only Yes No

Enforce password history – 24 passwords remembered Yes No

Maximum password age – 60 days Yes No

Minimum password age – 1 day Yes No

Account lockout duration – 0 minutes Yes No

Account lockout threshold – 3 invalid logon attempts Yes No

Reset account lockout counter after – 60 minutes Yes No

Enforce user logon restrictions – Enabled Yes No

Maximum lifetime for service ticket – 600 minutes Yes No

Maximum lifetime for user ticket – 10 hours Yes No

Maximum lifetime for user ticket renewal – 7 days Yes No

Maximum tolerance for computer clock synchronization – 5 minutes Yes No

Enable computer and user accounts to be trusted for delegation – BUILTIN\Administrators Yes No

Network security: Do not store LAN Manager hash value on next password change – Enabled Yes No

Network security: Configure encryption types allowed for Kerberos - Enabled Yes No

Automatic certificate management – Disabled Yes No

Allow users to select new root certification authorities (CAs) to trust – Enabled Yes No

Client computers can trust the following certificate stores – Third-Party Root and Enterprise Root Certification Authorities Yes No

To perform certificate-based authentication of users and computers, CAs must meet the following criteria – Registered in AD Yes No

MEDICAL DEVICE RISK ASSESSMENT 16 of 22 Version 2.0

2.21 I S T HE SY S TEM E QUIP ED WI T H I NTELL IGE NT PLA TFO RM M AN AGEME NT I NT ERF ACE S ( IPM I)?

( IPMI te ch no lo gy a l lows o ut o f ba nd ma na ge me n t o f comp ut e r sys t em s by pas s in g th e O p era t in g Sy st em) , i f so de sc r i be i ts i nt e n de d p ur po se a nd l i s t sp ec i f i c se rv ice s re q ui r ed to s up p ort th e sy st em . I n dica te w he t he r IP MI t ra f f ic s u ppo rt s e ncry p t io n o f Da ta in T ra n s i t , to a n d f rom th e B as e boar d Ma n ag eme n t Co nt ro l le r (B MC) , an d whe t he r “c i p he r 0” ca n be d is ab le d.

2 .22 A UT HEN TIC A TIO N

(Doe s th e pro po se d me di c a l sy st em/ d ev ice s u ppo rt any o f t h e fo l low in g? )

DoD Password complexity rules (case sensitive, 15-characters, lower, upper, numeric, alphabetic, and special characters)

Password History/Aging (90 days)

Operating System services that utilize anonymous access

Biometrics

Public Key Infrastructure (PKI) using X.509 certificates

Remote Access authentication

Certificates/Tokens

2 .23 A UD ITI NG

(Doe s th e pro po se d me di c a l sy st em/ d ev ice s u ppo rt any o f t h e fo l low in g?)

Audit logs

Customizable audit levels

Retention settings for system logs

Audit logs protection from deletion

Are audit trail events date/time stamped?

Can audit trail events include source/destination IP information?

Can audit trail events include protocols?

Can audit trail events include User ID information?

Can audit trail events include changes to Administrator account information?

2 .24 B IO S F IRMW A RE (F W )

Is the BIOS Firmware configuration password-protected?

Is there a BIOS Firmware master override provided by the vendor?

MEDICAL DEVICE RISK ASSESSMENT 17 of 22 Version 2.0

2.25 A N TI VI RU S/ A NTIM AL WA RE

Antivirus/Antimalware recommended best practices (if available) *List items which should be excluded from scanning.

Antivirus/Antimalware Heuristics scanning supported?

2 .26 D AT A A T RES T (D A R)

Is the encryption algorithm NIST FIPS 140.2 compliant?

DAR Encryption products and versions validated by the manufacturer

DAR Encryption recommended best practices *Provide technical recommendations that address the protection mechanisms of data at rest.

DAR Removable Media *Does the system/device provide encryption of portable media.

Backup Encryption supported algorithms (3DES/AES/RC4/Other)

2 .27 D AT A I N T R AN S IT ( DI T)

Is the encryption algorithm NIST FIPS 140.2 compliant?

DIT Encryption technologies and versions validated by the manufacturer

DIT Encryption recommended best practices

* Provide technical recommendations that address the protection mechanisms of data in transit.

2 .28 A V AIL AB IL I TY

Availability Position Paper on file system redundancy (if available)

Availability products and versions validated

Availability recommended best practices (if available) *Provide technical recommendations that address data availability.

2 .29 IP v6

(IPv6 capability – Indicate whether the following software components of the proposed medical system/device are capable of sending/receiving TCP/IP version 6 datagrams:

Is the Operating System capable of transmitting/receiving TCP/IP version 6 Datagrams?

Is the Primary Application capable of transmitting/receiving TCP/IP version 6 Datagrams?

Is the Database Engine capable of transmitting/receiving TCP/IP version 6 Datagrams? (if applicable)

MEDICAL DEVICE RISK ASSESSMENT 18 of 22 Version 2.0

2.30 IP v6 – Co mp l ia nc e d oc ume nt at io n

• If the system/device is natively capable of exchanging data in the three areas listed above, provide letter of compliance.

• If the system supports TCP/IP version 6 through the use of hardware/software based TCP/IPv6 transformers, please describe the technical characteristics and methodology employed to achieve IPv4/IPv6 interoperability, along with technical considerations regarding latency, overhead and redundancy. This is particularly important when describing systems that are considered Real Time, and/or High Availability (HA).

• If the proposed medical system/device does not currently support IPv6 data communications, please provide a letter of commitment to upgrade to IPv6, including milestones (in company letterhead from the company’s vice president or equivalent).

2 .31 HO S T-B A SED I NT RU SI ON P RE VEN TIO N SY STEM ( HIP S )

Does the proposed medical system/device support the use of a host based Intrusion Prevention System (IPS)?

2 .32 HO S T B A SED SEC UR IT Y S YS TEM (Mc Afee H BS S )

Host Based Security System – Describe whether the proposed system supports the installation and operation of a Host Based Security System. A Host Based Security System is a commercial software based application specifically designed to protect and maintain the security baseline of a system. It actively monitors, detects and counters against known cyber threats. Host Based Security Systems are managed by local administrators and are configured to address known exploit traffic using an Intrusion Prevention System (IPS) and host firewall. If the proposed medical system/device has been evaluated against a Host Based Security Systems, provide application title, version, and modules used to conduct its evaluation. If false positives were recorded during evaluation use the following section to list all known instances including the process identifiers and their primary purpose. Example: McAfee EndPoint Security, version 1.0.0.

2 .33 I NT RU SIO N DETEC TIO N/ PRE VEN TIO N SY S TEM – F ALSE PO SIT I VES

(De scr i be p ro ce s se s l ik e ly to c r ea te fa ls e- pos i t iv e a l er ts ) Intrusion Detection/Intrusion Prevention Systems – List all processes known to generate false IPS/IDS false positives. For example: spoolsv.exe incorrectly detected as Backdoor. Ciadoor.B, Hacktool.Privshell or VBS.Massscal.Worm malware.

MEDICAL DEVICE RISK ASSESSMENT 19 of 22 Version 2.0

2.34 M EDIC AL S YS TEM/ DE VICE RECO VERY /LO S S

(A pp l i e s to la p to p s, ta bl et s , a n d por ta bl es on ly . ) Accidental loss – Describe whether the proposed medical system/device portable components support remote wipe and/or geo tracking services in the event of accidental loss, theft, misplacement.

2 .35 M EDIC AL S YS TEM/ DE VICE S TA N DA R DS CO NFO R MANCE S T ATEME NT S

(For e xa mp le IHE , DICO M) Conformance Statements - List all conformance statements associated with the system/device. Please provide proof of certification. For example, DICOM, IHE, MDS2.

2 .36 S YS TEM U SE R DESC RI PTIO N S

(Fo r e xa mp le : Me d ica l t ec hno log i st , f i e l d s erv ic e en gi n ee r , p hys ic ia n) Role Minimum Access Level (non-privileged, privileged, administrator/root)

2 .37 WI RELES S ( IEEE 80 2.1 1)

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?

Wireless Mode of Operation infrastructure?

2 .38 WI RELES S – IEEE 8 02. 15 BL UETOO TH

(Wir e l e ss Pe r sona l Ar ea N etwor k – WP A N)

Frequency (GHz) Modulation Throughput (Mbps) Range (ft.) (indoor/outdoor)

2 .39 WI RELES S – IEEE 8 02. 15 Z igBee

MEDICAL DEVICE RISK ASSESSMENT 20 of 22 Version 2.0

2.41 WI RELES S – IEEE 8 02. 15 (a /b /g/ n )

Frequency (GHz) Modulation (FHSS/OFDM/DSSS/CCK) Throughput (Mbps) Range (ft.) (indoor/outdoor)

2 .42 WI RELES S – OT HER – ULTR A WI DE B A ND ( UWB ) , IEEE 80 2.1 6

WiM AX , IR /M IC ROW AVE , ULTR A SOU N D, R A DIO ( VH F/ UH F )

2 .43 OT HER

Power Requirements (Voltage/Amps):

Weight (lbs.)

Physical Dimensions (H/W/D):

Environmental specifications:

2 .44 P HY SIC AL S AFEG U AR DS

Does the system include a physical locking anti-tampering sensor mechanism?

Does the system expose data interfaces, such as USB/IEEE 1394 which could be used to bypass the Operating System?

2 .45 COM M ERCI AL POI NT OF CO NT AC T (POC ) I N FOR MATI ON – PRO DUC T M A N AGER ( PM )

Name Phone E-Mail

2 .46 COM M ERCI AL POI NT OF CO NT AC T (POC ) I N FOR MATI ON – A PPLIC A TIO N/ NETWO RK ENG I NEER

2 .47 COM M ERCI AL POI NT OF CO NT AC T (POC ) I N FOR MATI ON – SEC URI TY MA N AGER

2 .48 COM M ERCI AL POI NT OF CO NT AC T (POC ) I N FOR MATI ON – I NCI DEN T REPO RTI NG

MEDICAL DEVICE RISK ASSESSMENT 21 of 22 Version 2.0

APPENDIX A

To obtain a detailed list of various components of operating systems, including firmware information, follow the procedure outlined below.

Instructions are provided for Microsoft Windows, Linux (including the most common distributions), and VMware. Please ensure that the output produced by the various utilities and commands is captured using plain text formatted (.txt) files. For consistency, you may name these files using the hostname of the device and the data they contain; for example:

“meddev1-os-info.txt”

And

“meddev1-sw-info.txt”

Operating System Inventory

Microsoft Windows operating systems (all currently supported versions)

1. Using local administrative rights, access the Microsoft Windows desktop interface

2. From the command prompt, launch the MSINFO32.EXE utility

3. Select File + Export from the main menu

4. Save the file in text format

LINUX based medical systems

1. Access the root prompt

2. Enter the uname –a > filename or uname –mrs > hostname-os-info.txt commands, where filename denotes the output file

3. You may also obtain similar information by using dmesg > hostname-os-info.txt where filename denotes the output file

VMWare based medical systems

1. Access the VMWare service console

2. At the root prompt, enter vmware –vl

3. You may redirect the output of the above command as follows: vmware –vl > hostname-os-info.txt

Software Inventory

Microsoft Windows based medical devices (all currently supported versions)

1. Access the Microsoft Windows desktop interface

2. Run the PowerShell command interface (Start + Accessories + System Tools + PowerShell)

3. At the PowerShell prompt, type wmic

4. At the WMIC prompt, enter /output:c:\hostname-sw-info.txt product get name,version and notice that the spacing and punctuation has to be exactly as shown above, for instance no spaces between "name,version"

LINUX based medical devices

1. CentOS – At the root prompt, type the following command: rpm –qa | less > hostname-sw-info.txt

2. Debian - At the root prompt, type the following command: dkpg –get-selections > hostname-sw-info.txt

3. Ubuntu - At the root prompt, type the following command: sudo dpkg—get-selections > hostname-sw-info.txt

4. Free BSD - At the root prompt, type the following command: pkg_version | less > hostname-sw-info.txt

5. OpenBSD - At the root prompt, type the following command: pkg_version | less > hostname-sw-info.txt

MEDICAL DEVICE RISK ASSESSMENT 22 of 22 Version 2.0

Services running on LINUX based medical devices

At the root prompt, enter service –list –all > hostname-proc-info.txt

Active ports and protocols running on a LINUX/Microsoft Windows based medical device

At the root/command prompt, enter netstat –a > hostname-ports-info.txt

Active processes running on a LINUX based medical device

At the root prompt, enter ps –a > hostname-procs-info.txt

DO NOT COMPLETE ANYTHING B EYOND THIS POINT

IDENTIF ICATION INFORMATION

ACN:

TDP:

MDRAQ Serial Number:

CE POC:

Contracting POC:

Blue Section Reviewed By:

Gold Section Reviewed By:

Final Disposition:

Overall Risk Level:

PMO Authorization Path Recommendation:

TECHNICAL RECOMM ENDATION