There is apparently a bit of fear going around information security circles that the next big trend in the disclosure wars is going to be "Partial Disclosure". In the past, the vulnerability research community has embraced the concepts of "Full Disclosure" and/or "Non-Disclosure". Once those concepts had been sufficiently played out, the general consensus was to move towards "Responsible Disclosure" whereby the security researcher responsibly discloses the discovered vulnerability to the vendor and works in a cooperative fashion in an effort to minimize the risk to the general user populous. This has worked well in the vast majority of cases that I have had the pleasure of managing the disclosure process.

Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn't want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users' systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor's hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the "problem" that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn't ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

FREE Security Tutorials from Veracode

Cyber Security Risks
Mobile Security
CRLF Injection
Flash Security
SQL Injection Hack

Veracode Security Solutions

Software Security Testing
Binary Analysis
Application Analysis

Veracode Data Security Resources

Data Security Issues
Data Breaches
Data Loss Protection

About Tyler Shields

Tyler Shields is a Senior Researcher for the Veracode Research Lab whose responsibilities include understanding and examining interesting and relevant security and attack methods for integration into the Veracode product offerings. He also keeps track of new developments from other computer science and information security researchers to ensure that Veracode technologies are always kept in line with the most recent security advancements.

Comments (1)

CG | October 21, 2008 7:17 pm

I'm not sure that partial disclosure is the way to go at all. The idea of researchers saying "I know something that you don't know" poses quite a challenge to a group of people who pride themselves on figuring tough problems out and generally believe that there should be few secrets that some know and others do not. Giving security people a few pieces of the puzzle and then expecting them to wait for the rest and/or keep quite once they figure out the puzzle? naaaa. Not to mention the FUD that promptly ensues (just like you mentioned and we say with the DNS vuln).

I'm also not sure a "No Homers" club to decide on the impact of vuln is the right way to go either for the reasons you mentioned. But it is certainly within the rights of the researcher to chose their own disclosure method.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.