While a hack may not lead directly to monetary gain, there are multiple reasons for unauthorized access to devices and data. One reason for data breaches is to obtain information that can assist identity theft and allow someone to obtain opiates. This motivation is a common one in the theft of medical data. Personal health data is a desirable target.

There are other reasons that device hacks are becoming more common. In some instances competitors sponsor the hacking of products to undermine an established market position. Sometimes there is no reason for a device hack—hackers will attempt to hijack any devices just to prove it can be done. Additionally, unethical practitioners may use your device off-label, or a competitor may hijack your device and use it to enhance the value of their product. None of these possible motives should be ignored.

In today’s world it is a given that medical devices will be connected. This can greatly enhance value, but with risks which we must address. Turning a blind eye to these issues is not a supportable product plan.

Security Incidents

News reports include a number of high profile breaches both inside and outside the health space. As always, hackers find a weak link in the chain and proceed to exploit it.

Twenty years ago, security in the credit card processing space was not as robust as it is today. With the growth of online commerce and thus online transactions, there were a number of incidents where personal data and or financial data was compromised. Cases include theft of laptops with databases that were not encrypted and, unsurprisingly earlier this year, there was a case of 43,000 unencrypted health records on a laptop that was stolen.

There was a protected health information (PHI) breach when an electromyography device with PHI on it was stolen, because it looked like a laptop. While the data loss was not on the same scale as a database breach where thousand to millions of records are compromised, we must understand that data on devices needs to be protected.

Clearly in all of these cases we first need to ask, “why is a database of sensitive information on a portable device?” There need to be very good reasons to justify the benefits of this scenario.

Secondly, we need to understand that all PHI must use encrypted storage on the device. Policies must ensure we have multiple lines of defense. The failure of any one cannot allow the compromise of data, so the loss of the device should not immediately expose the PHI.

Thirdly, we have to assume that a hacker is going to try and compromise our device. We may consider these threats to be low risk, but as connectivity continues to grow, potential exposures grow at a much greater rate.

Security Policies

Security has to begin at the highest levels with a simple awareness of the value of the data and the associated responsibility. Our policies need to acknowledge that we should not be keeping any PHI that is not necessary, and we need to guard the PHI that is needed.

Secondly, our policies must acknowledge that medical devices and systems must be secure and cannot have their functions compromised, either by competitors or hackers.

Analyzing the Risk

To conduct a cybersecurity risk analysis, our first task is to ensure access to the appropriate skills. While these skills are still not central to many teams developing medical devices, they are well developed in other industries such as the online transaction processing sector and other places where hackers can compromise financial information. The financial sector has many years of experience in guarding against attacks, which range from compromising functionality to the theft of data. Experience has been built to guard against everything from simple denial of services attacks to database breaches.

Tools

Some industries have clear standards on exactly what needs to happen to secure data and systems. Medical device and systems do not have a fully prescriptive set of requirements yet. Fortunately, there are tools and standards that will assist in properly securing devices and systems.

IEC-62304 is a good starting point. It helps to define process and structure, which will isolate critical functions. Decomposition of the system and documenting the interfaces will allow for a risk analysis of the interfaces and of any SOUP (Software of Unknown Provenance), such as an operating system.

UL-2900-1 and UL-2900-2-1 are two documents that can help us to identify and mitigate common cybersecurity risks. They include useful references such as http://cwe.mitre.org/ (Common Weakness Enumeration). Listed are common security vulnerabilities and details. Injection attacks are still the most common. These exploit improper processing of user / communication channels inputs where malformed input can access protected data and functions. These attack vectors have been common for decades, and they are still one of the primary vulnerabilities.

Other references enumerate common code weaknesses. While these do not apply to all projects, they are good reference to ensure common errors are addressed.

For all SOUP in the device, attention needs to be paid to all known vulnerabilities. This is an ongoing process to ensure that the risk is understood over time.

These tools can be part of a development processes which can address cybersecurity in a structured manner.

The Development Cycle

Once initial requirements are formed, we need to immediately begin to address security issues. A risk based approach is common. It is useful to segregate issues into data breaches and device function compromises. While there will be an intersection of threats common to both, it is useful to address them separately to highlight specific security issues.

Data

It is common to retain data. The first question we should ask when it comes to PHI is, “Can we delete it?”. If we only require the data for a limited period, or do not require it at all, we can eliminate exposures by deleting the PHI, or keeping it for only a short time. If we need to store the PHI, simple measures of physical protection should be considered. Having the PHI on a portable drive or laptop as part of the system is not a good idea. A device that can be removed is an unnecessary exposure.

Encryption

If we need the PHI, one of the cornerstones is that all PHI should be encrypted. This is not optional. This ensures if someone is able to access the media the PHI will be secured. It is good practice to encrypt not only the PHI but logs as well. If any PHI “leaks” into the logs it will be secured.

As with all encryption, proper key management is necessary. Access to keys should be limited to only necessary people/functions. Frequently this defaults to a wide group including personnel who are necessary for maintenance. One of the attack vectors used by hackers is default keys used for administration. Care must be taken to ensure all of these vectors are closed.

If we are transferring PHI to other systems, we must ensure that the appropriate level of encryption is used; TLS 1.2 is necessary at this time. Many protocols used to transport data will automatically negotiate an encryption method. When provisioning systems we must ensure the appropriate levels are used and non-appropriate encryption methods are not allowed.

Function

We need to guard the operation of our system to ensure that if it is compromised, critical functions are not affected. A good baseline is to isolate critical functions so they cannot be changed. Like deleting unnecessary PHI, this can mitigate many risks. However, with more complex systems, isolating critical functions may not be possible. Proper decomposition, risk analysis and testing are tools that allow us to design and build a system.

Testing

As with all testing, security testing should begin as soon as possible during development. It includes not just direct testing, but also a variety of other activities in support of the goal. Audits of the security architecture and interfaces, as well as code reviews and penetration testing, all provide higher confidence that vulnerabilities will not creep into the device.

Maintenance

Once the system is released it is convenient to have functions and interfaces that allow monitoring, diagnosis and updating. If these capabilities exist, they can be compromised. If the software can be updated, a hacker can update the software. All of these functions need to be carefully audited and tested. A risk analysis should also be performed to compare the benefits of making them available remotely against the risk of the increased attack surface. For example, is it feasible to only allow updates by direct physical access?

Conclusion

As noted early in this article, in today’s world it is a given that medical devices will be connected. This connectivity greatly enhances value, but comes with risks which must be addressed. Include cybersecurity as part of the development, testing, and maintenance process. This ensures connectivity and its associated added capabilities will enhance products without undue exposure. Turning a blind eye to these issues is not a supportable product plan.

Resources

1. MedTech Intelligence. 2018 MedTech Events: FDA Submissions, Cybersecurity, Recalls and More.
   https://medtechintelligence.com/news_article/2018-medtech-events-fda-submissions-cybersecurity-recalls/
2. Healthcare IT News. Data of 43,000 patients breached after theft of unencrypted laptop. http://www.healthcareitnews.com/news/data-43000-patients-breached-after-theft-unencrypted-laptop
3. SecurityFocus. TJX theft tops 45.6 million card numbers. https://www.securityfocus.com/news/11455
4. HIPAA Journal. Stolen Electromygraphy Device Contained 836 Patents PHI, says SSM Health. https://www.hipaajournal.com/stolen-electromyography-device-contained-836-patients-phi-says-ssm-health-8822/
5. Wikipedia. IEC 62304. https://en.wikipedia.org/wiki/IEC_62304
6. UL. FDA Recognizes UL 2900-1 Cybersecurity Standard for Medical Devices. https://www.ul.com/inside-ul/fda-recognizes-ul-2900-1-cybersecurity-standard-for-medical-devices/