Slashdot Mirror
Heartbleed To Blame For Community Health Systems Breach
An anonymous reader writes: The Heartbleed vulnerability is the cause of the data breach at Community Health Systems, which resulted in 4.5 million records (containing patient data) being compromised. According to a blog post from TrustedSec, the attackers targeted a vulnerable Juniper router and obtained credentials, which allowed them access to the network's VPN.
The ticket was accidentally routed to cardiology. The attending physician checked it out and the router's heartbeat was absolutely normal and there was no evidence of bleeding in the chassis.
It would have been good form to update the vulnerable device. But it's not "to blame" for the data loss. The people who willfully broke in and grabbed the patient data are the cause of the loss.
If your breaks were failing, you didn't do anything about it, and then another car ran a red light and you plowed into them it would be all their fault? No, The person that ran the light, the break manufacturer, and more importantly you, would all be at fault. The healthcare company is just as much at fault as the attackers, there's no excuse for not having patched that equipment.
The hospital had an Internet-facing router that was accessible via SSH or HTTPS?
If they were stupid enough to do that, then someone else had probably stolen all their data already.
What if it was a Juniper SSL VPN Appliance? TFA is a bit vague; but if the system has VPN access and Juniper gear it seems pretty likely that they might be using that, which would necessarily involve SSL on an internet facing device, though not necessarily SSH or HTTPS.
They said they think they were breached sometime between April and June. Heartbleed was announced in April. The window was zero to two months, not five.
And it's not that data security is a low priority, it's just that it may not be as high a priority as network availability. This is health care, where problems in communication might affect patient outcomes. "Hey, sysadmin, Doctor Green couldn't respond to his page last night, and the patient died as a result." These are the kinds of arguments that are thrown at the IT departments at every health care provider. Whether or not we consider them rational or valid is irrelevant.
So in that backdrop, we might try to understand that they probably don't just slam in every patch that the vendor has to offer, at least not without a giant process circus. I would guess that they have a patch intake process, where they have to run the patch by some engineering team that evaluates the nature of the patch, and devises some kind of testing plan to execute in their lab environment. They then have to pass it to the testing team who will set up and execute the patch process in the lab, document all their findings, and then turn the patch over to the production network team. They'll put it on their list, and they'll have their own manager who says "whoa, why are you security guys rushing to slam this patch in to my border router? Let's slow down and think about this one."
I could easily see it taking a month in a big, regulated corporate environment.
John
Dammit Jim! I'm a doctor, not a server administrator!
I know people who work there. Their only priority is profit. A few weeks ago they did the largest settlement ever with the feds for defrauding medicare. One of the higher ups in a town hall meeting about their atrocious turn over rate compared their employees to janitors. They put red tape over things that should be simple which causes employees to use improper routes to just get something working for now.