But wait, there's more! Postmarket Security

Congratulations!

You shipped your new software controlled medical device and you built it securely. You did your threat modeling, risk assessment, risk controls and then you verified everything was solid. It feels wonderful. Short of a coordinated attack by a nation state your device will never be hacked. Time to move on to the next great product.

However, in the words of the great cybersecurity expert Justin Bieber, "Never Say Never". Never say your device won't be hacked. The security landscape shifts too fast. As a medical device software developer there are post market security concerns that you need to add to your worry list. This blog post will dive into a few of these post market issues.

Security Issues and Timeliness

Hopefully you have a great team that handles complaints at your company. However, make sure your complaints team is aware of the special attention that security complaints require. In the US, the 2016 FDA post market cybersecurity guidance sets some tight timelines. Since this guidance is several years old you are probably aware of its provisions but if you have not read this before, perhaps you should sit down before you do. If there is a serious security issue with your software, then you have 30 days after learning of the issue to notify your customers and 60 days to fix, test and deploy it.

Yikes. If you do have an uncontrolled security risk, that only gives you 2 months for you and your company to go through the 7 stages of grief plus coding and V&V. If you are like me, it will probably take you a few weeks just to get through the first grief stage of shock and denial that there could even be a problem with your software.

Plan, Plan, Plan

The only way to meet a timeline like this is to plan ahead of time. It is different for us in a regulated industry like medical devices but how long do you think it takes a commercial website like Facebook, Spotify or Apple to fix, test and deploy a security flaw? Definitely faster than 60 days. The elevation of privileges issue CVE-2021-1782 in iOS 14.4 appears to have been patched and deployed in around 30 days to millions of devices.

Some key planning points for handling postmarket security issues:

• Streamline complaint reporting - make sure the complaint team knows that anything that could possibly be a security issue is reported to R&D quickly.

• Monitoring - it will often be the case that a potential security issue shows up with off the shelf software that you use. You need to be monitoring for these and related issues. More on this in a later post.

• Identify security response team - if a potential security issue is reported there needs to be a knowledgeable team already in place to jump in quickly to decide if it is a real issue and what to do about it. This is likely a cross-functional team.

• Coordinated vulnerability disclosure - this includes the complaint intake techniques above including policies to receive vulnerability reports and publish remediation information. This should include sharing the information via membership in an Information Sharing Analysis Organization (ISAO) such as H-ISAC.

• Use good software development tools - commercial internet companies are not doing manual testing

  • Automated unit testing

  • Static analysis

  • Automated software requirements testing

• Robust software update - streamlined and tested methods for getting the fixed software deployed

Example

As an example from 2019, the FDA released an advisory called Urgent/11 where an IP stack vulnerability existed with a number (11) of common platforms such as VxWorks. (BTW- Wind River in my experience is a great company. I am sure they would like to have this issue back but they handled it very professionally.) It is my understanding that the vendors of these common platforms like Wind River notified their customers prior to the public disclosure of the vulnerability so that the customers could be prepared. Let's assume this happened to your product and you got that notification from Wind River or the other vendors, what would/ should happen?

1. You have a coordinated disclosure policy in place that establishes a mechanism like an email or website form where the vendor was able to submit the issue securely and confidentially.

2. You have a response plan and response team with cross functional members that can quickly determine the scope of the issue. This team should include Quality and Regulatory.

3. Hopefully, your premarket threat models already include this type of issue but if they don't then your models would be extended to the new issue.

4. The issue should be risk rated using internal processes or using the MITRE MD CVSS or similar technique. It could be that the issue is not serious at this point which would mean you would only need to document it well. However, let's assume it is.

5. If possible, develop a work around for the issue that your customers can use to secure your system in the field before the fix can be sent. This could be taking the device off the network or configuring the system in an already existing secure mode.

6. Your Quality and Regulatory departments will need to weigh in but my reading of the FDA postmarket guidance is that FDA will not enforce the reporting requirements of the Code of Federal Regulations part 806 regarding corrections if you follow steps like these in this post provided there are no deaths or serious adverse events associated with the issue.

7. Information about the issue should then be shared with customers directly (do you have a customer list sorted by product and software version?) and shared through your ISAO.

8. Now get busy with the rest of the software team to upgrade the bad IP stack in this case and perform the necessary testing to demonstrate full functionality. If you have automated testing this will go much more quickly.

9. Keep your customers and the ISAO notified of the progress.

10. The software upgrade path will have been worked out long ago so use that to deploy your change securely. Obviously, having to bring your product back to get upgraded in the factory would not be ideal.

Personally, I have never been through this exercise with one of my products and I hope I never do but I am sure that having done planning up front will make this process much smoother if the situation ever occurs.

This is my first blog post. I appreciate you sticking with it through to the end. Please leave a comment with your thoughts. Also if you have suggestions for other posts, please let me know. Thanks.