Tag Archives: embedded

Information Security Best Practices

What is more important – patient safety or hospital IT?

What is more important – patient safety or the health of the enterprise hospital Windows network?  What is more important – writing secure code or installing an anti-virus?

A threat analysis was performed on a medical device used in intensive care units.  The threat analysis used the PTA (Practical threat analysis) methodology.

Our analysis considered threats to three assets: medical device availability, the hospital enterprise network and patient confidentiality/HIPAA compliance. Following the threat analysis, a prioritized plan of security countermeasures was built and implemented including the issue of propagation of viruses and malware into the hospital network (See Section III below).

Installing anti-virus software on a medical device is less effective than implementing other security countermeasures that mitigate more severe threats – ePHI leakage, software defects and USB access.

A novel benefit of our approach is derived by providing the analytical results as a standard threat model database, which can be used by medical device vendors and customers to model changes in risk profile as technology and operating environment evolve. The threat modelling software can be downloaded here.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this
risk-driven medical device security

Health Information Technology Patient Safety Action & Surveillance Plan

This is a quick update on two new documents released by the HHS and the IMDRF:

 Health Information Technology Patient Safety Action & Surveillance Plan

The US Department of Health and Human Services published on July 2, 2013 the Health Information Technology Patient Safety Action & Surveillance Plan. The FDA belongs to the HHS.

The plan defines several types of action in three categories: Learn, Improve, Lead.

·       Learn – focuses primarily on monitoring of safety of Health IT in the field.

·       Improve – includes investigating adverse events and taking corrective action. Also included are setting safety priorities and incorporating safety into certification criteria for Health IT.

·       Lead – encourages the private sector leadership for Health IT Safety and develops a risk-based regulatory framework for Health IT.

The plan is found at http://www.healthit.gov/sites/default/files/safety_plan_master.pdf .

 Standalone Medical Device Software: Key Definitions

The International Medical Device Regulators Forum, a medical device-focused regulators-only successor group to the Global Harmonization Task Force (GHTF), has released a new document for consultation regarding the definition of standalone software used for medical purposes.

The document, Standalone Medical Device Software: Key Definitions, was released on 1 July 2013 and is being coordinated by the FDA.

As the document explains, “Software for medical purposes is becoming increasingly important and … can appear in many forms and on many computing platforms.” For example, some software is embedded into a type of medical device, while others are sold as stand-alone software meant to work on a variety of devices (e.g. mobile devices) or settings (e.g. cloud-based computing or local networks).

A major issue with respect to regulators is the fast pace at which the technology is progressing. Accordingly, this leads to problems in understanding what is required and what is expected (note: what is required is not necessarily what is expected and what is expected is not necessarily what is required).

The document provides a detailed analysis and definition of standalone medical device software (SMDS). According to the IMDRF, medical device software – which is defined as a medical device — “may include but are not limited to” the following characteristics:

·       capable of running on general purpose (non-medical purpose) computing platforms

·       not necessary for a hardware medical device to achieve its intended medical purpose

·       may be used in combination (e.g., as a module) with other devices

·       may be interfaced with other medical devices, including hardware medical devices and other standalone medical devices software

Software that meets the definition of SMDS and is part of another software, regardless if the other software has a medical purpose or not, is still considered as a SMDS.

The document is found at http://www.imdrf.org/docs/imdrf/final/consultations/imdrf-cons-sskd-130701.pdf.

If there are any questions, please contact us.

 

Tell your friends and colleagues about us. Thanks!
Share this

The top 10 mistakes made by Linux developers

My colleague, Dr. Joel Isaacson talks about the top 10 mistakes made by Linux developers. It’s a great article and great read from one of the top embedded Linux programmers in the world.

The Little Engine That Could

Copyright 2004 Joel Isaacson. This work is licensed under the Creative Commons Attribution License.

I  try to explain what are the top 10 mistakes made by Linux developers as I see it. I’m aware that one person’s mistake is another person’s best practice. My comments are therefore subjective.

I will use an embedded Linux device, the WRT54GS, a wireless router as an illustration of an embedded Linux device.An interesting article about this device can be found in: http://www.pbs.org/cringely/pulpit/pulpit20040527.html.

“The Little Engine That Could” How Linux is Inadvertently Poised to Remake the Telephone and Internet Markets – By Robert X. Cringely

So what are the top 10 mistakes made by Linux developers?

10 – Pick a vendor.
9 – Then pick a platform.
8 – We are not in Kansas anymore.

Support Issues

10 – Pick a Vendor

  • In my experience picking a large foreign company for support is not the best way to go for various reasons.
  • More about this later.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this

Why Microsoft Windows is a bad idea for medical devices

I’m getting some push back on LinkedIn on my articles on banning Microsoft Windows from medical devices that are installed in hospitals – read more about why Windows is a bad idea for medical devices here and here.

Scott Caldwell tells us that the FDA doesn’t rule “out” or “in” any particular technology, including Windows Embedded.

Having said that, Microsoft has very clear language in their EULA regarding the use of Windows Embedded products:

“The Products are not fault-tolerant and are not designed, manufactured or intended for any use requiring fail-safe performance in which the failure of a Product could lead to death, serious personal injury, severe physical or environmental damage (“High Risk Activities”).”

Medical device vendors  that  use Windows operating systems for less critical devices, or for the user interface are actually increasing the threat surface for a hospital, since any Windows host can be a carrier of malware that can take down the entire hospital network, regardless of it’s primary mission function, be it user-friend UI at a nursing station or intensive care monitor at the bedside.

Medical device vendors that use Microsoft IT systems management “best-practices” often  take the approach of “bolting-on” third party solutions for anti-virus and software distribution instead of developing robust, secure software, “from the ground up” with a secure design, threat analysis, software security assessment and secure software implementation.

Installing third-party security solutions that need to be updated in the field, may be inapplicable to an embedded medical device as the MDA (Medical Device Amendments of 1976) clearly states:

These devices may enter the market only if the FDA reviews their design, labeling, and manufacturing specifications and determines that those specifications provide a reasonable assurance of safety and effectiveness. Manufacturers may not make changes to such devices that would affect safety or effectiveness unless they first seek and obtain permission from the FDA.

It’s common knowledge that medical device technicians use USB flash drives and notebook computers to update medical devices in the hospital. Given that USB devices and Windows computers are notoriously vulnerable to viruses and malware, there is a reasonable threat that a field update may infect the Windows-based medical device. If the medical device is isolated from the rest of hospital network, then the damage is  localized, but if the medical device is networked to an entire segment, then all other Windows based computers on that segment may be infected as well – propagating to the rest of the hospital in a cascade attack.

It’s better to get the software security right than to try and bolt in security after the implementation.Imagine that you had to buy the brakes for a new car and install them yourself after you got that bright new Lexus.

It is not unusual for medical device vendors to fall victim to the same Microsoft marketing messages used with enterprise IT customers – “lower development costs, and faster time to market” when in fact, Windows is so complex and vulnerable that the smallest issue may take a vendor months to solve. For example – try and get Windows XP to load the wireless driver without the shell.   Things that may take months to research and resolve in Windows are often easily solved in Linux with some expertise and a few days work. That’s why you have professional medical device  software security specialists like Software Associates.

With Windows, you get an application up and running quickly, but it is never as reliable and secure as you need.

With Linux, you need expertise to get up and running, and once it works, it will be as reliable and secure as you want.

Yves Rutschle says that outlawing Microsoft Windows from medical devices in hospitatls  sounds too vendor-dependant to be healthy (sic) (Seems to me that this would make the medical device industry LESS vendor-dependent, not more vendor-dependent, considering the number of embedded Linux options out there.)

Yves suggests that instead, the FDA should create a “proper medical device certification cycle. If you lack of inspiration, ask the FAA how they do it, and maybe make the manufacturers financially responsible for any software failure impact, including death of a patient“. (The FDA does not certify medical devices, they grant pre-market approval).

I like a free market approach but consider this:

(Held)The MDA’s pre-emption clause bars common-law claims challenging the safety or effectiveness of a medical device marketed in a form that received premarket approval from the FDA. Pp. 8–17.

Maybe the FDA should learn from the FAA but in the meantime, it seems to me if the FDA pre-market validation process had an item requiring a suitable operating system EULA, that would pretty much solve the problem.

Tell your friends and colleagues about us. Thanks!
Share this

Mcafee embedded device security

If Mcafee is jumping into this area – then it might explain some of the synergy with the Intel acquisition – two years ago, Intel went public with products aimed at driving medical monitoring into the home – see Intel launches medical device for home patient monitoring.  Home monitoring (the Intel Health Guide is a 10.5″ tablet) “is a big area of focus and a growth opportunity for Intel” according to Mariah Scott, director of sales and marketing for Intel’s Digital Health Group.

Enhance device security
Protect embedded devices against existing and unknown zero-day threats via malware (such as worms, viruses, Trojans and buffer-overflow threats, etc.). Because many embedded devices such as ATMs and kiosks have a large attack area, they face increased security vulnerabilities. McAfee Embedded Security ensures that the device—when in production and in the field—is secure and cannot be compromised.

The Mcafee product is clearly aimed at embedded Windows devices – which are unfortunately over 1/2 of embedded medical devices since a good many software developers come from IT backgrounds and don’t have the cojones to deal with Linux let alone embedded Linux on small footprint hardware.  Some of the collateral makes a lot of sense while other parts seem like typical security vendor marcom   –  like the part about assuring HIPAA compliance with tamper free logs. When you have a hammer, everything looks like a nail as I noted in my post last year on the true cost of HIPAA privacy violations

The product feels like a commercialization of a project that their professional services group did for a particular customer. The discussion about supporting integration of multi vendor channels sort of  smells like an Intel aphorism and while it might serve Intel, multi-vendor channel integration may be  the exception rather than the rule in the medical device space,  since most medical device vendors are  small specialized business units or startups intent on preserving their own IP.

Tell your friends and colleagues about us. Thanks!
Share this

Solaris and real-time Java for embedded systems?

It’s always interesting to see if industry analysis stands the test of time, like Dana Gardner (formerly with the Yankee Group, now with Interarbor Solutions)  who told Internetnews.com back in 2004 that  “Solaris may find fertile ground in the embedded space with a combination of real-time Java and the Solaris operating system”.

Hmm. Now there’s an idea.

After coming home from a trip to our Warsaw office and a babysitting stint with our grand-daughter Carmel,

I started cleaning up my Web site archives. I found this article I wrote back in November 2004.  I will let the readers be the judge of the relevance of Sun Solaris as an embedded operating system in 2008.

As usual, Sun is flip-flopping on strategy and looking in the wrong direction – this time towards the embedded market market. Despite the hoopla at this month’s announcement party to launch Solaris 10, the focus for the operating system is moving towards embedded appliances. No wonder – the embedded market in terms of unit shipments is almost 10 times the size of the PC market with over 1.1 Billion units shipping annually. But – even if you can shoehorn Solaris 10 into 64M Ram does it really make sense for Sun to go there?

ARM — including StrongARM and XScale architectures – are gaining on x86 as the most popular processor architecture for embedded development. Since the beginning of 2004, embedded developers are projecting that they’ll base more projects on ARM than x86 processors in their projects during the next two years.

Vendors that use Linux are finding it easier than ever to go straight to the Open Source community and roll their own embedded Linux platforms instead of locking themselves into Montavista for support. Vendors with strong developer expertise in Windows go to Windows CE for embedded applications and leverage their knowledge.

In other words – forget it. Solaris 10 isnt available on the hardware platforms of choice (ARM) and doesnt provide a convincing alternative for developers to switch from their familiar and proven environments whether Open or closed source.


To make things worse, looks like someone at Sun is directing analysts to say stupid things like this:

Scaling Solaris down for the embedded market is exactly what analysts have been suggesting for Sun. Dana Gardner, senior analyst with The Yankee Group, told internetnews.com one area that Solaris may find some fertile ground in the embedded space is with a combination of real-time Java and the Solaris operating system.

“Real time Java” – is this fertile ground or just marketing fluff for Sun?

What do you think ? Let me know!

Tell your friends and colleagues about us. Thanks!
Share this