Manufacturer Disclosure Statement for Medical Device Security and You

By Steven Hughes

One of the core foundational documents of any HTM cybersecurity program is the MDS2 (Manufacturer Disclosure Statement for Medical Device Security) which provides information on your medical device or Software as a Medical Device (SaMD) mapped directly to security controls established by National Institute of Science and technology (NIST), International Electrotechnical Commission (IEC) and International Standards Organization (ISO). Medical Device Manufacturers (MDMs) supply an MDS2 on their product at the time of sale or upon request from health delivery organizations (HDOs). The MDS2 allows the MDM the opportunity to communicate critical security related information through a standardized form that assists HDOs in the evaluation of a medical device’s security capabilities, how to best handle any issues when they occur as well as compare devices during the product selection process.

The MDS2 standard was developed by Healthcare Information and Management Systems Society (HIMSS) and the National Electrical Manufacturers Association (NEMA), and most recently revised by NEMA and the Medical Imaging & Technology Alliance (MITA) back in 2018 with the latest version of its standard, ANSI/NEMA HN 1-2019 MDS2 published in 2019. The new version provides medical device manufacturers with an expanded MDS2 form to collect and report information related to their products’ security capabilities to their customers. MDMs fill in responses to a series of 240 questions that cover 23 different security capabilities about the device.

WHAT IS IN AN MDS2

The questions asked in an MDS2 provide the HDO with information needed to properly evaluate, purchase, implement, sustain and secure the device in their organization while ensuring it meets their contracting and security requirements at the time of purchase such as:

• Does the device perform automatic installation of software updates?
• Does the manufacturer notify the customer when updates are approved for installation?
• Does the device require vendor or vendor-authorized service to install patches or software updates?
• Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer?
• Does the device have the capability to receive remote installation of patches or software updates?
• Does the device contain anti-malware software?
• Does the manufacturer have a process in place to assess device vulnerabilities and updates?
• Does the manufacturer have an approved list of third-party software that can be installed on the device?
• What types of private data are stored on the device, and how are they transmitted?
• Does the device support and enforce unique IDs and passwords for all users and roles (including service accounts)?
• Is the SBOM for this product available?

Note: Some of the questions may need follow up with the MDM to determine if service and support contracts are needed and should be included in the planned purchase and sustainment costs of the medical device.

RECOMMENDATIONS FOR USING MDS2 SUCCESSFULLY

These recommendations are adapted from material found on the ECRI (www.ECRI.org) and AAMI (www.aami.org) websites:

• Make sure a MDS2 form is requested for each medical device during the prepurchasing/procurement phase or for systems in your current inventory lacking an MDS2.
• Verify with the MDM that they are using the latest version of the MDS2. If an outdated form is received, request that the manufacturer provide you with a completed MDS2 based on the latest version. The manufacturer should update the MDS2 form for each of its devices as updates/new software versions are released.
• Verify model, OS, firmware and software version of the device matches the version on the MDS2 or matches what will “ship.”
• The MDS2 form is meant to provide a way of reporting the technical, model-specific elements of information needed by an HDO to begin medical device security risk assessments. Note: There may be variations based on SKUs, operating system and software version installed. If you have more than one variation, be sure you have the proper MDS2 for each variation in your inventory and its risk score rated accordingly.
• If the MDM hasn’t yet completed one for your device, you can send a copy or link to the MDS2 at NEMA (www.nema.org), see QR code for direct link. NEMA also recommends referencing the instructions document (HN 1-2019) and example worksheet.
• The MDS2 assists in determining whether the device meets your security requirements “as is,” can be compliant with compensating controls, or cannot meet your requirements even with compensating controls. HTM, IT and risk management should review the MDS2 to assist in product comparisons and final purchasing decisions. NOTE: All answers on an MDS2 may not be applicable to all devices and should be evaluated accordingly.
• MDS2 questions are formatted with a response of “Yes,” “No,” “N/A,” (Not Applicable) or “See Note” with little to no room for misinterpretation or confusion. NOTE: Some questions require technical details to be provided in the “Notes” field, review these fields closely. You may also request any supplemental documentation including network diagrams, security documentation (listing of ports, protocols, and services used), software dependencies, device and software inventory, a Software Bills of Materials (SBOM) which is asked in the MDS2, etc.
• Verify that the MDM has filled the form out properly and completely. If insufficient information is provided in the MDS2 form, request that the MDM expound to meet your standards and/or request a conference call with the manufacturer’s technical team for clarification with other members of your risk assessment team. NOTE: Not all questions can be answered, but more questions answered helps create a better security profile.
• Use the MDS2 to determine if the device generates, stores and/or transmits Protected Health Information (PHI), how much data is stored on the device, how it is protected, the type of data, and if the data is stored permanently or temporarily. If data is permanent, the manufacturer should be able to provide instructions how it can be removed. This will also help determine what breach notification action must be taken per the HIPAA Breach Notification Rule with Health and Human Services (HHS).
• Upload or link to your MDS2 forms to your device entry in your asset management database, Computerized Maintenance Management System (CMMS), Governance, Risk Management, Compliance (GRC) system, Internet of Medical Things (IoMT) solution or store in a simple networked repository with shared access to all parties involved (HTM, IT, Security, etc.). Some software solution vendors even allow the data from the MDS2 to be imported and ingested. This may facilitate and automate future risk management and vulnerability remediation efforts.
• Check with the MDM periodically (some MDMs have websites or portals) for updated MDS2 forms or when product changes occur – like changes to the operating system and/or major version changes of installed software. Additional software tools are also available from several CMMS vendors and third-party security vendors that can use MDS2 information in the creation of a risk profile or a Common Vulnerability Scoring System (CVSS) risk score for a particular device which rely heavily on current and updated information.
• Detailed information collected on a MDS2 allows for an accurate risk assessment as well as the best configuration for proper operation, patching, updates, security and guidance used in the care and feeding of the medical device as deemed by the MDM, while it resides in your hospital organization.

HOW OFTEN SHOULD YOU UPDATE YOUR MDS2?

Very rarely are these documents updated and unfortunately remain a static document. As mentioned previously, HDOs should request a new MDS2 when there is a significant or major change/update to the operating system or software version so an accurate risk analysis and proper patching can occur.

Several MDS2 forms received from MDMs are created using outdated or old forms from 2008 and 2013. If you are using an IoMT solution and this data is being used, make sure your MDS2 documents are current as this can affect your risk analysis and accuracy of properly identifying your medical devices in your cybersecurity program.

Several third-party security systems can store and even process the information on an MDS2 sheet to assist and provide insight in notifying HDOs of potential vulnerabilities and some even provide pre-procurement and post-procurement risk analysis. Some also ingest the number of PHI on a device which is needed in to properly report breaches to HHS per HIPPA when a vulnerability is identified.

Many third-party IoMT solutions also have a large collection of MDS2s. This is great for organizations without a way of archiving MDS2 documents or lack a cache of their own, but unfortunately most are old, outdated or based on an older version of the MDS2 form and this may affect a proper risk assessment. If not current, this will ultimately leave gaps in your security posture if you are relying on this for an accurate assessment of your medical device inventory cybersecurity health. Another thing to consider is how deeply the data from the MDS2 is integrated into the rest of the solution and how it is used. If the data is outdated, it can cause false positives for vulnerabilities that may not exist potentially wasting valuable time and resources verifying devices that may have already been patched. Work with your IoMT solution provider to verify the data is accurate and up to date as well as how it is used.

If you also manage non-medical devices or research devices, using the MDS2 as a template for documenting those devices can also be used to help with preprocurement as well as address patching strategy, risk assessment, and security for systems like security door systems, temperature control systems, elevators, security cameras, IoT devices, nurse call systems, etc. These systems generally can’t receive enterprise baselines and don’t currently have a standardized method of proper documentation and risk assessment. Inherently they also have a higher potential attack surface than medical devices because of lower security standards, unpatched and unknown vulnerabilities and poor documentation. They would benefit from using similar best practices and documentation outlined in the MDS2 form.

WHAT IS NEXT FOR MDS2?

With innovation and maintaining updated MDS2, HDOs will be able to easily ingest the information into their CMSS or IoMT security program along with information given on SBOMs to better assess what they have, what can be patched and what needs to be patched/updated. SBOMs are still in their nascent stage with the potential to tap into a regularly automated updated SBOM feeds directly from the manufacturer, which could automate the updating of MDS2 documents stored on MDMs websites or an HDOs CMMS system providing updated information in near real time.

Zack Hornberger from MITA states that the “MDS2 aims to makes sure that no one is left behind on cybersecurity – which can sometimes keep universal tools like MDS2 tied to more accessible, but maybe less state-of-the-art, communication methods. Still, everyone wants to see MDS2 continue as the gold standard for device cybersecurity information sharing between MDMs and HDOs.”

Steven Hughes, FAC-COR FACP/PM VHA-CM, is a VISN 21 Biomedical Engineer with the VA Sierra Pacific Network.