Patch Tuesday: a look behind the scenes

On the second Tuesday of every month, Microsoft releases security updates for its products. This has become known as “patch Tuesday”.

In April this year the software giant released its largest ever update, patching 64 software vulnerabilities - affecting Windows and Office, among other products - nine of which it rated as critical.

So what processes lie behind this patching ritual?

All Microsoft’s fixes are the responsibility of Trustworthy Computing, a body created by the firm in 2002 to “deliver a more secure, private and reliable computing experience”.

Trustworthy Computing employs a collaborative approach, so that while its staff continually search for threats and vulnerabilities, it also receives information from external parties.

“Disclosures come from different sources, including security software vendors and independent security researchers,” explains Jerry Bryant, group manager, response communications at Trustworthy Computing.

Potential vulnerabilities are analysed and then fixes are developed and tested.

Updates are prioritised according to the severity of the flaw and whether the vulnerability is a known public issue or was privately reported.

Microsoft prefers vulnerabilities to be reported privately, but does this deprive enterprises of information that might be critical to their security? After all, it could be months before Trustworthy Computing finds space in its schedule for any particular fix.

Bryant argues that by sharing its vulnerability information with the security industry, Trustworthy Computing ensures that the right people get the disclosures at the right time.

“The Microsoft Active Protections Program (MAPP) involves 80 or so vendors worldwide. That includes Symantec, Trend, McAfee, Cisco - basically any vendors that have some form of protection product.

And Andy Kellett, senior analyst at Ovum, concurs that disclosures should go to Microsoft in the first instance, as it is the most trusted source for fixes.

“There have been times when people have developed fixes before Microsoft, but there have also been malicious ‘fixes’ released. I would rather rely on the official source.”

Once vulnerabilities have been identified and prioritised and fixes developed, the updates need to be tested. If Microsoft released patches that either didn’t work at all, or didn’t work on some systems, or in conjunction with some applications, customers would quickly lose faith in it.

“The test process is pretty significant, and usually takes about two months per fix,” says Bryant. “There are lots of versions of the platforms we have to test against, and we do extensive application compatibility testing.”

Once the testing is complete and the patches are released, it’s up to the users to download and install them. But there can be issues here too, meaning some organisations need to do their own testing.

This will be dependent on the software environment in the enterprise.

Bryant says: “Those enterprise customers that have quite a few custom applications would need to do more internal testing before they deploy a patch, but this is probably less important for those running more standard platforms and business applications.”

However, if the software was properly coded in the first place, would it be necessary to embark on an endless process of fixes? Or is it an example of great customer service, continuing to support products and protect customers years after the initial release?

Kellett believes that both arguments hold weight: “It’s a combination of both. We’re in this situation because of the initial insecure coding of the software. But there’s now an expectation within the industry that organisations such as Microsoft take responsibility for any vulnerabilities that are found, and that they do that via the patching process.”

Clive Longbottom, founder of analyst firm Quocirca, agrees: “Some fixes deal with changes in the market, you could call that good support. Others paper over cracks, and you could call that bad coding.”