Measuring software security is difficult and inexact; as a result, the market for secure software has been compared to a ‘market of lemons.’ Schechter has proposed a vulnerability market in which software producers offer a time-variable reward to free-market testers who identify vulnerabilities. This vulnerability market can be used to improve testing and to create a relative metric of product security. This paper argues that such a market can best be considered as an auction; auction theory is then used to tune the structure of this ‘bug auction ’ for efficiency and to better defend against attacks. The incentives for the software producer are also considered, and some fundamental problems with the concept are articulated.

We examine the code base of the OpenBSD operating system to determine whether its security is increasing over time. We measure the rate at which new code has been introduced and the rate at which vulnerabilities have been reported over the last 7.5 years and fifteen versions. We learn that 61 % of the lines of code in today’s OpenBSD are foundational: they were introduced prior to the release of the initial version we studied and have not been altered since. We also learn that 62 % of reported vulnerabilities were present when the study began and can also be considered to be foundational. We find strong statistical evidence of a decrease in the rate at which foundational vulnerabilities are being reported. However, this decrease is anything but brisk: foundational vulnerabilities have a median lifetime of at least 2.6 years. Finally, we examined the density of vulnerabilities in the code that was altered/introduced in each version. The densities ranged from 0 to 0.033 vulnerabilities reported per thousand lines of code. These densities will increase as more vulnerabilities are reported. 1

Security risk regression models have been successful in estimating the likelihood of attack for simple security threats in which o#ensive and defensive innovations occur at a slow pace, such as burglary. Adapting regression models to the numerous and dynamic threats that face computer systems will be more challenging. One reason is that models of remote network attacks will need to account for the adversaries' ability to use the network to cover their tracks, reducing the risks of incarceration and other harm that could result from staging attacks. When our adversaries no longer face significant risk, the aggregate cost of time, e#ort, and other resources required to stage a successful attack is more likely to be the salient deterrent. The resource cost of attack depends on how strong the system's security is in resisting attack. I present a framework for security risk regression models in which regressors are chosen from four classes, one of which is this security strength. I then present significant refinements to previous metrics of security strength and their measurement.

Abstract not found

The software engineering tools historically used to examine faults can also be used to examine vulnerabilities and the rate at which they are discovered. I discuss the challenges of the collection process and compare two sets of vulnerability characterization criteria. I collected fifty-four months of vulnerability data for OpenBSD 2.2 and applied seven reliability growth models to the two data sets. These models only passed applicability tests for the data set that omits dependent data points. Musa’s Logarithmic model has the best one-step-ahead predictive accuracy of the three acceptably accurate models for that data set. It estimated that fifty-four months after OpenBSD 2.2’s release, the mean time to vulnerability discovery for OpenBSD 2.2 was 42.5 days and that 58.4 % of the vulnerabilities it contains had been found. However, a trend analysis cannot rule out the possibility that there is no trend at all in the rate of vulnerability detection, and this result casts doubts on the accuracy of the reliability growth models. The lack of a clear decreasing trend in that analysis highlights one of the challenges of using reliability growth models on vulnerability data: it may be a true reflection of the system or it may be caused by the changes over time in the effort invested in vulnerability detection.

We address the question of how much security is required to protect a packaged system, installed in a large number of organizations, from thieves who would exploit a single vulnerability to attack multiple installations. While our work is motivated by the need to help organizations make decisions about how to defend themselves, we also show how they can better protect themselves by helping to protect each other.

Abstract not found

Abstract.Internet end-users increasingly face threats of compromise by visiting seemingly innocuous websites that are themselves compromised by malicious actors. These compromised machines are then incorporated into bot networks that perpetuate further attacks on the Internet. Google attempts to protect users of its search products from these hidden threats by publicly disclosing these infections in interstitial warning pages behind the results. This paper seeks to explore the effects of this policy on the economic ecosystem of webmasters, web hosts, and attackers by analyzing the experiences and data of the StopBadware project. The Stop-Badware project manages the appeals process whereby websites whose infections have been disclosed by Google get fixed and unquarantined. Our results show that, in the absense of disclosure and quarantine, certain classes of webmasters and hosting providers are not incentivized to secure their platforms and websites and that the malware industry is sophisticated and adapts to this reality. A delayed disclosure policy may be appropriate for traditional software products. However, in the web infection space, silence during this period leads to further infection since the attack is already in progress. We relate specific examples where disclosure has had beneficial effects and further support this conclusion by comparing infection rates in the U.S. where Google has high penetration to China where its market penetration rate is much lower. 1

Software correctness has bedeviled the field of computer science since its inception. Software complexity has increased far more quickly than our ability to control it, reaching sizes that are many orders of magnitude beyond the reach of formal or automated verification techniques. We propose a new paradigm for evaluating “correctness ” based on a rich market ecosystem in which coalitions of users bid for features and fixes. Developers, testers, bug reporters, and analysts share in the rewards for responding to those bids. In fact, we suggest that the entire software development process can be driven by a disintermediated market-based mechanism driven by the desires of users and the capabilities of developers. The abstract, unspecifiable, and unknowable notion of absolute correctness is then replaced by quantifiable notions of correctness demand (the sum of bids for bugs) and correctness potential (the sum of the available profit for fixing those bugs). We then sketch the components of a market design intended to identify bugs, elicit demand for fixing bugs, and source workers for fixing bugs. The ultimate goal is to achieve a more appropriate notion of correctness, in which market forces drive software towards a correctness equilibrium in which all bugs for which there is enough value, and with low enough cost to fix, are fixed.

Abstract—Security vulnerabilities in software are one of the primary reasons for security breaches, and an important challenge from knowledge management perspective is to determine how to manage the disclosure of knowledge about those vulnerabilities. The security community has proposed several disclosure mechanisms, such as full vendor, immediate public, and hybrid, and has debated about the merits and demerits of these alternatives. In this paper, we study how vulnerabilities should be disclosed to minimize the social loss. We find that the characteristics of the vulnerability (vulnerability risk before and after disclosure), cost structure of the software user population, and vendor’s incentives to develop a patch determine the optimal (responsible) vulnerability disclosure. We show that, unlike some existing vulnerability disclosure mechanisms that fail to motivate the vendor to release its patch, responsible vulnerability disclosure policy always ensures the release of a patch. However, we find that this is not because of the threat of public disclosure, as argued by some security practitioners. In fact, not restricting the vendor with a time constraint can ensure the patch release. This result runs counter to the argument of some that setting a grace period always pushes the vendor to develop a patch. When the vulnerability affects multiple vendors, we show that the responsible disclosure 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. This implies that the coordinator does not necessarily increase the grace period to accommodate more vendors. We then extend our base model to analyze the impact of 1) early discovery and 2) an early warning system that provides privileged vulnerability knowledge to