This has been a high-profile year for health information technology (IT) cybersecurity incidents, with a particular focus on medical devices being exposed to risk. While the WannaCry ransomware had a limited impact in the United States, it greatly affected hospitals in the United Kingdom. And although the system wiper, NotPetya, did not have a widespread effect, it was quite devastating for the organizations that were hit. Indeed, while never before appearing on its top 10 list, the ECRI Institute ranked “Ransomware and Other Cybersecurity Threats to Healthcare Delivery Can Endanger Patients,” as the number one health technology hazard for 2018.
With this rise in high-profile activities, interactions among stakeholders in our space have jumped as well. The constant focus, driven in large part by the Food and Drug Administration (FDA), has been around “collaboration.” Indeed, in the FDA’s final guidance on postmarket management of device security, it states the following:
“The Agency wishes to promote collaboration among the medical device and Health IT community to develop a shared understanding of the risks posed by cybersecurity vulnerabilities to medical devices and foster the development of a shared understanding of risk assessment to enable stakeholders to consistently and efficiently assess patient safety and public health risks associated with identified cybersecurity vulnerabilities and take timely, appropriate action to mitigate the risks.”
FDA security experts have appeared all over the country to interact with anyone who needs to hear this message. And they have been dedicated collaborators themselves when manufacturers are interacting with security researchers. They are doing everything they can to not be a bottleneck for a manufacturer getting a security patch developed and deployed.
Those interactions with security researchers are referred to as coordinated vulnerability disclosure (CVD). Through CVD, the researcher approaches the manufacturer, which then works with the researcher to agree on a resolution. This allows a fix to be prepared and ready at the time the vulnerability is announced to end users. This process reduces the risk that general knowledge of the issue will lead to exploits in the wild before the fix is ready to go. Again, this is something recommended in the FDA’s postmarket guidance, and more manufacturers are establishing such programs to work with researchers as collaborators.
Supporting this process is a Department of Homeland Security group referred to as Industrial Control Systems Cyber Emergency Response Team (ICS-CERT). CERTs coordinate information among many parties to provide clear communications on discovered vulnerabilities and how to obtain the fix (e.g., software patch). US-CERT works with vulnerabilities in general IT systems and desktop computers. Industrial control systems are part of many “critical infrastructures” that the government deems essential to the operation of our society as a whole. Failure in these systems due to cyberattacks can lead to loss of life. So rather than create a separate CERT for each infrastructure category, ICS-CERT inherited the support of healthcare technology.
If a manufacturer doesn’t have a disclosure policy in place, a researcher can use ICS-CERT as a go-between, and even if the researcher contacts the company directly, getting ICS-CERT involved as a collaborator is valuable. Its charter is to assist in reaching a satisfactory conclusion for discovered vulnerabilities and publish those conclusions in an “advisory” notice on its website. (https://ics-cert.us-cert.gov).
The other external organization that is focused on collaboration in this space is the National Healthcare Information Sharing & Analysis Center (NH-ISAC; https://nhisac.org). ISACs are aligned with critical infrastructure sectors and coordinate among a broad cross section of stakeholders. Sharing information ranges from daily feeds on noted suspicious network activities; to coordination calls when major outbreaks occur; to electronic, web, and in-person forums for asking questions of your peers; and to education and idea exchange. Formal agreements exist among NH-ISAC, ICS-CERT, and the FDA regarding their respective roles and expectations in managing collaboration in this space.
Medical device manufacturers also have device cybersecurity groups that have been formed within both AdvaMed and the Medical Device Manufacturers Association. They meet regularly by phone and discuss issues such as legislation that is working through Congress. Health delivery organizations (HDOs) have similar groups that interact through the Association for Executives in Healthcare Information Security and the Healthcare Information and Management Systems Society.
Manufacturers and HDOs also collaborate through various standards activities. Developing a consensus standard is a true collaboration. AAMI has the Device Security Working Group and security efforts in its wireless group.
Despite the many vehicles for collaboration, certain activities still need to be done. We have yet to find a good forum for a broad cross section of manufacturers and HDOs to meet. Security meetings tend to be dominated by manufacturers, as their budgets often lend them greater flexibility to attend. That said, it has been noted that when we get together, it tends to be the large manufacturers talking to the large HDOs. Again, likely for budget and skills reasons, involvement of small to midsize organizations on both sides tends to be scarce. This lack of participation can mean that solutions that are developed may not scale down adequately.
Areas that we have discussed that require more work include the following:
- Common hospital network architectures. Manufacturers know that there is a wide range of network architectures in hospitals (if you have seen one, you have seen one). It is hugely expensive to research enough institutions to know that a device can be successfully networked in a wide enough set. Coming up with a set of example networks from large to small would be helpful, in order to guide manufacturers in creating products that are ready to network successfully in most HDOs.
- HDOs seek more information on what is in their hospitals so that they can assess risk, particularly when an outbreak is happening. A collective discussion is occurring around using a software bill of materials (BOM) as a means of communication. Much collaboration is needed to ensure that a software BOM can be accurately created and communicated in a form that is usable by an HDO, which may have 2,500 different device types in its inventory. We also need to determine how to track software BOM updates when patches are incrementally applied across an institution’s campus.
- Security questionnaires are a big effort to support by a manufacturer. The MDS2 (Manufacturer Disclosure Statement for Medical Device Security) form is not adequate for most HDOs; therefore, more questions are tacked on, resulting in an additional 100 to 300 items. Each request is different. It would be helpful to reach agreement on a single form that can be used by all, so manufacturers can prepare it once and provide it to anyone who needs it.
The response to the threats that have emerged has been an increasing amount of cross-sector collaboration: from regulators, to government organizations, to HDOs, and to manufacturers. As the FDA said long ago, cybersecurity is a shared responsibility—and collaboration is an essential part.
Ken Hoyme is director of product security at Boston Scientific in Maple Grove, MN, and a member of the BI&T Editorial Board.