A zero-day vulnerability refers to an exploitable weakness in software that is usually unknown to a vendor. Since this vulnerability has never been shared publicly, no days have gone by to address the issue; thus it is on “day zero”. While such a vulnerabilitymay be intentionally introduced, more often these vulnerabilities are inadvertently created. Zero-day exploits use an exploitable weakness to carry out an attack. Such exploits can be obtained through research and investigation or purchased through private-sector providers5
Governments and private actors have increasingly debated the use of zero-day software vulnerabilities given their potential to militarize cyberspace.To craft policy to address zero-days, it is necessary to understand that software vulnerabilities have a life cycle with three fundamental parts:
- First, a zero-day vulnerability is written or introduced; a programmer writes code that is fundamentally exploitable or amenable to exploitation (e.g. software amenable to a vulnerable configuration).
- Second, that zero-day vulnerability is discovered, typically after that software is implemented. Sometimes, different groups of researchers independently find the same vulnerability, often referred to as “rediscovery”.6 Researchers then develop means to exploit that vulnerability. These means, often called “exploits”, can then be purchased by either the public or private sector. The process by which the government decides to withhold or disclose vulnerabilities to a software vendor (with the expectation that the vendor develops a mitigation measure like a patch) is commonly referred to as the “vulnerabilities equities process” in the US.
- Third, an exploit must be used on systems running the vulnerable software. To the extent that the exploit is deployed before mitigation measures (e.g. patches) can be developed, that exploit will result in some damage or harm. While patches are the most common form of mitigation measure, sometimes vulnerabilities are managed by other means (e.g. by avoiding a particular software configuration).
To address the first part of the life cycle, policy-makers may consider promoting or legislatively adopting coding standards for software vendors to limit the number of vulnerabilities created. Several commendable industry initiatives have been designed to promote secure coding standards based on expert guidance and community consensus (e.g. OWASP, NIST 800-64).78 However, even with greater resources devoted to coding standards and practices, zero-day vulnerabilities will continue to exist due to human error and other factors.
To address the second part of the life cycle, policy positions vary on two axes: involvement in the zero-day market and disclosure. (The third part of the life cycle is addressed under point 4.2 “Vulnerability liability”.):
- Governments can completely exit the zero-day market and avoid research dedicated to finding software vulnerabilities. Alternatively, governments may choose to invest heavily in finding and exploiting vulnerabilities.
- Governments may choose to stockpile vulnerabilities for use at some future date or disclose these vulnerabilities to software vendors so that software vendors issue patches. The longer a given vulnerability exists, the more likely that it is rediscovered and exploited by other actors, including criminals and nation-state adversaries.
The risks and benefits of zero-day policy also depend on these two axes:
- The more heavily involved a government is in the research and purchasing of zero-day exploits, the more likely that software vulnerabilities are to be discovered generally. Government purchases incentivize researchers to find vulnerabilities, particularly as the monetary value of vulnerabilities rises. While there is an active community of researchers who do not have pecuniary motives for surfacing vulnerabilities for general research, private-sector vendors have begun to embrace the value of creating “bug-bounty” programmes where compensation is provided to individuals who inform companies about vulnerabilities in their products. As the public sector becomes a more active purchaser for knowledge of vulnerabilities — absent increased bounties — these programmes are less likely to be effective (as individuals will go to the highest bidder).9
- The more government discloses vulnerabilities to the private sector, provided the private sector expeditiously mitigates those vulnerabilities, the more likely software is to be secure against all actors. This will have a double-edged effect as government may seek to utilize those exploits for law enforcement or espionage and will be unable to do so.
One important ancillary factor when considering a government’s engagement with zero-day vulnerabilities is the placement of decision-making authority. In the US context, the “vulnerabilities equities process” is managed through the Executive branch owing to national security considerations. However, in other contexts, that same process could be an explicit legislative function. For example, continuing the US policy analogy, the American Congress could also pass legislation enumerating how vulnerabilities will be shared with the private sector.
Case study: Google, Project Zero
Google has embarked on an ambitious effort to find and disclose vulnerabilities to software vendors. Google’s effort is noteworthy both in terms of its intellectual underpinnings and clever use of disclosure to incentivize patching vulnerabilities.10
Google has invested in discovering and disclosing zero-day vulnerabilities owing to a belief that patching zero-days is a highly efficient way to guarantee security. To put this belief in context, it is important to note that software is developed within the security methodology of defence-in-depth. A helpful physical analogue might be that of a medieval castle, which had many layers of defence, from moats to outer walls to ramparts and inner walls. The most devastating exploits utilize multiple zero-days to penetrate many layers of defence to breach a target (e.g. Stuxnet). Google believes that patching a small number of vulnerabilities can extraordinarily improve security as the impenetrability of one layer rebuffs an entire exploit.11
Google has also pioneered an effective method to ensure that the vulnerabilities it discovers are promptly patched by software vendors. Namely, Google promises to disclose vulnerabilities to the public after a finite period of time to incentivize vendors to invest in developing and deploying patches rapidly.
Connecting policy to values
Zero-day policy choices balance a number of important trade-offs, particularly with respect to security, economic value, privacy and accountability:
- Security is improved in two almost symmetrically different scenarios. One line of thinking, more associated with the “offence” approaches in the framework, is that government can provide greater security for their citizens and firms by virtue of advance notice of an attack. Here, the government achieves advance notice of an attack by utilizing zero-day exploits against adversaries to predict or to thwart their intentions.
- Another way government can promote security is by sharing vulnerabilities with the private sector to “harden” information and communication technology (ICT), and to prevent adversaries from using those same exploits against a given country’s citizens. The efficacy of this latter approach is premised on the timely private-sector development of mitigation strategies for shared vulnerabilities.
- The economic value associated with different zero-day policy scenarios is a function of a few different effects. First, greater security through both offence and defence is associated with less intra-state damages arising from cyberincidents. However, in the case of an “offensive” approach, security must be weighed against the risk of the same vulnerabilities being used against a country’s citizens, as well (an instance where a zero-day vulnerability is “rediscovered” by an adversary). Additionally, some observers have noted that actions whose impact is to deteriorate trust in ICT create substantial intangible costs in terms of diminished ICT adoption.
- Privacy is also impacted by choices in some scenarios. Namely, in an “offence” approach, the improvement in security is premised on decreased privacy. In most cases, presumably decreased privacy should be limited to suspected criminals but the risk is that the confidentiality of innocent individuals will also be compromised.
- The extent to which vulnerabilities are shared withthe private sector impacts the accountability of both the public and private sectors. If the public sector shares more vulnerabilities with the private sector, it is incumbent on the private sector to rapidly develop mitigation measures against those vulnerabilities, increasing the private sector’s accountability. The opposite is also true; with more zero-day vulnerabilities held for greater periods of time, the public sector has greater accountability to ensure that those vulnerabilities are not weaponized by adversaries.