I have been doing a lot of reading lately about the history of security research and the issue of full disclosure. It is a huge debate issue and it was something that before I started getting into security, I was completely unaware of. It isn’t something that hits the news often and when a vulnerability makes the news, the background issue about the disclosure of it is usually so controversial that nobody touches on it in the mainstream.
So what is it exactly? Well it is in regard to when a security vulnerability is discovered, the debate revolves around whether or not knowledge of that vulnerability should be open to the public. Some people say that making sensitive information like that public only put the customers and general public more at risk by releasing that information out into the wrong untrusted hands. Others say that untrusted individuals already had that information and that releasing it to the public will help speed up the process of getting a proper fix for the vulnerability out to the people that need it.
No matter where you stand on the issue, both sides seem to agree that one of the greatest issues is communication. There are generally two parties involved with the issue. One being the vendors that make the software at risk, the others being the security researchers that initially discovered the vulnerability. These parties must communicate in such a way that is in the public’s best interest. However, poor communication between the two can deteriorate relations and can lead to the disclosure of sensitive vulnerability information. Vendors typically claim that they are not given enough time to get a fix properly release. The security researches sometimes claim that waiting too long to get a patch to the general public is putting the public at an increased risk with each day that goes without a proper patch.
There have been many disclosure policies that have been developed over the last decade that are aimed at helping develop proper communication between all parties involved such as RFP, OIS, and ZDI. Many of these are just guidelines and are there just out of general respect for both sides. Neither side, however, is obligated to follow those guidelines. They do help give each side of the fence a certain set of expectations. If one side is following a specific policy and staying within the guidelines set, then the other side will know what to expect. It also helps open lines of communication that may not have been there before the policies were put in place. Many times, when a security researcher discovered a flaw in a piece of software, they’d have no idea where to turn to to get the flaw fixed.
After reading more and more about the history of this issue, when I see events that happen, like the DNS vulnerability that Dan Kaminsky and the associated vendors handled, it really amazes me how well everyone involved were able to communicate and help get the issue resolved. Without open lines of communication from both sides, we just won’t be prepared enough to handle wide spead isssues properly when they arise.