Hot spots for medical device software security
I think that 2011 is going to be an exciting year for medical device security as the FDA gets more involved in the approval and clearance process with software-intensive medical device vendors. Considering how much data is exchanged between medical devices and customer service centers/care givers/primary clinical care teams and how vulnerable this data really is, there is a huge amount of work to be done to ensure patient safety, patient privacy and delivery of the best medical devices to patients and their care givers.
On top of a wave of new mobile devices and more compliance, some serious change is in the wings in Web services as well.
The Web application execution model is going to go through an inflection point in the next two years transitioning from stateless HTTP, heterogeneous stacks on clients and servers and message passing in the user interface (HTTP query strings) to WebSocket and HTML5 and running the application natively on the end point appliance rather than via a browser communicating to a Web server.
That’s why we are in for interesting times I believe.
Drivers
There are 4 key drivers for improving software security of medical devices, some exogenous, like security, others product-oriented like ease of use and speed of operation.  Note that end-user concerns for data security don’t seem to be a real market driver.

1. Medical device quality (robustness, reliability,usability, ease of installation, speed of user interaction)
2. Medical device safety (will the device kill the patient if the software fails, or be a contributing factor to damaging the patient)
3. Medical device availability (will the device become unavailable to the user because of software bugs, security vulnerabilities that enable denial of service attacks)
4. Patient privacy (HIPAA – aka – data security, does the device store ePHI and can this ePHI be disclosed as a result of malicious attacks by insiders and hackers on the device)

Against the backdrop of these 4 drivers, I see 4 key verticals: embedded devices, mobile applications, implanted devices and Web applications.
Verticals
Embedded devices (Device connected to patient)

1. Operating systems, Windows vs. Linux
2. Connectivity and integration into enterprise hospital networks: guidelines?
3. Hardening the application verus bolting on security with anti-virus and network segmentation

Medical applications on mobile consumer devices (Device held in patient hand)

1. iPhone and Android – for example, Epocrates for Android
2. Software vulnerabilities that might endanger patient health
3. Is the Apple Store, Android Market a back door for medical device software with vulnerabilities?
4. Application Protocols/message passing methods
5. Use of secure tokens for data exchange
6. Use of distributed databases like CouchDB to store synchronized data in a head end data provider and in the mobile device The vulnerability is primarily patient privacy since a distributed setup like this probably increases total system reliability rather than decreasing it. For the sake of discussion, CouchDB is already installed on 10 million devices world wide and it is a given that data will be pushed out and stored at the end point hand held application.

Implanted devices (Device inside patient)

1. For example ICD (implanted cardiac defibrillators)
2. Software bugs that results in vulnerabilities that might endanger patient health
3. Design flaws (software, hardware, software+hardware) that might endanger patient health
4. Vulnerability to denial of service attacks, remote control attacks when the ICD is connected for remote
5. programming using GSM connectivity

Web applications  (Patient interacting with remote Web application using a browser)

1. Software vulnerabilities that might endanger patient health because of a wrong diagnosis
2. Application Protocols/message passing methods
3. Use of secure tokens for data exchange
4. Use cloud computing as service delivery model.

In addition, there are several “horizontal” areas of concern, where I believe the FDA may be involved or getting involved

1. Software security assessment standards
2. Penetration testing
3. Security audit
4. Security metrics
5. UI standards
6. Message passing standards between remote processes