Jonsson and Olovsson [JO97] tested the effect an attacker’s knowledge and expe- rience had on successfully compromising a system. Assigning students to attack a University computer system, they measured number of successful breaches, rate of breach and experience level. They concluded that there appears to be a learning curve that disadvantages the less experienced attacker.
Gopalakrishna and Spafford [GS05] presented a trend analysis of vulnerabilities reported on Bugtraq, CVE and ICAT. They speculated that the increased rate of discovery of vulnerabilities of the same type in a piece of software was the result of a learning period. They reasoned that this ’learning’ was the period of time required for a given piece of software to gain a "critical-mass" of users before bugs are discovered.
However, as Ozment [Ozm07] points out, this incorrectly assumes that some fixed proportion of the total user population are looking for vulnerabilities. Ozment con- jectured scenarios in which an attacker discovers a vulnerability or reads about the details of one, and applies these “lessons learned” to a similar domain by attempting an attack of a similar type. This observation is the contrapositive to the benefits of rapid releases we have proposed in this dissertation: the usefulness of these “lessons
learned” is minimized as the section of the codebase relevant to the type of vulnera- bility in question may have already been deprecated by the time the attacker applies this learning. Indeed, this is further supported by the Bug Bounty findings presented by Coates [Coa11], wherein the vast majority of flaws reported fall into a small set
Chapter 3
The Honeymoon Effect
“Vitality shows in not only the ability to persist but the ability to start
over.”
(F. Scott Fitzgerald)3.1
Properties of the Early Vulnerability Life Cycle
Existing approaches to understanding the vulnerability life cycle focus on attempting to measure the lifetime of vulnerabilities in long standing systems. These are systems that are assumed to have ’stood the test of time’ in that their easy to find defects (and the resulting vulnerabilities) have been discovered and patched. [OS06, AFM00, Ran10]
The focus of these studies is on the vulnerability of software relatively late in its life cycle. In this chapter, I examine the characteristics of the first vulnerabilities found in software while it is new, and I present the results of the first study to look at the intervals from genesis to initial vulnerability discovery and from initial vulnerability discovery to second.
To understand the early vulnerability life cycle, I analyzed the vulnerabilities of several versions of the most popular software products, Operating Systems, server
applications and user applications, I measured the time between the official release date of the version and the disclosure dates of the vulnerabilities. Surprisingly I found that, in the majority of cases, the average period between release date of a software
product and its very first vulnerability, (often referred to as a Zero-day or 0-day),
is considerably longer than the mean time between first vulnerability and second or between the second and the third. A similar, although slightly less pronounced effect is present when minor version releases are considered.
I call this unexpected grace period the Honeymoon Effect, alluding to the bliss-
ful state newlyweds experience in the first days of marriage, and believe it to be important, because this new quantitative analysis challenges the expectations and intuition of the software engineering community about the effect of software quality
on security. The results suggest thatearlyin the system life cycle, when new software
is first deployed, factors other than intrinsic quality of the software can dominate the question of how likely a system is to be attacked. For the purpose of this discussion,
I define an Intrinsic Property as any property or characteristic of a software prod-
uct that can directly controlled by the developer, such as, programming language,
addition of features, patch release rate, etc. An Extrinsic Property is defined as
a characteristic of the environment in which the software operates (lives). Extrin- sic properties are properties of components that may be essential to the program’s functionality, such as the operating system needed by the software to function, or ancillary such as other applications on the system, firmware, networking protocols, shared libraries, etc., that are not under the direct control of the software program developer.
Interestingly, I found that on newly deployed systems, that is, those that have not yet had the "easy" bugs fixed and patches made available, often enjoy a longer "honeymoon" period (before the first zero-day attack occurs) than they will enjoy later in their life.
The Honeymoon Effect also illustrates a tension between current software engi- neering practices and security: the effect of code reuse. “Good programmers write code, Great programmers reuse ” is an often quoted aphorism. [Ray99] An implicit assumption made is that reusing code not saves effort, but as the code has been deployed and is in service, it is both more reliable and more secure. While reliability in the absence of an adversary may result from code reuse, the addition of an adver- sary completely changes the observables as I will show in subsequent sections of this chapter of the thesis.