For many small businesses, it will go down as The Summer of the Patches. The arrival, in quick succession, of the Blaster, Welchia, and Sobig.F attacks in August 2003 had many companies scrambling to patch their vulnerable software. It was bad enough that there were so many patches to administer; what made it worse was that there was so little time in which to do so.

Consider this: The Blaster worm arrived just 26 days after Microsoft disclosed an RPC DCOM Windows flaw and released a patch for vulnerable systems. The worm took advantage of what some security experts have called the most widespread Windows flaw ever. For a time, Blaster was infecting as many as 2,500 computers per hour.

In contrast, software patches for earlier viruses, such as Nimda, Code Red, and Slammer, were available for a significant amount of time before each attack. These threats spread swiftly due in part to known vulnerabilities that went unpatched. In the case of Slammer, which in the first minute of its life doubled the number of machines it infected every 8.5 seconds, Microsoft had released a patch a full six months earlier.

Bottom line: patching security vulnerabilities may make you want to tear your hair out, but it is a practice that can help prevent potentially costly damage to your business’ financial statement and reputation. Moreover, given the furious speed at which today’s viruses spread, it is paramount that you stay on top of patches so that you have time to test them before they are deployed.

Why it’s important
A report by the CERT Coordination Center at Carnegie Mellon estimates that 99 percent of all reported intrusions “result through exploitation of known vulnerabilities or configuration errors, for which countermeasures were available.” That’s all the more reason why you should respond promptly when software developers make their patches available publicly.

Patches for known vulnerabilities are available on software developers’ Web sites, but too often these are ignored or unnoticed. And that’s the dilemma -- the task of applying patches is often perceived as time-consuming, expensive, complex, or as a low priority. But if you incorporate procedures for reviewing and applying patches into your daily routine it will not only ensure that the job gets done, but it could ultimately take up less time.

Developing a patch management policy
If you are running a number of software programs, it is important to stay up-to-date with the patches for each one, and apply them as needed. Now more than ever, patching must be recognized as a crucial part of doing business, and it should be included into your overall security policy. For starters, consider the following:

• Keep in touch with software developers. Many software developers offer a notification list to their customers, and they also post information about patches and updates on their Web sites. Consult these on a routine basis.

• Determine the severity of each vulnerability. An effective patch management policy describes the processes that will be used to identify and deploy patches, and the ownership of each step in the workflow. The first step in this process is to develop a profile for each application you use that describes each application's sensitivity. For example, what is the business risk of a security breach for each application -- low, medium, or high? Next, how much downtime should be allotted to patch a vulnerability in each application?

• When possible, separate reviewer from deployer. Keeping these two roles separate is a good way to provide a measure of checks and balances. It also helps to ensure that the person who reviews advisories is as unbiased as possible.

• Document it. Put all patch management procedures in writing. Clearly define and assign all patch management responsibilities – i.e., identification of vulnerabilities, evaluation and testing of patches, and implementation of patches. Document all decisions to install or reject specific patches.

• Test, test, and test again. Sometimes the patch itself can cause unforeseen security problems. Before you roll out any patch to production systems, apply it in a test environment to make sure that it does not open vulnerabilities previously corrected or introduce any new vulnerabilities. Horror stories abound of companies that peremptorily applied patches that then knocked them out of service.

• First things first. In cases where multiple patches need to be installed, care should be taken to ensure that they are installed in the proper order.

• Consider a third-party service. If the patch management process is proving all too much for your company, perhaps it’s time to evaluate a third-party patch identification and management service. These services may be able to reduce the costs and overhead associated with patch management.

Conclusion
Inadequate patching of software vulnerabilities exposes small businesses to significant risk. These vulnerabilities can cause system unavailability, create security weaknesses, and corrupt critical system components or data. Software vulnerabilities resulting in security weaknesses can also leave computer systems unprotected and open to misuse by unauthorized parties, such as computer hackers.

To prevent such situations from occurring, you need to be vigilant about software vulnerabilities. Stay on top of these by tapping as many sources of information as you can. If you do, and if you follow consistent patch management procedures, you’ll be in a position to move quickly to mitigate any risks associated with software vulnerabilities.