Medical device security
September 11, 2014
Identifying and mitigating risk
By Jeremy Molnar
The technology behind medical devices has advanced exponentially over the last few decades and has helped to streamline procedures and foster research. Unfortunately, the same technology has also been introducing security risks to data that have been left largely unchecked by most organizations.
In order to secure these devices and ensure the protection of data, it’s important to understand the architecture and associated risks affecting medical devices now. Modern medical devices are basically simplified computer systems — they are running an operating system and application specific to the device, and they have memory (and often even a hard drive). Each of these presents its own forms of risk and potential vulnerability. Despite this, medical devices frequently cannot be managed by IT due to U.S. Food and Drug Administration restrictions; however, IT may have the resources, tools, and processes for properly maintaining and securing computer systems in a health care environment.
Recently (specifically April 8th, 2014), Microsoft officially stopped supporting Windows XP. This means that critical vulnerabilities identified as affecting XP will not be addressed, leaving them susceptible to malware, hacking, software errors, and crashing. How does this affect medical devices specifically? Unfortunately, a large percentage of medical devices are still using XP as their backend operating system (OS), likely because it was the newest OS available when the devices were created. It was assumed that since these devices were using an embedded XP configuration, they were more difficult to compromise. Additionally, manufacturers have been resistant to push out supported security updates; in fact, some manufactures have been known to completely resist updating devices at all. This is likely due to the FDA certification process, as most changes or updates would require recertification which can be costly to the manufacturer. The result is devices being left out of an organization’s migration and patch management plans. As “Heartbleed” has recently shown, unmitigated vulnerabilities can result in a significant issue and risk to both systems and data.
Network connectivity is also often found in modern medical devices. Some newer devices may even have wireless capabilities. While the intent of this connectivity is to simplify the process of transmitting data to other systems such as an EHR, it has also made it significantly easier for attackers to attempt to compromise medical devices. In fact, an attacker may not even need to compromise the endpoint device to access its data. He or she could potentially access the data stream if the appropriate protections are not in place. The HIPAA Security Rule identifies the importance of encrypting data (both at rest and in motion), but it leaves it to individual organizations to determine how best to address the specification. This simply means either encrypt or have a very good reason for not encrypting. Unfortunately, a large number of organizations assume that strong perimeter defenses are enough to justify not encrypting. Of course, in these situations, a breach of the perimeter puts the entire network, systems (including medical devices), and data at risk of compromise.
It is important for BioMed, clinical engineering, and other teams managing medical devices to either leverage the expertise of IT to ensure that medical devices are meeting the same stringent standards that have been defined for other computer systems in the environment (where possible) or to define and apply their own security standards. How should these standards be defined exactly? The first step is to conduct a formal risk analysis of individual devices to identify the risks so that they can either be addressed/ mitigated or associated compensating controls be identified. In fact, the FDA released new guidance around the security of medical devices in June 2013, and it identified the importance of manufacturers providing “a specific list of all cybersecurity risks” as well as “a specific list and justification for all cybersecurity controls.” Once the risks have been formally identified, it’s just a matter of identifying needed remediation activities or the details around risk acceptance.
Ultimately, addressing security for medical devices at most organizations likely does not involve developing new processes, rather it requires changing the scope to include those devices. Once an organization has identified that these devices can and do present a risk to the organization, the appropriate steps can be taken to either secure those devices or implement compensating controls which will help ensure the confidentiality, integrity, and availability of the organization’s health data.
About the author: Jeremy Molnar is vice president of technical compliance services for CynergisTek, Inc. Molnar has over 14 years experience dedicated to information security, with nine years focused on health care IT. He has participated in hundreds of assessments and remediation plans with clients to help them build comprehensive information security programs. Molnar graduated cum laude from Excelsior College with a Bachelor or Science in Management Information Systems, and his certifications include CISSP, MCSE, CCNA Security and CIPSS.
By Jeremy Molnar
The technology behind medical devices has advanced exponentially over the last few decades and has helped to streamline procedures and foster research. Unfortunately, the same technology has also been introducing security risks to data that have been left largely unchecked by most organizations.
In order to secure these devices and ensure the protection of data, it’s important to understand the architecture and associated risks affecting medical devices now. Modern medical devices are basically simplified computer systems — they are running an operating system and application specific to the device, and they have memory (and often even a hard drive). Each of these presents its own forms of risk and potential vulnerability. Despite this, medical devices frequently cannot be managed by IT due to U.S. Food and Drug Administration restrictions; however, IT may have the resources, tools, and processes for properly maintaining and securing computer systems in a health care environment.
Recently (specifically April 8th, 2014), Microsoft officially stopped supporting Windows XP. This means that critical vulnerabilities identified as affecting XP will not be addressed, leaving them susceptible to malware, hacking, software errors, and crashing. How does this affect medical devices specifically? Unfortunately, a large percentage of medical devices are still using XP as their backend operating system (OS), likely because it was the newest OS available when the devices were created. It was assumed that since these devices were using an embedded XP configuration, they were more difficult to compromise. Additionally, manufacturers have been resistant to push out supported security updates; in fact, some manufactures have been known to completely resist updating devices at all. This is likely due to the FDA certification process, as most changes or updates would require recertification which can be costly to the manufacturer. The result is devices being left out of an organization’s migration and patch management plans. As “Heartbleed” has recently shown, unmitigated vulnerabilities can result in a significant issue and risk to both systems and data.
Network connectivity is also often found in modern medical devices. Some newer devices may even have wireless capabilities. While the intent of this connectivity is to simplify the process of transmitting data to other systems such as an EHR, it has also made it significantly easier for attackers to attempt to compromise medical devices. In fact, an attacker may not even need to compromise the endpoint device to access its data. He or she could potentially access the data stream if the appropriate protections are not in place. The HIPAA Security Rule identifies the importance of encrypting data (both at rest and in motion), but it leaves it to individual organizations to determine how best to address the specification. This simply means either encrypt or have a very good reason for not encrypting. Unfortunately, a large number of organizations assume that strong perimeter defenses are enough to justify not encrypting. Of course, in these situations, a breach of the perimeter puts the entire network, systems (including medical devices), and data at risk of compromise.
It is important for BioMed, clinical engineering, and other teams managing medical devices to either leverage the expertise of IT to ensure that medical devices are meeting the same stringent standards that have been defined for other computer systems in the environment (where possible) or to define and apply their own security standards. How should these standards be defined exactly? The first step is to conduct a formal risk analysis of individual devices to identify the risks so that they can either be addressed/ mitigated or associated compensating controls be identified. In fact, the FDA released new guidance around the security of medical devices in June 2013, and it identified the importance of manufacturers providing “a specific list of all cybersecurity risks” as well as “a specific list and justification for all cybersecurity controls.” Once the risks have been formally identified, it’s just a matter of identifying needed remediation activities or the details around risk acceptance.
Ultimately, addressing security for medical devices at most organizations likely does not involve developing new processes, rather it requires changing the scope to include those devices. Once an organization has identified that these devices can and do present a risk to the organization, the appropriate steps can be taken to either secure those devices or implement compensating controls which will help ensure the confidentiality, integrity, and availability of the organization’s health data.
About the author: Jeremy Molnar is vice president of technical compliance services for CynergisTek, Inc. Molnar has over 14 years experience dedicated to information security, with nine years focused on health care IT. He has participated in hundreds of assessments and remediation plans with clients to help them build comprehensive information security programs. Molnar graduated cum laude from Excelsior College with a Bachelor or Science in Management Information Systems, and his certifications include CISSP, MCSE, CCNA Security and CIPSS.