Heartbleed To Blame For Community Health Systems Breach

← Back to Stories (view on slashdot.org)

Heartbleed To Blame For Community Health Systems Breach

Posted by Soulskill on Wednesday August 20, 2014 @12:12AM from the bet-you-wish-you'd-patched dept.

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.

89 comments

Min score:

Reason:

Sort:

It's not like they've had 5 months to fix it... by Anonymous Coward · 2014-08-20 00:16 · Score: 1, Insightful

Oh wait, that's right, they have. Heartbleed became public in early April.
1. Re:It's not like they've had 5 months to fix it... by Anonymous Coward · 2014-08-20 00:26 · Score: 0
  
  Oh wait, that's right, they have. Heartbleed became public in early April.
  But we're understaffed and data security is such a low priority . . .
2. Re:It's not like they've had 5 months to fix it... by fuzzyfuzzyfungus · 2014-08-20 00:29 · Score: 5, Funny
  
  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.
3. Re:It's not like they've had 5 months to fix it... by dannywoodz · 2014-08-20 00:34 · Score: 1
  
  It was: http://www.freebsd.org/securit.... FreeBSD has OpenSSL in the base system, but can simultaneously have a different version installed via the ports system. Make sure you update both.
4. Re:It's not like they've had 5 months to fix it... by thieh · 2014-08-20 00:35 · Score: 1
  
  Says who they are staffed at all? unless it takes 5 months to investigate I say someone is getting fired.
5. Re:It's not like they've had 5 months to fix it... by Sproggit · 2014-08-20 00:35 · Score: 1
  
  OpenSSL libs were vulnerable.
  OS that these libs were on is irrelevant.
6. Re:It's not like they've had 5 months to fix it... by thieh · 2014-08-20 00:38 · Score: 2
  
  FreeBSD patched it back in April; when/whether the sysadmins want to firmware-update their stuff is a separate discussion.
7. Re:It's not like they've had 5 months to fix it... by plover · 2014-08-20 00:49 · 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.
  
  --
  John
8. Re:It's not like they've had 5 months to fix it... by rhazz · 2014-08-20 01:08 · Score: 5, Funny
  
  Dammit Jim! I'm a doctor, not a server administrator!
9. Re:It's not like they've had 5 months to fix it... by RivenAleem · 2014-08-20 01:31 · Score: 1
  
  Its temperature was checked by putting a thermometer in the back door.
10. Re:It's not like they've had 5 months to fix it... by Anonymous Coward · 2014-08-20 01:32 · Score: 0
  
  Exactly... and it is COMPLETELY RATIONAL for this timeline to be as described. The real question should be, what steps could have been enacted immediately to alert and acknowledge a possible security breach, how should that occur, and who should see it done.
  Large corporate environments need more lead time on these issues...
11. Re:It's not like they've had 5 months to fix it... by Anonymous Coward · 2014-08-20 01:54 · Score: 0
  
  > 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.
  It is certainly true. While work can be done without IT if necessary, it does take longer, and with limited resources that leads to bad treatment. So availability is mission critical. Security is, too, but unlike a nuclear reactor, medical systems are much more open, with many interfaces. Security is always going to be difficult to maintain. OpenSSL was state of the art until recently, and well trusted. Maybe that has shifted slightly, and in high security environments, several layers of security are now indicated.
12. Re:It's not like they've had 5 months to fix it... by guru42101 · 2014-08-20 02:10 · Score: 4, Interesting
  
  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.
13. Re:It's not like they've had 5 months to fix it... by kthreadd · 2014-08-20 02:16 · Score: 1
  
  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.
14. Re:It's not like they've had 5 months to fix it... by ColdWetDog · 2014-08-20 02:47 · Score: 2
  
  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 of differing abilities.
  When you have a breach like this, you don't just go "Eureka! I've found it!". You start out with "what the fuck...." You call somebody else. Who calls somebody else. Who calls the feds. Somebody else calls corporate legal.
  Now you have a real problem. You have at least one committee.
  And we all know how well this scenario turns out...
  
  --
  Faster! Faster! Faster would be better!
15. Re:It's not like they've had 5 months to fix it... by ColdWetDog · 2014-08-20 03:25 · Score: 1
  
  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, 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.
  
  --
  Faster! Faster! Faster would be better!
16. Re:It's not like they've had 5 months to fix it... by Anonymous Coward · 2014-08-20 04:01 · Score: 0
  
  I used to work for these clowns. The people at corporate play musical chairs at such at rate that large projects regularly get lost in the shuffle or postponed while entire chains of management either quit or get sucked into different groups.
  Its not that its a large corporate environment. It's that its a large corporate environment managed by a horde of shrieking monkies that wont move on your giant project with a deadline tied to government penalties, but dont want you to proceed without their say so.
17. Re:It's not like they've had 5 months to fix it... by sabri · 2014-08-20 04:59 · Score: 2
  
  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...
  
  --
  I'm not a complete idiot... Some parts are missing.
18. Re:It's not like they've had 5 months to fix it... by Applehu+Akbar · 2014-08-20 07:38 · Score: 1
  
  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 over from your gateway practitioner. Each time you fill out one of these monstrosities, you run the risk of misremembering some part your lifetime record of symptoms and treatments, any of which might be critical to the procedure you are about to undergo.
  The one part of the ACA that I really applaud is the mandate to digitize medical records. Long after we've gotten over the controversy about increased insurance rates and copays, this will be the part that we will look back on with affection.
19. Re:It's not like they've had 5 months to fix it... by mschwanke97402 · 2014-08-20 11:54 · Score: 1
  
  "Even if you are a big player like Community you're probably busy running around putting out fires most of the time." Which translated likely means that you've given your IT department short shrift. If IT hasn't the time to keep current with security then they are incompetent or understaffed. Either way it is management's fault.
20. Re:It's not like they've had 5 months to fix it... by brentrad · 2014-08-20 14:57 · Score: 1
  
  One small nitpick: it was actually The Health Information Technology for Economic and Clinical Health Act (HITECH), a part of the 2009 stimulus bill, that first mandated digitizing medical records.
  
  http://en.wikipedia.org/wiki/H...
  
  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.)
Blame Canada by Anonymous Coward · 2014-08-20 00:21 · Score: 0

They've been jealous of our health care, I've seen this coming.
1. Re:Blame Canada by gmhowell · 2014-08-20 06:42 · Score: 1
  
  All that hockey hullabaloo and that bitch Anne Murray too!
  
  --
  Jesus was all right but his disciples were thick and ordinary. -John Lennon
No, not the cause of the breach. by ScentCone · 2014-08-20 00:24 · Score: 1

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.

--
Don't disappoint your bird dog. Go to the range.
1. Re:No, not the cause of the breach. by Charliemopps · 2014-08-20 00:43 · Score: 4, 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.
2. Re:No, not the cause of the breach. by Anonymous Coward · 2014-08-20 02:04 · Score: 0
  
  If your breaks were failing,
  It's brakes, not breaks.
3. Re:No, not the cause of the breach. by Anonymous Coward · 2014-08-20 02:34 · Score: 0
  
  The company is definitely at fault. No question. However it would be interesting to know what other vulnerabilities were exploited. I mean it is fine to say that the heartbleed vulnerability was exploited to get them a VPN connection to the network. OK, that's the first step. Honestly if someone comes to our companies network and plugs their notebook into an ethernet jack they aren't going to get very far without some exploit to use. I'd like to know what these attackers did once they were ON the network. I'm sure their databases have some sort of authentication and their front end servers must too. Was it just SQL injection after that or something else? Inquiring minds want to know dammit!
4. Re:No, not the cause of the breach. by ScentCone · 2014-08-20 06:10 · Score: 1
  
  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 the crime" are you unclear about? Though your car analogy is a bad one, it's very similar to, "You can't be in a collision with a person driving a car through a red light without that other person actually running the red." It's not complicated.
  
  --
  Don't disappoint your bird dog. Go to the range.
5. Re:No, not the cause of the breach. by Anonymous Coward · 2014-08-20 07:09 · Score: 0
  
  Sometimes people make typos, them's the brakes.
I call bullshit by Gothmolly · 2014-08-20 00:24 · 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.

--
I want to delete my account but Slashdot doesn't allow it.
1. Re:I call bullshit by Anonymous Coward · 2014-08-20 00:32 · Score: 0
  
  That being the least of their issues. If they're stupid enough to do that, then they're even stupider than you expect.
  Likely there was a "once you're in, you're in" policy going on.
2. Re:I call bullshit by fuzzyfuzzyfungus · 2014-08-20 00:45 · Score: 4, 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? 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.
3. Re:I call bullshit by Zero__Kelvin · 2014-08-20 01:57 · Score: 3, Insightful
  
  It might surprise you to know this, but one of the main purposes of SSH and HTTPS is to allow internet based access to LANs securely. Saying they are stupid for using the right tool is, well, stupid. How do you propose to implement a VPN without SSL? What, exactly, do you think the purpose of SSL is?
  
  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?
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Access restrictions by ebonum · 2014-08-20 00:25 · Score: 1

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.
1. Re:Access restrictions by GNious · 2014-08-20 00:29 · Score: 1
  
  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 cannot really be blamed.
2. Re:Access restrictions by thieh · 2014-08-20 00:30 · Score: 1
  
  Hospitals do run 24/7 so the patching window might be a bit different than most places. But then again, backup and failover is supposed to be a thing.
3. Re:Access restrictions by benjymouse · 2014-08-20 01:57 · Score: 1
  
  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.
  
  --
  Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
4. Re:Access restrictions by ColdWetDog · 2014-08-20 03:31 · Score: 1
  
  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.
  
  --
  Faster! Faster! Faster would be better!
5. Re:Access restrictions by Jawnn · 2014-08-20 03:41 · Score: 1
  
  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?
6. Re:Access restrictions by Anonymous Coward · 2014-08-20 08:50 · Score: 0
  
  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.
  the junipers are in brentwood in their main corporate datacenter. the hospitals connect back to the main corporate datacenter over an mpls cloud.
7. Re:Access restrictions by cbhacking · 2014-08-20 09:10 · Score: 1
  
  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? Sure, if it could recognize Heartbleed requests that would work, but if the IDS had been updated since Heartbleed went public then surely the router would have been updated too...
  
  --
  There's no place I could be, since I've found Serenity...
It's not like they've had 5 months to fix it... by Anonymous Coward · 2014-08-20 00:26 · Score: 0

Aren't Juniper routers based on a proprietary version of FreeBSD? Is FreeBSD also vulnerable too then?
Blame them, not Heartbleed by Anonymous Coward · 2014-08-20 00:28 · 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.
1. Re:Blame them, not Heartbleed by plover · 2014-08-20 00:56 · Score: 2
  
  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.
  
  --
  John
2. Re:Blame them, not Heartbleed by Anonymous Coward · 2014-08-20 01:59 · Score: 0
  
  UNLESS.... its a mission critical patch....
3. Re:Blame them, not Heartbleed by jellomizer · 2014-08-20 02:04 · Score: 1
  
  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 records.
  Just going patching your systems blindly is open to disaster as you could cause a systems that is critical for maintaining life for a person to fail. These updates need to be scheduled with a fail plan in place.
  
  --
  If something is so important that you feel the need to post it on the internet... It probably isn't that important.
4. Re:Blame them, not Heartbleed by Anonymous Coward · 2014-08-20 02:40 · Score: 0
  
  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.
  The Heartbleed patch isn't/wasn't a garden variety update. For an SSL VPN appliance it would defeat the whole point of the system: security.
  There need to be procedures in place to allow these type of updates to occur off-cycle.
  Revenue Canada (~IRS) took down their services in the middle of tax season (a few weeks before the deadline), and even the few hours they were up caused some personal information to leak.
  Hearthbleed was a "drop everything, upgrade, and get a new cert, NOW" vulnerability, especially on external facing systems.
5. Re:Blame them, not Heartbleed by TMYates · 2014-08-20 02:57 · Score: 1
  
  Saying that an exploit couldn't have been used in the first place is just nonsense. It would be better to say that with the adequate security and audit policies in place, they should have been alerted as soon as someone started trying to test for a heartbleed vulnerability. Action should have been taken as soon as they saw traffic repeatedly running a heartbleed exploit to prevent the disclosure of the information. Nothing can cover 100% and in this case, they were likely waiting on a vendor to patch their system. At the time the passwords were scraped, Juniper may have still been working on a patch (assuming the information that it was a week after announcing heartbleed). This should have been where the IT admins ordered the 72oz cups of coffee and stared at the screen for days on end.
6. Re:Blame them, not Heartbleed by iggymanz · 2014-08-20 03:45 · Score: 1
  
  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.
7. Re:Blame them, not Heartbleed by plover · 2014-08-20 07:34 · Score: 1
  
  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 would never place one as a mission critical node on any network. Then again, that's not my choice to make, just one we have to live with.
  
  --
  John
8. Re:Blame them, not Heartbleed by mschwanke97402 · 2014-08-20 11:59 · Score: 1
  
  Ahem! Heartbleed has got to be one of the most important exploits announced in the last few years. Anyone in a position of managing IT security had no excuse for not immediately reviewing their exposure and implementing any required remedial action. Now, if it were to come out that IT types wanted to do something but were blocked by management concerns of convenience or cost...
9. Re:Blame them, not Heartbleed by jellomizer · 2014-08-21 03:41 · Score: 1
  
  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.
  
  --
  If something is so important that you feel the need to post it on the internet... It probably isn't that important.
10. Re:Blame them, not Heartbleed by plover · 2014-08-21 10:35 · Score: 1
  
  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 saving someone's life. And you don't know when that is; just that if you're interrupting me, it probably is now.
  #3. Give Me Exactly What I Want. For I am the giver of life and death, and you must respect me.
  So unless a problem is currently causing them an outage (so not just any old problem, it has to be causing an actual outage), it won't rise to the level of severity that says "skip all quality control processes and immediately patch this."
  It doesn't matter if the router is vulnerable to hacking. It doesn't matter if a hacker who pwns the router could brick it. It doesn't matter if he is stealing patient records. Those things aren't interfering with #1, 2, or 3. So follow procedures, deploy it in a lab, go through testing and QA, and install it only on Wednesday afternoons when the hospital admins are all on the back nine.
  
  --
  John
Safe data ? by Anonymous Coward · 2014-08-20 00:31 · Score: 0

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.
1. Re:Safe data ? by VTBlue · 2014-08-20 00:40 · Score: 1
  
  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?
2. Re:Safe data ? by hsmith · 2014-08-20 01:35 · Score: 1
  
  Yeah, paper is much safer because you can't just walk in and walk out with the folder.
3. Re:Safe data ? by Anonymous Coward · 2014-08-20 02:06 · 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...
4. Re: Safe data ? by Anonymous Coward · 2014-08-20 02:15 · 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.
5. Re:Safe data ? by Wansu · 2014-08-20 03:06 · Score: 1
  
  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.
  
  --
  Wansu, th' chinese sailor
6. Re:Safe data ? by Anonymous Coward · 2014-08-20 19:51 · Score: 0
  
  If you have nothing to hide, you won't mind posting your medical records here (and financial records too, while we're at it)?
7. Re:Safe data ? by VTBlue · 2014-08-21 14:19 · Score: 1
  
  Clearly you don't appreciate my sarcasm. I agree with you anonymous coward.
design by sociocapitalist · 2014-08-20 00:52 · Score: 1

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.

--
blindly antisocialist = antisocial
1. Re:design by Zero__Kelvin · 2014-08-20 02:05 · Score: 1
  
  "Should such data be on a network accessible from the Internet (even secured)?"
  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?
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
2. Re:design by guru42101 · 2014-08-20 02:12 · Score: 2
  
  With 200+ facilities it kind of has to network accessible if they're using a centralized system.
3. Re:design by sociocapitalist · 2014-08-20 02:21 · Score: 1
  
  "Should such data be on a network accessible from the Internet (even secured)?"
  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.
  
  --
  blindly antisocialist = antisocial
4. Re:design by Zero__Kelvin · 2014-08-20 02:37 · Score: 1
  
  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!
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
5. Re:design by Bengie · 2014-08-20 04:23 · Score: 1
  
  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.
6. Re:design by sociocapitalist · 2014-08-21 00:15 · Score: 1
  
  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.
  
  --
  blindly antisocialist = antisocial
7. Re:design by sociocapitalist · 2014-08-21 00:26 · Score: 1
  
  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 terms of cost and not in terms of requirements. On top of that you are, of course, pulling the costs out of your ass but whatever - obviously you feel that whatever the cost would be it wouldn't be worth it to have the level of security provided, even comparing those out of your ass estimates versus the mufti-trillion dollar a year medical industry in the US.
  
  --
  blindly antisocialist = antisocial
8. Re:design by sociocapitalist · 2014-08-21 00:29 · Score: 1
  
  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.
  
  --
  blindly antisocialist = antisocial
9. Re:design by Zero__Kelvin · 2014-08-21 00:48 · Score: 1
  
  "You have to decide if you want security or not. If you connect something to the Internet, it is not secure."
  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
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
10. Re:design by sociocapitalist · 2014-08-21 04:04 · Score: 1
  
  "You have to decide if you want security or not. If you connect something to the Internet, it is not secure."
  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.
  
  --
  blindly antisocialist = antisocial
11. Re:design by sociocapitalist · 2014-08-21 19:35 · Score: 1
  
  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.
  
  --
  blindly antisocialist = antisocial
12. Re:design by Zero__Kelvin · 2014-08-22 00:57 · Score: 1
  
  This from an idiot that thinks that disonnecting a network from the internet magically makes it secure :-) Later loser. Plonk
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
13. Re:design by sociocapitalist · 2014-08-23 22:26 · Score: 1
  
  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 answering.
  
  --
  blindly antisocialist = antisocial
14. Re:design by Anonymous Coward · 2014-08-24 00:58 · Score: 0
  
  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.
15. Re:design by sociocapitalist · 2014-08-24 21:40 · Score: 1
  
  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 substance in your remarks.
  "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."
  As I already told you in a previous mail, the cost would be a negligible percentage of the business revenue in the medical, insurance and related industries and as such it would be a cost they would not even feel. Consider the billions of USD currently being paid by banks as fines to the US. Many billions each bank. Billions are only a huge amount of money that someone who thinks small chokes on. Try and get your head around what I said last time you mentioned cost. Billions in costs are nothing compared to trillions in revenue. BNP is paying 9 billion USD. You know what that is for them? 1% (one percent in case the numbers are too complicated for you) of their yearly revenue.
  Point value for your comments = 0 = no substance in your remarks. Going to have to scrape that tongue a little harder jerky.
  Now why don't you pull something else out of your ass and tell me how a system or network disconnected from the Internet is going to be less secure than one that is connected, all other factors being equal, as all of the Internet related attack vectors have gone away. Of course you cannot, because it cannot actually be more secure, and so you revert to more personal attacks and further load claims without substance, rather stating any actual counter arguments that might actually mean something.
  Big surprise - yet again nothing of value in your answer = Point value = 0 = STILL no substance in your remarks. That tongue must be really nasty with fungus.
  Total value of what came out of your mouth = 0
  Come play with the big boys when you get your shit together, 'Kid'.
  
  --
  blindly antisocialist = antisocial
it outsourcing by Joe_Dragon · 2014-08-20 02:02 · Score: 1

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.
2 factor authentication would have blocked this by Anonymous Coward · 2014-08-20 03:29 · Score: 0

If they would have simply required some type of 2 factor authentication like SecurID for ALL VPN access this would never have happened. Token codes can't be reused.
Operating Systems by ArkiMage · 2014-08-20 04:41 · Score: 1

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
1. Re:Operating Systems by cyberspittle · 2014-08-20 04:50 · Score: 1
  
  It is rare for Windows Server to run on bare metal. Most are run as a virtual machine. Hypervisors are the last thing customers update.
2. Re:Operating Systems by Anonymous Coward · 2014-08-20 07:03 · Score: 0
  
  It is rare for Windows Server to run on bare metal. Most are run as a virtual machine. Hypervisors are the last thing customers update.
  as a guy who used to work there, i can tell you that chs still has hundreds of physical windows servers.
3. Re:Operating Systems by Anonymous Coward · 2014-08-20 08:20 · Score: 0
  
  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
  almost 100% of their servers are using SSL offloading so that an actual network device is the one hosting the SSL certs.... usually an F5 or an ACE.
4. Re:Operating Systems by cbhacking · 2014-08-20 09:14 · Score: 1
  
  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.
  
  --
  There's no place I could be, since I've found Serenity...
Medical systems least likely to be updated by cyberspittle · 2014-08-20 04:49 · Score: 1

With always on and 0 downtime, they are the ultimate target to hack. No need for zero-day exploits. Now, one can get all the personal information they need from the most vulnerable of people. Really makes me sick.
2 factor authentication would have blocked this by Anonymous Coward · 2014-08-20 05:08 · Score: 0

2F was demonstrated to be bypassed with Heartbleed due to the ability to grab the authentication token on devices. Heartbleed was unique because it blew most security technologies using OpenSSL out of the water regardless of best practices and two factor.
so the guy to blame is... by Anonymous Coward · 2014-08-20 06:57 · Score: 1

...brad porter. he pushed really hard to get junipers in to replace the cisco vpn solution. he is also keen on dragging his feet on anything that really didn't matter to him.
WTF? W.T.F.!?! 5 months later...!?! by Anonymous Coward · 2014-08-20 07:10 · Score: 0

On the day that they bug was proclaimed to the world, just before the proclamation, there was a OpenSSL release, which *FIXED THE BUG*. You you get either a patch, or a whole new version (with the patch in). All you have to do is download, do an md5 checksum, compile, install. All of that should take between 5 and 10 minutes (depending on speed of compilation, your exact installation, etc.). I use OpenSSL with a large web application, and because it comes along with 26 other programs, I install, then test the installation, then build it along with rebuilding everything else (building everything else using one script that calls 10 other scripts that build 26 packages takes about 40 minutes (running the script takes 5 seconds of my time, but the computer (4 cores/8 threads) takes 45 minutes @ 100% load and nothing else running). So it might take them a day, or to be in line with weekend processes, 1 week, or maybe even 1 month to get the fix in. 5 months later, they find a problem, and I'm telling you that heartbleed isn't their biggest problem: the CXO in charge of security needs to meet the axe.