You're cute. I've done this shit for a living for a while. Yes, many companies' incidence response procedures are crap, but they shouldn't, and it is perfectly possible to get an emergency countermeasure deployed within 24 hours with all the t's crossed and i's dotted and perfect SOX compliance and whatever else you need. It's just something you need to think about before the emergency hits you.
But what are you trying to accomplish here? Argue that a project with 100 developers has more eyes on the code than one with 4? Moot point, no argument.
We don't get the luxury of having 50 identical software projects with different team sizes and a size control, so we have to go with the real world and "everything else being equal" is just a way of saying that you if you want to compare closed vs. open source, you need to compare comparable projects, not an open source project with a handful of people with a closed source project two orders of magnitude larger - or the other way around.
sysadmin, firewall admin - let's not pick nits here. The point is that there are mitigating measures, and if signing off on something that prevents your company secrets leaking out to the Internet without you even noticing takes more than 24 hours then your incident response procedures are retarded and you can hire me for a workshop to improve them dramatically.
Yeah, there was absolutely nothing anyone could do. Oh wait, except for this brutally complex and technically challenging thing right from the official vulnerability announcement:
This issue can be addressed by recompiling OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag. Software that uses OpenSSL, such as Apache or Nginx would need to be restarted for the changes to take effect.
That was definitely not a feasabole option for anyone on the planet...
Except for the "nothing can be done" part. That's not your judgement call to make. There is always at least one option - pulling the power plug - and it might well be a feasable temporary solution for some people affected.
But we were talking about mitigating measures. That is almost never patch and recompile, it's things like turning off a service, changing the firewall rules, moving servers into a different network - things that are very much within the duties of the sysadmin (with proper clearance and risk acceptance by management, etc. etc.)
Basically, if you have a bug that makes your internal network open to the world, but you can avoid it by disabling feature X in the config file, and your company doesn't require feature X, then that's something the sysadmin can do, and he can do it right now, while the vendor is working on a patch.
The thing is that the manufacturer must not be the one to set the time they get to fix this
I agree on that 100%
most people are not able to do anything without patch.
That depends a lot on the particular problem. In many cases, there are mitigating measures that can be taken until a patch is available, and I'd argue strongly that the people affected should make the call on that, not you or I or anyone else.
By withholding information, you are making decisions for other people. But you are not in a position to make that call, because you are not the one who suffers the consequences.
I advocate for giving everyone all the information so they all can act according to their needs and abilities. I argue for letting people make their own decisions.
Yes, of course, a closed source development that does external code reviews can have more eyes on the project then an open source development that does no external code reviews. But then you're comparing apples and oranges.
I didn't see it's the thousands of eyes that fanatics claim.
I'm simply saying that if your source code is open, your number of eyes on the project is (dev team) + (people looking at it) while for a closed source project the number is (dev team).
Since "people" cannot be negative, by necessity (dev team) + (other people) >= (dev team)
How does that guarantee that more experts will review a given piece of security code than in a proprietary, closed-source, locked-up development organisation that also has mandatory code reviews?
It doesn't.
It does guarantee that the number of reviewers is equal to or higher, provided everything else is equal.
Yes, this argument is being made a million times and it doesn't prove anything because it rests on so many assumptions that may or may not be true that it's total truth value is about as good as tossing a coin.
The two most important:
First, you assume that the official patch is the only thing that can be done. In many, many cases there are other (temporary) measures that can be taken to mitigate a problem or limit its impact. Who are you to decide for everyone on the planet with their different needs and scenarios which is better?
Second, you assume that there are thousands of hackers who didn't know about it. Yes, it is likely that the number of bad guys knowing about the problem was less than 100% before the announcement. But any real professional doesn't care about number of hackers, he cares about risk, which is number multiplied by impact. If the people who are the worst danger to my business and are most likely to target me already have the exploit, I don't give a fuck about a thousand random script kiddies also getting it.
So are you going to take your server offline until there is a patch?
Depends, but yes for many non-essential services, that is indeed an option. Imagine your actual web service doesn't use SSL, but your admin backend does. It's used only by employees on the road, because internal employees access it through the internal network.
Sure you can turn that off for a week. It's a bit of trouble, but much better than leacking all your data.
Or if it's not about your web service, but about that SSL-secured VPN access to your external network? If you can live without home office for a week, you can turn that off and wait for the patch, yes.
Most importantly, who are you to decide that everyone should wait for a patch instead of giving people the opportunity to deploy such mitigating measures?
I think giving the software vendor 2 weeks to fix the bug (...) is reasonable
People don't learn.
We used to do that.
Full disclosure evolved primarily as a countermeasure because vendors took those grace periods not as a "we need to get this fixed in that time", but as a "cool, we can sit on our arses doing nothing for another two weeks".
As usual, the answer lies somewhere between extremes.
My preferred choice of being left alone or being beaten to a pulp is being left alone, not some compromise in the middle, thank you. Just because there are two opposing positions doesn't mean that the answer lies in the middle.
I've given more extensive reasoning elsewhere, but it boils down to proponents of "responsible disclosure" conveniently forgetting to consider that every delay also helps those bad guys who are in posession of the exploit. Not only can they use it for longer, they can also use it for longer against targets who don't know they are vulnerable.
Many, many companies run non-essential services that they would not hesitate to shut down for a few days if they knew that there's an exploit that endangers their internal systems. Other companies could deploy mitigating measures while waiting for the patch.
Don't pretend sysadmins are powerlessly waiting with big eyes for the almighty vendor to issue a patch.
That is true. However, you also need to take a few other things into account. I'll not go into detail, I think everyone has enough knowledge and imagination to fill in the blanks:
There is an actual black market for exploits where they are bought and sold.
Not announcing a weakness withholds the information not just from the bad guys, but also from sysadmins, preventing mitigating measures and proper risk awareness.
We have over 20 years of history proving that vendors regularily move slower or not at all until a weakness is making headlines
There have been many cases where several researchers had partial information about an exploit, and only once combined was the true impact known. For example, one research might know about the problem and how to exploit it, but thinks it can't be leveraged to a compromise. Another might know about the potential compromise, but think it can't be triggered in a real-world scenario.
Despite all the theoretical arguments seemingly in favour, security through obscurity does not work and we've known that for like forever.
First, OpenSSL is not typical of Free Software. Cryptography is always hard, and other than, say, an Office Suite, it will often break spectacularily if a small part is wrong. While the bug is serious and all, it's not typical. The vast majority of bugs in Free Software are orders of magnitude less serious.
Second, yes it is true that the notion that anyone can review the source code doesn't mean anyone will actually do it. However, no matter how you look at it, the number of people who actually do will always be equal or higher than for closed source software.
Third, the major flagships of Free Software are sometimes, but not always picked for price. When you're a fortune-500 company, you don't need to choose Apache to save some bucks. A site-license of almost any software will be a negliegable part of your operating budget.
And, 3b or so, contrary to what you claim, quite a few companies contribute considerable amounts of money to Free Software projects, especially in the form of paid-for support or membership in things like the Apache Foundation. That's because they realize that this is much cheaper than having to maintain a comparable software on their own.
The only possible way is to disclose to the responsible manufacturer (OpenSSL) and nobody else first, then, after a delay given to the manufacturer to fix the issue, disclose to everybody. Nothing else works. All disclosures to others have a high risk of leaking. (The one to the manufacturer also has a risk of leaking, but that cannot be avoided.)
It's not about leaking. The reason I'm not alone in the security community to rage against this "responsible disclosure" bullshit is not that we fear leaks, but that we know most of the exploits are already in the wild by the time someone on the whitehat side discovers it.
Every day you delay the public announcements is another day that servers are being broken into.
IT security industry experts are beginning to turn on Google and OpenSSL, questioning whether the Heartbleed bug was disclosed 'responsibly.
Are you fucking kidding me? What kind of so-called "experts" are these morons?
Newflash: The vast majority of 0-days are known in the underground long before they are disclosed publicly. In fact, quite a few exploits are found because - drumroll - they are actively being exploited in the wild and someone's honeypot is hit or a forensic analysis turns it up.
Unless you have really, really good reasons to assume that this bug is unknown even to people whose day-to-day business is to find these kinds of bugs, there is nothing "responsible" in delaying disclosure. So what if a few script-kiddies can now rush a script and do some shit? Every day you wait is one day less for the script kiddies, but one day more for the real criminals.
Stop living in la-la-land or in 1985. The evil people on the Internet aren't curious teenagers anymore, but large-scale organized crime. If you think they need to read advisories to find exploits, you're living under a rock.
"I think there is a world market for maybe five computers"
Even if Thomas J. Watson never actually said it, the quote fits well here. Or you could say "company says competitor has limited potential, news at 11".
Fernlicht goes further. At night in the countryside, you can often use it because you're literally the only car on the road.
Or maybe that's just me because when I drive long distances at night, I make it deep in the night so there's no traffic.
I've rarely driven through NRW, but at the northern edge to Niedersachen, around Osnabrück for example, there's definitely lights on the Autobahn. There most definitely are in Berlin, Hamburg, etc. But yes, it's mostly near and in the large cities.
Liar! They have water and they have land. What more of topology do you want? Ok, they sometimes turn the former into the later for no reason other than forcing all the map makers to redraw and all the encyclopedias to update the "land size" entry every few decades, but aside from that...
Someone posted a video link above. Not karma whoring, so I'm not repeating it here. If you want an actual image of the actual road, look a few comments further up.
Oh, wait, humans can actually see by starlight alone.
If you give your cones time to adapt to night vision. Even a small bit of non-red light falling on them will ruin it instantly for about 20 minutes. Good look keeping night vision up in a car.
Uh... I am german and I've driven thousands of kilometers on the Autobahn at night. While long stretches of it do in fact not have lighting, the parts in or near cities often do. And that's where even at night you get some traffic.
But since the Autobahn has a mid-divider, there's really nothing that you need to see. You see the tail lights of cars in front of you much better in the dark anyways, and at 160 or 200 kph, a deer jumping in front of you isn't a problem of visibility.
Much of it all is, however, due to the specific design of the Autobahn. When you're on an Autobahn, you know with absolute certainty that there won't be any traffic lights, crossings or intersections. You know that the street was built to handle speed, so there won't be any sudden turns and twists, and if it turns by anything that remotely resembles a curve, there will be fat signs warning you of a "sharp corner" that is probably really dangerous if you go Mach 1. So even at 240 kph, the max I've ever driven at night, you feel strangely safe coasting down a road where your lights illuminate maybe the next 3 seconds in front of you.
As a matter of fact, if civilization were to break down, starvation would be our main problem very soon, because for the first time in history, we have > 50% of the population living in cities world-wide (and > 90% in the west), and we have maybe 1% of the population involved in food production, so if something catastrophic were to bring down the logistics of moving the stuff into the population centers, our supplies would run out really, really quickly.
Slashdot Mirror
You're cute. I've done this shit for a living for a while. Yes, many companies' incidence response procedures are crap, but they shouldn't, and it is perfectly possible to get an emergency countermeasure deployed within 24 hours with all the t's crossed and i's dotted and perfect SOX compliance and whatever else you need. It's just something you need to think about before the emergency hits you.
Of course everything else is never equal.
But what are you trying to accomplish here? Argue that a project with 100 developers has more eyes on the code than one with 4? Moot point, no argument.
We don't get the luxury of having 50 identical software projects with different team sizes and a size control, so we have to go with the real world and "everything else being equal" is just a way of saying that you if you want to compare closed vs. open source, you need to compare comparable projects, not an open source project with a handful of people with a closed source project two orders of magnitude larger - or the other way around.
There's a difference?
sysadmin, firewall admin - let's not pick nits here. The point is that there are mitigating measures, and if signing off on something that prevents your company secrets leaking out to the Internet without you even noticing takes more than 24 hours then your incident response procedures are retarded and you can hire me for a workshop to improve them dramatically.
Yeah, there was absolutely nothing anyone could do. Oh wait, except for this brutally complex and technically challenging thing right from the official vulnerability announcement:
This issue can be addressed by recompiling OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag. Software that uses OpenSSL, such as Apache or Nginx would need to be restarted for the changes to take effect.
That was definitely not a feasabole option for anyone on the planet...
You are right on those.
Except for the "nothing can be done" part. That's not your judgement call to make. There is always at least one option - pulling the power plug - and it might well be a feasable temporary solution for some people affected.
Absolutely.
But we were talking about mitigating measures. That is almost never patch and recompile, it's things like turning off a service, changing the firewall rules, moving servers into a different network - things that are very much within the duties of the sysadmin (with proper clearance and risk acceptance by management, etc. etc.)
Basically, if you have a bug that makes your internal network open to the world, but you can avoid it by disabling feature X in the config file, and your company doesn't require feature X, then that's something the sysadmin can do, and he can do it right now, while the vendor is working on a patch.
The thing is that the manufacturer must not be the one to set the time they get to fix this
I agree on that 100%
most people are not able to do anything without patch.
That depends a lot on the particular problem. In many cases, there are mitigating measures that can be taken until a patch is available, and I'd argue strongly that the people affected should make the call on that, not you or I or anyone else.
By withholding information, you are making decisions for other people. But you are not in a position to make that call, because you are not the one who suffers the consequences.
I advocate for giving everyone all the information so they all can act according to their needs and abilities. I argue for letting people make their own decisions.
See other reply.
Yes, of course, a closed source development that does external code reviews can have more eyes on the project then an open source development that does no external code reviews. But then you're comparing apples and oranges.
I didn't see it's the thousands of eyes that fanatics claim.
I'm simply saying that if your source code is open, your number of eyes on the project is (dev team) + (people looking at it) while for a closed source project the number is (dev team).
Since "people" cannot be negative, by necessity (dev team) + (other people) >= (dev team)
How does that guarantee that more experts will review a given piece of security code than in a proprietary, closed-source, locked-up development organisation that also has mandatory code reviews?
It doesn't.
It does guarantee that the number of reviewers is equal to or higher, provided everything else is equal.
Yes, this argument is being made a million times and it doesn't prove anything because it rests on so many assumptions that may or may not be true that it's total truth value is about as good as tossing a coin.
The two most important:
First, you assume that the official patch is the only thing that can be done. In many, many cases there are other (temporary) measures that can be taken to mitigate a problem or limit its impact. Who are you to decide for everyone on the planet with their different needs and scenarios which is better?
Second, you assume that there are thousands of hackers who didn't know about it. Yes, it is likely that the number of bad guys knowing about the problem was less than 100% before the announcement. But any real professional doesn't care about number of hackers, he cares about risk, which is number multiplied by impact. If the people who are the worst danger to my business and are most likely to target me already have the exploit, I don't give a fuck about a thousand random script kiddies also getting it.
So are you going to take your server offline until there is a patch?
Depends, but yes for many non-essential services, that is indeed an option. Imagine your actual web service doesn't use SSL, but your admin backend does. It's used only by employees on the road, because internal employees access it through the internal network.
Sure you can turn that off for a week. It's a bit of trouble, but much better than leacking all your data.
Or if it's not about your web service, but about that SSL-secured VPN access to your external network? If you can live without home office for a week, you can turn that off and wait for the patch, yes.
Most importantly, who are you to decide that everyone should wait for a patch instead of giving people the opportunity to deploy such mitigating measures?
I think giving the software vendor 2 weeks to fix the bug (...) is reasonable
People don't learn.
We used to do that.
Full disclosure evolved primarily as a countermeasure because vendors took those grace periods not as a "we need to get this fixed in that time", but as a "cool, we can sit on our arses doing nothing for another two weeks".
As usual, the answer lies somewhere between extremes.
My preferred choice of being left alone or being beaten to a pulp is being left alone, not some compromise in the middle, thank you. Just because there are two opposing positions doesn't mean that the answer lies in the middle.
I've given more extensive reasoning elsewhere, but it boils down to proponents of "responsible disclosure" conveniently forgetting to consider that every delay also helps those bad guys who are in posession of the exploit. Not only can they use it for longer, they can also use it for longer against targets who don't know they are vulnerable.
Many, many companies run non-essential services that they would not hesitate to shut down for a few days if they knew that there's an exploit that endangers their internal systems. Other companies could deploy mitigating measures while waiting for the patch.
Don't pretend sysadmins are powerlessly waiting with big eyes for the almighty vendor to issue a patch.
There's a black market where you can buy and sell 0-days.
Sure you give it to more people (and for free) than before. But the really dangerous people are more likely than not to already have it.
That is true. However, you also need to take a few other things into account. I'll not go into detail, I think everyone has enough knowledge and imagination to fill in the blanks:
Despite all the theoretical arguments seemingly in favour, security through obscurity does not work and we've known that for like forever.
Several fundamental mistakes in there.
First, OpenSSL is not typical of Free Software. Cryptography is always hard, and other than, say, an Office Suite, it will often break spectacularily if a small part is wrong. While the bug is serious and all, it's not typical. The vast majority of bugs in Free Software are orders of magnitude less serious.
Second, yes it is true that the notion that anyone can review the source code doesn't mean anyone will actually do it. However, no matter how you look at it, the number of people who actually do will always be equal or higher than for closed source software.
Third, the major flagships of Free Software are sometimes, but not always picked for price. When you're a fortune-500 company, you don't need to choose Apache to save some bucks. A site-license of almost any software will be a negliegable part of your operating budget.
And, 3b or so, contrary to what you claim, quite a few companies contribute considerable amounts of money to Free Software projects, especially in the form of paid-for support or membership in things like the Apache Foundation. That's because they realize that this is much cheaper than having to maintain a comparable software on their own.
The only possible way is to disclose to the responsible manufacturer (OpenSSL) and nobody else first, then, after a delay given to the manufacturer to fix the issue, disclose to everybody. Nothing else works. All disclosures to others have a high risk of leaking. (The one to the manufacturer also has a risk of leaking, but that cannot be avoided.)
It's not about leaking. The reason I'm not alone in the security community to rage against this "responsible disclosure" bullshit is not that we fear leaks, but that we know most of the exploits are already in the wild by the time someone on the whitehat side discovers it.
Every day you delay the public announcements is another day that servers are being broken into.
IT security industry experts are beginning to turn on Google and OpenSSL, questioning whether the Heartbleed bug was disclosed 'responsibly.
Are you fucking kidding me? What kind of so-called "experts" are these morons?
Newflash: The vast majority of 0-days are known in the underground long before they are disclosed publicly. In fact, quite a few exploits are found because - drumroll - they are actively being exploited in the wild and someone's honeypot is hit or a forensic analysis turns it up.
Unless you have really, really good reasons to assume that this bug is unknown even to people whose day-to-day business is to find these kinds of bugs, there is nothing "responsible" in delaying disclosure. So what if a few script-kiddies can now rush a script and do some shit? Every day you wait is one day less for the script kiddies, but one day more for the real criminals.
Stop living in la-la-land or in 1985. The evil people on the Internet aren't curious teenagers anymore, but large-scale organized crime. If you think they need to read advisories to find exploits, you're living under a rock.
"I think there is a world market for maybe five computers"
Even if Thomas J. Watson never actually said it, the quote fits well here. Or you could say "company says competitor has limited potential, news at 11".
Fernlicht goes further. At night in the countryside, you can often use it because you're literally the only car on the road.
Or maybe that's just me because when I drive long distances at night, I make it deep in the night so there's no traffic.
I've rarely driven through NRW, but at the northern edge to Niedersachen, around Osnabrück for example, there's definitely lights on the Autobahn. There most definitely are in Berlin, Hamburg, etc. But yes, it's mostly near and in the large cities.
Liar! They have water and they have land. What more of topology do you want? Ok, they sometimes turn the former into the later for no reason other than forcing all the map makers to redraw and all the encyclopedias to update the "land size" entry every few decades, but aside from that...
Someone posted a video link above. Not karma whoring, so I'm not repeating it here. If you want an actual image of the actual road, look a few comments further up.
Oh, wait, humans can actually see by starlight alone.
If you give your cones time to adapt to night vision. Even a small bit of non-red light falling on them will ruin it instantly for about 20 minutes. Good look keeping night vision up in a car.
Uh... I am german and I've driven thousands of kilometers on the Autobahn at night. While long stretches of it do in fact not have lighting, the parts in or near cities often do. And that's where even at night you get some traffic.
But since the Autobahn has a mid-divider, there's really nothing that you need to see. You see the tail lights of cars in front of you much better in the dark anyways, and at 160 or 200 kph, a deer jumping in front of you isn't a problem of visibility.
Much of it all is, however, due to the specific design of the Autobahn. When you're on an Autobahn, you know with absolute certainty that there won't be any traffic lights, crossings or intersections. You know that the street was built to handle speed, so there won't be any sudden turns and twists, and if it turns by anything that remotely resembles a curve, there will be fat signs warning you of a "sharp corner" that is probably really dangerous if you go Mach 1. So even at 240 kph, the max I've ever driven at night, you feel strangely safe coasting down a road where your lights illuminate maybe the next 3 seconds in front of you.
As a matter of fact, if civilization were to break down, starvation would be our main problem very soon, because for the first time in history, we have > 50% of the population living in cities world-wide (and > 90% in the west), and we have maybe 1% of the population involved in food production, so if something catastrophic were to bring down the logistics of moving the stuff into the population centers, our supplies would run out really, really quickly.