[opening] all right, thank you for coming today. how many futures software security can have? if we believe that risk management is about changing the future, also software security may have more than one possible future. and this talk is about a specific kind of futures contracts and a prediction market that might help us in making, among all possible futures for software security, the future where: - information symmetry is finally established between buyers and sellers, - software manufacturers have incentives to build security in, and - software buyers have a financial instrument to hedge against information security risks. the story of software security futures is the story of Beewise, an experimental project about metrics, quantification of risks and estimations for the probability of loss events. and quantification of probabilities of loss events are key to security metrics and risk management. [Context] "Security metrics are the servants of risk management, and risk management is about making decisions. Therefore, the only security metrics we are interested in are those that support decision making about risk for the purpose of managing that risk." - Dan Geer at the same time, we know... Today, security stakeholders face a challenging task in assessing the risks they are exposed to, as they have incomplete information about the number and the severity of vulnerabilities affecting their systems. As a matter of fact, current economic, regulatory and legal incentives are misaligned, distorted or ineffectual. Software defects are the broken windows of our information society. They broadcast a greater message of disorder, inviting more elements of disorder, or even cyber crime. The reality is that: "Software products have among the highest levels of defects of any products sold today, and there is very little accountability on the part of producers and software products." In order to understand the story of beewise, we need to understand the story of: - bugs & carrots; - M&Ms; - bees & crowd; and - back to the future [BUG] the story of bugs and carrots. it's the story of why we do things. and why software makers, buyers and cyber attackers behave in the way they do. I will refer you to the full slide deck for a more comprehensive review of incentives, normal and perverse, in the software market. for the sake of speech time, it will suffice to note how today... Due to several economic reasons, namely network externalities and information asymmetries, neither vendors have incentives to build sound security technology into their products nor are users willing to spend extra money on security technology (Ross Anderson, Why Information Security is Hard) so, from the supply side, the market of lemons suggests that vendors under-supply security to the market. from the demand side, the tragedy of commons tells us that users demands less security than appropriate. what we observe here is what economists call a market failure. a market failure is about the inability to self-correct. software-manufacturers will not forgo markets share. software buyers will not forgo features. cyber attackers will not forgo attacking tens of millions of vulnerable systems. how to invert this market? how do we change? this leads us to m&m, or markets and metrics. in order to change, we need new incentives. when people engage in activities that imposes high social costs, it usually means that private cost is to low... ... to change behavior then, require raising the private cost of a particular activity. economists would call this internalize the externalities we have two way to that, and they are not mutually exclusive. - establishing laws and regulations in the information security area (fixing liability models, security will not be perceived as an externality anymore) - establishing new markets with feedback mechanisms (hence balancing the information between buyers and sellers, mitigating the problems at their source) here i want to focus on the second strategy, and more specifically on economic approaches to security metrics that can contribute towards establishing information symmetry. i'm specially interested in an area of research that has its ancestors in micro-economics. it deals with market concepts to gather security-relevant information and extract quantitive indicators on information security properties. for the sake of completeness, i should say a second area of research exists and its based on investment and decision theory. it has yielded to a number of quantitative metrics that can be applied as guidelines in investment decisions. some of them have dubious effectiveness, but more importantly limitations and challenges exist... for instance, risk management metrics require estimations for severity and probability of loss events. we know how in traditional risk management those values are often deduced from historical data. and we know also how this barely feasible at the moment for IT security. at the same time also quantification and complexity are further challenges in applying investment metrics in IT security. historical data is scarce even with organizations that have been using IT technology for a long time, because sometime it is hard to quantify data or because there is a lack of rigor of methodological collection. but i believe a more interesting economics based approach exist to security metrics. and it's about deriving metrics from market mechanisms. metrics based on market mechanisms are not necessarily employed in an economic or business context, but their way of measurement is based on economic principles. the key realization is that the observation of economic agents' decision yields useful indicators for their expectations and can eventually be used to construct operable metrics. the kind of metrics arising from market mechanisms are forward-looking, because market prices are based on expectation about the future rather than on historical data. we can classify these metrics in metrics derived from existing markets and metrics arising from the design of specific information security markets. i will skip over metrics derived from existing markets. it will suffice to say that they are merely a post-hoc indicator for insecurity, rather than a metric for security in a state where no incidents happens. now, if we look at the countermeasures proposed in the literature some of them stimulate new markets and therefore are not only good tools to align incentives, but also to obtain a new class of security metrics. vulnerabilities as a security-related information can be traded. a number of vulnerability markets have been proposed so far. they range from bug challenges and auctions, to vulnerability brokers, cyber insurances and exploit derivatives. the ideal vulnerability market fulfill three, plus one, functions: - information function - the ability to use market prices as forward-looking indicators of security properties (ie, countering the lemons effect) - incentive function - allow monetary compensation for security research and development (high priority to security issues) - risk-balancing function - the market provides instruments to hedge against large information security risks (ie, mitigate the impact of occasional security breaches) and - efficiency - orthogonal to the other functions and characterized in terms of: low transaction costs, liquidity, transparency, accountability. with bug challenges and auctions there is no possibility to do risk-balancing at all; moreover the information obtained about the market price from a bug challenge is only a lower bound. brokers gives questionable incentives and not always leads to the disclosure of the vulnerability to the public. exploit derivatives and cyber insurance looks both promising. the former provides a timely indicator, while insurances can be less efficient due to (presumably) high transaction costs, bad portfolio balancing or high correlation risks. let's giver a closer look to exploit derivatives they transfer the mechanism of binary options from finance to information security. they don't require to trade sensitive vulnerability information. and the contract is build around contracts that pays out a defined sum in case of security events. consider a pair of contract (c and c'), where c pays a fixed amount of money, say 100 eur, if there exist a remote root exploit against some specified server software x on platform y at data d in the future. the inverse contract c' pays out the same face value if there exist no remote root exploit submitted to a market authority before date d. it is evident that the value of the bundle (c, c') is 100 eur at any time and that selling and buying the bundle is risk-free. assume now that there is an exchange platform, where the contracts c and c' can be traded individually at prices determined by matching bid and ask orders. the platform settles the deals, and publish the price quotes from order book. then the ratio of the market price of c and its face value approximately indicates the probability of software x being compromised before date d. i argue that exploit derivatives have the promise to attract a large number of interest groups, including: - software users - cyber-insurance companies - investors - software-vendors - security experts and vulnerability researchers. software users would demand C in order to hedge they are exposed to due to their computer systems in place. the same applies for cyber-insurance companies underwriting their custmers' cyber-risk. investors would buy contracts c' to diversify their portfolios. software vendors could be interested from several point of views. - they could demand contract c that pays if their software remains secure as a means to signal to their customers that they trust their own system. or contract C_comp that pay if their competitors' software get compromised - one could even think of software vendors using exploit derivatives as part of their compensation scheme to give developers incentives to secure programming. security experts and vulnerability researches could use the market to capitalize efforts in security analyses. if, after a code review, they consider a software a secure (wrt to some family of vulnerabilities), they could buy contract c' at higher rate than the market price. otherwise they buy contract c and afterwards they follow their preferred vulnerability disclosure strategy. few remarks about this instrument. - no co-operation of vendors is needed. - the number of different contracts is solely limited by demand. - since almost all markets are settled in money, the often difficult quantification is inherently implied by the market mechanism on the other hand, while most existing markets are good at predicting future states in the long run, the advantages go along with short term frictions, an, in terms of metrics, with measurement errors. i will not dig into this, but exploit derivatives might remind you about water derivatives, that gained in the last years more and more popularity in the financial marketplaces. though, some criticalities exist. how to bootstrap exploit derivatives? weather derivatives were first traded by companies accustomed to trading contracts based on the electricity and gas prices in order to hedge their prices risk of their utilities. i don't believe approaching the cme is today the most viable approach, without some preliminary research corroborating the value exploit deriviatives might create. the modeling of contracts can be challenging, requiring financial players the knowledge of reliability growth models, and the understanding of the nature of software defects) furthermore, exploit derivatives - as proposed in literature - require a market authority (a kind of trusted third party) to test candidate exploit and publish them to provide verifiability and countering fraud. [bees and crowds] ...