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.

100 pages, 31 326 words without appendices or diagrams. Yes.

12 days until thesis is due in on Friday the 13th! Arrgh.

To be honest I have never struggled so hard to write something. I can write a fairly decent quality ten page conference paper (having done the research) in two to three days. Writing this seems to be far slower. I keep finding other projects to which I can meaningfully contribute to make myself feel competent. We affectionately call this WABing for Work Avoidance Behavior. I will get around to blogging some of the great, completely non-thesis related ideas I have implemented. In the past I have pushed myself to the point of requiring medical intervention, most notably while on the SRC last year. At the moment however, I struggle writing for more than a couple of hours and end up feeling absolutely awful about myself. I find with a confusing mix of inadequacy, a need for perfection and feelings that the task is too big. Worse still, I am stuck in our quiet university town with nobody here and will be missing out on new year celebrations.

Luckily I have some great friends, a wonderful girlfriend and a supportive family.

I found a kindred spirit in the thesis writing blog and some great advice in Stop Procrastinating and Complete your Dissertation (also see Procrastination & Time Management). Then there is always the great PhD (Piled High and Deeper) comics. However, the best advice by far is in Dr. Tucker-Ladd's chapter on Procrastination, it spoke to me.

As an aside, congratulations to Yusuf who has handed in his completed thesis already.

Aaw, I'm just whining, some people have real problems.

UPDATE: Serendipity went mad on the HTML for this one, it managed to break my atom feed. All fixed.

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.

I just pointed this out in my last entry, but I felt it deserved its own entry. I once discussed the trade-off inherent in introducing a patch schedule, and I have said it before (one, two, three). The latest patches from Microsoft fix some vulnerabilities that have been actively exploited for the last month.

While a monthly patch schedule helps overworked administrators in general. An on the ball administrator has to rely on additional defenses to prevent exploitation from skilled attackers. Given the general increase in net security and additional testing Microsoft gets to put in to ensure a quality patch. Is network security monitoring the future?

Well then, Bleeding snort has the latest signatures.

While doing some research on threats and attackers for my MSc I found some interesting papers. It seems we are lacking in an understanding of 'the underground.'

• The New Hackers on the Block
• Computer crime - an historical survey
• FBI/CSI Computer Crime Survey 2005
• Laws of Vulnerabilities 2005 update
• Cyber Crime Sentencing - the effectiveness of Criminal Justice Responses

As Microsoft starts to get patching right, Oracle starts screwing it up, badly. OSVDB has a nice post on David Litchfield's (OWN - Oracle's Worst Nightmare) latest findings on Oracle patching following his open letter earlier in the year. Four year old vulnerabilities aren't good, what's worse is that this isn't a once off, it is part of a series of screw-ups that have been exposed at Oracle. On the up-side they make for a great example in my thesis.

What could you have done beforehand to protect yourself against Zotob and its kin? “Install the patch” is the obvious answer, but it’s not really a satisfactory one. There are simply too many patches. Although a single computer user can easily set up patches to automatically download and install -- at least Microsoft Windows system patches -- large corporate networks can’t. Far too often, patches cause other things to break.

It would be great to know which patches are actually important and which ones just sound important. Before that weekend in August, the patch that would have protected against Zotob was just another patch; by Monday morning, it was the most important thing a sysadmin could do to secure the network.

Given that it’s impossible to know what’s coming beforehand, how you respond to an actual worm largely determines your defense’s effectiveness. You might need to respond quickly, and you most certainly need to respond accurately. Because it’s impossible to know beforehand what the necessary response should be, you need a process for that response. Employees come and go, so the only thing that ensures a continuity of effective security is a process. You need accurate and timely information to fuel this process. And finally, you need experts to decipher the information, determine what to do, and implement a solution.

source (here)

Which is exactly what my final thesis contains. A process for handling and responding to vulnerabilities and patches, a model of how much of this process can be automated and expert information to help train up experts.

The SANS ISC Poll for this week is asking how long you take to deploy your patches. The majority of people seem to do it in a week, followed by the next highest group who do it in a day. The witty worm has been the fastest vulnerability to worm turnaround yet at just 36 hours, so I can understand people wanting to deploy in a day, but how the hell do they test the patches in that time?