At the Information Security South Africa conference 2006 I published a paper arguing that our current understanding of the risks associated with monthly patch release cycles is pretty poor. This discussion is pretty important given that entities such as Gartner recon monthly release will be the new industry standard.

I basically argue that in the case of delayed (responsible) disclosure patch schedules work well, but in the case of instantaneous (0day) disclosure none of the purported benefits, namely better quality patches and better deployment scheduling are accrued. I then move onto some solutions.

I think this is a really important paper and a really important discussion. Of course, I am the author so I would think that. The paper is available at:

/masters/files/issa2006/issa-2006-patch_schedule.pdf

My Masters thesis on Patch Management entitled "Limiting Vulnerability Exposure through effective Patch Management: threat mitigation through vulnerability remediation" is now available. Given some bandwidth problems please rather download a compressed version (zip, gzip, bzip2).

Here's the abstract:

This document aims to provide a complete discussion on vulnerability and patch management. The first chapters look at the trends relating to vulnerabilities, exploits, attacks and patches. These trends describe the drivers of patch and vulnerability management and situate the discussion in the current security climate. The following chapters then aim to present both policy and technical solutions to the problem. The policies described lay out a comprehensive set of steps that can be followed by any organisation to implement their own patch management policy, including practical advice on integration with other policies, managing risk, identifying vulnerability, strategies for reducing downtime and generating metrics to measure progress. Having covered the steps that can be taken by users, a strategy describing how best a vendor should implement a related patch release policy is provided. An argument is made that current monthly patch release schedules are inadequate to allow users to most effectively and timeously mitigate vulnerabilities. The final chapters discuss the technical aspect of automating parts of the policies described. In particular the concept of 'defense in depth' is used to discuss additional strategies for 'buying time' during the patch process. The document then goes on to conclude that in the face of increasing malicious activity and more complex patching, solid frameworks such as those provided in this document are required to ensure an organisation can fully manage the patching process. However, more research is required to fully understand vulnerabilities and exploits. In particular more attention must be paid to threats, as little work as been done to fully understand threat-agent capabilities and activities from a day to day basis.

Here is a brief chapter breakdown:

1. Introduction
2. Vulnerability and Patch Management - an analysis of vulnerability, malware and threat trends followed up by an analysis of problems with patches.
3. Policy Solutions - an in-depth patch management framework for creating an organisational patch management policy.
4. Vendor Release Patch Policy - an analysis of how vendors can best manage the risks associated with releasing patches.
5. Practical Solutions - an analysis of where technology is needed in patch management and what is currently available.
6. Conclusion

The thesis is still being examined after which I will submit the final version with corrections. What this means is that if you have any corrections, please send them to me.
The thesis was examined and passed. Irritatingly, one examiner strongly recommended a distinction while the other strongly argued against one (on the basis that the thesis was not scientific enough, but highly practical). At least there was no ambivalence.

UPDATE: added compressed versions.

UPDATE II: added new version with over 32K worth of corrections.

UPDATE III: Updated examination status to passed.

In my soon-to-be-published paper, I make a point that it is a good idea for vendors to make friends with security researchers in an effort to encourage delayed disclosure (some people call it 'responsible' disclosure).

It is interesting then to see that Microsoft will be throwing a party for security researchers at BlackHat. This, along with their BlueHat efforts is a very good idea. I look forward to seeing if it pays off given the past (and somewhat current) negative opinion of some security practitioners towards Microsoft. Or, more simply, will it have a material effect on the number of Microsoft 0days?

My ISSA paper was just accepted as a full research paper. The comments were pretty good too, of course I am only quoting the good bits, but:

Reviewer One:

Excellent insight shown, well researched, very relevant topic.

Reviewer Two:

The paper presents an interesting and well-written discussion, which is extensively supported by references to existing literature.

Reviewer one had mostly grammatical corrections, but reviewer two built some positive arguments against some of my points, which is always a good sign of a thoughtful reviewer and meaty arguments. I think I can rebut them pretty easily and will add them to the paper.

Rhodes is sending down a well sized phalanx of presenters, and I will be proudly representing my company. I can't wait. I just hope those lazy Sensepost bums contribute something this year, instead of recruiting ;)

Wow, it seems Microsoft managed to get their MS06-015 cumulative IE patch rolled out with only a few compatibility problems with older HP, NVIDIA, Siebel and Kerio Firewall products. Pretty good given the non-security ActiveX change they bundled in there.

Oh, they also fixed that security vulnerability that was activley exploited in the wild since March 23rd. Now given the lag time in patch deployment (current research suggests 19 days for internal machines), it should just be just over a month that attackers have been able to wade through the average windows box.

Can someone tell me why Microsoft decided that the best way to get a patch out as quickly as possible was to bundle a huge, non-security modificcation into it?

I would like to nominate Mary Landesman and Shavlik for the "Quality FUD" award, for their paper entitled Security Patch Management: Breaking New Ground. The subtitle is "A discussion of agent and agentless technology", although how this relates to the title is beyond me.

In this eight page paper with precisely five references (of which one, while using the word 'agent' is clearly referring to autonomous semantic-web based agents and not client/server architecture agents) she manages to make a plethora of unsubstantiated claims plainly meant to sell Shavlik's agentless technology. Her main ploy is to make it sound like installing agents to every machine is hard work, and so having to do that every time there is a patch emergency would be bad. Of course you only need to install them once, but lets not confuse 'facts' with the truth. She doesn't seem to realise that if her Shavlik software can deploy executable patch content it could probably deploy agents too, *sssh* don't tell.

This isn't a bash at Shavlik software or an endorsement of agent based solutions. She even quotes her CEO as saying he thinks the whole debate is a "red herring", I prefer the term "a load of crap". If you are logging into a box remotely with administrator rights, then you aren't doing much different from an agent, the code just happens to be transmitted every time instead of stored locally.

I wonder how many morons they fool with this faux-academic ninja-marketing technique?

Blue Lane seems to be getting more attention. I found this post through SA's own Dimension Data's blog. I once wrote about Patch Point when a reader asked for my opinion on it. At the time their site had very little information and I suspected that the product was snake oil. Since then more information has been added, and the post at Rational Security cleared up my understanding.

I am now prepared to roll back my claim that it is snake oil, but it still looks like a stupid idea. The basic idea is that the 'virtual patch' will modify network traffic in the same was that the vendor's patch will. Thus if the vulnerability involves sending over large UDP packets, the inline patch will truncate them, or if it involves a SQL injection, the inline patch will strip the offending SQL.

This bring me to several point, which I will summarise:

• Why is stripping a malicious request better than blocking it?
• How is this different from an IPS?

After fiddling with Brian Kreb's work yesterday, (available at SecurityFix) I decided to take it a step further and draw some pretty graphs. Here the patches were sorted into chronological order based on the date of the original report. It is interesting to note that Microsoft patches vulnerabilities reported at the end of the year faster than they do those reported at the beginning. In the graphs, blue lines are full disclosure vulnerabilities and the orange are responsible disclosure vulnerabilities. The full disclosure graph also shows the large improvement in patch times in those cases. I used a 5-point rolling average for the trend curves. It is interesting to note the cyclical nature of the Patch Times on the summary graph. There aren't just random spikes and troughs there are usually other highs and lows building up to them. It would be nice to know what projects were on at Microsoft that may lead to the general increase in patch times over that period, alternatively it could be the nature of the vulnerabilities. Any ideas?

Also in the last three years, Microsoft has:

• Released 99 critical patches
• Taken an average of 120 days to release a patch
• Taken an average of 62 days to release patches for full disclosure vulnerabilities

The original spreadsheet is available in:

• Open Office
• Excel
• HTML

I changed the day calculations so that they will work in Excel, however Excel is unable to display the graphs correctly and just shows two sets of bars instead of bars and a trend line, so I recommend either the OpenOffice version or the HTML.

As an aside, what are the correct terms for the two types of disclosure. Responsible disclosure is a rather morally laden term, and calling the alternative irresponsible or non-responsible seems silly. I am using 'full disclosure' in this entry, but it seems wrong.

While going over the research on Microsoft's time to patch produced by Brian Krebs at SecurityFix, I noticed a few things which didn't add up. His calculations for the number of days from internal or full disclosure until patch release appeared wrong. On double checking it seems they were. The calculations for 2005 were particularly bad with a total of 118 days going missing or being added. There are many off by one errors and in one case the disclosure date was listed after the patch release date, once the year was changed from 2003 to 2002 it made sense. For both 2003 and 2004 the number of patches were counted incorrectly! Given that the information was vetted by Stephen Toulouse of Microsoft, it is strange they they both missed this. The other possibility is that I have missed something, anyone care to double check my calculations? Brian has since seen this post and linked to it.

A spreadsheet is available with my calculations next to Krebs. In my corrected days column I have italicized and centered the days where my results and his disagree. I used Open Office's DAYS() function I just do a normal subtraction to calculate the difference in the days.

• Open Office Version
• Excel Version
• HTML Version

While the errors were sometimes quite large, the average calculations are not badly affected as the days were sometimes higher, and othertimes lower than they should be. The dates are still hugely useful, and all sorts of interesting information can be derived from them (eg1, eg2), it would be nice to have the same info for other vendors. Thus, the new summary is:

	2003	2004	2005
Number of Critical Patches	34	28	37
Ave. Days from Report to Patch	90.7	136	134
Ave. Days from Disclosure to Patch	73.6	55	46

UPDATE: added link to SecurityFix's follow-up post and Dan Geer's work

Brian Krebs at SecurityFix has done some nice research into the turnaround from Disclosure to Patch of all critical Microsoft Patches for the last three years (2003-2005). The summaries can he found at: 2003, 2004, 2005.

He contacted the original researchers and Microsoft to verify the dates and times, and Steven Toulous of the MSSRC vetted his results. The summary is:

	2003	2004	2005
Number of Critical Patches	33	29	37
Ave. Days from Report to Patch	90.7	134.5	133.5
Ave. Days from Disclosure to Patch	71.1	55	46

This shows that Microsoft has been taking longer to fix 'responsibly' disclosed vulnerabilities, most likely due to their increased testing regime, and fixing publicly disclosed vulnerabilities which they were not previously notified of faster. The increase is understandable and the marginal increase in risk is justified if the risk from faulty patches is greatly decreased. The decrease is a good sign, but 46 days is still way too long, a skilled attacker doesn't need underground sploits if they have that long.

I have been writing my thesis and am trying to come up with some a priori reasons as to why vendors releasing patches in certain ways will have certain effects.

The bit of research I have just cooked up seems to indicate that for software which has a large community of users likely to get involved in the testing of patches, it makes more sense to release a detailed advisory and patch as soon as possible, instead of keeping it to yourself and releasing a patch when it is ready. This is still a very early version and is changing rapidly, please treat it as such.

I don't want to flood things with large images, so click on the graphs for a larger version.