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.
Re: (Score:2)
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.
it outsourcing (Score:2)
also if they had there or some of there it farmed out to some outsourcing firms that can slow down updates / make hard to get stuff done even more so if there is a lot of contractors and sub contractors in the mix.
Re:It's not like they've had 5 months to fix it... (Score:5, Interesting)
Re: (Score:3)
It's a bit more complex than that. First of all, network security IS important. It's just hard. As countless Slashdot 'discussions' have shown. Even if you are a big player like Community you're probably busy running around putting out fires most of the time. Community is big enough that they probably have a dedicated network security team. Somewhere. But they have something like 200 hospitals. And I can guarantee you that they're on different platforms running different software managed by persons
Re: (Score:1)
Re: (Score:2)
No, the nation's most overpaid industry has developed a paper-centered mentality that is difficult to change not because it can't afford to, but because sealing off medical records in paper prisons helps maintain the monopoly status of providers. Whenever you go to a new specialist for the first time, note the wall of paper records behind the receptionist. At the opening of your visit you will have to sit down and fill out a history - this, in a century in which the needed information could easily be zipped
Re: (Score:2)
http://en.wikipedia.org/wiki/H... [wikipedia.org]
Although I believe the ACA actually expanded on HITECH, mandated Meaningful Use requirements, etc. (I was hired at a pediatric clinic in 2008 specifically to help them convert from paper charts to an EHR.)
Re: (Score:1)
Re: (Score:1)
OpenSSL libs were vulnerable.
OS that these libs were on is irrelevant.
Re: (Score:2)
It depends. If your operating system bundled the library and happened to ship it without the heartbeat feature enabled or included then it was also fine.
Re: (Score:3)
Re: (Score:3)
Aren't Juniper routers based on a proprietary version of FreeBSD? Is FreeBSD also vulnerable too then?
Juniper had it fixed back in April already...
http://kb.juniper.net/InfoCent... [juniper.net]
Re:It's not like they've had 5 months to fix it... (Score:5, Funny)
Re:It's not like they've had 5 months to fix it... (Score:5, Funny)
Re: (Score:2)
Its temperature was checked by putting a thermometer in the back door.
Re: (Score:2)
Yeah, the big problem was when they tried to bill for it. The router realized it didn't have good insurance (Community didn't renew the service contract) and so it panicked and tried to muck with the billing program (since it the data had to run through the router anyway). It got confused about billing codes (there probably is an ICD 10 code for this [icd10data.com], but we're not going to 10 for another year), opened a port to talk to another router and, just like a naked Windows 95 box, got pawned.
Re: (Score:2)
All that hockey hullabaloo and that bitch Anne Murray too!
No, not the cause of the breach. (Score:2)
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: (Score:2)
another car ran a red light and you plowed into them it would be all their fault?
Yes. The accident, as simplistically as you're describing it - which implies that "failing" or not, "you" were still able to drive around - is the fault of the driver that broke the law by running the red light. Without that driver's bad driving, the accident would not have occurred. Just like without the Chinese deliberately cracking in to take medical records, they wouldn't have thus been in receipt of those records. Which part of "the data theft cannot happen without a data thief actually acting to do t
I call bullshit (Score:1, Flamebait)
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.
Re:I call bullshit (Score:5, Interesting)
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 [juniper.net]? 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.
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?
Access restrictions (Score:2)
How does getting onto the VPN equate to accessing the secret stuff? Isn't there another layer of security?
Whatever punishment these guys ( the sys admins ) get, it won't be enough. At some point it would be nice to see people who screw up suffer the consequences.
I admin a few machines (annoying, but required). Heartbleed got so much press, I thought everyone patched all their systems within days. I did.
Re: (Score:2)
Am thinking we should look at the requirements and budgets set out by management, before we put the admins into the stockades.
Yeah, the admins probably could have done better, but if there were expressed requirements to do stuff in a given way, perchance from upper management to make something easier, the admins might not have had much say in the matter.
Likewise, if there wasn't sufficient budget to do things correctly (not really seeming likely, given the nature of this beast, but possible), the admins can
Re: (Score:2)
We also don't know WHERE this router was. Community has 200 hospitals. That's a lot of routers. You don't upgrade everything at once, especially in a network that is running 24 x 7. Hell, I wonder how many companies with 200 sites even knows where all of it's routers are.
It could well have been hidden in a file cabinet in a disused lavatory.
Re: (Score:2)
Re: (Score:2)
How does getting onto the VPN equate to accessing the secret stuff? Isn't there another layer of security?
The Heartbleed bug is an extremely serious information disclosure bug.
Via a simple attack the attackers can read the memory of the VPN appliance which holds the latest SSL keys, passwords, usernames, you name it. The attackers could potentially also have been able to read session identifiers and thus potentially bypass 2-factor auth even if it was in place.
Heartbleed will go over in the history as the most expensive bug of all times. It already is, and we have not seen the last of the consequences.
Re: (Score:2)
How does getting onto the VPN equate to accessing the secret stuff? Isn't there another layer of security?
That is a good point. OK, they gained a presence on a sensitive network. How is it that they were able to bang around and breach critical systems on that network with no one noticing? No IDS/IPS that would have detected something like that? Or were the systems so poorly secured that breaching them didn't make enough noise for an IDS to notice?
Re: (Score:2)
No, it's not a good point because you're missing the entire point of the Heartbleed vulnerability. Heartbleed lets you get *everything* SSL-related on a host. It's not "just" the private keys and such; it also contains passwords, authentication tokens, two-factor auth values, and so on. In short, it gives you everything that is required to successfully impersonate a legitimate user, and gain just as much access as that user does.
As for IDS, how the hell is an IDS supposed to recognize that this is an attack
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: (Score:3)
I realize reading the article is considered bad form, but if you read it you'd learn they think they were breached sometime between April and June. Heartbleed was announced in April. That's somewhere between zero to two months. Lots of big shops have a monthly patching cycle, and you don't just drop every patch into a mission critical system the day it arrives.
Re: (Score:2)
Part of the effort is trying to determine what systems are vulnerable during that time as well.
So we get the flaw released on day one, It will take a while to audit all the systems to make sure they are not vulnerable.
Health Care IT is complex, Mixing new technology with extremely out of date technology. You have a LOT of network traffic as all these systems needs to talk to each other. You are required by law to share the data and keep it private at the same time. Data sets are often in the millions of re
Re: (Score:2)
you make excuses, emergency patching can be done quickly and not blindly. At my employer we tested and patched heartbleed on an emergency basis two days after it was announced, evaluating over two hundred servers and patching where necessary.
Re: (Score:2)
Over 200 servers? Lightweight.
A medium sized hospital has thousands of server. And the software often requires out of date OS and Browsers. Healthcare on the average is 10 years behind in IT then the rest of the industry.
Re: (Score:2)
Given our track record with Juniper, "drop everything and patch now" is a foolhardy approach, especially with something as important as a border router or firewall. I wouldn't apply any of their patches without seeing a long track record of safety. With heartbleed there was an unknown level of risk that they would be attacked; with any given Juniper patch there is a known risk the network would just go down.
Of course, given the choice, I wouldn't select a Juniper device to route packets to a doghouse, and
Re: (Score:1)
Re: (Score:2)
Heartbleed may be a huge IT problem, but you seem to have forgotten that health care system decisions are not made by IT security managers. They are run by demi-gods that we mere mortals are instructed to refer to as "doctors." And the doctor's prioritized view of IT is this:
#1. Be Available. I may need this system right this second in order to save a life. I don't care if it's my kid's Nintendo DS, I'm telling you it might save a life.
#2. Stay The Hell Out Of My Way. Don't interrupt me when I'm savi
Re: (Score:1)
Re: (Score:2)
The only way to keep medical information of any type safely is to keep to paper and folder . There is no way that i will ever trust any network attached device with private medical information.
What are you hiding? Do you shit gold nuggets?
Re: (Score:2)
Clearly you don't appreciate my sarcasm. I agree with you anonymous coward.
Re: (Score:2)
Re: (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...
Re: Safe data ? (Score:1)
You can't just walk in and out if you are physically in China.
Paper records limit exposure to roughly the number of employees. Electronic records raises that level to millions from all over the world.
If you share your records in a multi-hospital system, as was the case here, then you now have exposure through multiple poorly managed IT departments.
Re: (Score:2)
Even in the days when you could just walk in and out with the folder, data breaches were rare. And all you could get were a few records anyway.
design (Score:2)
Should such data be on a network accessible from the Internet (even secured)?
It's not like having a second network dedicated to medical enterprise inter-connectivity would make much of a cost difference in the US system.
Re: (Score:2)
Should they even use computers? Maybe they shouldn't even use paper. The most secure system would be to just memorize it all, but then someone might come by with a wrench! Security is now, and always has been, a trade off. It is a delicate balancing act. They could keep all records in a vault, and only allow the President to access it. OTOH, people might die because they get a medication that would be fine for most, but is de
Re: (Score:2)
Should they even use computers? Maybe they shouldn't even use paper. The most secure system would be to just memorize it all, but then someone might come by with a wrench! Security is now, and always has been, a trade off. It is a delicate balancing act. They could keep all records in a vault, and only allow the President to access it. OTOH, people might die because they get a medication that would be fine for most, but is deadly to them because the information wasn't readily available to staff. Would you rather have someone find out you are allergic to a drug, or die because the hospital made damn sure nobody knew?
You've said a lot but you haven't actually addressed the point I'm making. Perhaps you've misunderstood.
Let me try and be more clear.
The medical establishment can have it's own internet - call it medinet or whatever, that does not need to be connected to the Internet.
I see no good reason for this separate infrastructure to connect to the Internet.
Re: (Score:2)
Re: (Score:2)
I understood your point. At least I thought I did. I thought you were proposing that each hospital have a seperate physical LAN for patient data. Now I see your poroposal is even more absurd. You propose that a seperate WAN be created just for hostpitals. In order to make this secure, it would obviously mean running seperate physical connections, which couldn't be run to the same endpoints, meaning of course the investment of billions of dollars including the cost of new buildings, land, construction, security personnel, etc.
I suppose if by "not much of a cost difference" you mean embark on a multi-billion to trillion dollar project that will take decades to complete, then yes. The best part of your idea? It would mean people attack a diffent network, which also would have the same heartbleed style issue, since having a different network doesn't make things magically secure. Great idea though!
You have to decide if you want security or not. If you connect something to the Internet, it is not secure. This is why the military has networks that are not connected to the Internet.
To address your point about heartbleed still being an issue - it would be an 'internal' issue and as such, on a network not connected to the Internet, would not be an entrance point for anyone outside the network and it's much easier to police who does what on your own network than across the Internet.
You think only in term
Re: (Score:2)
I didn't read past that phenomenally ridiculous statement other than to read the second sentence, almost accidentally. Also, .mil. Make sure you explain to the military that the vast majority of the computers they use are insecure. ROTFLMAO
Re: (Score:2)
I didn't read past that phenomenally ridiculous statement other than to read the second sentence, almost accidentally. Also, .mil. Make sure you explain to the military that the vast majority of the computers they use are insecure. ROTFLMAO
I'm sure they're quite aware that anything connected to the Internet isn't secure.
Do you think otherwise? Do you really think that anything that IS connected to the Internet can be completely secure?
I'm putting up with your obnoxiousness for now just to see where you take this, if anywhere.
Re: (Score:2)
No answer from you, as expected based on your previous posts showing that you don't actually know much of anything and try and get by on an acerbic sense of humor that really just comes across as obnoxiousness.
So you go right ahead and ROTFLYAO because it's obviously all that you're truly capable of doing. Well, that and defecating from your mouth.
Re: (Score:2)
Re: (Score:2)
This from an idiot that thinks that disonnecting a network from the internet magically makes it secure :-) Later loser. Plonk
Obviously it isn't magic, though at your level of comprehension (or lack thereof) it might seem like it.
Not connecting a system or a network to the Internet removes the vast majority of possible attack vectors, so yes it's inherently more secure than any system or network connected to the Internet.
As obviously, you have nothing of substance to say so you hide behind insults and obnoxiousness - so please, unless you actually come up with something other than some childish level of discourse just stop answeri
Re: (Score:2)
Dude. You are a completely ignorant kid, with no idea what you are talking about. You claimed that anything connected to the internet is by definition insecure when by your own definition everything is insecure. Now you are finally talking about degrees of security. If you do a little research you can start throwing around some more terms you don't understand, but you can't undo the posts that show how completely clueless you actually are. You can't even figure out that the cost of what you are proposing is astronomical, and the approach almost guarantees that any implemented system will be less secure. You are the reason why the world is dangerous and insecurity is rampant. Just accept that you need to learn what you are talking about before opening your mouth and the internet will be a better place for it. Also, stay out of the security field. It doesn't need more clueless bafoons.
Kid. Continuing to show your complete ignorance, as usual.
Let's go point by point to see how much substance you've actually managed to scrape off your tongue or if it's all just fungus from you not brushing.
" You claimed that anything connected to the internet is by definition insecure when by your own definition everything is insecure."
Yes. I claim this. If you disagree you're free to make some substantial remarks on how exactly this is incorrect. You know, like an adult would
Point value = 0 = no subs
Re: (Score:2)
I see no good reason for this separate infrastructure to connect to the Internet.
Let me know how your IT can remote in from home without having an Internet connection at some point. Remoting in is nearly a requirement of all information systems.
Re: (Score:2)
I see no good reason for this separate infrastructure to connect to the Internet.
Let me know how your IT can remote in from home without having an Internet connection at some point. Remoting in is nearly a requirement of all information systems.
'Remoting' is not in and of itself a requirement. Getting the job done, whatever that job is, is the requirement. If you need 24x7 coverage for whatever job needs to get done, then hire enough people to have onsite 24x7 coverage.
Re: (Score:3)
Re: (Score:2)
With 200+ facilities it kind of has to network accessible if they're using a centralized system.
Yes but not a network that needs to be connected to the Internet.
Operating Systems (Score:2)
What OS do their applications run on? Heartbleed didn't affect Windows, which has it's own SSL code. OpenSSL was the culprit and that's primarily used on *nix/posix systems.
This doesn't prove much of anything, but:
[user@system ~]$ curl -I www.chs.net | grep Server:
Server: Microsoft-IIS/7.5
Re: (Score:1)
Re: (Score:2)
Wow, you didn't even read the *summary*? That's some impressive skill there. Hint: Juniper routers do *not* run Windows. They do terminate SSL though, and therefore see all the data that goes in or out. Which means Heartbleed can be used to extract all that data... including login credentials.
Medical systems least likely to be updated (Score:1)
so the guy to blame is... (Score:1)