IT Security — How Important Is Patch Management?

By Chuck Grigg & Joe Oleksak

Network Security
Universal Advisor, 2004 Issue No. 1 

Businesses who've been burned by the CodeRed worm, Melissa virus, or Nimda understand the importance of keeping systems up to date with appropriate virus protection patches, but for several other organizations (those that, for the time being, remain without incident), patch management is merely an afterthought conducted once the organization is attacked — an afterthought that can cost an organization significant time and money.

The CERT/Coordination Center (CC)3, a security industry standard for Information Technology (IT) professionals, estimates that 95 percent of all network intrusions could be avoided by keeping systems up to date with appropriate patches. It’s important, therefore, that organizations develop, formalize, and implement a Patch Management Program (PMP) to arm their IT departments with the appropriate tools to fight this endless battle.

An effective PMP is composed of four, easy-to-follow steps:

1. Identify

2. Prioritize

3. Test

4. Implement

Identify

There are many methods an organization can use to identify patch releases for all its systems and network components (servers, routers, firewalls, etc):

• Vendor Web sites and mailing lists

• Newsgroups and third-party Web sites and mailing lists

• Vulnerability databases (CERT, ICAT, etc.)

• Windows updates

• Vulnerability scanners, etc.

It’s up to the organization to decide how they will identify necessary patches. What’s important is that mechanisms are chosen and a procedure formalized and followed as part of the organization’s PMP. For example, if operating on a Windows 2000 platform, weekly visits to Microsoft.com and a procedure for running the Microsoft Baseline Security Analyzer tool on a monthly basis might be a viable solution for patch identification.

However, not all vulnerabilities have associated patches; a common flaw of many PMPs is that they address monitoring for patches but fail to consider current vulnerabilities. Although this is understandable given the responsibilities of the usually understaffed and overworked IT department, it can be dangerous because the hacker’s modus operandi is monitoring and exploiting vulnerabilities.

Therefore, an organization may have more success with their PMP if they include a visit to the National Infrastructure Protection Center (NIPC) twice per month. The NIPC produces a biweekly publication called “Cybernotes,” which lists all new vulnerabilities published during the previous two weeks (available at http://www.nipc.gov/ cybernotes/cybernotes.htm). This step, coupled with the Microsoft patch identification procedure mentioned above, truly adds value to the PMP.

Finally, a patch management database should be maintained that contains information on all patches that apply to the organization. At a minimum, the patch database should include the patch or a hyperlink to the Web site containing the patch and instructions on how to install the patch.

Prioritize

The next component in an effective PMP is prioritizing the systems and applications for patch updates. Depending on the size and complexity of the organization’s network, it can be a difficult endeavor for IT to install all patches in a timely manner. As a result, setting priorities for which systems and network components to patch and in what order is essential to an organization’s PMP.

The first step in prioritizing is to inventory all systems and network components (if an inventory doesn’t already exist). An inventory should include the following:

• Hardware — Type, manufacturer, and unique identifier (serial number)

• Operating System — Type, manufacturer, version number, and current patch level

• Major Applications — Type, manufacturer, version number, and current patch level

Understanding software applications that are installed by default is also important (e.g., IIS is installed by default by SMS and SQL Server on Windows platforms) because administrators often patch only what they believe is currently running on their systems.

Once an inventory is available, a patch-focused risk assessment should be performed to determine the priority of the systems to be patched. When performing a patch-focused risk assessment, an organization should evaluate its systems for the following:

• Threats: Activities with the potential to cause harm to a system or network. Examples of systems that frequently face high threat levels are Web servers, e-mail servers, and other hosts traditionally accessible to external users and servers that contain high-value information such as financial databases, proprietary information, or other items of interest to internal and external offenders.

• Vulnerabilities: Flaws, misconfigurations, or weaknesses that allow the security of the system to be violated. Systems that often have significant vulnerabilities include Web servers, systems installed by inexperienced personnel, and systems that allow unauthenticated access to resources.

• Criticality: A measure of the importance a system has to the organization’s mission. Systems frequently considered mission critical include mail servers, database servers, and network infrastructure nodes.

Systems that face significant threats, are vulnerable, and are mission critical should be patched before hosts that face few threats, are secure, and are not mission critical.

Test

The third component of a PMP is a pre-installation testing process. Testing is a critical step in a PMP;  without proper testing, an administrator might unknowingly damage the confidentiality, integrity, and availability of the organization’s network, systems, and/or data.

Whatever the source of the patch (vendor, security Web site, friend, etc.), the organization’s IT group should always take precautions before attempting installation:

• Always verify cryptographic check sums, or digital signatures. This helps mitigate the risk of obtaining and installing a compromised patch containing Trojans or viruses.

• Always virus scan patches before installation. Remember to verify the antivirus signatures are up to date.

• Always test patches before implementing them on production boxes. Make sure the patch:

• Corrects the vulnerability.

• Does not open an old vulnerability.

• Does not create a new vulnerability.

• Does not degrade system performance.

• Is compatible with other required applications.

If, for any reason, the organization is unable to install a patch (i.e., it fails one of the tests listed above), the organization should formally document this within the patch management database. The patch management database should be populated with detailed justification for why the organization was unable to install the patch.

Implement

The final component in a PMP is applying the patch. Applying the patch may be as simple as modifying a configuration setting or installing a hot fix provided by the vendor. It may even require the installation of a new software version. Whatever the solution, it’s important to remember that a simple patch application methodology will never apply to all systems and applications. This is why it’s important to include detailed installation instructions along with lessons learned and results from each test in the organization’s patch management database.

In Conclusion

Implementing and executing an effective PMP can significantly reduce the likelihood of system and network component compromise. Hackers and virus writers often subscribe to the concept of “least resistance.” Consequently, properly patched systems and network components may effectively deter hackers, prevent viruses from propagating, and provide the organization with a more secure operating environment.