A Primer On Device Security, Part 2: Network And Device Controls

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.

Part one of this three-part series focused on purchasing controls and perimeter defenses. This piece will break down both the network and device controls that must be in place to create a secure environment.

Protecting any device starts with implementing the right set of network security controls, from segmenting devices to effectively managing DNS requests.

Network Security Controls

• Network Segmentation: Network segmentation is highly useful in preventing the spread of malware and other threats through a network, and is very beneficial in containing a threat if an endpoint or device is compromised. All medical devices should be an isolated network segment that restricts communication solely to the systems that are required for functionality. All other communications should be restricted. Network segmentation is often achieved through the creation of VLANs and ACLs to control the flow of traffic in VLANs, but can also be achieved by using a separate physical network infrastructure, which is particularly useful in areas where a concentration of the same type of medical device will be deployed.
• Internal Firewalls: Internal firewalls can be used to improve upon network segmentation and to further restrict communications of devices solely to the systems they need to interact with. Firewalls, particularly next generation models, can also monitor and restrict traffic in ways that ACLs in switches cannot, as they typically allow for deeper levels of traffic inspection. Internal firewalls are also highly useful for protecting “one-off” devices, such as an MRI machine, where isolation is sought, but it doesn’t warrant the purchase of an entirely separate physical network infrastructure. Internal firewalls help to promote a zero-trust model with regards to the communication with medical devices.
• Internal Network IDS: If traffic from network segments containing medical devices is routed through an internal network Intrusion Detection System, signatures can be created to detect default login credentials, attempts to connect to command and control IPs, and other forms of network traffic that may indicate an attack on a medical device. While similar in function to an IDS at a perimeter this helps take into account that a compromised endpoint within the organization may be used as a staging ground to launch an attack against medical devices.
• Syslog Server: Where possible, medical device logs should not just be stored on the device itself but should be exported to a distinct syslog server to allow for the collection and analysis of events that affect the device. This is critical in cases where the device itself can no longer be trusted, or a security issue makes the log data on the device inaccessible.
• Log Monitoring: Related to above control, some form SIEM or log analysis should be performed on the collected log data. For example, a high occurrence of failed login attempts on a device or even a high occurrence of successful logins across a large number of devices (outside of scheduled maintenance) may be indicative of an attack from IoT malware like Mirai.
• Vulnerability Scanning: IoT devices should be routinely scanned to ensure they are properly configured and that outdated software does not leave them susceptible to compromise. As such, IoT devices should be included in part of the organization’s larger vulnerability management program. Not all IoT devices and features may be readily assessed by traditional vulnerability scanners and specialized scanners may have to be considered. Even with specialized scanners, there is such diversity amongst IoT devices that manual compliance auditing may be needed in some cases.
• DNS Sinkholes: While some medical devices may require DNS to function properly (e.g. to transmit results by hostname, to connect to update servers, etc.) it is highly likely that these devices will only need to be able to resolve a very limited number addresses. The security of a medical device deployment can be improved by having dedicated DNS servers that can only resolve the limited number of IP addresses required to function. All other DNS requests can be sinkholed.

Device Security Controls

Some of the most critical controls to protect any network enabled medical device will need to be implemented within the device itself. These are recommended configurations that take advantage of such controls. Not all devices will support all controls, but such deficiencies should have been identified in the security audits done prior to purchase and compensating controls identified at the time.

• Change Default Credentials: As widely illustrated by the recent Mirai and Bashlight botnets, default credentials are a highly effective means of leaving IoT devices vulnerable, and medical devices are no exception. All devices should have their default credentials changed prior to deployment on the network, and devices with hardcoded credentials should not be used. Account credentials used in place of the defaults should be compliant with organizational password polices.
• Account Lockout: Changing the default password won’t matter if the device can easily be compromised with a dictionary attack or brute force attack. Account lockout features should be configured to block logins after 3 to 5 login attempts.
• Enable Secure Transport Devices: These should be configured to only send data in a secure format and secure protocols like ssh and https should be used in place of insecure protocols like telnet and http. Insecure networking protocols should be disabled wherever possible.
• Spare copy of firmware/software: In the event that a device is compromised, having a spare copy of its firmware or software is critical to restoring it functional state in a timely manner. Staff should be trained and competent in procedures to load reload software/firmware on the various types of medical devices supported.
• Backup of device configuration: In addition to the software or firmware used to run the device, there is most likely also some custom configuration required to make it run properly on your network. Backing up these custom settings after changes occur will help to ensure that devices can be restored to functional status in as timely a manner as possible.
• Baseline Configurations: Related to the controls above baseline configurations should be established for each device to ensure proper configuration with regard to clinical functionality and security. In the event a device-specific backup is not available, the baseline configuration can be modified to ensure the quick restoration of device in a manner that is compliant with organizational security policies.
• Encrypt Storage: Medical devices should support encryption of any PHI and/or PII stored on the device. This feature should be turned on in case of device theft or an unauthorized user gaining physical access to the device.
• Different User Accounts: Admin accounts and user level accounts should be possible, and ideally, the admin account should be bound to the management interface and unusable on any internet facing interface.
• Restrict Access to Management Interface: The management interface of the device has the potential to do the most damage if it is compromised, as it will more easily allow access to administrative functions.
• Update Mechanisms: Whether via automatic download or the manual install of new software/firmware, all devices will require updating at some point. Mechanisms should be put in place to identify the need for updates and to ensure the routine update of all medical devices so that unpatched vulnerabilities remain minimized.
• Compliance Monitoring: As time passes, changes are often made to systems, and applied updates may introduce changes. Compliance monitoring should be routinely done to ensure that updates or other changes keep device configurations consistent with baseline configurations and organizational security policies.
• Physical Security: Security controls should be put in place to ensure that physical access to medical devices is limited only to authorized individuals, and that physical theft of the device is prohibited.
• Asset Management: Keeping track of where devices are located and what versions of software/firmware they are all running will be invaluable in helping to determine the scope of potential incident. It will also be extremely valuable for tracking the remediation phase of any incident response.

The final segment of this series will focus on interface and central station security, security and penetration testing, and incident response.