Timing the Application of Security Patches for Optimal Steve Beattie, Seth Arnold, Crispin Cowan, Perry Wagle, and Chris Wright† –WireX Communications, Inc. Adam Shostack –Zero Knowledge Systems, Inc.

ABSTRACT Security vulnerabilities are discovered, become publicly known, get exploited by attackers, and patches come out. When should one apply security patches? too soon, and you may suffer from instability induced by bugs in the patches. Patch too late, and you get hacked by attackers exploiting the vulnerability.Weexplore the factors affecting when it is best to apply security patches, providing both mathematical models of the factors affecting when to patch, and collecting empirical data to give the model practical value. Weconclude with a model that we hope will help provide a formal foundation for when the practitioner should apply security updates.

Introduction of penetration due to attack and of corruption due to a defective patch, with respect to , and then solve ‘‘To patch, or not to patch, – that is the question: – for the intersection of these two functions. Whether ’tis nobler in the mind to suffer The slings and arrows of outrageous script kiddies, These costs are functions of than just time. Or to take up patches against a sea of troubles, We attempt to empirically inform the cost of failure And by opposing, end them?’’ [24] due to defective patches with a survey of security advisories. Informing the cost of security penetration ‘‘ W h e n to patch?’’presents a serious problem to due to failure to patch is considerably more difficult, the security administrator because there are powerful because it depends heavily on many local factors. competing forces that pressure the administrator to While we present a model for penetration costs, it is apply patches as soon as possible and also to delay up to the local administrator to determine this cost. patching the system until there is assurance that the patch is not more likely to cause damage than it pro- Bad Patch Risk poses to prevent. Patch too early,and one might be Penetration Risk applying a broken patch that will actually cripple the Optimal Time to Patch system’sfunctionality.Patch too late, and one is risk from penetration by an attacker exploiting a hole that is publicly known. Balancing these factors is problematic. Risk of The pressure to immediately patch grows with Loss time after the patch is released, as more and more script kiddies acquire scanning and attack scripts to facilitate massive attacks [4]. Conversely,the pressure to be cautious and delay patching decreases with time, as more and more users across the Internet apply the patch, providing either evidence that the patch is Time defective, or (through lack of evidence to the contrary) Figure1:Ahypothetical graph of risks of loss from that the patch is likely okay to apply.Since these penetration and from application of a bad patch. trends go in opposite directions, it should be possible The optimal time to apply a patch is where the to choose a time to patch that is optimal with respect to risk lines cross. the risk of compromising system availability.Figure 1 conceptually illustrates this effect; where the lines cross In particular,many security administrators feel is the optimal time to patch, because it minimizes the that it is imperative to patch vulnerable systems imme- total risk of loss. diately.This is just an end-point in our model, repre- senting those sites that have very high risk of penetra- This paper presents a proposed model for finding tion and have ample resources to do local patch testing the appropriate time to apply security patches. Our in aid of immediate deployment. Our intent in this approach is to model the cost (risk and consequences) study is to provide guidelines to those do not †This work supported by DARPAContract F30602-01-C- have sufficient resources to immediately and patch 0172. everything, and must choose where to allocate scarce

2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA101 Timing the Application of Security Patches for Optimal Uptime Beattie, et al. security resources. Wehave used the empirical data to Most system administrators understand that these arrive at concrete recommendations for when patches risks are present, either from personal experience or should be applied, with respect to the apparent com- from contact with colleagues. However,weknow of no mon cases in our sample data. objective assessment of how serious or prevalent these It should also be noted that we are not considering flaws are. Without such an assessment it is hard to the issue of when to disable a service due to a vulnera- judge when (or even if) to apply a patch. Systems bility.Our model considers only the question of when administrators have thus had a tendency to delay the to patch services that the site must continue to offer.In application of patches because the costs of applying our view,ifone can afford to disable a service when patches are obvious, well known, and have been hard to there is a security update available, then one probably balance against the cost of not applying patches. Other should not be running that service at all, or should be sources of delay in the application of patches can be running it in a context where intrusion is not critical. rigorous testing and roll-out procedures and regulations by organizations such as the US Food and Drug Lastly,wedonot believe that this work is the Administration that require known configurations of final say in the matter,but rather continues to open a systems when certified for certain medical purposes [1]. new area for exploration, following on Browne, et al. [4]. As long as frequent patching consume a signifi- Some organizations have strong processes for cant fraction of security resources, resource allocation triaging, testing, and rolling-out patches. Others have decisions will have to be made concerning how to deal mandatory policies for patching immediately on the with these patches. release of a patch. Those processes are very useful to them, and less obviously,toothers, when they report The rest of this paper is structured as follows. The bugs in patches. The suggestions that we regard- next section presents motivations for the models we use ing delay should not be taken as a recommendation to to describe the factors that make patching urgent and abandon those practices.1 that motivate caution. Then, the next section formally The practical delay is difficult to measure, but its models these factors in mathematical terms and pre- existence can be inferred from the success of worms sents equations that express the optimal time to apply such as Code Red. This is illustrative of the issue cre- patches. The subsequent section presents methods and ated by delayed patching, which is that systems remain issues for acquiring data to model patch failure rates. vulnerable to attack. Systems which remain vulnerable The paper then presents the empirical data we have col- run a substantial risk of attacks against them succeed- lected from the Common Vulnerabilities and Exposures ing. One research project found that systems containing (CVE) database and describes work related to this months-old known vulnerabilities with available but study.The paper ends with discussions the implications unapplied patches exposed to the Internet have a ‘‘life of this study for future work and our conclusions. expectancy’’measured in days [14]. Once a break-in Problem: When ToPatch has occurred, it will need to be cleaned up. The cost of such clean-up can be enormous. The value of applying patches for known secu- Having demonstrated that all costs relating to rity issues is obvious. A security issue that will shortly patch application can be examined in the ‘‘currency’’ be exploited by thousands of script-kiddies requires of system administrator time, we proceed to examine immediate attention, and security experts have long the relationship more precisely. recommended patching all security problems. How- ever,applying patches is not free: it takes time and Solution: Optimize the Time to Patch carries a set of risks. Those risks include that the patch will not have been properly tested, leading to loss of To determine the appropriate time to patch, we stability; that the patch will have unexpected interac- need to develop a mathematical model of the potential tion with local configurations, leading to loss of func- costs involved in patching and not patching at a given tionality; that the patch will not fix the security prob- time. In this section we will develop cost functions lem at hand, wasting the system administrator’s time. that systems administrators can use to help determine Issues of loss of stability and unexpected interaction an appropriate course of action. have a direct and measurable cost in terms of time First, we define some terms that we will need to spent to address them. Todate, those issues have not take into account: been a focus of security research. There is a related • epatch is the expense of fixing the problem issue: finding a list of patches is a slow and labor- (applying the patch), which is either an oppor- intensive process [7]. While this makes timely appli- tunity cost, or the cost of additional staff. cation of patches less likely because of the investment • ep.recover is the expense of recovering from a of time in finding them, it does not directly interact failed patch, including opportunity cost of work with the risk that applying the patch will break things. 1As a perhaps amusing aside, if everyone were to follow However,the ease of finding and applying patches has our suggested delay practice, it would become much less ef- begun to get substantial public attention [20] and is fective. Fortunately,wehave no expectation that everyone not our focus here. will listen to us.

102 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA Beattie, et al. Timing the Application of Security Patches for Optimal Uptime

delayed. Both this and the next cost may administrator will want to patch vulnerable systems at include a cost of lost business. the earliest point in time where epatch(t) ≤ enopatch(t). • ebreach is the expense of recovering from a secu- The cost of patching a system will have two rity breach, including opportunity cost of work terms: the expense of applying the patch, and the delayed and the cost of forensics work. expense of recovering from a failed patch. Applying a • pfail is the likelihood that applying a given patch will likely have a fixed cost that must be paid patch will cause a failure. regardless of the quality of the patch. Recovery cost, • pbreach is the likelihood that not applying a however,will only exist if a given patch is bad, so we given patch will result in a security breach. need to consider the expected risk in a patch. Since a All of these costs and probabilities are parame- systems administrator cannot easily know a priori terized. The costs epatch, ep.recover,and ebreach are all whether a patch is bad or not, we multiply the proba- particular to both the patch in question and the config- bility that the patch induces failure by the expected uration of the machine being patched. However, recovery expense. This gives us the function because the factors affecting these costs are so specific epatch(t)=pfail(t)ep.recover + epatch (1) to an organization, we treat the costs as constants. This It is possible, although not inexpensive, to obtain is constant within an organization, not between organi- much better estimations of the probability of failure zations, which we believe is sensible for a given sys- through the use of various testing mechanisms, such as tems administrator making a decision. having a non-production mirror of the system, patch-

The probabilities pfail and pbreach vary with time. ing it, and running a set of tests to verify functionality. Whether a patch is bad or not is actually a fixed fact at However,such systems are not the focus of our work. the time the patch is issued, but that fact only becomes The cost of not applying a patch we consider to known as the Internet community gains experience be the expense of recovering from a security breach. applying and using the patch. So as a patch ages with- Again, an administrator is not going to know a priori out issues arising, the probability of a patch turning that a breach will occur,soweconsider the cost of out to be bad decreases. recovery in terms of the probability of a security breach occurring. Thus we have: The probability pbreach is a true probability that increases with time in the near term. Browne, et al. [4] enopatch(t)=pbreach(t) ebreach (2) examined exploitation rates of vulnerabilities and Pulling both functions together,asystems determined influencing terms such as the release of a administrator will want to patch vulnerable systems scripted attack tool in rates of breaches. However,the when the following is true: 1 p (t)e e p (t) e (3) rate of breach is not a simple function fail p.recover + patch ≤ breach breach |Internet Hosts| In attempting to apply the functions derived N or even (where N is the number of above, a systems administrator may want to take more |InternetHosts| precise estimates of various terms. hosts or unprotected hosts that a systems administrator On the Cost Functions is responsible for and |InternetHosts|isthe number of hosts on the Internet). Not every host with a vulnera- Expenses for recovering from bad patches and bility will be attacked, although in the wake of real security breaches are obviously site and incident spe- world events such as the spread of Code Red [6] and cific, and we have simplified some of that out to ease its variants, as well as work on Flash [26] and Warhol our initial analysis and aid in its understanding. [28] worms, it seems that it may be fair to make that We could argue with some confidence that the assumption. cost of penetration recovery often approximates the cost of bad patch recovery.Inmany instances, it probably Thus we will consider both probabilities pfail and amounts to ‘‘reinstall.’’This simplifying assumption pbreach as functions of time (t), and them pfail(t) and p (t). may or may not be satisfactory.Recovery from a break- breach in is likely harder than recovery from a bad patch, Next, we want to to develop two cost functions: because recovery from bad patch may simply be a rein- • epatch(t): cost of patching at a given time t. stall, or at least does not involve the cost of dealing • enopatch(t): cost of not patching at a given time t. with malice, while recovery from getting hacked is The probable cost of patching a system drops identifying and saving critical state with tweezers, re- over time as the Internet community grows confidence formatting, re-installation, applying patches, recovering in the patch through experience. Conversely,the prob- state from backup, patching some more, ensuring that able cost of not patching follows a ‘ballistic’ trajec- the recovered state carries no security risk, and per- tory,asthe vulnerability becomes more widely known, forming forensics, a non-trivial expense [10]. However, exploitation tools become available, and then fall out it is possible that recovery from a bad patch could have of fashion [4]; but, for the part of the ballistic curve ahigher cost than penetration recovery – consider a we are concerned with, we can just consider cost of patch that introduces subtle system corruption that not patching to be monotonically rising. Therefore, the is not detected for a year.

2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA103 Timing the Application of Security Patches for Optimal Uptime Beattie, et al.

Furthermore, we note that many vendors are different vendors provide very different levels of working to make the application of security patches as information in their advisories. simple as possible, thereby reducing the expense of We decided instead to work from the Common applying a security patch [22, 25, 29]. As the fixed Vulnerabilities and Exposures (CVE) [16], a MITRE- cost of applying a patch approaches zero, we can sim- hosted project, to provide common naming and con- ply remove it from the equations: cordance among vulnerabilities. Since MITRE is an pfail(t) ep.recover ≤ pbreach(t) ebreach (4) organization independent of vendors, using the CVE Alternately,wecan assume that recovery from database reduces the chance of bias. Starting from being hacked is C times harder than recovery from bad CVE allows us to create generic numbers, which are patch (C may be less than one). While the math is still useful because many vendors do not have a sufficient fairly simple, we are not aware of systemic research history of security fixes. However,there are also many into the cost of recovering from security break-ins. vendors who do have such a history and sufficient pro- However,aprecise formulation of the time is less cess (or claims thereof) that it would be possible to important to this paper than the idea that the time examine their patches, and come up with numbers that absorbed by script kiddies can be evaluated as a func- apply specifically to them. tion of system administrator time. Expenses incurred Data Gathering in recovery are going to be related to installation size Starting from the latest CVE (version 20020625), and number of affected machines, so an argument that we the entries into digestible chunks. Each section there is some relationship between costs can be made. was assigned to a person who examined each of the ref- This allows us to state that: erences. Some of the references were unavailable, in e = Ce (5) breach p.recover which case they were ignored or tracked down using a We can substitute this into equation 4: search engine. They were ignored if the issue was one pfail(t) ep.recover ≤ pbreach(t) Cep.recover (6) with many references (e.g., CVE-2001-0414 has 22 ref- Dividing each side by ep.recover,wearrive at the erences, and the two referring to SCO are not easily decision algorithm: found.) If there was no apparent patch re-issue, we pfail(t) ≤ pbreach(t) C (7) noted that. If there was, we noted how long it was until Recall our assumptions that p (t)rises with the patch was withdrawn and re-released. Some advi- breach sories did not make clear when or if a bad patch was time and pfail(t)drops with time. Therefore, the earliest time t that equation 7 is satisfied is the optimal time to withdrawn, and in that case, we treated it as if it was apply the patch. withdrawn by replacement on the day of re-issuance. When to Start the Clock Methodological Issues While we discuss the value of the equations above ‘‘Thereare morethings in Heaven and Earth, at given times, there are actually numerous points from Horatio, which time can be counted. There is the time from the Then aredream’tofinour Philosophy.’’ [24] discovery of a vulnerability,time from the public Research into vulnerabilities has an unfortunate announcement of that vulnerability,and time since a tendency to confound researchers with a plethora of patch has been released. Browne, et al. [4] work from data gathering issues. These issues will impact the the second, since the first may be unknown, but the assessment of how likely a patch is to fail. It is impor- spread of the vulnerability information may be better tant to choose a method and follow it consistently for modeled from the first, especially if the vulnerability is the results to have any meaning; unfortunately,any discovered by a black hat. A systems administrator may method chosen causes us to encounter issues which only care from the time a patch is available, although are difficult and troubling to resolve. Once we select a some may choose to shut offservices known to be vul- method and follow it, our estimates may be systemati- nerable before that as a last resort, and work has been cally wrong for several reasons. Cardinality issues are done on using tools such as chroot(2), Janus [12], and among the worst offenders: SubDomain [9, 13] to protect services that are under • Vendors rolling several issues into one patch: attack. In this paper,wehave chosen to start counting An example of this is found in one vendor time from when the patch is released. patch [19] which is referenced by seven candi- dates and entries in the CVE (CAN-2001-0349, Methodology CAN-2001-0350, CVE-2001-0345, CVE-2001- The first thing to consider when deciding to 0346, CVE-2001-0348, CVE-2001-0351, and experimentally test the equations derived previously is CVE-2001-0347). asource of data. Weconsidered starting with specific • Vendors rolling one patch into several advi- vendors’ advisories. Starting from vendor data has sories: An example here is CVE-2001-0414 flaws: it is difficult to be sure that a vendor has pro- with a dozen vendors involved. The vulnerabil- duced advisories for all vulnerabilities, the advisories ity is not independent because and BSD may not to other information in useful ways, and vendors commonly share fixes, and so an

104 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA Beattie, et al. Timing the Application of Security Patches for Optimal Uptime

update from multiple vendors may be the same by observing the knees in the curves shown in Figures patch. If this patch is bad, then in producing a 7and 9, and these inferences would be stronger if generic recommendation of when to patch, we there were sufficient data points to be confident that could choose to count it as N bad patches, the knees were not artifacts of our sample data. which would lead to a higher value for pfail,and More data points would be desirable, but obtain- consequently,later patching. If the single patch ing it is problematic. Wefound the CVE repository to is good, then counting it as N good patches be limiting, in that it was difficult to determine could bias the probability of patch failure whether any given security patch was defective. For downward. future research, we recommend using security advi- • Vendors releasing advisories with work- sory information direct from vendors. In addition to arounds, but no patches: An example is providing more detail, such an approach would help CVE-2001-0221, where the FreeBSD team facilitate computing patch failure rate with respect to issued the statement ‘‘[this program] is sched- each vendor. uled for removal from the ports system if it has not been audited and fixed within one month of We donot believe that these issues prevent a discovery.’’Noone fixed it, so no patch was researcher from analyzing the best time to patch, or a released. A related situation occurred when a systems administrator from making intelligent choices third party,unrelated to Oracle, released an about when to patch. However,these methodological advisory relating to Oracle’sproduct along with issues do need to be considered in further studies of aworkaround, and Oracle remained completely security patch quality. silent about the issue (CVE-2001-0326). We Empirical Data recorded these instances but treated them as non-events – our goal is to measure quality of In this section, we examine the data we collected patches; if no patch was released, there is noth- as discussed in the previous section. Weexamined 136 ing to measure. CVE entries, dating from 1999, 2000, and 2001. Of There are several other potential sources of bias. these, 92 patches never were revised leading us to We may not have accurate information on whether a believe they were safe to apply,20patches either were vendor released an updated patch, because the CVE updated or pulled, and 24 CVE entries were non-patch entry points to the original, and the vendor released a events as discussed in ‘Methodological Issues.’ Table subsequent/different advisory.This potentially intro- 2summarizes this data. Of the 20 patches that were duces a bias by reducing our computed probability of determined to be faulty,all but one (CVE-2001-0341) aharmful patch. had an updated patch released. Of these, three were found to be faulty and had a second update released; When patches are not independent, there is bias one subsequently had a third revision released. Table 3 in a different direction; consider if one or more ven- summarizes the data for the revised patches. dors released a revised update while others did not (for example, CVE-2001-0318). Weconsidered each CVE Total CVE entries examined 136 entry as one patch, even if it involved multiple ven- Good patches 92 dors. Wechose to record the data for the vendor who issued the latest advisory revision (e.g., Debian over Revised or pulled patches 20 Mandrake and Conectiva in CVE-2001-0318). This Non-patch entries 24 potentially introduces a bias towards patches being Table 2:Quality of initial patches. less reliable than they actually are. Systems adminis- trators tracking the advisories of one specific vendor would not have this potential source of bias. Revised or pulled patches 20 Good revised patches 16 It may be difficult to decide if a patch is bad or not. For example, the Microsoft patch for Re-revised patches 3 CVE-2001-0016 was updated six months after its Pulled and never re-released patches 1 release. There was a conflict between this patch and Table 3:Quality of revised patches. Service Pack 2 for Windows 2000. Installing the patch would disable many of the updates in Service Pack 2. Table 4 analyzes the properties of the patch revi- Note that SP2 was issued four months after the patch, sions. The middle column shows the number of days so there was four months where the patch was harm- from the initial patch release until an announcement of less, and two months where the patch and Service some kind appeared indicating that the patch was bad, Pack 2 conflicted. Wetreated it as if was bad for the for the 20 patches that were revised. The right column entire six months. shows the number of days from the revised patch There is a potential for concern with the number release until notification that the revised patch was of CVE entries we have examined. In the next section, faulty,for the three issues that had subsequent revi- we attempt to infer appropriate times to apply patches sions. Three data points is insufficient to draw

2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA105 Timing the Application of Security Patches for Optimal Uptime Beattie, et al.

14 13 12 11 10 9 8 faulty 7 patches 6 5 4 3 2 1 0 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 days from initial patch release Figure5:Ahistogram of the number of faulty initial patches.

0.18 pfail(t) 0.16 0.14 0.12 probability 0.1 0.08 0.06 0.04 0.02 0 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 days from initial patch release

Figure6:The probability pfail(t)that an initial patch has been incorrectly identified as safe to apply.

115

110

105 patches resolved 100

95

90 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 days from initial patch release Figure7:Acumulative graph showing the time to resolve all issues.

106 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA Beattie, et al. Timing the Application of Security Patches for Optimal Uptime meaningful conclusions, so we will disregard doubly older,unpatched Red Hat Linux system containing or more revised patches from here on. Wefound one months-old known vulnerabilities could be as short as triply revised patch, occurring seven days after the asmall number of days, as attacker vulnerability scan- release of the second revision. ning tools quickly located and exploited the vulnerable machine. However we note that this probability may Subsequent not correlate to the system administrator’s site. Site Notification Initial revision revision specific factors – site popularity,attention to security time in days (20 data points) updates, vulnerability,etc. – affect the local p (t), (3 data points) breach and as such it must be measured locally. Maximum 500 62 Minimum 1 1 7 Average 64.2 22.7 6 Median 17.5 5 Std deviation 117.0 34.1 5 Table 4:Analysis of revision data. 4 faulty Figure 5 presents a histogram over the 20 revised patches 3 patches of the time from the initial patch release to the 2 time of the announcement of a problem with the patch, while Figure 8 examines the first 30-day period in 1 detail. Figure 6 presents the same data set as a proba- bility at a given time since initial patch release that a 0 patch will be found to be bad, i.e., an empirical plot of 0 3 6 9 12 15 18 21 24 27 30 days from initial patch release pfail(t)from equation 7. Figure 7 plots the days to resolve an accumulated Figure8:Aclose-up histogram of the first class inter- number of security issues, while Figure 9 examines val in Figure 5. It shows the number of faulty ini- tial patch notifications occurring within 30 days the first 30-day period more closely.These plots are of initial patch release. subtly different from the previous data sets in two ways: 106 • Time to resolution: In the previous graphs, we counted time from when the security patch was 104 announced to the time the patch was announced 102 to be defective. Here, we are measuring to the time the defective patch is resolved. Of the 20 100 revised patches, 16 provided a revised patch patches 98 concomitant with the announcement of the resolved patch problem, two had a one-day delay to the 96 release of a revised patch, one had a 97 day 94 delay to the release of a revised patch, and one defective patch was never resolved. 92 • No patch ever released: Of the 136 CVE 90 entries that we surveyed, 24 never had any 0 3 6 9 12 15 18 21 24 27 30 patch associated with them, and so for these days from initial patch release plots, will never be resolved. Figure9:Aclose-up cumulative graph of the first 30 Ideally,wewould like to be able to overlay Fig- days in Figure 7. It shows the issue resolution ure 6 with a similar probability plot for ‘‘probability of time for those occurring within 30 days of initial getting hacked at time t past initial disclosure,’’or patch release. pbreach(t). Unfortunately,itisproblematic to extract such a probability from Browne, et al.’sdata [4] After determining local probability of a breach because the numerator (attack incidents) is missing (i.e., pbreach(t)), the administrator should apply Figure 6toequation 7 to determine the first time t where many data points (people who did not bother to report equation 7 is satisfied. However,since pbreach(t)isdif- an incident to CERT), and the denominator is huge ficult to compute, the pragmatist may want to observe (the set of all vulnerable nodes on the Internet). the knees in the curve depicted in Figures 7 and 9 and From Honeynet [14] one may extract a pbreach(t). apply patches at either ten or thirty days. Honeynet sought to investigate attacker behavior by placing ‘‘honeypot’’(deliberately vulnerable) systems Related Work on the Internet, and observing the subsequent results. This paper was inspired by the ‘‘Code Red’’and In particular,Honeynet noted that the lifespan of an ‘‘ N i m d a ’’ worms, which were so virulent that some

2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA107 Ti m i n g the Application of Security Patches for Optimal Uptime Beattie, et al. analysts conjectured that the security administrators of told that 90% of patients survive. It is possible that the Internet could not patch systems fast enough to stop similar framing issues may influence administrators them [20]. Even more virulent worm systems have been behavior with respect to security patches. devised [28, 26] so the problems of ‘‘when to patch?’’ and ‘‘can we patch fast enough?’’are very real. Discussion The recent survey of rates of exploitation [4] was As we performed this study,weencountered sev- critical to our work. In seeking to optimize the trade- eral practical issues. Some were practical impediments offbetween urgent and cautious patching, it is impor- to the execution of the study,while others were of tant to understand both forms of pressure, and larger concern to the community of vendors and users. Browne, et al. provided the critical baseline of the Addressing these issues will both make future research time-sensitive need to patch. in this area more consistent and valid, and also may Schneier [23] also studied rates of exploitation improve the situation of the security practitioner. versus time of disclosure of security vulnerabilities. The first issue is that of setting the values for the However,Schneier conjectured that the release of a constants in our equations, e.g., the cost of breach vendor patch would peak the rate of exploitation. The recovery versus the cost of bad patch recovery,and the subsequent study by Browne, et al. of CERTincident probability of a breach for a given site. These values data above belied this conjecture, showing that are site-specific, so we cannot ascertain them with any exploitation peaks long after the update is released, validity: demonstrating that most site administrators do not • Aweb server that is just a juke box farm of apply patches quickly. -ROMs is not as susceptible to data corrup- tion as an on-line gambling house or a credit Reavis [21] studied the timeliness of vendor-sup- bureau, affecting the relative costs of recovery. plied patches. Reavis computed the average ‘‘days of Aprivate corporate server behind a firewall is recess’’(days when a vulnerability is known, but no • less likely to be attacked than a public web server patch is available) for each of Microsoft, Red Hat hosting a controversial political advocacy page. Linux, and Solaris. Our clock of ‘‘when to patch?’’ starts when Reavis’ clock of ‘‘patch available’’stops. We wish to comment that the administrator’s quandary is made worse by vendors who do a poor job Howard [15] studied Internet security incident of quality assurance on their patches, validating the rates from 1989 to 1995. He found that, with respect systems administrator’s decision to not patch. Our to the size of the Internet, denial-of-service attacks ideas can be easily taken by a vendor as advice as to were increasing, while other attacks were decreasing. how to improve their patch production process and The cause of these trends is difficult to establish with- improve their customer’s security.Ifthe standard devi- out speculation, but it seems plausible that the expo- ation of patch failure times is high, then administrators nential growth rate of the Internet exceeded the will rationally to patch, leaving themselves inse- growth rate of attackers knowledgeable enough to per- cure. Extra work in assurance may pay great divi- petrate all but the easiest (DoS) attacks. dends. In future work, it would be interesting to exam- In 1996, Farmer [11] surveyed prominent web ine vendor advance notice (where vendors are notified hosting sites and found that nearly two-thirds of such of security issues ahead of the public) and observe sites had significant vulnerabilities, well above the one- whether the reliability of subsequent patches are more third average of randomly selected sites. Again, root reliable, i.e., do vendors make good use of the addi- causes involve speculation, but it is likely that this tional time. resulted from the complex active content that prominent In collecting data, we noticed but have not yet web sites employ versus randomly selected sites. It is analyzed a number of trends: Cisco patches failed also likely that this trend has changed, as e-commerce rarely,while other vendors often cryptically updated sites experienced the pressures of security attacks. their advisories months after issue. The quality of In recent work, Anderson [2] presents the view- advisories varies widely.Wefeel it is worth giving point that many security problems become simpler kudos to Caldera for the ease with which one can when viewed through an economic lens. In this paper, determine that they have issued a new patch [5]. How- we suggest that the system administrator’s failure to ever,they could learn a great deal from some Cisco patch promptly is actually not a failure, but a rational advisories [8] in keeping detailed advisory revision choice. By analyzing that choice, we are able to sug- histories. Red Hat’sadvisories included an ‘‘issue gest a modification to that behavior which addresses date,’’which we later discovered is actually the first the concerns of the party,rather than simply exhorting date that they were notified of the issue, not the date administrators to patch. they issued the advisory.There has not, to our knowl- Also worth mentioning is the ongoing study of edge, been a paper on ‘‘how to write an advisory,’’or perception of risk. In McNeil, et al. [17], the authors on the various ways advisories are used. point out that people told that a medical treatment has If one assumes that all problems addressed in a10% risk of death react quite differently than people this paper relating to buggy patches have been solved,

108 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA Beattie, et al. Timing the Application of Security Patches for Optimal Uptime the administrator must still reliably ascertain the valid- without breaking compatibility or compromising per- ity of an alleged patch. Various forms of cryptographic formance. Dr.Cowan has co-authored 34 refereed pub- authentication, such as PGP signatures on Linux RPM lications, including those describing the StackGuard packages [3] and digital signatures directly on binary compiler for defending against buffer overflow attacks. executables [27] can be used. Such methods become He can be reached via email at [email protected] . essential if one employs automatic patching mecha- Adam Shostack is currently on sabbatical from nisms, as proposed by Browne, et al. [4] and provided his role as Most Evil Genius for Zero-Knowledge sys- by services such as Debian apt-get [25], Ximian Red tems. Prior to that, he was director of technology for Carpet [29], the Red Hat Network [22], and the auto- Netect, Inc, where he built vulnerability scanners. He 2 matic update feature in Microsoft Windows XP [18]. has published on topics including cryptography,pri- Conclusions vacy,and the economics of security and privacy.He can be reached via email at [email protected]. ‘‘Never do today what you can put off till tomor- Perry Wagle received his M.Sc. in Computer Sci- rowiftomorrow might improve the odds.’’ ence at Indiana University in 1995, then dabbled in –Robert Heinlein evolutionary biology until 1997, when he headed to The diligent systems administrator faces a the Oregon Graduate Institute to the Immunix quandary: to rush to apply patches of unknown quality project’ssurvivability research. For Immunix, he was, to critical systems, and risk resulting failure due to among a number of things, the primary programmer of defects in the patch? Or to delay applying the patch, the first released version of the StackGuard enhance- and risk compromise due to attack of a now well- ment to GCC. When Immunix spun offinto the WireX known vulnerability? We have presented models for startup in 1999, he generated a second version of the pressures to patch early and to patch later,formally StackGuard, but stayed at OGI to work on the Infos- modeled these pressures mathematically,and popu- phere project and is still participating in the Timber lated the model with empirical data of failures in secu- project there. He recently joined WireX to research rity patches and rates of exploitation of known flaws. various compiler enhancements to building secure Using these models and data, we have presented a Linux distributions, including a third and never-again notion of an optimal time to apply security updates. version of StackGuard. He can be reached via email at We observe that the risk of patches being defective [email protected] . with respect to time has two knees in the curve at 10 Chris Wright is one of the maintainers of the days and 30 days after the patch’srelease, making 10 Linux Security Module project. He has been with the days and 30 days ideal times to apply patches. It is our project since its inception and is helping guide LSM hope that this model and data will both help to inspire into the mainstream Linux kernel. He is employed by follow-on work and to form a best-practice for diligent WireX where he gets to do security research and administrators to follow. Linux kernel hacking. He can be reached via email at [email protected] . Author Information Seth Arnold graduated from Willamette Univer- References sity in 2001 with a B.Sc. in Computer Science, Mathe- [1] Ross Anderson, Security Engineering: A Guide matics, and Religious Studies. He has been a system to Building Dependable Distributed Systems, administrator,has played cryptographer,and is cur- John Wiley & Sons, Inc., p. 372, New York, rently employed at WireX Communications in the 2001. research group. He can be reached via email at [2] Anderson, Ross, Why Information Security is [email protected] . Hard – An Economic Perspective, 17th Annual Steve Beattie is employed in the Research Group Computer Security Applications Conference at WireX Communications and was involved in the (ACSAC),New Orleans, LA, December 2001. development of the StackGuard, SubDomain, Race- [3] Bailey,, Maximum RPM,Red Hat Press, Guard and FormatGuard security tools. He received a 1997. Masters Degree in Computer Science from the Oregon [4] Browne, Hilary K., William A. Arbaugh, John Graduate Institute, and was previously employed as a McHugh, and William L. Fithen, ‘‘A Trend Systems Administrator for a Knight-Ridder newspa- Analysis of Exploitations,’’InProceedings of the per.Hecan be reached via email at [email protected] . 2001 IEEE Security and Privacy Conference, Dr.Crispin Cowan is co-founder and Chief Scien- pages 214-229, Oakland, CA, http://www.cs. tist of WireX, and previously was a Research Assistant umd.edu/˜waa/pubs/CS-TR-4200.pdf, May 2001. Professor at the Oregon Graduate Institute. His research [5] Caldera, Inc., Caldera Security Advisories, http:// focuses on making existing systems more secure www.caldera.com/support/security/, 2001. 2We have not verified the cryptographic integrity of any of [6] CERTCoordination Center,CERTAdvisory these automatic update mechanisms. CA-2001-19 ‘‘Code Red’’Worm Exploiting

2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA109 Timing the Application of Security Patches for Optimal Uptime Beattie, et al.

Buffer Overflow In IIS Indexing Service DLL, com/DisplayDocument?id=340962, September http://www.cert.org/advisories/CA-2001-19.html, 2001. August 2001. [21] Reavis, Jim, Linux vs. Microsoft: Who Solves [7] Christey,Steven M., An Informal Analysis of Security Problems Faster?,[no longer available Vendor Acknowledgement of Vulnerabilities, on the web], January 2000. Bugtraq Mailing List, http://www.securityfocus. [22] Red Hat, Inc., Red Hat Update Agent,https://rhn. com/cgi-bin/archive.pl?id=1&mid=168287, March redhat.com/help/sm/up2date.html, 2001. 2001. [23] Schneier,Bruce, Full Disclosureand the Window [8] Cisco Systems, Inc., Security Advisory: Cisco of Exposure, http://www.counterpane.com/crypto- Content Services Switch Vulnerability,http:// gram-0009.html#1, September 2000. www.cisco.com/warp/public/707/arrowpoint-cli- [24] Shakespeare, William, Hamlet,Act I, Scenes 3 filesystem-pub.shtml, April 2001. and 4, F.S.Crofts & Co., New York, 1946. [9] Cowan, Crispin, Steve Beattie, Calton Pu, Perry [25] Silva, Gustavo Noronha, Debian APT Howto, Wagle, and Virgil Gligor,SubDomain: Parsimo- http://www.debian.org/doc/manuals/apt-howto/ nious Server Security, USENIX 14th Systems index.en.html, September 2001. Administration Conference (LISA),New Orleans, [26] Staniford, Stuart, Gary Grim, and Roelof LA, December 2000. Jonkman, Flash Worms: Thirty Seconds to Infect [10] Dittrich, Dave, The Forensic Challenge,http:// the Internet,http://www.silicondefense.com/flash/, project.honeynet.org/challenge/, January 2001. August 2001. [11] Farmer,Dan, Shall WeDust Moscow? Security [27] van Doorn, Leendert, Gerco Ballintijn, and Survey of Key Internet Hosts & Various Semi- William A. Arbaugh, Signed Executables for Relevant Reflections,http://www.fish.com/survey/, Linux,Technical Report UMD CS--4259, December 1996. University of Maryland, 2001. [12] Goldberg, Ian, David Wagner,Randi Thomas, [28] Weaver,Nicholas C., Warhol Worms: The Poten- and Eric Brewer,‘‘A Secure Environment for tial for Very Fast Internet Plagues,http://www. Untrusted Helper Applications,’’ 6th USENIX cs.berkeley.edu/˜nweaver/warhol.html, August Security Conference,San Jose, CA, July 1996. 2001. [13] Hinton, Heather M., Crispin Cowan, Lois Del- [29] Ximian Inc., Ximian Red Carpet Automated Soft- cambre, and Shawn Bowers, ‘‘SAM: Security wareMaintenance and Version Management, Adaptation Manager,’’ Annual Computer Secu- 2001. rity Applications Conference (ACSAC),Phoenix, AZ, December 1999. [14] The Honeynet Project, Know Your Enemy: Revealing the Security Tools, Tactics and Motives of the BlackHat Community,Addison Wesley,Boston, 2002. [15] Howard, John D., An Analysis of Security Inci- dents on the Internet 1989 – 1995,Ph.D. thesis, Carnegie Mellon University,http://www.cert. org/research/JHThesis/Start.html, October 1997. [16] Martin, Robert A., ‘‘Managing Vulnerabilities in Networked Systems,’’ IEEE Computer Society COMPUTER Magazine,pp. 32-38, http://cve. mitre.org/, November 2001. [17] McNeil, B. J., S. G. Pauker,H.C.Sox, and A. Tversky,‘‘On the Elicitation of Preferences for Alternative Therapies,’’ New England Journal of Medicine,No. 306, pp. 1259-1262, 1982. [18] Microsoft, Automatic Update FeatureinWindows XP,http://support.microsoft.com/directory/article, asp?ID=KB;EN-US;Q294871, October 2001. [19] Microsoft Corporation, Microsoft Security Bul- letin MS01-031 Predictable Name Pipes Could Enable Privilege Elevation via Telnet,http://www. microsoft.com/technet/security/bulletin/MS01-031. asp?frame=true, June 2001. [20] Pescatore, John, Nimda Worm Shows You Can’t Always Patch Fast Enough,http://www.gartner.

1102002 LISA XVI – November 3-8, 2002 – Philadelphia, PA