I'm a little torn on this whole issue. While I have, for most of my life, supported full disclosure, because in general I feel that proprietary information, of any kind, is bad (for society, not the person controlling the information), recently I've started to agree that something needs to be done about the state of computer security.
The problem lies in the fact that computer software has no real automatic failure point. If you buy a car that was poorly designed, and had many flaws, you will find out soon enough when it breaks down. Software won't do that. Once it works, it will keep working for the most part. Yes, it will slowly lose performance if not designed right, but you rarely have catastrophic failure.
The full disclosure movement had an amazing effect on computer security. It made developers accountable for their code. Developers had to come to terms with the fact that code, by nature of existing, is not secure, it does not exist in a vacuum, and, because of that, cannot be left alone indefinitely. In essence, full disclosure created a security field, and made software development better because of it.
However, full disclosure doesn't seem to work any more (at least not the way it is currently done). Simply releasing any and all exploits found makes it easier for anyone to exploit software. When the people running software were experts, and kept on top of keeping their software updated, patched and secure, that wasn't a bad thing. It forced manufacturers to release patches in a timely manner, since people using their code would be expecting the patch. Some place in the past decade and a half, that shifted. Everyone runs software now, and, generally, are the people responsible for keeping it secure.
Optional security patches, when the exploits are publicly available, are not an option. Look at Conficker: the patch actually created interest in the exploit, which created the most recent major security related scare, simply because the patch to fix it was optional, and (evidently) millions of computer operators never took that option. With the huge demand for software, finding skilled, well educated programmers is often not an option. This leads to security issues that developers don't even understand, or even know where to start patching.
Like wise, zero disclosure is also not an option. If zero-day exploits sold in a black market become the norm, it makes it so that only highly organized criminals, or security organizations with deep pockets, will know how exploits work.
The script-kiddie phenomenon is reaching a critical point. When running a bot-net, stealing identities, and all sorts of "hacking" activities require a skill set that qualifies you for a secretary position, something needs to be done about it. Software developers are not testing software adequately. End-users are not patching adequately.
While I don't agree with zero-disclosure, hopefully a shift towards less disclosure may make developers start taking security more seriously from the start. For most users, patching will rarely, if ever, happen. Once developers can't claim that someone else will find security holes later, and hope the users patch them, they may have to start making sure the code they first ship meets some kind of security standards.
They're right. Full disclosure is shifting responsibility away from developers, and onto "security" companies and end users. This is not an inherently good thing, and is currently become a bad thing very quickly.
Full disclosure is shifting responsibility away from developers, and onto "security" companies and end users.
Why not look at it this way: Companies don't have a financial motivation to spend extra engineering man-hours on security in the absence of full-disclosure.
I think the problem here is that security researchers (and hackers concerned about security in general) believe that security should be a concern of software companies, but they don't realize the prisoner's dilemma that software companies find themselves in. If I run a software company and I spend extra man-hours on security, but my competitor doesn't, and they beat me to market, what do I gain? Will I have enough cash on hand to survive the 2 years it might take for a crippling exploit of their code to arrive and finally give me the market advantage?
In a perfect world all code would be security reviewed, all the hungry children in Africa would have plenty of food to eat, there would be no wars, and John Lennon would still be alive to sing about it all... go figure.
> Software won't do that. Once it works, it will keep working for the most part. Yes, it will slowly lose performance if not designed right, but you rarely have catastrophic failure.
What planet, or more likely, what universe do you live in where 'software rarely have catastrophic failure'? And more importantly, how can I get there as soon as possible? My life would be considerably less miserable in such a place...
The problem lies in the fact that computer software has no real automatic failure point. If you buy a car that was poorly designed, and had many flaws, you will find out soon enough when it breaks down. Software won't do that. Once it works, it will keep working for the most part. Yes, it will slowly lose performance if not designed right, but you rarely have catastrophic failure.
The full disclosure movement had an amazing effect on computer security. It made developers accountable for their code. Developers had to come to terms with the fact that code, by nature of existing, is not secure, it does not exist in a vacuum, and, because of that, cannot be left alone indefinitely. In essence, full disclosure created a security field, and made software development better because of it.
However, full disclosure doesn't seem to work any more (at least not the way it is currently done). Simply releasing any and all exploits found makes it easier for anyone to exploit software. When the people running software were experts, and kept on top of keeping their software updated, patched and secure, that wasn't a bad thing. It forced manufacturers to release patches in a timely manner, since people using their code would be expecting the patch. Some place in the past decade and a half, that shifted. Everyone runs software now, and, generally, are the people responsible for keeping it secure.
Optional security patches, when the exploits are publicly available, are not an option. Look at Conficker: the patch actually created interest in the exploit, which created the most recent major security related scare, simply because the patch to fix it was optional, and (evidently) millions of computer operators never took that option. With the huge demand for software, finding skilled, well educated programmers is often not an option. This leads to security issues that developers don't even understand, or even know where to start patching.
Like wise, zero disclosure is also not an option. If zero-day exploits sold in a black market become the norm, it makes it so that only highly organized criminals, or security organizations with deep pockets, will know how exploits work.
The script-kiddie phenomenon is reaching a critical point. When running a bot-net, stealing identities, and all sorts of "hacking" activities require a skill set that qualifies you for a secretary position, something needs to be done about it. Software developers are not testing software adequately. End-users are not patching adequately.
While I don't agree with zero-disclosure, hopefully a shift towards less disclosure may make developers start taking security more seriously from the start. For most users, patching will rarely, if ever, happen. Once developers can't claim that someone else will find security holes later, and hope the users patch them, they may have to start making sure the code they first ship meets some kind of security standards.
They're right. Full disclosure is shifting responsibility away from developers, and onto "security" companies and end users. This is not an inherently good thing, and is currently become a bad thing very quickly.