This post results from the project “MedSec” within the Munich Cyber Security Program (MCSP) The MCSP is a cooperation project between Champlain College and ComCode (Germany). This project focuses on Cybersecurity topics for medical devices / medical services
This week I dove into the world of Software as a Medical Device (SAMD) and the regulations and applications of security that face this part of MedSec. SAMD is defined as software intended to be used for one or more medical purposes that perform these without being connected to a hardware device. The purpose of the software is to treat disease, prevention of disease, and diagnosis a disease.
SAMD is a rapidly growing part of Medsec and therefore has a rapidly growing threat landscape that regulators have to try and defend against. Many times when it comes to security measures the focus comes to protecting the data that the software collects from the patient and how it is stored. Regulators in both the EU and the FDA have put strict requirements on the securing of the device’s data and all information generated. For example, DiGa, which is a recent platform for SAMD applications, has specifically laid out requirements for data security. The session information for a customer as the connection to the software has to be encrypted and hidden to avoid being vulnerable to attacks such as session hijacking or clickjacking. The data cannot be transferred across the software or out of the device without being encrypted and having some form of access control and authorization attached to it. These are explicitly laid out in their security requirements showing how important data security is. Along with this, the data is required to be stored in a way that prevents it from being transferred off the software’s platform if it’s connected to another software or device. This essentially means that the software has to be designed to be self-insulating. Now, these are just some of the requirements that DiGa requires and these extend to both the software and the post-market monitoring.
Another component to SAMD I found was that due to the information-based nature of these types of devices, the need for information integrity was a top priority. Ensuring that the data is collected correctly and that the information within the software cannot be compromised was key for the regulators. To ensure this every action that occurs involving private patient data is required to be recorded, logged and then this data has to be securely and safely kept away from the rest of the information on the device. This is to ensure that the data doesn’t get mixed up for either the device’s functions or an investigator looking into an incident.
That’s another thing, for SAMD the post-market monitoring is while less restrictive than some devices, it is still comprehensive and operates on a much smaller timetable as threats need to be found and updated much faster than on other devices might be. An emphasis is put on finding vulnerabilities as each software iteration has to have a penetration test and vulnerability/risk assessment done. These have to not only take into account the actual software but whatever software it is intended to be installed on or operated with and how the software interacts with it.
The biggest problem I had this week was figuring out how all the security measures work together and how regulators approach security on a “device” that is not necessarily installed on a machine that the manufacturer controls or has access to. In my search for a solution to this problem, the regulators’ approach was both interesting and reassuring. Next week I will be looking into other ways regulators try to expand these security measures along with seeing examples as to how these tests and changing needs are addressed by manufacturers within the field.
Follow us for more updates on this project! For further questions about Munich Cyber Security Program, or this project please feel free to contact mcsp@comcode.de
Written By: Michael Verdi ’22 // Computer & Information Systems Security