Heartbleed Not Only Reason For Health Systems Breach
Community Health Systems bad patching practices are nothing compared to its poor encryption, network monitoring, fraud detection, and data segmentation, experts say.
A security researcher has announced that the notorious OpenSSL bug,
Heartbleed
, was the initial point of entry for the
attack on Community Health Systems (CHS) that netted 4.5 million identity records
-- but other researchers point out that Heartbleed is only the beginning of the problem.
David Kennedy, CEO of TrustedSec, first announced Heartbleeds involvement on Fox News and in
a TrustedSec blog post
Wednesday afternoon. Kennedy says he had this confirmed by three people close to the incident, who remain anonymous. CHS has not yet publicly confirmed this and could not be reached for comment as of press time.
The initial attack vector was through the infamous OpenSSL heartbleed vulnerability which led to the compromise of the information... Attackers were able to glean user credentials from memory on a CHS Juniper device via the heartbleed vulnerability (which was vulnerable at the time) and use them to login via a VPN, Kennedy said in yesterdays blog post.
This is why we put up
Heartbleed.com
, says David Chartier, CEO of Codenomicon, which discovered the Heartbleed bug, in conjunction with Neel Mehta of Google Security. We were very passionate about telling people how to recover from this.
Codenomicon advised vulnerable parties to not only upgrade to a new version of OpenSSL, but also to revoke encryption keys, issue new encryption keys, and make users change their passwords.
Trouble is, not everyone followed those recovery steps (if any), nor in a timely manner. Chartier says that revoking and re-issuing keys, in particular, took some time for security managers to do. The Heartbleed vulnerability became public April 7. CHS believes the intrusion in their systems occurred in April and June. Chartier says he will be not at all surprised if it turns out that Heartbleed was part of how attackers obtained the records in this attack.
The CHS breach is being hailed as the biggest security incident Heartbleed has caused so far -- at least the biggest one we know about.
Although it is irrational to think that Heartbleed hasn’t already been utilized in even larger-scale attacks prior to the Community Health Systems breach, this is just the largest thus far where the investigation proved Heartbleed was what got them the data, says Evan Keiser, security analyst for SilverSky. Taking into account how long many major corporations, hospitals, government, and healthcare servers were vulnerable to the Heartbleed bug I would be extremely surprised if this was the biggest attack in terms of scale.
Regardless of whether or not CHS has suffered the worst blow from the bludgeoning of the OpenSSL bug, some caution that we should not focus too much on one unpatched vulnerability; there are plenty of other mistakes CHS made.
It seems pretty obvious to me that Heartbleeed could have played a role, but its not how [attackers] got their hands on the data, says Dr. Vincent Berk, CEO of FlowTraq.
Berk compares Heartbleed to sonar pings. Just like most of the pings a submarine sends out arent going to be echoed with anything interesting, Heartbleed hacks can, but rarely will, come back with valuable data like privileged access credentials. Theres no way really to tell what kind of data you [are going to] get, and most of it is trash.
As Berk explains, because of the extensive attention in both industry and consumer media, everyone knew about Heartbleed, and surely competent, caring security professionals would have made sure all systems were adequately patched. Either [CHS] didnt care or theyre just not qualified to manage their systems, says Berk. Assuming they did care, and just failed to patch for such a well-publicized vulnerability, says Berk, I can only imagine how many other ways to get in there are... If it wasnt Heartbleed, it would have been something else.
One of CHSs biggest offenses, says Berk, is that they were only watching for what came into the network, not for what was going out of it -- like 4.5 million customer records. Exfiltrating such a large set of data would take time and computing resources that should have raised red flags.
That is just downright embarrassing, says Berk. Nobody was watching. Nobody was stopping it.
Similarly, just like the large-scale exfiltration of protected data is abnormal, there are other kinds of uncharacteristic behavior that was probably exhibited by the attackers using a legitimate employees credentials.
Its very easy to get your hands on valid credentials, says Nir Polak, CEO and co-founder of Exabeam. Whether its a leak through Heartbleed or merely spearfishing, Polak says, legitimate logins will be lifted and borrowed by attackers.
Trying to prevent that from happening is a worthwhile endeavor, says Polak, but organizations need to act under the assumption that sometimes its going to happen anyway -- and start looking for ways to tell if a legitimate user is behaving strangely.
Its been happening in the fraud protection industry for a long time, says Polak, noting how banks now routinely monitor for inconsistencies in customers purchasing activities. If an expensive purchase is made at a point-of-sale machine in Italy, when the legitimate customer is still buying groceries in New York as usual, the account may be flagged and frozen. [Those methods] just need to be applied to information security.
New technologies are being created to do just that; for example, the BioCatch passive biometrics solution
DarkReading has covered
before.
Patching a highly publicized vulnerability in open-source code is just one small task companies must do to fulfill a bigger responsibility to lock down all the computing tools they use. Chartier points out that some companies may not have realized that OpenSSL was part of their environment, because it might have been located in embedded systems.
It is part of an enterprises’ obligation to their customers and stakeholders, that they understand their supply chains, says Veracode CTO Chris Wysopal. To help, they must look into third-party code auditing programs so they can rapidly assess their deployed environment for software vulnerabilities, even in the case where the software is on an appliance.
Vendors need a way to quickly understand where they have built products with open-source components, Wysopal says. All products should use Software Composition Analysis with an alerting mechanism for rapid response when a new vulnerability is made public in an open source component. And if the software component analysis tool integrates with a SAST solution, all the better so they can instantly find all locations components in their previously scanned code.
Another weakness in CHSs infrastructure is the apparent lack of segmentation in their customer database. CHS owns, leases, or operates 206 hospitals in 29 US states, none of which served 4.5 million patients all on their own.
Heartbleeds role in the CHS breach is noteworthy, but more noteworthy are the pile of best practices (and common sense practices) that the hospital chain failed to do.
While Heartbleed was how the credentials were stolen this time, says Joshua Roback, security architect for SilverSky, this could have just as easily been a common spear phishing attack, similar to the Target attack earlier this year. The real concern is the ability to hack into the database once logged in, and then exfiltration [of] the data.
As of press time, Community Health Systems stock price continues to rise. In fact, it is
nearing its 52-week high
.
Tags:
Heartbleed Not Only Reason For Health Systems Breach