When it comes to protecting patient data, IT executives face an uphill climb — and it’s only getting steeper. From Mirai to Brickerbot, the attacks are becoming increasingly sophisticated, making it critical that medical device security is a top priority. To that end, the Open Web Application Security Project (OWASP) has released a set of best practices for the secure deployment of devices. This initiative aims to educate hospital IT leaders on how to better secure patient information, serving as a compliment to the FDA’s recent postmarket guidelines for improving security in the development and manufacturing of connected medical devices.
In this three-part blog series, project leader Christopher Frenz, who is also director of IT Infrastructure at Interfaith Medical Center, provides a comprehensive guide for securing medical devices. The first piece will focus on purchasing controls and perimeter defenses.
With the growth of EMR systems and the increasing use of network-enabled medical devices, hospitals and other healthcare facilities are becoming more interconnected than ever. While this increasing level of interconnectedness often results in improvements to both the quality and efficiency of patient care, it is not without some potential security drawbacks. Many medical devices are extremely costly to upgrade or replace, and such legacy systems within healthcare facilities are often commonplace.
Moreover, many devices were engineered with patient safety and life-saving as the sole functions, and little attention was paid to security. These trends are evidenced by recent FDA recommendations, as well as numerous security studies that find many medical devices rife with security vulnerabilities. Additionally, such networked-enabled medical devices within hospitals are often not deployed with security in mind, which can further add to the ease of compromise. With the explosion of botnets and other malware that now target IoT devices (of which medical devices can be considered a subtype), the need for security minded deployments of medical devices is more essential than ever. This is intended to serve as a comprehensive guide to the secure deployment of medical devices within a healthcare facility.
One of the best ways to preserve the security of any healthcare environment is to take measures to prevent the introduction of security vulnerabilities by ensuring only devices that provide a reasonable measure of security are introduced.
- Security Audit/Evaluation: Prior to any medical device being purchased or brought onto any network, the device should be compared to the organization’s internal security standards and a determination should be made as to whether the device is capable of meeting them. Can the device comply with password policies, account lockout policies, and other security controls the organization considers essential?
- Privacy Audit/Evaluation: In a similar manner, prior to any system acquisition, a privacy evaluation should be performed to ensure the device possesses the requisite security controls to enable patient data to be collected, stored, and transmitted in a way that is consistent with organizational policy. Where applicable, preference should be given to solutions that were designed with Privacy by Design principles in mind.
- Support: Any device purchased will only be considered supportable by the vendor for a finite period of time. Given the critical role that patching vulnerabilities plays in maintaining the security of any system, particular attention to should be given to what kind of support the vendor will provide, how frequently they release patches, and for how many years they will continue to provide patches. Given the long active lifetime of many medical products, paying attention to the long-term ability to patch systems is a critical security consideration that should weigh in on purchasing decisions.
Wherever possible, medical devices should be fully denied access to anything external, but there are some cases where this might not be possible, as they may need to connect to update servers, transmit data to cloud-hosted medical records systems, or transmit data to third party services for assessment (e.g. remote radiology reading services). These controls are designed to control the flow of information between medical devices and external resources and services.
- Firewalls: Firewalls at the perimeter are an essential control to ensure that communications between medical devices and external resources are either outright denied (where feasible) or restricted to communications that are essential for the device to function properly. In the case where a medical device is reachable over the internet, particular attention should be taken to ensure he device has a separate administrative interface, and that external access to the administrative interface is not possible from outside the organization’s internal network.
- Network Intrusion Detection System: Network Intrusion Detection Systems at the perimeter can be helpful in detecting exploit attempts from external parties, as well as detecting traffic going to command and control sites and ransomware key generation sites. These systems can provide early warning of an attack attempt or successful compromise of a network-enabled device.
- Proxy Server/Web Filter: For devices that communicate with external resources via http and/or https, a proxy server or web-filtering appliance may allow for even finer grained control over communications than a firewall. Moreover, many proxy servers have the ability to perform antivirus scans of Web traffic. Where this is possible, it is recommended to use a different AV engine than the one used on internal endpoints, as that will help to maximize the chance of successful detection for any malware vector. Additionally, many appliances perform the ability to perform SSL stripping and these appliances can often be used as a part of a data loss prevention (DLP) system as a result. DLP may be advisable for use with medical devices that may require internet access in some form, but would not normally be used to transmit PII or PHI to an external entity.
In part 2 of this series, we’ll focus on the network security controls that need to be in place, from internal firewalls to vulnerability scanning.