Heartbleed To Blame For Community Health Systems Breach 89
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.
It's not like they've had 5 months to fix it... (Score:1, Insightful)
Oh wait, that's right, they have. Heartbleed became public in early April.
Blame them, not Heartbleed (Score:2, Insightful)
The Heartbleed vulnerability is the cause of the data breach at Community Health Systems
Oh no. The cause isn't a specific software vulnerability, let alone one for which a patch exists from several months now and is universally known. Don't blame Heartbleed, blame the technical stuff. Had they have adequate security and audit policies in place designed to protect the information they guard, and Heartbleed (or any other well-known exploit) couldn't have been used in the first place.
Re:No, not the cause of the breach. (Score:5, Insightful)
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.
Re:It's not like they've had 5 months to fix it... (Score:5, Insightful)
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.
Re:I call bullshit (Score:4, Insightful)
Now there was certainly a lack of understanding of security, and they clearly have a crunchy on the outside chewy in the middle setup, but that has nothing to do with SSL, nor is it absurd to allow employees to VPN in to the hospital.
Perhaps you have heard of online banking? I'm curious. How exactly do you propose to do that without SSL?
Re:Safe data ? (Score:3, Insightful)
Yeah, paper is much safer because you can't just walk in and walk out with the folder.
But you can't walk in from Russia and walk out with 4.5 million folders either...