The e ect of competition intensity on cybersecurity - … e ect of competition intensity on...
Transcript of The e ect of competition intensity on cybersecurity - … e ect of competition intensity on...
The effect of competition intensity on cybersecurity - An empirical
analysis of security patch release on the web browser market∗
Arrah-Marie Jo†
June 2016
Very preliminary and incomplete
Abstract
This paper empirically examines the effect of competition intensity on software vendors’ security provision
behavior. Specifically, we analyze the relationship between market competition intensity and the time a
software publisher spends to release a security patch when it is informed about a vulnerability affecting
its product. We study the case of a market at the heart of Internet based security issues, namely the web
browser market. We rely on a 10-year pooled cross-sectional data set on software vulnerabilities, discovered
and patched from January 2006 to December 2015. Our results suggest that market competition impacts
negatively the vendor’s responsiveness in releasing a security patch; that is, the more competitive the market
is, the less a software vendor invests in its product security. In addition, we find that disclosure accelerates
patch release and open source software are patched faster than proprietary software.
1 Introduction
Discovery of highly critical vulnerabilities such as Heartbleed, Shellshock, and Poodle, recently brought the
subject of vulnerability discovery and patching at the center of Internet and cybersecurity discussions. These
vulnerabilities have been extensively exploited for several years and have affected more than two third of active
web sites on the Internet, partly due to the predominance of few systems.1
Despite security practitioner’s efforts, attackers move faster to exploit critical vulnerabilities than vendors
provide patches. In 2014, vendors spent on average 59 days to release a patch for the five most exploited
zero-day vulnerabilities, while these vulnerabilities were exploited in thousands of attacks from the first month
∗I thank my thesis advisor Marc Bourreau for his patient guidance and support.†Telecom Paris Tech. E-mail: [email protected], Shellshock and Poodle are vulnerabilities in cryptographic software library called OpenSSL. These weaknesses allow
stealing information that are protected, under normal conditions, by the SSL/TLS encryption used to secure transactions on theInternet.The impact of these vulnerabilities is all the more serious as software affected by these vulnerabilities are extremely widespread. Asa matter of fact, in 2014, the combined market share of just Apache and Nginx, the two most widely spread webservers using theOpenSSL library, was over 66% out of the active web sites on the Internet. (Source: http://heartbleed.com)
1
of their discovery.2 How can we explain such difference in the attacker and vendor’s responsiveness? Technical
explanations may be part of the answer, yet in recent years, researchers have realized that economic analysis can
offer as much a valuable insight as technical answers (Anderson and Moore, 2007). From this perspective, a
relevant question is to identify the economic factors affecting a firm’s incentives to invest in the security of its
product. Considering that markets in the software industry are generally highly concentrated (Varian, 2001),
do software publishers have enough incentives to provide an appropriate level of security to their users? In
particular, does the market competition have a positive or a negative impact on a software’s security quality?
Economists have long been interested in the relationship between market competition and investment
incentives. An extensive IO literature covers the subject, yet it is hard to find general tendencies both in
theoretical and empirical results (Aghion and Griffith, 2008). Competitive pressure can encourage investments
in order to “escape competition”. On the other hand, post innovation rents may provide stronger incentives
to invest, that is, the “Schumpeterian effect” of competition can prevail (Aghion, Bloom, Blundell, Griffith,
and Howitt, 2005). In light of this context, our objective in this paper is to examine empirically the effect of
the competition intensity on a software vendor’s security provision behavior. More precisely, we analyze the
relationship between the market competition intensity and the time a software publisher spends to release a
patch when it is notified about a security flaw affecting its product. We study the case of a market situated at
the center of Internet based security issues, namely the web browser market.
For this purpose, we compiled a cross-sectional data set on software vulnerabilities of web browsers discovered
and patched from January 2006 to December 2015. Limiting our study to a single market – the web browser
market – is relevant for several reasons. First, it is a key market for Internet security issues, web browsers
being the principal “Window” of the World Wide Web, installed on almost all computers and devices that have
access to the Internet.3 For instance, the five most exploited zero day vulnerabilities in 2014 and 2015 have
directly affected web browsers.4 Secondly, we limit our study to a single market where we are able to obtain
a simple and accurate proxy of the market competition, using the Herfindahl-Hirschmann Index (HHI) from
the quarterly market share of each web browser.5 Third, we study a market presenting a large variation of the
concentration (and thus of the competition intensity) which enhances the robustness of our analysis. The model
is additionally tested on the rendering engine market, which we can consider as an upstream market for web
browsers. Lastly, we only consider vulnerabilities directly assigned to web browsers. In other words, we only
consider vulnerabilities which can be secured by web browser publishers themselves without relying on a third
party publisher so that the patching time spent by the vendor depends on its own investment decision.6
2Source: ISTR – Internet Security Report April 2015 Symantec figures in p.673The WWW is not Internet. It is rather one way to use the Internet. The World Wide Web Consortium (W3C) defines the
WWW as an information space where documents and other web resources are identified by URLs, interlinked by hypertext links,and can be accessed via Internet. Source: http://www.w3.org/Help/#webinternet
4Source: Symantec annual report on Internet Security (ISTR 2014 and 2015)5We use 1 - HHI/10 000 as a measure of the market competition intensity.6 For instance, vulnerabilities that concern Adobe Flash is excluded from our study because in this case, the patch is mainly
developed by Adobe and not the Web browser publishers.
2
Our results show that competition intensity has a negative impact on the rapid patching of a web browser by
its publisher. In other words, the more the market is competitive, the less the software vendor invests in product
security. This may be due to the specificity of the web browser market, which presents a revenue model typical
to markets with indirect network externalities: the use of web browsers are free of charge for the users and the
market is essentially subsidized by search engines revenu. In addition, we find that software vendors tend to
release a security patch more rapidly when the vulnerability information is disclosed to public earlier, and that
open source browsers or rendering engines are patched faster than proprietary ones.
This work draws from two strands of literature: the economics of information security and the economic
literature on the relationship between competition and investment.
The literature on the economics of information security is recent and thriving; it aims at studying the
potential market failures causing information systems insecurity. Vulnerability discovery and patch management
are one of the topics at the heart of this field. Analytical works in this literature study various questions: some
papers analyze the welfare implications of different liability and information disclosure policies (August and
Tunca, 2011; Choi, Fershtman, and Gandal, 2010; Arora, Nandkumar, and Telang, 2006b); others investigate the
coordination possibilities between software vendors and customers in the patch management process (Cavusoglu,
Cavusoglu, and Zhang, 2008) or examine the role of different vulnerability discovery mechanisms (Kannan and
Telang, 2005). However, few studies account for the impact of market structure on firms’ information security
provision. Kim, Chen, and Mukhopadhyay (2009) build a model of risk sharing for security losses between
software vendors and users. They show that market competition can lead to a higher level of risk sharing, and
therefore a higher level of security quality. They study the vendor’s incentive to share the risks with its users with
a broad definition of ”risk sharing”, which includes information sharing, damage cost or security investment cost
sharing. In our paper, we specifically focus on the vendor’s investment incentives in software security. Gal-Or and
Ghose (2005) examine the effects of market characteristics such as the degree of intra-industry competitiveness
and firm size on a firm’s information sharing behavior and security technology investment decisions. One of
their main findings is that the incentives to share information and to invest in security increase as the degree of
competitiveness in an industry increases. Their model focuses on the role of information sharing, which acts as a
strategic complement of firm’s security technology investment and as a social welfare-enhancing mean. Arora,
Caulkins, and Telang (2006a) analyze the initial security quality of a software and the patching behavior of
software vendors and find that the market size has a crucial role on the vendor’s behavior. Their model however
considers only a market under monopoly. To the best of our knowledge, no analytical paper investigates the
direct impact of market competition on the patching behavior of software vendors.
So far, empirical work dealing with vulnerability discovery and patch management have essentially focused
on issues related to vulnerability disclosure. Some researchers study the impact of vulnerability information
disclosure to stock exchange prices (Campbell, Gordon, Loeb, and Zhou, 2003; Telang and Wattal, 2007) and
3
other papers closer to ours on security investment (Gordon, Loeb, Lucyshyn, and Sohail, 2006; Arora, Krishnan,
Telang, and Yang, 2010b). In particular, Arora et al. (2010b) exploit similar data as in our study to investigate
the vendor’s responsiveness to vulnerability information disclosure and the impact of information disclosure on
the frequency of cyber-attacks. Ransbotham, Mitra, and Ramsey (2008) use security alerts data from a private
security service provider to examine the impact of market-based vulnerability disclosure on the risk of cyber
attacks. Our empirical model accounts for the impact of vulnerability information disclosure but it is not our
main subject of interest. Information disclosure is rather considered as one of the essential factors that enable to
isolate the effect of competition intensity.
The study that comes closest to ours is of Arora, Forman, Nandkumar, and Telang (2010a). Our paper has a
similar purpose with them in that we both analyze empirically the effect of competition on software publishers’
security investment behavior. Indeed, both of us consider that the extent to which a vendor internalizes its
customer losses is influenced by competition. Also, both of us use the time to patch as a measure of software
quality. However, our approach differs to theirs in several points. First, Arora et al. (2010a) analyze software
vendor’s investment behavior in reaction to other vendors that share a common vulnerability. They consider
that sharing the same vulnerability put vendors in a competitive situation, whether they are actually operating
in the same market or not. In our case, we consider a narrower definition of the market competition by limiting
our analysis to interactions within a single market and using a proxy of the market competition deriving from
the market concentration. Secondly, we test our model on one specific market during a relatively long period
of time – a ten-year-period – in order to capture both short and long term effect of competition to software
vendor’s investment behavior.7
The rest of the paper is organized as follows. In Section 2 we provide a brief summary of the web browser
market history and its specificities. Than we describe the vulnerability discovery and patching process. Section
3 describes the rationale behind our empirical approach. Section 4 presents the data. Section 5 presents the
econometric model and the variables. Estimation results follow in Section 6 and the final section provides
conclusions.
2 Background and economic framework
2.1 The web browser market
A web browser is a software that gives access to the World Wide Web (WWW). It retrieves and displays content
from remote web servers using the HyperText Transfer Protocol (HTTP). Web resource are usually written in
HyperText Markup Language (HTML) and may contain diverse types of content such as PDF or images. They
may be augmented with technologies such as Cascading Style Sheets (CSS), which adds additional layout and
styling information, or use JavaScript for client-side computation. The most popular web browsers today are
7Our data covers a 10-year-period from 2006 to 2015 while Arora et al. (2010a) consider a 4-year-period from 2000 to 2003.
4
Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, and Apple Safari (see Figure 1).
Figure 1: Web browser’s market share from 2006 to 2015
As it is the case for any software, web browsers are dependent to the operation system (OS) on which
they run. Its dependency to a platform naturally brings compatibility and lock-in issues. For instance, in the
mid-1990s, Microsoft took advantage of the dominance of Windows on computers to extend Internet Explorer’s
market share when facing the competition of Netscape. Today however, web browsers are available on various
types of hardware, from desktop computers to cell phones and tablets, and major operation systems of computers
and smartphones have more than 50 browsers available on it, which users can freely and easily install or remove.
Besides, a web browser is a platform itself, where web surfers and website owners meet. Moreover, increasingly,
a browser is not just a single piece of software but an entire suite of applications. For instance, Google Chrome
is totally integrated to Google’s other web services: the user is able to get its bookmarks or Google Maps history
back from one Chrome browser to another, just by logging on to its Google account. Along with the increasing
use of Internet and the growth of Web-related industry, the browser’s role as a platform is enlarged, benefiting
from direct and cross network externalities.
The privileged position of a web browser is also strengthened by the importance of its core component,
the rendering engine. The rendering engine, sometimes called “web browser engine” or “layout engine”, is the
component responsible for displaying the requested content according to the formatting information. It is also
used in a range of web applications such as email clients or eBook readers that require the displaying and editing
of web content. The four most used rendering engines are created and maintained by the four major web browser
publishers: Webkit by Apple, Blink by Google, Gecko by Mozilla and Trident by Microsoft. Except for Trident,
these rendering engines have an open source license, which allows developers to modify and integrate them freely
in other software.
Because the way a web browser as well as other web applications interpret and display web resource depend
on the rendering engine it uses, a rendering engine is not only essential for the web application itself but also
has a crucial role in the definition and evolution of web standards.8 Until 2000s, web browsers conformed to
only a part of web standards specifications. As a result, “users” of both sides of the “platform” had to bear the
8Web standards are the normative specifications of technology or methodology that are applicable to the World Wide Web. Inrecent years, the term has been more frequently associated with the trend of endorsing a set of standardized best practices forbuilding web sites, and a philosophy of web design and development that includes those methods. Source: Wikipedia
5
cost of incompatibility: when using the wrong browser, web surfers could not view content or perform desired
transactions and web designers should neglect some browsers thus locking out potential customers or implement
multiple versions of every web page in order to accommodate incompatible browsers. Today, web standards
application has been strengthen by the work of the World Wide Web Consortium (W3C) and the Web Standards
Project (WaSP).
The central role of web browsers as a platform explains why publishers do not charge any fee to the users.
Indeed, the revenue model of Web browser publishers differs from one to another, but none of them charge
directly the users. Most web browsers are paid by search engine companies to make their engine default or to
include them as an option. For instance, almost the entirety of Mozilla’s income comes from royalties paid by
Google. In the case of Apple, Microsoft and Google, the development of the web browser is funded by the sales
of other services and products. For instance, Google exploits user data from Chrome to improve Google AdSense
program, from which its main revenue comes.9
Internet Explorer dominated the web browser market until the beginning of 2000s but competition was
gradually introduced with the launch of Firefox in 2004 and Apple’s rendering engine becoming open source in
2005. The data used in our paper covers a ten-year-period just afterwards, from 2006 to 2015. It is a period
characterized by a dynamic market, with the development of competition and improvement of quality. Web
browser publishers started offering new functionalities, better rendering performance and frequent updates (see
Figure 2). New web browsers were released by small software vendors and open source projects. Also, Google
released its first browser Chrome in 2008. If developing its own rendering engine is a costly and timely process,
the possibility to use open source rendering engines have certainly accelerated the entry of new players in the
market.10 At the same time, Web standards application has been strengthen by the wide use of compliance
tests such as Acid2 in 2005 and Acid3 in 2008.11 After such period of dynamism, the market has become more
concentrated in recent years, with Google gradually acquiring a dominant position since the deployment of its
own open source rendering engine Blink in 2013.
All in all, we see that the web browser market has a very central role in the evolution of the WWW and that
behavior of firms playing in this market may have considerable repercussions in the Web industry. Within this
context, investment on quality by the web browser publishers – such as the provision of security to users – seems
clearly an important issue. Besides, estimating the market power of firms in this market and using its usual
definition – the ability of a firm to raise the market price over marginal cost – is difficult, as firms do not charge
any price to the consumer. It is impossible to understand a firm’s behavior by considering the web browser
market alone; at the same time, there are too many unknown factors to take account if we consider the whole
9Source: http://lifehacker.com/5763452/what-data-does-chrome-send-to-google-about-me, http://www.investopedia.
com/articles/investing/020515/business-google.asp10Mozilla’s rendering engine Gecko became open source in 1998, Apple’s rendering engine Webkit become open source in 2005,
Google forked its own rendering engine Blink from Webkit and released it also in open source in 2013.11Acid2 and Acid3 are tests of Web standards compliance published and promoted by the Web Standards Project to expose Web
page rendering flaws in web browsers. At the time of the first test’s release, every browser failed it, but now a the major browsers onthe market pass it. Source: Wikipedia
6
Figure 2: Web browser’s update frequency
multi-sided market (that is, all the markets depending on the web browser market).
2.2 Software vulnerability and cybersecurity
2.2.1 Vulnerability research programs
In information system and computer security, a vulnerability refers to a weakness in the architecture, design, or
code, which allows an attacker to reduce a system’s information assurance, such as compromising the integrity,
availability or confidentiality of the data it processes.12 If the affected device is connected to a network accessible
through Internet – which is actually the case of almost all devices nowadays – it may be targeted by remote
attackers.
A vulnerability can be fixed by the development of a security patch by the vendor and its installation by
the user. The active discovery of vulnerability and its rapid patching are thus crucial to minimize the risk of a
system’s exposure (Schneier, 2000; McGraw and CTO, 2004). Today, different public and private organisms
are specialized in vulnerability research and help software publishers and companies – the users of information
systems – to deal with security incidents. Some are non commercial, such as Computer Emergency Response
Teams (CERT), others work for commercial purpose, operating in the market for vulnerabilities. CERTs are
security expert groups acting as coordinators between software publishers, user companies and researchers
that identify the security flaws. A CERT may have its own research team but does not purchase vulnerability
information; security problems are reported on a volunteer basis. In the commercial side, security firms called
also security infomediaries remunerate researchers for the discovery of vulnerability and communicate with
vendors to provide protection solutions for their clients. iDefense and Tipping Point are the two major security
firms playing in this market. Also, an increasing number of software vendors manage their own security research
team or offer bounties for vulnerability discovery. Google, for instance, launched a program called Google Project
Zero since 2014.
In our study, the main data sources are precisely these vulnerability research programs, namely Tipping
Point’s Zero Day Initiative (ZDI) program, iDefense Vulnerability Contributor Program (VCP), and Google
12Source: https://cwe.mitre.org
7
Project Zero. ZDI is a program run by the security firm Tipping Point since 2005. VCP is the corresponding
program of Verisign initiated in 2003. Both ZDI and iDefense notify the affected vendors and communicate with
them until the release of a security patch. Google Project Zero is a recent project initiated by Google in 2014
similar to the two other programs, financially rewarding researchers for vulnerability discovery.13 Information
about the vulnerability is kept confidential during a period of time specified by the infomediary’s disclosure
policy.
2.2.2 Vulnerability lifecycle
Figure 3 presents major events that may occur during the lifecycle of a software vulnerability, from its discovery
(either by a malevolent or a well-intentioned actor) to its mitigation by the delivery of a patch and its installation.
This timeline is consistent with its representation by Ioannidis, Pym, and Williams (2012), Beres, Griffin, Shiu,
Heitman, Markle, and Ventura (2008), or Frei, May, Fiedler, and Plattner (2006).
Figure 3: Lifecycle of a vulnerability
Five key events outline the different phases of a vulnerability lifecycle: (1) the discovery of the vulnerability,
(2) the vendor being informed about the existence of the vulnerability, (3) public disclosure, (4) patch release
by the vendor, and (5) patch installation by the user. At each stage, the associated security risk is different
(Schneier, 2000).
The vulnerability may be discovered first by an individual or an organism that does not work for the affected
software’s vendor. We call it then a zero-day vulnerability, since the software vendor has zero days left to deliver
a patch before the vulnerability may be exploited once it is discovered.
The probability to identify a vulnerability and fix it, thus the probability the software is more secured may
depend on the effort the vendor puts in vulnerability discovery activity. In our study, we only consider the
vendor’s post-discovery effort, that is, its patching decision after being informed about the vulnerability.
From the moment the software vendor is informed about the vulnerability, he will spend some time to release
a security fix. All other factors being equal (such as the vendor’s initial assets to deliver a patch or the basic
time necessary to develop the patch), the faster the vendor releases the patch, the more it will cost for him. On
the other side, from the moment the vulnerability is discovered, the risk it is exploited will grow until a security
13Google Project Zero focuses especially on vulnerabilities that can affect its competitor’s product, an operation system where itsapplications may be installed, a module connected to its product, a standard or a protocol used by one of its product
8
patch is available. Yet, note that the risk associated to the vulnerability is not measurable by the vendor until it
is informed about it. Based on this idea, we consider the time spent to release the patch after the vulnerability
was known by the vendor as a measure of the vendor’s investment in security provision.
Information about the security flaw can be disclosed to public before the vendor releases a security fix.
Though the public disclosure of vulnerability information increases the software’s exposure to attack, many
advocate that disclosure can be an incentive for vendors to be more responsive in patching their software (Arora
et al., 2006a). Vulnerability research programs generally keeps the vulnerability information confidential during
a period of time after contacting the affected vendor, as they specify on their disclosure policy. For instance, ZDI
keeps the vulnerability information confidential for 4 months, iDefense for 6 months and Google Project Zero
for 3 months. Our study account for the impact of vulnerability information disclosure although it is not the
main focus of our model. It is rather used as one of the factors that help to isolate the effect of the competitive
pressure.
Lastly, the security risk will be entirely mitigated when the software user actually applies the patch. Though
some papers deal with this subject (Cavusoglu et al., 2008; Shostack, 2003) the patching behavior of the consumer
is beyond the scope of our paper.
3 The vendor’s patching decision
Economists often point out the necessity to attribute liabilities to those who can manage the risks. Software
vendor has naturally an essential role in securing the software. Although the user is responsible to actually install
the patch, software vendor is indeed the one who will determine the initial security quality of its software (Arora
et al., 2006a), decide whether he will differentiate the price of its product for more secured options (Anderson,
2001), defines its vulnerability discovery and patch development strategy as well as its vulnerability information
and disclosure policies (Choi et al., 2010).
In our paper, we focus on the patching strategy the vendor should set when it is informed about a security
flaw in its product. What is the reasoning behind its decision to develop the security patch more or less rapidly?
That is, what is the optimal cost it would accept to spend in patching the flaw?
Among the many examples we can give, take the case of the well-known Sony PlayStation attack. In April
2011, Sony PlayStation Network was hacked, leaving an outage of 23 days and causing the loss of 77 million
users’ personal data.14 Users of Sony PlayStation services were directly affected by the security breach since they
were not able to use the service they paid for almost one month. But most of all, they were victims of private
data loss of high importance such as their account’s password and bank account details. On the vendor side,
14The attack is guessed to be a mix of DDOS and SQL injection technics. Attackers exploited very simple weak-nesses of its network such as the use of outdated versions of web servers. Source: www.extremetech.com/gaming/
84218-how-the-playstation-network-was-hacked
www.consumerist.com/2011/05/04/security-expert-sony-knew-its-software-was-obsolete-months-before-psn-breach
9
Sony has suffered two types of damages: first, the network outage caused direct damages to the functioning of
the firm (such as business continuity) and second, he has suffered from the negative externalities caused by user
losses. In the case of a software vendor, it does not suffer direct damages from its own product’s vulnerability
unless it uses the product himself (compared to a service provider for which an outage of its service cause direct
damages to its business). Thus our model considers only the second effect, namely the indirect damages that the
vendor internalizes from the user losses.
Sony might have invested adequately in securing its network if it had rightly assessed the damage cost of the
attack. Similarly, a software vendor will decide to spend in security as much as the potential security breach on
its product is likely to cost for him. In other words, when the software vendor discovers a security flaw in his
product, two main factors will be taken account in his patching decision: the negative externalities caused by the
perceived potential security risks by users, and the cost of the patching. Our objective is to examine the impact
that the competitive pressure may have on these two factors on which the vendor’s patching decision is based.
What are the factors considered by users to evaluate the security quality of a software?15 First, from the
moment the consumer is informed about a vulnerability, that is, from the moment the user becomes aware about
the security risk, each day the software remains unpatched will impact negatively the user’s perception of the
security quality. Thus public disclosure of the vulnerability information is essential to the vendor reputation.
Factors such as the criticity or the type of the vulnerability play also an important role in shaping the vendor
reputation. Indeed, users may be more sensible to certain types of vulnerabilities that involve confidential data or
which are evaluated as critical by security professionals. Several papers address these points. For instance, Arora
et al. (2010b) study the impact of public disclosure and Campbell et al. (2003) the impact of security breaches
according to their confidential nature. Our econometric model also accounts for these factors.16 However, our
focus is more on the extent to which the vendor considers its reputation important, according to the market
competition level. Indeed, we expect that the vendor will consider more or less importantly its reputation
depending on the competitive pressure and its market power. This corresponds to what Aghion et al. (2005)
name the “escape competition effect” in the sense that market competition may foster investment by ”reducing
a firm’s pre-investment rents by more than it reduces its post-investment rents”.
The software publisher will also take account the initial cost of the patching in order to determine how much
he will additionally spend on the patch to release it more or less rapidly. Patching cost will depend both on the
technical complexity of the patch and the vendor’s ability to develop it. Security experts will need more time to
develop a patch for a technically more complex vulnerability then a less complex one. The vendor may also be
able to react more rapidly to security incidents if it has a permanent team dedicated to security issues or it
employs skilled developers capable of finding efficient solutions within a short time, which will necessarily cost
respectively more than not having a permanent team and employing less competent developers. The ability
15Vendor reputation is determined by the quality of the product as it is perceived by the users (Shapiro, 1982).16Note also that in the case of Web browsers, the vast majority (75.05%) of vulnerabilities are disclosed to public after the patch
is released. The disclosure effect is nevertheless considered in our model as a control variable.
10
of a firm to invest in fixed cost (such as having a security research team) may depend on the firm size, since
large vendors typically have higher sales volume that allows higher economy of scale. It may also depend on the
market size for similar reasons of economy of scale (Arora et al., 2006a). But more importantly, it may depend
on the competitive pressure, which can either encourage or impede the firm to invest in security quality. This is
what (Aghion et al., 2005) name the “Schumpeterian effect”.
All in all, our hypothesis is that the speed of patching depends on two main factors, that is, the extent to
which the vendor internalizes the cost of the insecurity perceived by the users and the necessary cost to develop
the patch, which in turn, are both influenced by the competitive pressure.
4 The data
For the purpose of our empirical analysis, we combine four data sources: (1) vulnerability information collected
from three different vulnerability research programs, (2) important dates (patch and new versions release
dates) about each web browsers from the publisher’s website, (3) quaterly market share of each browsers from
Statcounter.com, (4) additional information about each vulnerability from the National Vulnerability Database
(NVD) .
Our data was primarily collected from three different vulnerability research programs: Zero Day Initiative
(ZDI), iDefense Vulnerability Contributor Program (VCP), and Google Project Zero. ZDI is a program run by
the security firm Tipping Point since 2005. VCP is the corresponding program of Verisign initiated in 2003. As
explained in Section 2, these firms are the two primary players in the commercial vulnerability market, which
financially reward the researchers in exchange for the information they have about new vulnerabilities they
discover. Both ZDI and iDefense notify the affected vendor and communicate with her until the release of a
security patch. Information about the vulnerability is kept confidential during a period of time specified by their
disclosure policy. The disclosure timing policy is not strictly applied, but the actual duration of confidentiality is
revealed on the program’s website after the release of the patch. Google Project Zero is a recent project initiated
by Google in 2014 similar to the others.17 As in other programs, the vulnerability information is disclosed to
public once a patch has been released or after a 90-day-deadline.
In order to measure the time a software vendor spends to patch a vulnerability, we needed both the date of
the patch delivery and the date on which the vulnerability was reported to the vendor. Given that the later
information is of a highly confidential nature (especially from the software vendor point of view), these programs
were some of the few sources that provided this information.
From the websites of these three programs, we collected and consolidated the data about web browser
vulnerabilities they identified from January 2006 to December 2015. We only consider vulnerabilities affecting
web browsers and which the web browser publisher itself can secure without relying on a third party intervention.
17Google Project Zero focuses especially on vulnerabilities that can affect its competitor’s product, an operation system where itsapplications may be installed, a module connected to its product, a standard or a protocol used by one of its product
11
For instance, vulnerabilities that concern Adobe Flash are not taken account because in these cases, patches are
mainly developed by Adobe.
This database has been completed with information from the National Vulnerability Database (NVD) about
vulnerability characteristics such as the severity (CVSS),18 the type of security impacts, and the public disclosure
date. As some primary information such as the disclosure date is collected from this source, we consider only the
NVD-listed vulnerabilities.
For vulnerabilities that affect more than one browser, we created separated observations for each browsers.
This allows us to assess separately the behavior of each publisher. Indeed, different publishers can release patches
for their browsers within a different timeline even if they are affected by the same vulnerability.
From each browser’s website, we collect information about the release date of the affected browser’s versions
and the patch release date.
Lastly, for each vulnerability-browser pair, we collect the quarterly market share of the affected browser at
the date when the vulnerability was reported to the vendor, from Statcounter.com.
The 521 observations we consider in our analysis represents 14% of the total number of browser vulnerabilities
referenced on NVD.19 It is a sample that represents the whole population in a balanced manner over time (Figure
4 left). Nonetheless we note that vulnerabilities of very high severity (CVSS of 9 to 10) are significantly more
represented in our sample compared to the parent population. We explain this bias by the commercial nature of
the programs that reported the vulnerabilities (Figure 4 right). This bias is controlled in our regression by the
use of the CVSS as a control variable.
Figure 4: Comparison of the studied sample to the whole population
18CVSS is a scoring system initiated by the National Infrastructure Advisory Council (NIAC) of the United States and maintainedtoday by the Forum of Incident Response and Security Teams (FIRST).
19The parent population we are considering is all the vulnerabilities affecting Web browsers and referenced on the CVE catalog ofNVD as identified during the investigated period of time.
12
5 Econometric model and variables
In order to evaluate the effect of the market competition intensity to the vendor’s responsiveness in vulnerability
patching, the following OLS regression model has been defined:
Patching T = β0 + β1Comp+ β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε (5.1)
From the moment a software vendor is alerted about a vulnerability affecting its product, it will spend a certain
period of time to develop the patch and to release it. Our dependent variable Patching T (patching time) is
the time spent by the vendor to release the patch, that is, the duration between the date the vendor is informed
about the vulnerability and the date he releases a patch for it.
Our hypothesis is that the software vendor’s decision to publish the security fix more or less rapidly is
influenced by the market competition level. Hence our key independent variable is the competition intensity level
in the web browser market Comp (comp intensity). We define it as equal to 1–HHI with HHI the Herfindahl
index of the market at the date when the vulnerability is discovered. The HHI is computed from the quarterly
market share of each browser from Statcounter.com.
In order to isolate the market competition effect, our model control for a list of exogenous factors that may
impact the responsiveness of the vendor to develop a security patch.
First, V uln char accounts for the characteristics of the vulnerability such as the severity and the type of
the vulnerability. This vector of variables captures the impact of the potential risk the vulnerability represents
(whatever the market competition intensity or the position of the vendor on the market are, the vendor will
prefer to patch more rapidly a vulnerability that has a severe security impact) and the complexity of the patch
(vulnerabilities more complex to secure will need more time to be developed). More precisely, we use two types
of information: The Common Vulnerability Scoring System (CVSS) and the Common Weakness Enumeration
(CWE).20 The CVSS is a value ranging from 1 to 10 and takes account a number of characteristics such as the
complexity and the type of intrusion or the access complexity. The CWE is a formal list of software weaknesses
that can lead to exploitable security vulnerabilities.21 CVSS value is directly used as the vulnerability severity
variable. CWE are used as a system of dummies we named vulnerability type. These exogenous variables enable
us to capture the necessary cost and therefore the basically necessary time to release the patch.
Secondly, we control for the characteristics of the web browser and its publisher by V&Soft char. First,
the incentive of the vendor to release a security patch more or less quickly can depend on the maturity of the
software (software age). Indeed, software vendors usually limit or end the support for a product after a certain
period of time. We also control for vendor-specific characteristics by a vector of dummies (each vendor has
20These are “common language” defined with the goal of providing a common baseline standard for vulnerability identification,mitigation, and prevention efforts. Both are standardized metrics used by the development community and security practitioners.
21Software weaknesses referenced as CWE are: buffer overflows, format strings, etc.; structure and validity problems; commonspecial element manipulations; channel and path errors; handler errors; user interface errors; pathname traversal and equivalenceerrors; authentication errors; resource management errors; insufficient verification of data; code evaluation and injection; andrandomness and predictability. Source: MITRE
13
an assigned dummy). Indeed, vendors may have specific patch release policies that affect their patch release
decisions but are unobserved by us. Some of them may care more about their reputation because of the spillover
effect on their other products. The patching time can also depend on their financial ability to invest in security
(for example in order to afford a larger security development team). In Arora et al. (2006a), this gap between
vendors is controlled by the vendor size. In our case, web browser publishers present heterogeneous forms of
organization and business models, from open source foundation to multinationals listed on stock exchange (see
Table 1). The size of a firm is hence not an adequate information to account for the vendor specific unobserved
and we preferred to attribute a dummy variable for each vendor. In addition, our model takes account the effect
of opensource collaboration by using a dummy variable for whether the rendering engine is developed with an
opensource license.
Table 1: Comparison of web browsers
Browser Browser Rendering Rendering engine Vendor Type oflicense type engine license type Organization
Internet Explorer Proprietary Trident Proprietary Microsoft Multinational, publicly held corp.Chrome Freeware Blink GNU LGPL Google Multinational, publicly held corp.Safari Freeware Webkit GNU LGPL Apple Multinational, publicly held corp.Firefox Opensource MPL Gecko MPL Mozilla Foundation Foundation, non profit org.
Third, User ext captures externalities directly linked to users, such as the impact of information provided to
users and the number of users. Specifically, we account for the impact of vulnerability information disclosure by
the variable earlier disclosure, which is a dummy variable taking the value 1 if the vulnerability is disclosed to
public from 0 to 89 days after being reported to the vendor (That is, earlier than the conventional 90 days stated
by the disclosure policy of each vulnerability search programs from where our data set comes) and 0 if it is
disclosed to public after 90 days. The variable n users is the number of users for the concerned web browser and
therefore the number of users affected by the vulnerability. It captures the impact of the network size affected
by the vulnerability. We consider that the number of users of a web browser at a given time is the product of
the number of Internet user (total number of mobile and fixed broadband subscription in the World from ITU)
and the market share of the browser, assuming that for one connection to the Internet one web browser is used.
Finally, T effect captures the potential time trend and ε is the error term.
After having tested the linear relationship between patching time and market competition, we then test the
quadratic relationship. For this purpose, the following variant model has been defined:
Patching T = β0 + β1aComp+ β1bComp2+
β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε
(5.2)
14
Next, Eq. (5.1) and Eq. (5.2) are tested on the rendering engine market (So far, we have considered the
web browser market.). A rendering engine (called also the layout engine) is a core component of a web browser
that renders and interprets formatting information in order to display the web contents with required layout
and appearance. The web browser market is dependent to the rendering engine market since the later is a an
essential component of the web browser. Our objective here is to see whether we observe the same relation
between competition and patching time on the upstream market of web browsers. The econometric model does
not change, but the values of some variables are recalculated according to the considered market, such as the
HHI or the number of users affected by the vulnerability.
Lastly, we define a variant model using the market share of the affected web browser as the key explanatory
variable:
Patching T = β0 + β1M share+
β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε
(5.3)
Patching T = β0 + β1aM share+ β1bM share2+
β2V uln char + β3V&Soft char + β4User ext+ β5T effect+ ε
(5.4)
While the main objective of our study is to examine the impact of the market competition intensity which
reflects the potential market power some publishers can benefit when they are in a favorable position (such as
having a big market share), Eq. (5.3) and Eq. (5.4) rather test how publishers behave when they hold a larger
part of the market. We note that having a large market share does not necessarily imply having a large market
power.
All the models are estimated with ordinary least squares (OLS). For robustness checks, we also performed
variant regression tests with or without some of the control variables. A description of all variables is included in
Table 2 , while Table 3 presents descriptive statistics.
15
Table 2: Description of variables
Variable DescriptionDependent variablePatching time (Patching T )patching time Time spent by the editor to release a patch (unit: number of days)
(Release date of the patch – Reported date of the vulnerability to the vendor)Explanatory variablesCompetition intensity (Comp)comp intensity Herfindahl-Hirschman Index,(comp intensity)2 measured by each browser’s market share at the vulnerability discovery date
(reported date)Market share (M share)market share Market share of each browser at the date when the vulnerability was reported(market share)2 to the vendorVulnerability specific effects (V uln char)vulnerability severity Level of severity of the vulnerability (CVSS base score from 1 to 10)vulnerabililty type Classification of the type of weakness the vulnerability is subject to, such as “cross site
scripting”, “SQL injection”, “Information leak”. 12 type of weaknesses were associatedto web browsers vulnerabilities (dummies)
Software and vendor specific effects (V&Soft char)software age Maturity of the software at the time when the vulnerability is discovered
(unit: number of days) (discovery date of the vulnerability – release date ofthe earliest browser version affected by the vulnerability)
vendor dummies Dummies for each vendors : Google, Apple, Mozilla, Microsoft (dummies)opensource 1 if the affected web browser’s engine is opensource, 0 if not (dummy)User related externalities (User ext)n users Number of users of the browser on the date on which the vulnerability was reported.
(Market share of the browser number of internet user)earlier disclosure 1 if the vulnerability was publicly disclosed earlier than the conventional period of time
of 90 days, after being notified to the vendor, 0 if not. (dummy)Time effect (T effect)time effect The date on which the vulnerability was reported to the editor (unit: quaterly date)
Table 3: Descriptive statistics of variables
variable mean min max sdFor web browser marketpatching time 105 0 665 61.80comp intensity .725 .385 .791 .086cvss 8.9 3.3 10 1.13cwe119 Buffer errors (dummy) .42 0 1 .49cwe17 Code (dummy) .00 0 1 .062cwe94 Code injection (dummy) .11 0 1 .31cwe16 Configuration (dummy) .00 0 1 .044cwe79 Cross-Site Scripting (dummy) .00 0 1 .044cwe200 Information leak (dummy) .01 0 1 .11cwe20 Input validation (dummy) .05 0 1 .21cwe189 Numeric errors (dummy) .02 0 1 .15cwe22 Path traversal(dummy) .00 0 1 .044cwe264 Privileges and access control (dummy) .04 0 1 .19cwe362 Race conditions (dummy) .00 0 1 .062cwe399 Ressource management errors (dummy) .30 0 1 .46software age (number of days) 2197 0 5415 1534google (dummy) .05 0 1 .21apple (dummy) .11 0 1 .31mozilla (dummy) .11 0 1 .31opensource (dummy) .26 0 1 .44n users 524 11 1399 255earlier disclosure (dummy) .49 0 1 .50time effect 2012q4 2005q4 2015q4 9qFor rendering engine marketcomp intensity .65 .385 .731 .062blink (dummy) .021 0 1 .1439webkit (dummy) .13 0 1 . 337n user 580 51 1750 256
16
6 Estimation results
We first provide preliminary evidence on the relationship between competition and patching time through a
scatter plot of the patching time versus market competition, without accounting for other effects. Next we
present the regression results for linear models and for quadratic ones. For quadratic models, we compare the
different curves fitting with the estimated results. We also perform various robustness checks. In particular, we
present the estimated results for the rendering market. Lastly, we provide estimated results for the relationship
between patching time and vendor’s market share.
Figure 5: Scatter plot of patching time against competition intensity
First of all, when we look at the relationship between security investment and market competition without
accounting for any other effects, we observe a U-shape relationship as illustrated by Figure 5. Figure 5 plots a
measure of competition (1–HHI) on the x-axis against the patching time of a vulnerability for a web browser
on the y-axis. Each point represents a vulnerability-web browser pair. On the y-axis, we present the patching
time in an inverted way (we go toward the upside of the y-axis when the number of days passed to release the
patch decreases) to be consistent with the idea that the more the software vendor invests in security the faster
the patch is released.
The quadratic regression of competition intensity on patching time without other control variables provides a
consistent result with the scatter plot (Table 4); indeed the quadratic term of competition intensity is negative
and statistically significant and the x-coordinate of the maximum is located at 0.60.22 We though note that
this simple model accounts only for 2.4% of the data. Most of all, this regression does not account for some
factors that significantly impact the dependent variable such as the time trend, public disclosure of vulnerability
information, or individual characteristics of software vendors.
We now test the linear models that control also for other effects than competition intensity. Column 1 to 6
22Measure of the market competition varies from 0 to 1 as we have computed it as 1−HHI
17
of Table 4 display the regression results for linear models that include all or some of the control variables that
we have defined, as summarized below:
• (1) All control variables included (vulnerability specific effects, software and vendor specific effects, impact
of public disclosure and number of users, time trend)
• (2) All control variables except vulnerability type dummies
• (3) All control variables except opensource dummy
• (4) All control variable except number of users
• (5) All control variable except disclosure impact
• (6) All control variable except time effect
Table 4: OLS Regression of patching time by competition intensity
Competition intensity (Comp)comp intensity 1,003***
(346.3)(comp intensity)2 -840.6***
(284.2)Other control variablesV uln char NoV&Soft char NoUser ext NoT effect No
Observations 521R-squared 0.024
Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1
Table 5: OLS regression of patching time, linear relationship
VARIABLES (1) (2) (3) (4) (5) (6)Competition intensity (Comp)comp intensity 197.2*** 208.3*** 193.7*** 161.6*** 195.1*** -31.98
(48.29) (48.34) (48.21) (45.16) (55.68) (36.64)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes Yes Yes Yes Yes
vulnerability type dummies (V&Soft char) Yes Yes Yes Yes Yes
Software and vendor specific effectsoftware age Yes Yes Yes Yes Yes Yes
vendor dummies Yes Yes Yes Yes Yes Yes
opensource Yes Yes Yes Yes Yes
User related externalities (User ext)n users Yes Yes Yes No Yes Yes
earlier disclosure Yes Yes Yes Yes Yes
Time effect (T effect) Yes Yes Yes Yes Yes
Observations 521 521 521 521 521 521R-squared 0.368 0.344 0.366 0.362 0.178 0.329
Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1
Table 5 displays only the coefficients for variable comp intensity. Overall, we observe that patching time
18
get longer when competition intensity is higher. That is, a negative relationship between the responsiveness of
the vendor in releasing a patch and the market competition intensity. In other words, the more the market is
concentrated, the faster the vendor releases a security patch. Consistent results for the different regressions from
Column 1 to 6 confirm the robustness of our initial model Eq. (5.1) that account for all the control variables.
Figure 6: Evolution of competition intensity (1-HHI) from 2006 to 2015
We note that the impact of the competition intensity is statistically not significant for regression that does
not account for the time effect (Column 6). In fact, the time effect variable is strongly correlated with our
variable of interest comp intensity. Indeed, we see in Figure 6 that the competition intensity follows globally a
linear trend over the studied period of time except in recent years. Independently of the current market structure
of web browser market, there is no doubt that software industry actors, including the software vendors, show an
increasing interest in cybersecurity over time. They also invest more in security than before. Accounting for the
time trend in our model is therefore important in order to isolate the effect of market competition from other
factors that evolved similarly over time. We note that the time effect variable can also capture a part of the
competition effect.
In order to check the robustness of the linear model and to understand the role of the time effect variable
in our estimation, we also test the quadratic model (Eq.5.2). Table 6 displays the regression results for the
quadratic models accounting for different control variables as such:
• (1) No control variable
• (2) All control variables taken account (vulnerability specific effects, software and vendor specific effects,
impact of public disclosure and number of users, time trend)
• (3) All control variables except vulnerability type dummies
• (4) All control variables except opensource dummy
• (5) All control variable except number of users
• (6) All control variable except disclosure impact
• (7) All control variable except time effect
We also compute the curvature and the x-coordinate of the maximum for the function Patching T =
β1(comp)2 + β2comp+ γ in order to visualize graphically the relationship between our dependent variable and
19
Table 6: OLS regression of patching time, quadratic relationship
VARIABLES (1) (2) (3) (4) (5) (6) (7)Competition intensity (Comp)comp intensity 1,003*** 1,486*** 1,573*** 1,492*** 1,327*** 1,741*** 940.5***
(346.3) (412.5) (344.8) (413.9) (408.7) (474.1) (349.1)(comp intensity)2 -840.6*** -1,010*** -1,072*** -1,017*** -919.1*** -1,212*** -777.5***
(284.2) (315.1) (263.7) (316.4) (314.2) (360.9) (295.6)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes Yes Yes Yes Yesvulnerability type dummies Yes Yes Yes Yes Yes
Software and vendor specific effect (V&Soft char)software age Yes Yes Yes Yes Yes Yesvendor dummies Yes Yes Yes Yes Yes Yesopensource Yes Yes Yes Yes Yes
User related externalities (User ext)n users Yes Yes Yes Yes Yesearlier disclosure Yes Yes Yes Yes Yes
Time effect (T effect) -3.847*** -4.141*** -3.791*** -2.840*** -4.287***(0.840) (0.729) (0.835) (0.755) (0.922)
Observations 521 521 521 521 521 521 521R-squared 0.024 0.388 0.369 0.387 0.379 0.207 0.341
x coordinate of Maximum (−β2/2β1 ).597 .735 .733 .733 .722 .718 .605
Curvature (|β1|)841 1010 1072 1017 919 1212 777
Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1
explanatory variable of interest.
For all the regressions, we find a negative and statistically significant effect of the quadratic term of competition
intensity on the patching time. This result is also confirmed by the regression (7) where we do not account for
the time effect. Consistent results for the different regressions from (1) to (7) confirm the robustness of our
initial model that accounts for all the control variables. We also note that the linear model is as robust as the
quadratic model.
The negative coefficient for the quadratic term suggests an U-form relationship between market competition
and the speed of patch release. That is, software vendors invest more in security patch in a highly concentrated
market or in a highly competitive market one. Nevertheless, considering that the measure of competition intensity
in the studied market varies from 0.39 to 0.79 (cf. Table 3 of descriptive statistics) and that the x-coordinate of
the maximums are located close to 0.79, the relationship between patching time and competition intensity is
globally monotonous on the range of concentration rate covered by our tests. This is also graphically visible in
Figure 7 where we plot the fitting curves for quadratic regressions (1) to (7).
When we compare the curves of the regressions that accounts for the time effect variable to those that does
not, we see that the negative impact of the competition intensity on patching time is more emphasized when
the model accounts for the time effect, that is, regression (2) to (6). Moreover, we observe for these regressions
results that the variable time effect is negative and statistically significant (see Table 6): patches are released
20
Figure 7: Fitting curves for quadratic regressions
in average from 2.6 to 4.3 days earlier every quarter.
In Table 7 , we focus on other explanatory variables than competition intensity, such as the effect of opensource
and public disclosure. Table 7 displays the results for the following regressions:
• (1) Linear model with all the control variables (vulnerability specific effects, software and vendor specific
effects, impact of public disclosure and number of users, time trend)
• (2) Linear model with all the control variables except opensource dummy
• (3) Linear model with all the control variables except the disclosure impact
• (4) Quadratic model with all the control variables
• (5) Quadratic model with all the control variables except opensource dummy
• (6) Quadratic model with all the control variables except the disclosure impact
• (7) Quadratic model with all the control variables except the time effect
Our results support the idea that opensource software is patched more rapidly and that disclosure of
vulnerability information quickens the vendors to release a security patch.
Next, we apply our model to the market for rendering engines. The same linear and quadratic models
(Eq. 5.1 and Eq. 5.2) are applied, but we consider as one observation a vulnerability-rendering engine pair
(and not a vulnerability-web browser pair). As a result, the explanatory variable of interest value changes,
as well as values of some control variables such as vendor dummies and number of users. Estimation results
(displayed in Table 8) are similar to the web browser market except that the “escape competition effect” is
more emphasized. Indeed, we find a positive and statistically significant relation of competition intensity with
the patching time (the more market competition is intensive, the later patches are released) and a negative
and statistically significant quadratic term of competition intensity for the quadratic model. Besides, rendering
engine market is less impacted by competition intensity than the web browser one: on the web browser market,
the patching time presents a variation of 197 days for 1% of variation of the market competition intensity
21
Table 7: OLS Regressions of patching time, results for opensource & disclosure variables
VARIABLES (1) (2) (3) (4) (5) (6) (7)Competition intensity (Comp)comp intensity 197.2*** 193.7*** 195.1*** 1,486*** 1,492*** 1,741*** 940.5***
(48.29) (48.21) (55.68) (412.5) (413.9) (474.1) (349.1)(comp intensity)2 -1,010*** -1,017*** -1,212*** -777.5***
(315.1) (316.4) (360.9) (295.6)
Vulnerability specific effect (V uln char) Yes Yes Yes Yes Yes Yes Yes
Software and vendor specific effect (V&Soft char)software age & vendor dummies Yes Yes Yes Yes Yes Yes Yes
opensource -66.95*** -63.00*** -61.72*** -56.84*** -37.93**(16.78) (19.02) (16.12) (18.28) (15.10)
User related externalities (User ext)n users Yes Yes Yes Yes Yes Yes Yes
earlier disclosure -58.08*** -58.05*** -56.82*** -56.77*** -58.51***(4.199) (4.193) (4.002) (3.995) (4.272)
Time effect (T effect) Yes Yes Yes Yes Yes Yes
Observations 521 521 521 521 521 521 521R-squared 0.368 0.366 0.178 0.388 0.387 0.207 0.341
Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1
Figure 8: Fitting curve for regressions with all CV
22
Table 8: OLS Regression of patching time, considering the rendering engine market
Linear Quadratic QuadraticVARIABLES no CVCompetition intensity (Comp)comp intensity 98.48** 1,727** 1,031**
(45.78) (735.6) (401.9)(competition intensity)2 -1,345** -924.6***
(601.3) (352.9)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes
vulnerability type dummies Yes Yes
Software and vendor specific effect (V&Soft char)software age Yes Yes
vendor dummies Yes Yes
opensource -56.94*** -55.03***(17.12) (16.55)
User related externalities (User ext)n users Yes Yes
earlier disclosure -58.81*** -56.77***(4.226) (3.960)
Time effect (T effect) Yes Yes
Observations 521 521R-squared 0.368 0.344
x-coordinate of Maximum (−β2/2β1) N.A .64 .56Curvature ( |β1| ) N.A 1344 925
Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1
(according to the linear model with all control variables included) while we estimate a variation of 98 days
for the rendering engine market. Moreover, the x-coordinate of the Maximum is smaller for the rendering
engine market than in the case of web browser market, meaning that the idea of a U-relationship between
patching time and competition intensity is more consistent in the rendering engine market. Figure 8 helps
to visualize this difference of estimation results between the web browser market and the rendering engine market.
Lastly, Table 9 shows the result for the variant model (Eq. 5.3 and Eq. 5.4) using the market share of the
vendor as the key explanatory variable. It displays the regression results accounting for the different control
variables as such:
• (1) Linear model with all the control variables (vulnerability specific effects, software and vendor specific
effects, impact of public disclosure and number of users, time trend)
• (2) Linear model with all the control variables except opensource dummy
• (3) Linear model with all the control variables except the number of users
• (4) Linear model with all the control variables except the disclosure impact
• (5) Quadratic model with all the control variables
• (6) Quadratic model with all the control variables except opensource dummy
23
• (7) Quadratic model with all the control variables except the number of users
• (8) Quadratic model with all the control variables except the disclosure impact
Table 9: OLS Regression of patching time with market share as key explanatory variable
Variables (1) (2) (3) (4) (5) (6) (7) (8)Market share (M share)market share -145.8** -140.6** -62.51* -148.2** 13.53 1.313 34.92 -442.0
(58.44) (58.55) (32.14) (72.54) (306.9) (308.0) (61.73) (340.8)(market share)2 -128.0 -113.9 -143.3* 236.0
(234.1) (234.6) (76.87) (256.5)Vulnerability specific effect (V uln char)vulnerability severity Yes Yes Yes Yes Yes Yes Yes Yes
vulnerability type dummies Yes Yes Yes Yes Yes Yes YesYes Yes Yes Yes
Software and vendor specific effect(V&Soft char)software age Yes Yes Yes Yes Yes Yes Yes Yes
vendor dummies Yes Yes Yes Yes Yes Yes Yes Yes
opensource -64.44*** -59.07*** -60.75*** -66.57*** -66.67*** -56.89***(17.83) (17.01) (19.78) (18.16) (18.10) (19.78)
Externalities related to users (Userext)nbuser Yes Yes Yes Yes Yes Yes
earlier disclosure -57.99*** -57.95*** -57.75*** -58.52*** -58.42*** -58.57***(4.218) (4.214) (4.176) (4.217) (4.209) (4.291)
Time effect (T effect) Yes Yes Yes Yes Yes Yes
Observations 521 521 521 521 521 521 521 521R-squared 0.356 0.354 0.353 0.166 0.357 0.355 0.357 0.168
Robust Standard errors in parentheses*** p < 0.01, ** p < 0.05, * p < 0.1
The regression results show that the impact of market share is highly significant and affect the patching time
in the same direction as the competition effect. In other words, we observe a negative relationship between the
responsiveness of the vendor and its market share. Its estimated impact is as large as the competition effect (we
can compare the coefficients as they are normalized) for the linear model. Low statistical significance of the
competition intensity variable for the quadratic models supports the robustness of the linear result. Note that
the estimated results confirm also the positive and significant impact of opensource and disclosure variables.
7 Conclusion
We have built a data set related to vulnerabilities of web browsers and factors that may impact their patching
time. Our main objective was to examine the effect of the market competition to the vendor’s patching behavior.
We limited our tests on the web browser market, which is a representative market of the Internet based industry
and situated at the center of cybersecurity issues. We use a very simple measure of the market competition
intensity based on the HHI.
We find evidence that competition impacts negatively the vendor’s responsiveness in releasing a security
patch, that is, the more the market is competitive, the less the vendor spends in security provision. This
24
argument is also supported by the estimated results for the rendering engine market. In addition, the negative
relationship between vendor’s responsiveness and its market share confirm the idea that a software vendor does
not necessarily take advantage of its market position to neglect the security quality of its product. On the
contrary, the larger his market share is, the faster he fixes the security flaw.
Our finding is not intuitive. Indeed, although an extensive IO literature covers the relationship between
market structure and investment, it is hard to find general tendencies both in theoretical and empirical studies.
The unique empirical study in our knowledge dealing with similar data for a similar objective is Arora et al.
(2010a) and support a different conclusion regarding the relationship between competition and the security
provision effort of vendors. Our approach also differs from theirs in that we use a direct measure of the market
concentration to estimate the effects of competition while they analyze the impact of a vendor’s patching behavior
to its competitor ones.
References
P. Aghion and R. Griffith. Competition and growth: reconciling theory and evidence. 2008.
P. Aghion, N. Bloom, R. Blundell, R. Griffith, and P. Howitt. Competition and innovation: An inverted-urelationship. The Quarterly Journal of Economics, 120(2):701–728, 2005.
R. Anderson. Why information security is hard-an economic perspective. In Proceedings of the 17th AnnualComputer Security Applications Conference, page 358. IEEE Computer Society, 2001.
R. Anderson and T. Moore. Information security economics–and beyond. pages 68–91, 2007.
A. Arora, J. P. Caulkins, and R. Telang. Research note-sell first, fix later: Impact of patching on software quality.Management Science, 52(3):465–471, 2006a.
A. Arora, A. Nandkumar, and R. Telang. Does information security attack frequency increase with vulnerabilitydisclosure? an empirical analysis. Information Systems Frontiers, 8(5):350–362, 2006b.
A. Arora, C. Forman, A. Nandkumar, and R. Telang. Competition and patching of security vulnerabilities: Anempirical analysis. Information Economics and Policy, 22(2):164–177, 2010a.
A. Arora, R. Krishnan, R. Telang, and Y. Yang. An empirical analysis of software vendors’ patch releasebehavior: impact of vulnerability disclosure. Information Systems Research, 21(1):115–132, 2010b.
T. August and T. I. Tunca. Who should be responsible for software security? a comparative analysis of liabilitypolicies in network environments. Management Science, 57(5):934–959, 2011.
Y. Beres, J. Griffin, S. Shiu, M. Heitman, D. Markle, and P. Ventura. Analysing the performance of securitysolutions to reduce vulnerability exposure window. pages 33–42, 2008.
K. Campbell, L. A. Gordon, M. P. Loeb, and L. Zhou. The economic cost of publicly announced informationsecurity breaches: empirical evidence from the stock market. Journal of Computer Security, 11(3):431–448,2003.
H. Cavusoglu, H. Cavusoglu, and J. Zhang. Security patch management: Share the burden or share the damage?Management Science, 54(4):657–670, 2008.
J. P. Choi, C. Fershtman, and N. Gandal. Network security: Vulnerabilities and disclosure policy*. The Journalof Industrial Economics, 58(4):868–894, 2010.
S. Frei, M. May, U. Fiedler, and B. Plattner. Large-scale vulnerability analysis. pages 131–138, 2006.
25
E. Gal-Or and A. Ghose. The economic incentives for sharing security information. Information SystemsResearch, 16(2):186–208, 2005.
L. A. Gordon, M. P. Loeb, W. Lucyshyn, and T. Sohail. The impact of the sarbanes-oxley act on the corporatedisclosures of information security activities. Journal of Accounting and Public Policy, 25(5):503–530, 2006.
C. Ioannidis, D. Pym, and J. Williams. Information security trade-offs and optimal patching policies. EuropeanJournal of Operational Research, 216(2):434–444, 2012.
K. Kannan and R. Telang. Market for software vulnerabilities? think again. Management Science, 51(5):726–740,2005.
B. C. Kim, P.-Y. Chen, and T. Mukhopadhyay. An economic analysis of the software market with a risk-sharingmechanism. International Journal of Electronic Commerce, 14(2):7–40, 2009.
G. McGraw and C. CTO. Exploiting software: How to break code. In Invited Talk, Usenix Security Symposium,San Diego, 2004.
S. Ransbotham, S. Mitra, and J. Ramsey. Are markets for vulnerabilities effective? ICIS 2008 Proceedings,page 24, 2008.
B. Schneier. Managed security monitoring: Closing the window of exposure. Counterpane Internet Security,2000.
C. Shapiro. Consumer information, product quality, and seller reputation. The Bell Journal of Economics, pages20–35, 1982.
A. Shostack. Quantifying patch management. Secure Business Quarterly, 3(2):1–4, 2003.
R. Telang and S. Wattal. An empirical analysis of the impact of software vulnerability announcements on firmstock price. Software Engineering, IEEE Transactions on, 33(8):544–557, 2007.
H. R. Varian. High-technology industries and market structure. University of California, Berkeley, 33, 2001.
26