2

I work as a CISO/Director of Cybersecurity for a large hospital. My background is in penetration testing, but I'm fairly new (a couple years) to the healthcare side. The challenge that I and almost every healthcare security exec faces is securing with medical devices that are ghastly expensive to replace and have little or no security. (Except micro-segmtation and ACL's - I hear this as a catch-all solution all the time, but it's far easier said than done).

My question is how can the InfoSec community gather together and fundamentally reject the way medical device providers are treating security? I have seriously thought about putting together and/or creating what I consider to be "Medical device" security best practices and taking it to HIMMS or something, but I don't know that it would get traction. GE, Phillips and the like are much larger than our purchase orders. I think the government is starting to back away from the "FDA approval" nonsense, but not sure this would be enough.

How have other such guidelines improved or organically matured over time?

SomeGuy
  • 730
  • 3
  • 18

2 Answers2

3

I'm doubtful this is something the infosec community can change. Healthcare is too specialized and the devices are typically proprietary closed black boxes. You could develop a set of security standards and hold every vendor to those standards. Those that fail the audit would be subject to replacement (see below). There are lots of variations of security guidelines available, but honestly, the key to success is going to be strength in numbers... and dollars.

Companies that produce these "weak" products, like all other companies, work for money. The best way to "encourage" better behavior is to hit them where it hurts... the wallet.

If you really want to enact change, and I certainly hope you can, get several large hospitals to ban together and tie your purchases and renewals to specific changes in the products you're buying. Sure, GE and Phillips are monsters in comparison, but while companies treasure these super large customers, they can't depend only on them. If only one of them decided to change vendors, it would hurt too much (ie. all eggs in a couple of baskets). They still need other large and medium sized customers to balance out their revenue streams.

I work for a large software company and I have seen first-hand the impact a large angry customer can have on exactly what kinds of efforts we place in product development. When more than one large customer pushes hard for the same feature, bug fix, whatever, the sales team beats up on the product development team and the improvements get made... fast.

Now, if you're like most large customers, you can't simply refuse to buy a key component of your business... say patient telemetry machines... because you have to have them. But, chances are, you keep buying the same machines from the same company... I mean, most do because it's much easier to support a homogeneous environment. So, let your vendors of these key devices know that after this purchase you will be looking to replace your entire estate of "telemetry machines" because of security concerns. That will get their attention.

Some products are what we call "sticky". That means that once a customer has implemented a solution, it's hard to get rid of... and the vendors of these products know it and will start to take customers for granted. Tell the vendors of these sticky devices that you're putting out an RFP to their competitors. Talk about a scramble! Now, imagine several large customers all telling a particular vendor the same thing.

Also, for products that require licensing & maintenance renewals... tie the renewals and new license purchases to specific feature requests and security enhancements. ie. Make it part of the renewal contract that the vendor will implement A..B..and C within 12 months (or whatever). That way, they are contractually obligated to make the changes. You don't even have to threaten them if they don't meet the goal. At that point it's a breech of contract scenario and let the lawyers deal with it.

If you can get more large hospitals to demand the same things, the power of your request will be magnified significantly.

mikem
  • 248
  • 1
  • 6
3

Speaking from the other side of the fence - the validation period for medical devices is prohibitive in terms of reacting to fresh exploits on the host systems.

If it takes (for example) best part of 6 months to fully verify & validate a release, how do you react to MS pushing patches every Tuesday?

[Even if we were able to fully automate what testing we can automate - something I'm heavily in favour of - that still is probably measured in many weeks as some of the stuff requires physical interactions and you cannot automate that out.]

Approach we are considering will be to physically separate all comms from host via a separate hardware gateway (along the lines of a firewalla).

But I'd be all ears if you folks have any other suggestions or recommendations.

Amiga500
  • 142
  • 5
  • Just an addendum to the above... While I obviously... erm, probably.... can't go promoting who I currently work for on here - and don't really want to given it then opens a can of worms for any queries I post!!! A general rule of thumb across industries - smaller vendors will pay more attention to requests simply due to their scale than the behemoths. If you make a request to me that can sell a dozen systems, then that would at least get considered. [We are working toward IEC 81001-5-1 & IEC/TR 60601-4-5 - not there yet of course, but moving in the right direction.] – Amiga500 May 31 '22 at 14:07