An Empirical Analysis of Vendor Response to Disclosure Policy
Ashish Arora, Ramayya Krishnan, Rahul Telang, Yubao Yang
This version: March 4, 2005
Abstract Software vulnerability disclosure has generated intense interest and debate. In particular, there have been arguments made both in opposition to and in favor of alternatives such as full and instant disclosure and limited or no disclosure. An important consideration in this debate is the behavior of the software vendor. Does vulnerability disclosure policy have an effect on patch release behavior of software vendors? This paper compiles a unique data set from CERT/CC and Security Focus databases to answer this question. Our results suggest that early disclosure has significant positive impact on the vendor patching speed. Open source vendors patch more quickly than closed source vendors and severe vulnerabilities are patched faster. We also find that vendors respond slower to vulnerabilities not disclosed by CERT/CC. This might reflect unmeasured differences in the severity and importance of vulnerabilities. It might also reflect the stronger lines of communication between CERT/CC and vendors, and the value of the vulnerability analysis by CERT/CC. We also find that vendors are more responsible after the 9/11 event.
Keywords: Security vulnerability, disclosure policy, patching speed
Security Vulnerability Severity Classification
by Thomas Biege (thomas[at]suse.de)
27th January 2005
This paper will describe a method of classifying the severity of security bugs in software for Unix-like systems. On the following pages I will propose a metric with weights to describe the impact of vulnerabilities on a scala S with n elements to provide an objective rating system. This classification scheme should serve as reference for the SuSE Security Team for releasing security announcements. Hopefully this mechanism will be adopted by other vendors to have a vendor independent rating system. Such a vendor independent rating scheme will help customers, other vendors, and security companies/organisations to judge more precisely about the level of impact of a released security update.
The Likelihood of Vulnerability Rediscovery and the Social Utility of Vulnerability Hunting
by Andy Ozment
Initial attempts to apply software reliability growth models to the process of vulnerability finding relied upon noisy data. Here, a more appropriate data collection process is discussed and employed to identify the age of vulnerabilities in OpenBSD 2.2. A number of models are tested against the data and two are found to have acceptable goodness-of-fit. These models indicate that the pool of vulnerabilities in the system is being depleted. However, models that also fit the data but do not indicate depletion may also exist. While this result is thus not conclusive, it does suggest that more investigation is needed and that, contrary to prior work, vulnerability depletion cannot yet be ruled out. It is thus possible that vulnerability hunting can result in a more secure product and can provide a social benefit. Patch announcements and vulnerability reports are also used to quantitatively (albeit roughly) demonstrate that vulnerabilities are often independently rediscovered within a relatively short time span. This finding provides a quantitative and qualitative rationale for vulnerability disclosure policies intended to pressure vendors into more rapidly providing patches. Although neither result is conclusive, both contradict previous work by providing support for the conclusion that vulnerability hunting is socially useful.
Halvar posted to the DailyDave mail list today showing a brief flash based demonstration of some of his reverse engineering tools. The presentation shows how one can reverse engineer a Microsoft patch using binary diff analysis, and figure out exactly what the vulnerability is, down to the function.
What will this technology and method do, when hundreds (thousands?) of people can reverse engineer a patch that fast, and offer full vulnerability details within minutes of a patch? That type of information would be incredibly valuable to some people, probably for more nefarious purposes. That type of information would be incredible for the security community and vulnerability databases who often have a difficult time separating issues due to lack of details.
Even more interesting, would this show a more concise history of vulnerabilities in a given vendor’s product that demonstrates the same programs, routines and even functions are found vulnerable repeatedly? Would this help companies identify who should be singled out for additional “secure coding” workshops?
Economic Analysis of Incentives to Disclose Software Vulnerabilities
by Dmitri Nizovtsev and Marie Thursby
This paper addresses the ongoing debate about the practice of disclosing information about software vulnerabilities through an open public forum. Using game-theoretic approach, we show that such practice may be an equilibrium strategy in a game played by rational loss-minimizing agents. We find that under certain parameters public disclosure of vulnerabilities is desirable from the social welfare standpoint. The presence of an opportunity to disclose allows individual software users to reduce their expected loss from attacks and by doing so improves social welfare. We analyze the effect of several product characteristics and the composition of the pool of software users on the decisions to disclose and on social welfare and compare several public policy alternatives in terms of their efficacy in reducing the overall social welfare loss from attacks. Our results suggest that designing an incentive system that would induce vendors to release fixes sooner and improve the quality of their products should be among the priorities for any policymaking agency concerned with information security. Doing so would reduce individual incentives to disclose vulnerabilities, thus further reducing the potential damage from any given vulnerability.
Our preliminary analysis of information-sharing coalitions suggests that such entities have a positive effect only under a fairly restrictive set of conditions.
Document Detailing “CVE Content Decisions” Now Available
June 15, 2006 — A new document entitled “CVE Abstraction Content Decisions: Rationale and Application” detailing CVE content decisions (CDs) has been posted on the CVE Web site. CVE CDs are the guidelines used to ensure that CVE names are created in a consistent fashion, independent of who is doing the creation.
EMERGING ISSUES IN RESPONSIBLE VULNERABILITY DISCLOSURE
Hasan Cavusoglu, Huseyin Cavusoglu, Srinivasan Raghunathan
Security vulnerability in software is the primary reason for security breaches, and an important challenge for IT professionals is how to manage the disclosure of vulnerability information. The IT security community has proposed several disclosure policies, such as full vendor, immediate public and hybrid, and has debated which of these should be adopted by coordinating agencies such as CERT. Our early study (Cavusoglu et al. 2004a) analyzed the optimal disclosure policy that minimizes social loss when vulnerability affects only one software vendor. In this paper, we extend our early work into three directions in order to sled light on current issues in vulnerability disclosure process. (i) When the vulnerability affects multiple vendors, we show that the coordinator’s optimal policy cannot ensure that every vendor will release a patch. However, when the optimal policy does elicit a patch from each vendor, we show that the coordinator’s grace period in the multiple vendor case falls between the grace periods that it would set individually for the vendors in the single vendor case. (ii)
We analyze the impact of an early discovery, which can be encouraged with proper incentive mechanisms, on the release time of the patch, the grace period, and the social welfare. (iii) We also investigate the impact of an early warning system that provides privileged vulnerability information to selected users before the release of a patch for the vulnerability on the social welfare. Finally, we explore the several policy implications of our results and their relationship with current disclosure practices.
Preliminary and Incomplete
Internet Security, Vulnerability Disclosure, and Software Provision
Jay Pil Choi, Chaim Fershtman, and Neil Gandal1
April 5, 2005
In this paper, we examine how software vulnerabilities affect firms that sell software and consumers that purchase software. In particular, we model three decisions of the firm: (I) an upfront investment in the quality of the software to reduce potential vulnerabilities, (II) a policy decision whether to announce vulnerabilities, (III) and a price for the software. We also model two decisions of the consumer: (I) whether to purchase the software and (II) whether to apply a patch.
While symlink vulnerabilities are not new, Steven Christey from CVE points out a recent trend in “second-order symlink” vulnerabilities. Based on the recent examples published, there is a strong chance many applications have been vulnerable to such attacks in the past.
Study: Flaw disclosure hurts software maker’s stock
Robert Lemos, SecurityFocus 2005-06-06
The study analyzed the release of 146 vulnerabilities and found that a software company’s stock price decreased 0.63 percent compared to the tech-heavy NASDAQ on the day a flaw in the firm’s product is announced. The study assumed that the stock of a company would have the same trend as the stock index, and that any departure from the index would be due to the disclosure.
This exact research project has been on my ‘to-do’ list for years, glad to see someone has begun to analyze this. A few years back, Ted Bridis noted that Microsoft’s stock dropped several dollars the day or two after a world wide worm infestation that exploited MS products. There was also talk of Internet Security Systems’ (ISS) stock value taking a hit after the Witty worm (which exploited one of their products).
It will be extremely interesting to see this research carried further, noting details of the type of information disclosure (full, partial, vague), if the information is released in conjunction with vendors, etc.
The Register Article – Study: Flaw disclosure hurts software makers’ stock