Nicholas Daniell, Sunrise Labs
Soapbox

Robust Security Planning Requires Change in Mindset

By Nicholas Daniell
Nicholas Daniell, Sunrise Labs

Product architects are challenged to address security throughout the device lifecycle.

During a conference earlier this year, Suzanne Schwartz, M.D., MBA, director of emergency preparedness/operations and medical countermeasures at CDRH framed the problem of device security well: “Cybersecurity isn’t just a design issue. It’s not just at product launch. It’s a life cycle issue. It requires a change in mindset.”

Implementing a robust security plan for your medical device should be part of your commitment to your customers throughout the device lifecycle. Your customers want to know that the device will function as expected while protecting their information. Many customers are not aware of the multitude of ways that a device’s performance and data may be compromised and will rarely provide requirements that directly speak to security concerns; they just want the device to work as promised. When a customer uses your products, there is an implicit trust relationship that is formed. Product architects are challenged to address security to reinforce this relationship.

An experienced product architect will translate concerns about device lifecycle functionality and data confidentiality into a set of security-related requirements. This set of requirements starts with the regulatory requirements for the target device market. For example, according to IEC 60601 3rd Edition Section 14.13, “software that is intended to be connected by Network/Data Coupling to other equipment that is outside of the control of the manufacture, the manufacture shall list the HAZARDOUS situations resulting from a failure of the Network/Data Coupling”. Another example is in FDA’s cybersecurity guidance document (issued October 2014), which states, where appropriate, that a layered authorization model differentiated by the role of the user or device should be employed.

Ensuring device security often does not stop with meeting just the set of regulatory requirements. Firms generally search for ways to enhance security further, as they are very concerned about the cost of potential security breaches and the ever-changing landscape of sophisticated attacks. The cost of a security breach and violation of your trust relationship with your customers can be high. It can also have a large impact on your firm’s reputation as well as sales, which can alter how the market views your other products. Legislation (specifically the Health Information Technology for Economic and Clinical Health Act, or HITECH) now requires firms to disclose breaches with possible financial penalties. The number of sophisticated attackers is also increasing as more robust attack tools become available, in turn increasing the overall risk of a security breach.

Medical devices are increasingly becoming more complex and part of larger systems, adding to the challenges that product architects face. Security challenges are no longer confined to the device itself. The rapid rise in interoperability requirements and overall device complexity force product architects to think about security challenges more holistically. Often devices are part of a much larger ecosystem of care. A device may connect to a PC, which then connects to a server in the cloud to transfer key medical data. The data may then be analyzed with the information flowing back to the device, following the same path. Data leakage and malicious modification may occur anywhere along the two paths.

The use of standards-based technologies and protocols for connecting devices may also increase the chance of a sophisticated attack; an attacker can use the connection as a way to get into the device. As a responsible citizen within the ecosystem, the device must not only have a level of security within itself but also enable security (and trust) across the ecosystem.

Various system engineering techniques can help product architects better understand the overall problem and develop appropriate countermeasures to form elements of a security plan. Some key techniques include system threat modeling and risk analyses. In threat modeling, an evergreen list of attack modes are developed and tested against the product architecture. The results are understood and countermeasures are developed. It is very helpful to maintain a library of attack modes that can be reused against future product architectures. In understanding the failure modes due to security, one must also perform a risk analysis, gauging the level of severity of the failure mode, along with the probability of occurrence to finally develop an appropriate design countermeasure. For example, a life-threatening failure mode should have much higher priority than one that may be viewed as an annoyance and limiting in impact.

Usability studies must also be taken into account when considering design countermeasures. For example, in cases requiring an authentication/authorization framework to address confidentiality, the framework should match the threat level and risk analysis; not every device needs the same level of confidentiality protection since the data being protected may not be useful outside of the device. Care should also be taken to make sure the security measure is optimized for the computing power available to the device. For example, it may be difficult for smaller devices to perform complex cryptography. If this is an absolute requirement, it might require modifications to the microprocessor and application code. The key here is to have experienced product architects that can find the optimal level of security that enables the appropriate level of trust while also enabling a great user experience.

Your commitment to your customer does not end when they have purchased your device; it lasts throughout its lifecycle. Since the landscape of security challenges is continuously changing, you should also have a plan to address these challenges post launch. If there is a security breach, you may need a way to heal the breach in the field. You should also create a device end-of-life strategy. If there are concerns about data that is retained in the device, there should be methods to remove the sensitive data from the device or make it unusable when the device is being disposed.

Security lifecycle challenges are broad and deep, but they can be addressed using system engineering principles and experienced product architects. Addressing these challenges will help you to ensure a long-lasting trust relationship with your customers.

About The Author

Nicholas Daniell, Sunrise Labs

Comments

  1. Thomas Bousquet

    Great article, Nick. I don’t have much experience with medical devices, but a lot of this information applies beyond the medical field. It got me thinking about how data is secured in other devices/situations. The most obvious to me is the amount of data people input and access with their smartphones. I’m also sure that devices that similarly gather and transmit personal data are being used(or will be soon) in places like schools, police stations, government buildings, banks.

    It must take a lot of work to develop a product that allows users to see security as almost an afterthought while still keeping them secure. Unfortunately the customers probably don’t often recognize the work that goes into this and you won’t hear much about it unless it is something negative like a data leak.

    1. Christine Mukai

      Great article, Nick! Nice job creating more awareness of the importance of security throughout all phases of the development lifecycle, and in particular, from the beginning with threat modeling and risk analysis. I recently attended a talk by a Verizon representative on threats to the healthcare industry. Verizon has put together a very nice research study on the top threats to different industries. You will find some interesting details in this report called 2015 Data Breach Investigations Report which will be helpful in assessing threats for 2016:

      http://www.verizonenterprise.com/DBIR/2015/

      1. Nicholas Daniell

        Thanks for the comment Christine. I take a look a the report. It looks like the report gives some good insight on current current security risks. I believe reports like this can be helpful. It is important when doing risk analysis to have a deep and comprehensive understanding of the risks so you can develop effective mitigation strategies. Thanks again for you feedback.

    2. Nicholas Daniell

      Thanks for the feedback Tom. I agree that this point of view is translatable to many other industries.

      It can be a challenge sometimes to address security issues after the design phase a product has been completed. Security at it’s roots is risk. Applying a comprehensive risk management plan will help a product stay secure in a constantly changing environment. And like you said, if we do everything correctly nobody will know we did anything at all :) Thanks again for you comment.

Leave a Reply

Your email address will not be published. Required fields are marked *