MDS2: A Treasure Trove for Internet of Medical Things (IoMT) Security

Jan 26, 2022
7 minutes
... views

What are MDS2 documents?

MDS2 (Manufacturer Disclosure Statement for Medical Device Security) documents are probably the best resource to maximize clinical IoT security, as they contain invaluable information to improve the security posture of medical devices, yet, they are the least leveraged resource!

National Electrical Manufacturers Association (NEMA), an ANSI-accredited Standards Developing Organization, and Medical Imaging & Technology Alliance (MITA), has introduced the new voluntary standard - MDS2 documents - in conjunction with a diverse range of industry stakeholders and aligns with the 2018 U.S. Food and Drug Administration (FDA) Medical Device Cybersecurity Playbook, issued in October 2018.

The MDS2 form was introduced in 2004 to capture medical device security standards which provides healthcare delivery organizations (HDOs) with important information about risk management and medical device security controls to harden the devices against unauthorized access and cyberattacks. The MDS2 form continues to evolve, with updates published in 2013 and 2019. The 2019 version is a substantial improvement and the controls introduced in this version also mapped to the controls recommended in the following specification frameworks:

  • IEC/TR 80001-2-2:2012 — Application of risk management for IT-networks incorporating medical devices — Part 2-2: Guidance for the communication of medical device security needs, risks, and controls
  • SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
  • ISO/IEC 27002:2013 — Information technology — Security techniques — Code of practice for information security controls

How does the MDS2 information help maximize medical IoT device security?

MDS2 forms provide a structured format for the medical device manufacturers and Healthcare Delivery Organizations (HDOs) for security-risk assessment in managing medical device security issues.

The 2019 MDS2 version includes 23 different groups of security controls for medical devices. These controls help answer critical questions in accessing the cybersecurity risk and help surface additional device context and identify security anomalies. In fact, information within the MDS2 documents can help with the clinical IoT life cycle.



MDS2 forms help us answer some of the use cases:

  • Device Context: What operating system/ software does the device run?
  • Risk: Does the device transmit or maintain Electronic Protected Health Information (ePHI)? What type of ePHI data is collected? Does the device encrypt the ePHI data?
  • Risk/ Compliance: Is the device equipped with pre-installed anti-malware software? Can you install aftermarket anti-malware software?
  • Anomaly: Does the device support remote software updates? E.g., When network security detected downloads on the device.
The MDS2 documents are a great source of information for medical devices and similar to Threat Intelligence are an excellent tool in the Security Analyst's toolset.


There are a few challenges with operationalizing the MDS2 documents and getting the most out of them:

  1. Awareness: The InfoSec and Security Operations teams that are responsible for the security of HDOs typically are not aware of the existence of the MDS2 and the treasure trove of information in those documents
  2. Access: Different medical device modalities are often managed by different clinical teams and are typically not organized in a centralized repository., In most cases, Security teams do not have access to the MDS2 documents and lose the relevant security information of the medical devices when assessing risk to the network.
  3. Automation (lack thereof): A typical HDO has thousands of medical devices in their inventory, running different software versions. As MDS2 documents are software specific, this translates into manual upkeep of tens of thousands of documents for the entire inventory of medical devices. The manual process of looking up the information contained within the MDS2 document causes delays and errors when planning preventive maintenance or security upkeep.

Another challenge the healthcare industry is facing is that the medical device manufacturers are yet to incorporate the Software Bill of Materials (SBOM) details of their medical devices in the MDS2 forms, though the 2019 MDS2 version recommends it. We are working with OEM vendors to incorporate such information to greatly increase the risk assessment and security of their devices (e.g., QNX Real-Time Operating System (RTOS) BadAlloc vulnerability — CVE-2021-22156 that impacted many medical devices or Treck vulnerability impacting TCP/IP stack).

Complete medical device security controls list in the 2019 MDS2 form:

  1. Management of personally identifiable information
  2. Automatic logoff (ALOF) - Device's ability to prevent access and misuse by unauthorized users if the device is left idle for a period of time
  3. Audit controls (AUDT) - Ability to reliably audit activity on the device
  4. Authorization (AUTH) - Ability to determine the authorization of users
  5. Cyber security product upgrades (CSUP) - Ability to install/upgrade security patches
  6. Health data de-identification (DIDT) - Ability to remove information that allows identification of a person
  7. Data backup and disaster recovery (DTBK) - Ability to recover after damage or destruction of device data, hardware, software, or site configuration information
  8. Emergency access (EMRG) - Ability to access personally identifiable information in a medical emergency
  9. Health data integrity and authenticity (IGAU) - Ability to ensure that the stored data on the device has not been altered or destroyed in a non-authorized manner and is from the originator
  10. Malware detection/protection (MLDP) - Ability to effectively prevent, detect and remove malicious software (malware)
  11. Node authentication (NAUT) - Ability to authenticate communication partners/nodes
  12. Connectivity capabilities (CONN) - Connectivity capabilities of the device
  13. Person authentication (PAUT) - Ability to configure the device to authenticate users.
  14. Physical locks (PLOK) - Ability to prevent from compromising the integrity and confidentiality of personally identifiable information stored on the device or removable media
  15. Roadmap for third-party components in device life cycle (RDMP) - Manufacturer’s plans for security support of third-party components within the device’s life cycle.
  16. Software bill of materials (SBoM) - A Software Bill of Material (SBoM) lists all the software components incorporated into the device described for operational security planning
  17. System and application hardening (SAHD) - Device's inherent resistance to cyber attacks and malware.
  18. Security guidance (SGUD) - Availability of security guidance for operator and administrator of the device and manufacturer sales and service.
  19. Health data storage confidentiality (STCF) - Ability to ensure unauthorized access does not compromise the integrity and confidentiality of personally identifiable information stored on the device or removable media.
  20. Transmission confidentiality (TXCF) - Ability to ensure the confidentiality of transmitted personally identifiable information.
  21. Transmission integrity (TXIG) - Ability to ensure the integrity of transmitted data
  22. Remote service (RMOT) refers to all kinds of device maintenance activities performed by a service person via network or other remote connection.
  23. Other security considerations (OTHR) - Information not covered in other controls

Palo Alto Networks IoT Security for Healthcare

Palo Alto Networks IoT Security for Healthcare is a pioneering solution using Machine Learning (ML) for observing IoT and IoMT device network behaviors for classifying the devices, identifying anomalies, and making security policy recommendations. We are committed to improving medical IoT devices' security and risk assessment. We take a holistic approach to assessing the risks of IoT devices, MDS2 documents are one such source.

IoT Security for Healthcare supports ingesting the MDS2 documents, all 2004, 2013, and 2019 versions, and extracting the information contained within these documents. To make it further easier for our customers, we have taken a community approach to collectively improving the security and risk assessment of medical devices. You can contribute to the collection of MDS2 documents we support natively in our solution while benefiting from the insights from the MDS2 documents your peers have contributed. Our customers have already contributed ~2000 MDS2 documents.

Our IoT Security solution specifically addresses the challenges associated with the operationalization of MDS2 documents. You can view information extracted from the MDS2 documents in the context of your specific medical device, search for medical devices that match certain attributes of MDS2 (e.g., devices with ePHI), identify anomalies (e.g., devices not capable of remote software updates but are downloading), etc.

Want to learn more?

Contact your Palo Alto Networks representative to request a demonstration or free trial of our IoT Security solution. Or to learn more about managing the IoT security lifecycle, read our Healthcare CISOs Guide to IoT Security.


Subscribe to Network Security Blogs!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.