The Expert's View with Mark Olson

Medical Device Security: A Call to Action

A CISO Says FDA Needs to Address the Risks
Medical Device Security: A Call to Action

There is no shortage of risks to elevate the stress of an IT security practitioner. It is a condition that we all readily accept as part of the profession and, in some perverse way, enjoy as it provides the fuel for the hunt.

See Also: Webinar | The Future of Adaptive Authentication in Financial Services

One risk of particular concern is the security of the IT components embedded within medical devices (see: Monitoring Medical Devices: An Update).

So, let's step it up, FDA. Get out there and make a definitive statement on this matter. 

The Food and Drug Administration classifies devices used for providing medical care into classes, I, II and III. The Class III, and in some cases Class II, devices are required to obtain FDA 501K certification. Such certification is required to ensure the devices perform as intended, are reliable and cannot fail in such a way as to cause harm to a patient.

Our history is full of examples that justify the need for such oversight. For example, federal regulators have applied ever-improving controls and oversight to the automobile industry to ensure safety. These controls are under continuous study and improvement to keep pace with the advances in technology within automobiles.

Unfortunately, this is not happening at the same level in the medical device industry.

Like automobiles, medical devices are continually improving and include more and more computing power within them. To keep device costs as manageable as possible, they utilize off-the-shelf software and electronics. Many are now based on the Microsoft operating system and use off-the-shelf as well as custom-written applications to complete their package.

Stress-Inducing Risk

This increasing use of embedded technology has enabled tremendous strides in the advancement of patient care. It is also generating one of the more stress-inducing risks faced by security practitioners within healthcare.

It is difficult for anyone who uses a computer today to avoid hearing about the risks of not keeping your computer updated with the latest patches or the need to be running an anti-virus program on your computer. No corporate information operations team would even contemplate running the workstations with the first release of Windows XP and with no patches and no anti-virus protection. The risks such a model would present would simply be too high to accept.

Yet this is the environment the vendors of our current generation of medical devices are requiring of us. They do not permit the operators of their equipment to apply any operating system patches or utilize anti-virus programs. That leaves the systems vulnerable to years worth of tried and true malware as well as to all of the emerging server vulnerabilities.

Unreasonable Advice

Device manufacturers' "recommendations" for remediation vary from "isolate the device" to "put them on their own isolated physical network." These may be viable solutions in a small number of systems in a small environment - but they are impractical on a larger scale. It's unreasonable to isolate hundreds of such systems using these methods as the cost in both capital and labor rises exponentially.

I equate this to buying a high-end automobile - such as a Mercedes Benz - and having it delivered with old-style drum brakes and no power brake system, and the salesman advising, "Keep it under 20 mph and you should be able to stop with no problem." The risks presented by this would simply not be accepted by the customer base; no one would purchase the vehicle, and it would soon no longer be offered.

So why are we accepting the equivalent of this situation with our medical devices? The consequences of a medical device misbehaving due to malware are as devastating as the brakes not working adequately on our automobile.

Why has the FDA not stepped up to take the risk out of this equation ? If someone tried to sell an automobile today without an air bag, it would not be permitted to reach the market.

Send a Clear Message

The FDA can, and should, be sending a clear, concise message on this issue. I also challenge the device manufacturers: Don't short-change the engineering of IT support components of your products. The hard part was designing the medical device - how to secure the IT side of the product is well-understood. It is much more expensive to provide this protection at the user level than having it built into the device from the start.

Security as an afterthought is costly.

So, let's step it up, FDA. Get out there and make a definitive statement on this matter. And device manufacturers: Stop short-changing your engineering reputations and finish the job before you ship your products.

Mark Olson is chief information security officer at Beth Israel Deaconess Medical Center in Boston, Mass. He previously has held various engineering and management position at NCR, Digital Equipment Corporation (now HP), Electronic Data Systems (now HP) and Callisma (now AT&T professional services). Olson provides advisory services to security services companies in addition to being a speaker on security operations.



About the Author

Mark Olson

Mark Olson

CISO, Iron Mountain

Before joining Iron Mountain in 2013, Olson served for 10 years as CISO at Beth Israel Deaconess Medical Center in Boston, where he was vocal in encouraging regulators and manufacturers to improve medical device security provisions and safety problem reporting. Olson previously has held various engineering and management positions at NCR, Digital Equipment Corporation (now HP), Electronic Data Systems (now HP) and Callisma (now AT&T Professional Services).




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing databreachtoday.com, you agree to our use of cookies.