Recently, the folks at Core Security <a href="http://www.coresecurity.com/content/CORE-2010-0424-windows-smtp-dns-query-id-bugs">noticed</a> that Microsoft has been delivering <em>more</em> fixes during patch day than they have documented in their security bulletins. It's great that Microsoft is fixing more security issues, but when they're not documented the IT department's job could become even more challenging.

Dave Methvin, Contributor

May 31, 2010

2 Min Read

Recently, the folks at Core Security noticed that Microsoft has been delivering more fixes during patch day than they have documented in their security bulletins. It's great that Microsoft is fixing more security issues, but when they're not documented the IT department's job could become even more challenging.Most security issues aren't found by Microsoft, but instead by independent security researchers. In some cases, they're found by unknown black-hat criminals who immediately start to use them to deliver exploits and take over PCs. For either situation, once Microsoft knows about the exploit they start on a fix. Sometimes the fix comes in a few weeks; other times it can take months before Patch Tuesday delivers a fix for a problem that was reported to Microsoft. The urgency depends on the severity of the problem, and whether a known exploit is floating around in the wild.

A Microsoft patch is part of the Security Development Lifecycle (SDL) process. Whenever a security patch is required, Microsoft reviews the patch to ask "why did this happen, and what can we do to prevent it from happening again?" That process often involves a review of the code surrounding the area where the problem occurred. If it occurred because of a false assumption or a logic error, there's a chance that other areas of the code have similar problems that haven't been found yet. If new problems are found, it makes sense to fix them at the same time.

The white-hat researchers that report security problems know when their issues are fixed, since the security bulletin usually includes a "hat-tip" thanking them. The issues found by Microsoft during their own internal review don't necessarily need to be reported, especially if there seem to be no public exploits or knowledge they exist. That's how we get to situations like the Microsoft stealth fixes found by Core Security.

However, there's one complication with this just-fix-don't-tell policy. Once the patch is released, the bad guys can see what's been changed by comparing the old code to the patched code. They often do this to determine how they can exploit a particular problem. If some undisclosed-but-fixed problem is in there, the bad guys may be able to exploit it as well. Yet if Microsoft were to openly disclose the problems found during internal reviews, it's even more likely those problems would be exploited. Therein lies the conundrum.

Although some reports have made it appear that Microsoft is hiding important information from its customers, I don't see it that way. There's a very simple practice that can make the "disclose or don't" issue a non-problem for your organization: Apply patches as soon as possible. That way you'll be protected against both the disclosed and undisclosed problems.

About the Author(s)

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights