Elias, You raise some very good points, and they are the reasons why nothing has really happened in a positive way for some time. I agree with you that full disclosure is good in many ways. However, I believe that the potential damage that it can create is larger than the good that it can do. At the end of your note, you say: > What it boils down to is this: disclosure of detailed vulnerability >information benefits security conscious people, while, in the short them, >hurts people that do not keep up with security, with the hope that it >also helps them in the longer term. I disagree here. I found that the release of the scripts hurt people for a very long time- in some cases years. You are, however, onto a possible solution to the problem. This problem is all about time and the windows in which people must operate. It's a classic military command and control problem- first discussed by John Boyd in his OODA loop theory. In essence, Boyd says that who ever can react faster in a non-conventional confrontation will win. Right now the attackers are reacting faster than the vast majority of the people trying to protect their systems. Ideally, we'd have perfect management systems that downloaded patches automagically as soon as a vulnerability is reported (and of course everyone used such a system- NOTE: this is the ultimate virus vector which is a problem onto itself). Unfortunately, we don't have something like that now. I think the best idea is for people to follow something along the lines of RFP's policy. But, don't release the source code. Release enough information such that other experts can verify your results and develop counter-measures / scanners. Will vulnerabilities still get scripted without release of the source? Sure- but it's all about time, and the time to react and protect yourself. Over the last few years, I've been coming to the conclusion that any vast improvement in security will come from improvements in management- not some new security widget. Right now, I believe the biggest opportunity for improving security rests in finding ways to shrink the window of time that an attacker can successfully exploit a vulnerable system. Not releasing the source code to attacks in this case doesn't help shrink that window, but it does limit the size of the population who can take advantage of the window. Bill At 01:15 PM 8/10/2001 -0600, aleph1at_private wrote: > Without detailed information: > > How should third-parties develop countermeasures? In essence you are >arguing that only the vendor should be capable of fixing the vulnerable >software. > > How should authors of vulnerability scanners and intrusion detection >systems obtain information to produce new signatures? You may answer that >only qualified security vendors should have access to the information. >Who qualifies them? Who enforces these rules? What about non-commercial >or open source tools? > > How should academics obtain information for research purposes? You may >answer that only qualified security vendors should have access to the >information. Who qualifies them? Who enforces these rules? > > How should users verify the vendor fix works as described? Some vendors >have a history of requiring a few revisions of a patch to get it right. > > What do you do if the vendors is not cooperating, does not maintain >the product any longer, or no longer exist? > > Unless you can answer all this question successfully you will continue >to see detailed disclose of vulnerabilities. > > What it boils down to is this: disclosure of detailed vulnerability >information benefits security conscious people, while, in the short them, >hurts people that do not keep up with security, with the hope that it >also helps them in the longer term. > > Will security conscious people give up the benefits of detailed disclosure >of vulnerability information to help mitigate the short term risk of people >that are not keeping up with security? Doubtful. > >-- >Elias Levy >SecurityFocus.com >http://www.securityfocus.com/ >Si vis pacem, para bellum
This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 18:23:30 PDT