Management: No Longer Just an IT Problem
Michael J. Meyer and Joyce C. Lambert
- No software program is perfect. As problems and bugs are discovered,
the developer or a third party may fix them. This fix is what is
referred to as a software “patch.” If
the problem is related to a security issue, it is referred to as
a software “vulnerability.” This does not mean that
viruses, worms, or other programs that could exploit this vulnerability
exist, but that such exploitation is possible. The CERT Coordination
Center, which specializes in Internet security expertise and is
located at the Software Engineering Institute at Carnegie Mellon
University, indicates that reported software vulnerabilities have
grown from 171 in 1995 to 8,064 in 2006 (www.cert.org/stats).
Software users must be vigilant in protecting their information
systems. An efficient system is critical because the time it takes
for a reported vulnerability to be exploited is decreasing—perhaps
less than 24 hours. There is a recent trend of “zero-day”
exploits in which an exploit to a vulnerability is created before
or on the same day as the vulnerability becomes known by the software
developer (see netsecurity.about.com/od/newsandeditorial1/a/aazeroday.htm
or the US-CERT Quarterly Trends and Analysis Report, November
28, 2006). Brian Krebs reports on his computer security blog (blog.washingtonpost.com/securityfix/2006/11
/microsoft_warns_of_more_zeroda.html) that Microsoft’s
software was the target of at least 16 zero-day exploits in 2006
(January through November), up from just four in 2005.
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
Is a Patch Management System?
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.
Management Best Practices: What to Expect
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.
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
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.
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.”
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).
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
applications that are necessary for the networks to function (operating
systems) have the highest priority. Similarly, enterprise software
is usually a very high priority.
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.
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.
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.
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.
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.
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.
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,
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.
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).
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.
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?”
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).
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
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.
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
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
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).
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.
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.
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.
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,
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.
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.
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.
Patch Management System in Use
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.
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.
here to view Sidebar.
J. Meyer, DBA, CPA (inactive), is an assistant professor
of accounting at Ohio University, Athens, Ohio.
Joyce C. Lambert, PhD, CPA, CIA, is the Andersen
Professor of Accounting and the LL&E/Burlington Resources Professor
at the University of New Orleans, New Orleans, La.