Data Breaches and the Importance of Patching Tools
Among other things, our study points to the speed with which vulnerabilities are exploited and the speed with which admins patch systems.
The company I work, Verizon Business, this week released the "Verizon Business 2008 Data Breach Investigations Study
." We're very pleased with it and hope you find it interesting. One point seems to be getting some attention and perhaps could use a little clarification.
In our analysis of the study, we take note of the very small number of breaches that involved exploitation of a patchable vulnerability. In only about seven percent of the cases we examined was a patchable vulnerability part of the attack path the criminal followed. From this we observed that the industry generally thinks that patching faster is very important. We believe, that thinking is wrong.
Of that seven percent, we found that all of these vulnerabilities were being exploited at least one month after the release of the patch. That's not to say that vulnerabilities were not being exploited before a patch was made available, but only that for those where a patch was already available, criminals weren't attacking them within hours, days or even weeks -- it was taking months. In 96 percent of these cases the patch had been available for three months already.
Therefore we concluded that patching faster solves nothing, unless you think that patching faster than three months is "faster" than what you already do. We certainly believe that a reasonable regular maintenance scheduled should be done no longer than every 90 days.
The first point of contention is whether we're saying that people should abandon tools such as Microsoft's Automatic Updates. Certainly we are not saying this or even suggesting it. Automatic Updates are of enormous benefit to everyone, regardless how you get the actual patches deployed (e.g. either directly from Microsoft, or via a third-party tool that relies on Microsoft's regular patch releases.) However, you must have some way to determine whether patches have been received by all your computers, and, whether they were fully and properly installed, and finally, whether the system was rebooted if that was necessary. These can be tricky, but such problems represent a significant obstacle in relying solely on Automatic Updates or other tools that deploy but fail to report all aspects of successful deployment.
Also, there is the question of whether or not all systems that require the patch are included in your patching regime. As our study uncovered, a number of breaches involved a system that was not even known to the victim. If such a system isn't participating in a GPO domain, for example, it may not be adhering to concepts you're relying upon to ensure patching.
We do believe that far too much trust is being placed on the pressing of the button to send out a patch to all systems, rather than ensuring that all systems are accounted for and administered reasonably.
The other question we've received is regarding cost: Are we saying that patch solutions are too expensive? Again, definitely not -- we're not saying anything one way or another about the price of solutions. Our analysis suggests that a patch solution is seen as a necessary expense and that people believe it eliminates the even more costly task of visiting each machine for patching.
Knowing that some breached systems are without a necessary patch for years, in some cases, tells us people have overlooked the basics. We do believe this is, in part, because they believe their patch solution is all-encompassing when, in fact, it isn't. Even if a patch solution can be all-encompassing (and there's no reason to believe some cannot), rudimentary and basic tasks are being overlooked. Ensuring that your inventory includes all machines, and/or identifies all that are outside of your general patching inventory is critical. Some may argue this is no small task, but if a system can get a network address within your sphere of control, it can be inventoried.
A reasonable and regular check of DHCP server logs, for example, should allow you to identify MAC addresses that are new, different, unknown. Assigning an address to those MAC addresses that would, for example, "black hole" them should instigate a help desk call. At the very least, it would make them inaccessible to criminals.
The bottom line is that you cannot secure that which you do not know about. Patching is seen, far too often, as the solution rather than as a solution. Other simpler and cheaper solutions can lead to significant risk mitigation and should, therefore, always be done.
About the Author
Russ Cooper is a senior information security analyst with Verizon Business, Inc.
He's also founder and editor of NTBugtraq, www.ntbugtraq.com,
one of the industry's most influential mailing lists dedicated to Microsoft security.
One of the world's most-recognized security experts, he's often quoted by major
media outlets on security issues.