Heartbleed Pricetag To Top $500 Million?
darthcamaro (735685) writes "The Heartbleed OpenSSL vulnerability has dominated IT security headlines for two weeks now as the true impact the flaw and its reach is being felt. But what will all of this cost? One figure that has been suggested is $500 million, using the 2001 W.32 Nimda worm as a precedent. Is that number too low — or is it too high?"
That's ridiculous. I download firmware patches, software patches, etc on a daily basis. Patching heartbleed wouldn't even be out of the ordinary for my job as CIO. It basically costs IT nothing.
If Heartbleed leads to subsequent intrusions, then the pricetag will definitely go into the ten digit range. If web services are patched, both external and internal [1], then it still will be expensive.
[1]: There are a lot of embedded devices that use OpenSSL, some may not be able to be updated, especially if they are used for constant production runs. All and all, if one factored in man-hours and opportunity costs, the factor is larger. Especially because the OpenSSL patches are not done yet, so even patched systems will need re-patched once a stable, "blessed" release is made.
True - being able to manage your browser recognized CAs should be a core function of IT anyways, along with cert replacements. The real cost will be born by customers who largely are unschooled and don't know enough to install new CAs (the worst case scenario where CA certs are replaced across the board and no SSL/TLS CA certs are valid.) On the other hand, it might be enough to do a quick browser check and get them to finally upgrade to a decent browser version that does include the latest CAs. Which, in retrospect, will wind up being a zero-cost item since they should be doing this anyways.
The cesspool just got a check and balance.
I might as well beat all the fear mongering "security" companies that will state all kinds of absurd numbers, so I am going to say 1 trillion and countless lives lost.
Years ago I worked for an IT consulting company and those bozos made a lot of hay from the Y2K bug. They had guys going around saying to customers that they should stockpile food because all the cummins diesel engines had a Y2K bug that required advanced mechanical repairs to solve and basically all food trucks, fuel trucks, fire trucks, etc were all going to be shut down for at least a month. So I made a bet with the guy that this was total BS. On speakerphone I called Cummins very quickly got onto the phone with one of the top guys in their engineering. He said that the only clock in the engines was to keep track of hours of operation and it didn't actually know what date it was, just total hours. He had a guess that the other clock in many trucks would be on the dashboard to say what time of day it was.
This IT guys bozo answer: "Cover up"
So while the heartbleed bug was pretty damn good and definitely cost money, and I am willing to bet that it cost way more money than Y2K (in damage). I am now willing to bet that Heartbleed will go on to cost way more in fear mongered consulting fees and anti Open Source fear mongering. My brother-in-law just stated that Heartbleed showed how weak Open Source really is. He didn't have the faintest idea of what open source was. This guy is in a position to influence government decisions and is surrounded by the decision makers who probably have half the IT knowledge he does. So when the Mega consultants are done whispering in the government's ears I suspect that there will be fewer Open Source projects and that the mega consultants will start selling services such as "Open Source code Audits" and these audits will show vulnerabilities such as "widely leaked source code".
So while the fear mongering will tally up some absurd numbers it will be the defrauding of customers that will really make heartbleed expensive.
That's ridiculous. I download firmware patches, software patches, etc on a daily basis. Patching heartbleed wouldn't even be out of the ordinary for my job as CIO. It basically costs IT nothing.
That is the difficulty with all the estimates. Software defects, upgrades, and maintenance all cost money but it is generally just rolled up as part of the cost of doing business.
Every time a new patch or service pack or update gets released, there is a cost. But the cost is so commonplace as to be meaningless.
From the article, costs 1-5 are just normal business tasks. Of course there is a cost to rolling out patches. Every month's Patch Tuesday has Microsoft's patches costing organizations millions of dollars collectively around the globe. Security audits for this bug need to be done, but they need to be done for all the other recent discoveries as well. They are just costs associated with maintaining servers, much like the cost of oil changes and tires are associated with maintaining vehicles. They are not costs because of the bug specifically, they are costs because of all bugs and attacks generally.
Cost 6, "stolen data" is so vague as to be meaningless; if not heartbleed than some other exploit will be used to steal the valuable data.
//TODO: Think of witty sig statement
NPR this morning mentioned that, in all of 2013, OpenSSL received just $2000 in donations that they could use for "maintenance of the code base" work. (All of their other income was earmarked for specific work for specific customers.)
Funny enough, they said they've gotten some $10,000 this year, in the last few weeks, though note that most of this is small donations from other countries. There's no indication yet that any of the big U.S. corps most affected by this want to pony up the cash for a full security audit, though maybe some have employees working on it internally (for their own servers' versions, or maybe to share upstream).
I liked the analogy made in the NPR story, that OpenSSL is like public works infrastructure, except it has no tax authority for maintenance income. Not that I think paying for software should be mandatory, but hopefully some people will decide that, even when they don't have to pay "tax" on something, sometimes it's in their best interest to do so.
It doesn't hurt to be nice.
Maybe the companies that rely on open source software will realize that supporting the projects financially is in their best interest instead of freeloading like they do now.
Not that I think paying for software should be mandatory
You are forgetting a tenant of economics: there is no such thing as a free lunch. Someone is paying for that software. Heartbleed shows how you pay for it. You can use open source and never donate, living off the work of others for free. That's perfectly acceptable. But when the shit hits the fan, you have to pony up OT and scramble to patch and fix.
It is absolutely mandatory to pay for software. Everything requires resources to be built and maintained. If someone used OpenSSL and did not contribute, then they are now paying for the software.
I finally updated my sig, but now it's lame.
There's no indication yet that any of the big U.S. corps most affected by this want to pony up the cash for a full security audit, though maybe some have employees working on it internally (for their own servers' versions, or maybe to share upstream).
Perhaps the money is going to a more qualified team, the OpenBSD team (fyi - OpenSSH is also theirs, OpenSSL was not). They are doing a massive cleanup pass on the OpenSSL code which is to be followed by a security audit of the code.
Quote from http://www.inferse.com/14435/h...
Heartbleed was introduced into the OpenSSL software library by 31-year-old Robin Seggelmann, a Frankfurt, Germany developer who says that it was likely introduced while he was working on OpenSSL bug fixes around two years ago. “I was working on improving OpenSSL and submitted numerous bug fixes and added new features. In one of the new features, unfortunately, I missed validating a variable containing a length.” The error was also missed by a reviewer responsible for double-checking the code, “so the error made its way from the development branch into the released version,” Seggelmann said.
Cost to fix? free.
Cost to roll out? 1 trillion dollars, because the companies like to milk every excuse in the book.
In a very small non-technical business which relies on some ssl based services, where I am the only nerd, here's my experience.
I had to:
- Test everything with SSL that we use in-house (we got off easy), then patch openssl on our internal web server. That was mostly for fun, since our network is fairly secure, and nobody that uses our internal network would be smart enough to exploit heartbleed. But still, NAT invaders, you never know. Maybe an hour spent, probably less.
- Explain this bug to everyone that isn't tech saavy, how it probably wont make a difference for us, but what it means for security. It wasn't worth calling a meeting over, so I did it individually, took a while, though.
- Make all employees reset ALL of their passwords on the SSL websites we use, after testing a small sample of them and finding several were affected by the bug, better safe than sorry. From a micromanagement standpoint, this is actually a gigantic expense of time, since we generally don't cycle passwords on many of these sites very often, and often share non-critical accounts between employees. There's wasted time when everyone types the old password, scratches their head, tries to remember the new one, has to find someone else to ask, etc.. A customer could walk away in frustration if it takes too long. Probably an hour or two spent.
- Contact any of the web service providers that we use, that I know were affected, sit around, wait on hold (for a long time obviously) to try to get some kind of plan of action or disaster report out of them. Many hours spent, but probably a waste of time anyway.
- Loss of business from downtime of two critical sites that shut down for a few days when they discovered the bug. Not as bad as it could have been if it were a larger business.
So how much did it cost our organization specifically? A couple hundred bucks in time total might be a reasonable estimate. Definitely not a problem for an end user like us.
This is nothing in contrast to a bad IT problem - for example when our entire network got raped by Zeus.....
We're talking every email account compromised, our static ips placed on god knows how many blacklists, practically worldwide email blacklist of our entire domain, very difficult removal, loss of HUGE amounts of business data to cryptolocker, loss of reputation when many of our customers also got the virus from opening emails from us, or received spam under our name, our ISP even cut us offline until repairs were done, we were down for a week.
It even hit a backup drive with cryptolocker because someone left it plugged in, which was very unfriendly when the banks needed to audit some business data that was cryptolockered in two places. Management freaked and required very expensive antivirus software that slowed our computers to a crawl, requiring upgrade or replace of every system in the entire building.
I bet Zeus cost us over 50 grand, we had to change our domain name, which is the worst way out, and who knows what kind of data those assholes got while they were abusing our mail server.
We were tempted to burn the building to the ground and change our name to recover from that one.
ynow... there is a moral to this tale: if businesses and individuals making money from software (libre) had properly funded it, putting some of the money that they saved from not purchasing proprietary software into the hands of those software teams, would we be talking about this now? in all probability, the answer is no. the reason is because those teams would be able to expand, take on more people, pay for security audits and so on which they would otherwise, as we have discovered, not be in a position to do.
so my take on this is that it is really really simple: businesses have received what they paid for, and got what they deserved.
i have been through this experience - directly - a number of times. i worked on samba - quietly - for three years. whilst the other members of the team were receiving shares from the Redhat and VA Linux IPOs, which they were able to sell and receive huge cash sums - i was busy reverse-engineering Windows NT Domains so that businesses world-wide could save billions of dollars.... and not one single one of those businesses called me up to say thank you, have some cash. as a result, about a year after terminating work on samba i was working on a building site as a common labourer.
it was the same story with the Exchange 5 reverse-engineering, which the Open Exchange Team mirrored (copied, minus the Copyright and Credits).
there is a moral to this tale: unlike proprietary software, which has a price tag commensurate with its perceived value, the process of even *offering* payment to individuals working on a software libre project that has been downloaded, usually from a completely different location (via a distro), is completely divorced from the developers actual efforts.
even in shops in rural districts, it is understood that if the door is unlocked and the shopkeeper not there, you help yourself, open the till, sort out your own correct change and walk out. but in the software libre world there is often not even that level of expectation! the software is quotes free quotes therefore it is monetarily zero cost therefore we should not have to pay, right? and businesses are pretty pathological about taking whatever they can get without paying for it.
so the short version is: there is a huge disconnect in software libre between service provision (the software) and paying for that service, and i really cannot see a solution here. perhaps this really should be bigger news: perhaps in this openssl vulnerability we have an opportunity to make that clear.
There was some exploitation of the bug very soon after disclosure, but I can't see a way to win here. You can't tell everyone about the bug without telling the bad guys...
Actually you can. An AC in another story figured it out, and was promptly modded all the way up to +1.
You simply tell everyone that there is a vulnerability, but you do not tell them any details about what the vulnerability is. Instead, you simply announce a release date & time for a patch. People can either shut down their servers until the patch is released, or, if they're feeling lucky, they can keep running the old code until the patch is released since no one actually knows what the vulnerability is and so, in theory, they're in no more danger than they were the day before. Then, at the announced time, you release the patch, and because of the pre-release announcement, everyone with vulnerable servers has already taken them off-line, and so no one gets fucked by the patch essentially telling the hackers about the exploit.