Information Week [1] is running a piece on FDA Checks of Medical Hardware. After some review a NIST [2] paper quickly jumped into my head and memories of past experiences washed forward. After emailing our handlers alias it seems that a few of us have some direct experience in this matter.

To plug the critical controls [3] and just about all apply but to highlight:

CC3: Secure Configuration for Hardware and Software [4]

CC5: Malware Defense [5]

An interesting point to this is that in some cases if you patch a medical device you can void it's FDA certification. So a cunundrum quickly surfaces; to patch the Windows Embedded "Critical Life Saving Device" or not to patch.

Horror story, report of a fetal monitor crashing along with event correlation tracking a malware infected device on same subnet. Ended up that the fetal monitor had been infected with malware, fortunately it was not in use. 

Another interesting confidence builder? "your IV pump is infected, but don't worry, it can't infect any of the *other* patient equipment" ... 

There are some clear root causes to the above scenarios and something that is accelerating this is network convergence along with Bring Your Own Device programs. As most things are transported over Ethernet [6] networks quickly converge for cost savings measures. It becomes more of a challenge to perform proper network segmentation and traffic separation when you converge N services plus X unmanaged devices.

Something we are observing more often are Physical Infrastructure Security systems (e.g. Building Management, Wireless Door lock systems, Camera Infrastructure, etc) being converged onto Ethernet networks that also host data services to users.

We have seen networks that converge, voice (VoIP), Video, Data and iSCSI [7] and I can tell you that, let alone providing quality of service, it can become high management overhead process to perform network segmentation. The issue arises when cost savings causes decision makers to "Accept Risk" of converged networks and sometimes not fully understanding said risks.

 ==============

Now, some things we can do in the short term:

- Make complaints to your local or state authority (Here in the U.S. that's the FDA [8]). Although this diary is U.S. Centric, it is fairly safe to go down the "Slippery Slope" [9] that a parity of this issue exists in most modern medical institutions.

- Understand what is on your network, apply the critical controls and segment critical infrastructure to mitigate and reduce risk.

- Introduce segmentation controls like Private VLANs. [10] Firewalls for traffic separation, access control lists [11] to restrict device communication.

As the cost savings of Ethernet drives network convergence, we have to take low level measures to reduce risk. Remember a VLAN is not secure traffic separation but only a logical traffic separation measure! It's like saying NAT [12] is a security protocol...

Richard Porter

--- ISC Handler On Duty

Keeping the watch from 35,000 Feet, with In-Flight Wifi on US Flight 1507

[1] http://www.informationweek.com/news/healthcare/security-privacy/232900818

[2] http://csrc.nist.gov/news_events/cps-workshop/cps-workshop_abstract-1_gupta.pdf

[3] http://www.sans.org/critical-security-controls/

[4] http://www.sans.org/cag/control/3.php

[5] http://www.sans.org/cag/control/5.php

[6] http://www.ieee802.org/3/

[7] http://tools.ietf.org/html/rfc3720

[8] http://www.fda.gov/

[9] http://en.wikipedia.org/wiki/List_of_fallacies

[10] http://en.wikipedia.org/wiki/Private_VLAN 

[11] http://en.wikipedia.org/wiki/Access_control_list 

[12] http://en.wikipedia.org/wiki/Network_address_translation