Patch Management: No Longer Just an IT Problem

By Michael J. Meyer and Joyce C. Lambert

E-mail Story Print Story

Accountants and auditors, both internal and external, should be aware of how their companies and clients are managing the patch process, because it is a key control in securing a company’s data, including financial data. Recent AICPA Statements of Auditing Standards (SAS 104, Due Professional Care in the Performance of Work, and SAS 109, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement) as well as the COSO Integrated Framework for Enterprise Risk Management have increased the emphasis on and responsibility of auditors for assessing risk. Information-system security is critical for all organizations and its key component is patch management (Rod Trent, The Administrator Shortcut Guide to Patch Management, New Boundary Technologies, Realtimepublishers.com, 2004). Patch management is essential to the proper functioning of the financial reporting process, and auditors should recognize its importance because corrupted financial data can cripple an organization.

What Is a Patch Management System?

Simply having patch management software running on a computer system does not equate to a functioning patch management system. While patch software is an important part of the patch management system, it is only one component. A patch management system manages the patch process throughout the organization to ensure software patches are installed in an orderly and timely fashion to all systems that need it. Furthermore, patch management systems have built-in controls to ensure that patches will not impact the current configuration and functionality of the existing information system. Patch management systems generate metrics that allow management to track the patching process, identify weaknesses, and provide auditable documentation of the internal control’s effectiveness.

Patch Management Best Practices: What to Expect

In evaluating the effectiveness of a patch management system, several critical elements should be present (see “Information Security: Effective Patch Management Is Critical to Mitigating Software Vulnerabilities,” United States General Accounting Office report GAO-03-1138T, 2003; “Creating a Patch and Vulnerability Management Program,” NIST Special Publication 800-40, Version 2.0, 2005; Rod Trent, The Administrator Shortcut Guide to Patch Management, New Boundaries Technologies, Realtimepublishers.com, 2004; and Bill Brykczynski and Robert A. Small, “Reducing Internet-Based Intrusions: Effective Security Patch Management,” IEEE Software, pp. 50–57). This section describes 15 of the best practices that should be used as benchmarks for assessing the effectiveness of a patch management system.

Board of directors and upper-management support. For a patch management system to be effective, there must be support from upper management and the board of directors; they must be willing to fund and otherwise assist in the patch management process (e.g., create strict corporate policies regarding usage of corporate technology assets). Without management’s support, patch management systems will fail to achieve the level of security expected.

Assign responsibility to patch management group. Once upper management recognizes the importance of a proper patch management system, a group must be assembled to oversee it. One would expect there to be a significant IT presence in this group, because it will be in charge of implementation; however, the team should also have a liaison to the board of directors and include internal auditors and corporate accountants. The members from the IT department should have specific knowledge in system administration, system security (including intrusion detection and firewall management), operating systems, and any hardware or software used in the system. While the size of the patch management group will vary with the size of the organization, it should include enough people so that all of the requisite skills are represented, without being too large to function effectively. It is critical that this group be able to work quickly to identify vulnerabilities, understand the organization’s exposure, determine the necessity of installing any available patch, test the patch to ensure that it will not interfere with the existing system, and implement the patch through a predetermined installation hierarchy. Identifying the individuals responsible for the patch management system mitigates the possibility that dangerous vulnerabilities known to have circulating exploits will go unaddressed.

Set baselines for computer systems. A baseline is a standard set of software programs that individuals have available on their computers. This baseline should include the most current versions of programs installed with all vendor-released and tested patches. As organizations become more complex, keeping everyone on the network using the same software, or the same versions of software, becomes a significant challenge. Maintaining this consistency is necessary to know who should receive what patch. Too often, individual users will install updates or upgrades without the knowledge or approval of the responsible IT staff. User installation of nonbaseline programs should be limited and, in some cases, prohibited. Companies rarely have one single baseline for all employees; they often install a series of baselines based upon the job description and responsibilities of each individual. As Rod Trent notes: “Adhering to your baseline is important because a single, unpatched, nonstandard computer can make an entire environment vulnerable to attack.”

Risk-based hierarchy of software and hardware. The purpose behind creating a hierarchy of software and hardware is to develop a risk-based systematic process for testing, implementing, and installing patches. While there are numerous components to risk, two types of risk are of primary concern when setting priorities for patching: organizational risk (if the application is not available), and exposure risk (if the software is exposed to the Internet or an external network).

First, software should be prioritized in terms of which programs would present the greatest risk to an organization if they were not available. The highest-priority applications must be tested to ensure that the installation of the patch will not disrupt the software’s functionality. Usually, applications that are necessary for the networks to function (operating systems) have the highest priority. Similarly, enterprise software is usually a very high priority.

Second, a high priority should be given to those applications that are most at risk of attack because they are exposed to the Internet or other offsite access (web browsers and e-mail applications), as well as security software, including firewall and virus protection.

Specialty software, such as accounting software, sales contact information, or personnel applications, that contains confidential data is often targeted by computer hackers, making it a high priority. Assuming that the network is configured to protect this data and there is only limited accessibility to it, a lower risk priority can be assigned.

A similar process of prioritizing hardware assets should be set. A typical prioritization uses an organizational risk approach, which includes identifying hardware that the organization cannot do without. Usually servers are at the highest priority, and personal computers of nonessential staff at the lowest priority. It is important, though, that exposure risk be considered when setting priorities. As such, how employees use the hardware is as important as its functionality. Any hierarchy must be continually evaluated and updated. Attacks are constant, and hackers search for the weakest point of resistance.

End-user training. No matter how sophisticated the patch management system, there will always be a need for end users to be part of the process. While much of the work of the patch management system will be done by the patch software and the patch management group, compliance by end users is essential. For example, if end users are constantly downloading programs that affect the baseline, patch implementation will be negatively affected. In addition, the downloading of programs is an invitation for spyware, Trojan horses, viruses, or worms to enter the system.

Training end users is a necessary condition for their participation in the patch management system. They should be informed of the corporate policies and the consequences of failing to fulfill these expectations. Additionally, end users should be updated on what is being done to protect the company’s data, including personnel data, and why it is important to keep this safe. The training should be ongoing and involve all end users.

Patch software. The centerpiece of any patch management system should be the patch software. While software alone is not a sufficient replacement for a full patch management system, without patch software, any patch management system would be ineffective. Rather than relying on vendor-specific patch software, third-party patch software provides much broader coverage and functionality. A good patch application will automate most of the patching process, identifying the patches needed, installing them, and reporting which systems were patched. Patch software should be flexible enough to allow the specific targeting of systems and applications, following the hierarchy already developed.

Systematic identification of vulnerabilities. Effective patch management systems must be able to identify relevant vulnerabilities and alert the patch management group as to their existence, even if a patch is not available. The patch management group should be on the alert to determine what to do if an exploit surfaces prior to a patch being available. While many patch applications will monitor for new vulnerabilities, other resources should be regularly reviewed for relevant vulnerabilities. These resources include vendor security mailing lists and websites (e.g., Microsoft’s security website, at www.microsoft.com/technet/security/default.mspx), vulnerability database lists (e.g., National Vulnerability Database, nvd.nist.gov/; the US-CERT National Vulnerability Notes Database,
www.kb.cert.org/vuls; SANS Institute, www.sans.org; and Bugtraq, www.securityfocus.com/archive/1), and Internet discussion groups related to patch management. The process for identifying relevant vulnerabilities must be ongoing.

Patch management is a system—do not chase events. Patch management systems function best when vulnerability detection, testing, training, and implementation are integrated into the IT environment. Patch management systems that simply respond to the crisis of the day lack the responsiveness to adequately deal with zero-day attacks. As IT analyst Chris Roberge stated in an admonishment to those who see the need for patch management primarily as a response to known exploits: “It’s important to look at Patch Management as a process, ideally, a closed-loop process … This means, essentially, that patch management should be automated to the point where it can maintain your desired patch levels with as little human intervention as possible. Patch Management, as an automated series of best practices, has to be repeated regularly on your network to ensure protection from exposed vulnerabilities” (“Patch Management Best Practices,” a White Paper of Ecora Software Corporation, 2004).

Develop and maintain an IT asset inventory. One of the first steps in developing a comprehensive patch management system is to create a detailed inventory of all IT assets, including all hardware and software. Prior to creating baselines, knowing which software has been installed on each computer is essential to any patch management system. This inventory is the only way to find out which systems need patches. Like all components of patch management, this inventory is an ongoing process. While knowing the location of all company hardware is essential for patch management, it is also useful for financial reporting, tax reporting, data security, and asset disposal management.

NIST recommends that a typical asset inventory include the following items: system name, property number, main user, system administrator, physical location, connected network port, software configuration (operating system and version number, software packages and version numbers, network services, and IP address), and hardware configuration (CPU, memory, disk space, Ethernet address, wireless capability, and other input/output capability). Rod Trent said that once the inventory is compiled, the following questions should be answered: “How many operating systems are present that will potentially need to be patched? How many versions of operating systems are in use? How many applications and application versions are in use? Will different operating systems or application versions need different patches? How many unpatched systems are being used? How many unmanaged systems are being used? Which systems are mission critical? What existing software dependencies will impact how a patch is distributed?”

Through the establishment of an IT asset inventory, a patching hierarchy can be established; dangerous unpatched systems can be identified; outdated or unused software and hardware can be identified (creating cost savings); and control and order can be exerted over the use of IT assets. Nonstandard and noncompliant assets may be discovered, such as employees’ personal computers connected to the corporate information system through remote access. Because these assets are unlike most corporate assets, proper policies and procedures need to be established to ensure that these computers do not become the trapdoor that allows viruses or worms into the computer environment (“Patch Management Best Practices for IT Practitioners,” BITS Financial Services Roundtable, July 2004).

Test all patches. Chris Roberge said: “The reason for testing patches prior to deployment may be obvious, but should be stated clearly: patches sometimes break operating systems.” The importance of testing patches often gets ignored in the pressure to patch systems when a known exploit exists for a vulnerability. A well-designed patch management system can minimize the testing time while providing substantial assurance that the patch will work.

Proper testing requires that a test environment be created that mirrors all of the company baseline systems, including all servers and operating systems. A set of test data with known output is needed to determine whether the patch has any impact on the functionality of the test environment. While most patches have been tested to some degree by software vendors prior to issuance, this does not guarantee that a given patch will not have an impact on a given system. Patches created in response to a known exploit are often tested less rigorously by vendors (due to the rush to create and distribute the patch), as compared to service packs, which vendors test rather extensively prior to issuance. Once a patch has been determined to be safe, the patch management group should be on alert for any indication that the patch is negatively impacting system functionality.

Assess impact of new vulnerabilities. Once a relevant vulnerability is identified, the patch management group must assess the potential impact an exploitation of this vulnerability would have on each component of the information system. Not every organization needs to install every patch. The BITS Financial Services Roundtable suggests considering the following factors when evaluating the potential impact of a vulnerability: type and delivery of possible attack, severity of the vulnerability, and criticality of the system. If it is determined that critical systems (i.e., those classified as high priority) are at risk, action should be taken immediately. In extreme cases, it may be necessary to disable a resource if an attack is imminent and there is no proven patch available. If low-priority systems are at risk, however, there may be compensating controls to mitigate the need for immediate action.

Verify patch installations. Verification of patch installation is often tracked by patch software; however, if installation of the patch is reliant on a network connection or system reboot, installation may take time. Assuming that all employees understand the importance of patch management and are aware of the consequences if they do not do their part, patch installation should take hours rather than days. An updated inventory of assets will help determine if there are any systems that have not been patched. The patch management group must find those rogue computers and patch them. It is insufficient for the patch management group to assume that all systems have been patched. Since attacks converge on the point of least resistance, tracking and documentation of 100% compliance is necessary.

Patch management system metrics. As with all systems, the ability to measure effectiveness is necessary for the system to identify weaknesses so that improvements to the system can be made. NIST recommends collecting three categories of metrics: susceptibility to attack, mitigation response time, and cost. Susceptibility to attack metrics includes the number of patches (in total and per system), the number of vulnerabilities (in total and per system), and the number of network services (i.e., more services means higher susceptibility). Mitigation response-time metrics include response time for vulnerability and patch identification, patch deployment, patch testing prior to deployment, and compliance on at-risk systems. Cost metrics include the patch management group, system administrator support, patch software, and system failure (see “Creating a Patch and Vulnerability Management Program,” NIST Special Publication 800-40, Version 2.0, 2005, pages 3-1:3-8, and Kenneth MacLeod, “Patch Management and the Need for Metrics,” July 2004, SANS Security Essentials GSEC Practical Assignment, Version 1.4b).

Written policies and procedures. Because patch management is an important internal control, an organization must fully document its policies and procedures. The organization must document the corporate expectations of all levels of employees and enforce harsh punishments for individuals failing to fulfill their responsibilities. The policies should identify the obligations of the patch management group, the expected level of cooperation by system administrators related to security issues, and the hierarchy of software/hardware. Procedures should spell out exactly what is to be done to identify vulnerabilities, test patches, deploy and install patches, and determine patch compliance. The procedures should also require that all steps in the patch management process be documented to facilitate the auditing of this important internal control.

Create a contingency plan for zero-day attacks. In the area of IT security, the worst-case scenario is a zero-day vulnerability attack on critical systems. Organizations need to have plans in place to determine what they will do if a vendor patch is not available and their critical systems are vulnerable to an imminent attack. For example, would the company deploy a nonvendor patch as a temporary measure? Should the at-risk resources be disabled until a vendor-supplied patch is available and has been tested on the system? Use of nonvendor patches could do more harm than good, but they are sometimes recommended by experts when a vendor is slow to respond to a severe vulnerability. Especially with critical systems, companies cannot afford to have them disabled for any significant period of time, and with sufficient testing, nonvendor patches may be a valuable, though risky, temporary solution. Whatever the decision for a company, planning for an eventual zero-day attack is prudent and will reduce the panic that often accompanies a zero-day attack.

Aside from working toward the best practices above, organizations should fully engage accountants and auditors in the patch management process. Accountants and auditors play an important role in ensuring that this key internal control is effective.

Patch Management Systems and Accountants

It is especially important that accountants within an organization (corporate accounting and internal auditing), as well as external auditors, take an active role in the patch management system. There should be at least one representative from corporate accounting and internal auditing in the patch management group. External auditors should provide their expertise in designing and evaluating controls to help the patch management group improve the patch management system. Too often, accountants see the patch management system as an IT problem rather than as a key internal control protecting the financial information of a company. Corrupted financial data can cripple an organization. While the patch management system protects the entire information system, its role in protecting the financial information, especially where organizations employ ERP systems, is unassailable.

Accountants and auditors can participate in the patch management system without extensive IT training. For example, they can create an inventory of IT assets, facilitate high-level support by helping management understand the value of this internal control, write and edit policies and procedures for the patch management system, help in the design and measurement of patch management metrics, and help select the patch management software.

Role in the financial statement audit. Evaluating the quality of internal controls over the financial information is of vital interest within the course of a financial statement audit and is required by auditing standards. Because patch management is a key internal control, auditing the effectiveness of this control is necessary under Sarbanes-Oxley Act (SOX) section 404. The lack of an adequate, functioning patch management system could be a material weakness in internal control, possibly resulting in an adverse section 404 opinion on internal control or management’s assessment of internal controls. Auditors must be able to test whether these controls are working as designed. Following the best practices espoused earlier will enable the patch management system to be auditable. The key attributes that make a patch management system auditable include adequate documentation of policies and procedures, a significant set of meaningful metrics updated on a regular basis, and patch management software that can provide auditable information regarding the current status of any and all computers within an organization.

Role in enterprise risk management. A patch management system that functions well should support an organization’s enterprise risk management (ERM) system. In fact, the patch management system should be seen as a significant component of the enterprise risk management system because of its ability to both monitor the environment for potential risks and create an organized response to these risks.

The Patch Management System in Use

Patch management is a key control in any information system, requiring documentation and internal testing so that it can be evaluated as part of financial statement and SOX section 404 audits. As part of a larger ERM system, an effective patch management system provides valuable input on event identification, risk assessment, and risk response.

Every information system today is under constant attack. Because no software program is without flaws, entry points to an information system may be more numerous than many expect. This problem balloons when vulnerabilities are discovered and companies fail to install patches for programs when they are made available. Without a systematic process of patch management, companies are essentially leaving the doors to their information systems wide open to potential troublemakers.

Click here to view Sidebar.

©2009 The New York State Society of CPAs. Legal Notices