Automated Patch Management


Automated Patch Management










PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free
download.

Automated
Patch Management

by Brady Hicks

Copyright 2022, Faulkner
Information Services. All Rights
Reserved.

Docid: 00018900

Publication Date: 2206

Report Type: TUTORIAL

Preview

The task of keeping up
with the latest patches is a constant battle for already
overburdened IT administrators. Smaller environments may be able to
deploy patches manually, but for organizations of even a modest size,
automation is needed to stay
on pace. Automation does not imply that administrators can simply
install a tool and walk away, however. Careful selection,
configuration, and monitoring are required to make effective use of the products now
available on the market. This tutorial examines these and other considerations
when selecting an automated patch-management system.

Report Contents:

Executive
Summary

[return to top
of this
report]

An automated patch management tool is designed to assist with most of the
processes associated with tracking, acquiring, and deploying software
updates and hot-fixes.

Network
Management Tools
Market Trends
Network Management Tools
Tutorial

This form of patch management reduces IT labor requirements and helps ensure
that all software deployed on a network is updated to the approved version. Some
products are single-purpose tools whereas others incorporate patch management
functionality into suites that deliver a range of network-management
capabilities. In recent years, there has been a clear trend toward comprehensive
applications. This trend
signals that the technology has reached a new level of market maturity.

Today’s patch
management products are not, however, a panacea for all software updating needs.
Even the best and most comprehensive products require thoughtful
supervision and some manual effort to ensure that the patch management
process works effectively and adheres to internal policies.

Description

[return to top
of this report]

The patch management
process consists of three main steps and two complementary ones, as detailed in
Table 1.

Table 1. Patch Management Steps
Main Steps Complementary Steps
  1. Monitoring networked systems for software
    version compliance
  2. Testing
    patches
    before distributing them
  3. Installing
    approved
    patches
  1. Backing up all critical systems before starting
    the upgrade process
  2. Validating
    patch effectiveness prior to deployment

These processes are often aided by automated tools that streamline
testing and implementation, but some manual steps are almost always needed. The key processes of
patch management are described in Table 2.

Table 2. Patch Management Processes
Process Description
Backup Although
backing up critical systems is not necessarily associated with
distributing patches, it is a wise precaution for all organizations and
is considered a best practice. Certainly, system backups require a
substantial amount of time and computing resources and may not be
appropriate for all routine automatic patch distribution, especially
for patches that have been thoroughly tested and carry very little
chance of corrupting the network. Organizations must therefore balance
the time and resource requirements with the risk before installing
patches. If the system is corrupted from a bad patch, restoring it from
a recent backup can save considerable resources
compared to rebuilding it from scratch.
Monitoring Tracking the software
installed across a network
is difficult and time-consuming, particularly when end-users install
software without permission. Patch management software can scan a
network to determine which applications and versions are implemented at
each endpoint. This provides a means of identifying systems that do not
have
company-approved versions of software. After a patch
installation is completed, reporting functions can identify whether the
patch successfully addressed the problem that it was installed to fix.

The
data that patch management tools supply in their reports varies from
product to product. More data is not always better because lengthy
reports can be difficult to translate into actionable information. The
best reporting tools clearly present the
information that IT administrators need in order to identify security
vulnerabilities and other software issues.
Testing Applying new patches can be dangerous. Some patches are hastily
developed and create problems once implemented. Patches should always be tested
because it is impossible to predict in advance how a particular piece of
software will interact with a given environment. For instance, a patch for the
Windows operating system may have been tested by Microsoft but could still cause
problems when deployed with a third-party accounting application.

Many
vendors of patch
management software test the updates that Microsoft and other
providers create, write a description, and then make the patches
available to users of these products. Vendors identify new patches as
they are released, saving IT administrators the time-consuming work of
scanning
vendor sites, Web forums, mailing lists, and other sources to learn
when new patches are released.

Software
providers cannot test the interoperability of their software with all
other applications, so it is important for IT administrators to take
this responsibility upon themselves, confirming that the
patches are acceptable before deploying them on working devices. IT
administrators can define and enforce policies regarding which versions
of software are installed on the network. Other products allow
particular systems to be designated as test platforms. The patch is
loaded onto
these systems, and if there are no unexpected effects, it
then
gets deployed throughout the network.

Implementing
new patches in phases enables IT administrators to perform another
round of testing and validation. Once the patches are confirmed to be
operating properly, IT staff can proceed with a full implementation by
using available resources to automatically distribute patches
throughout the enterprise.

As with
other
widespread system upgrades, IT administrators should
use change management procedures and tools to track the patch
distribution and verify that they were successfully
installed on each system.
Automatic
Rollout		 Patch management servers typically communicate with
client systems in one of two ways: through agents installed on the
clients or through remote procedure calls
(RPCs), which do not require software to be installed on hosts.
Although using RPCs reduces the up-front labor needed to install agents
on client systems, this approach may not be effective in managing
remote hosts that reside on the other side of a firewall. The RPC
method may also provide less information about the potential security
vulnerabilities of clients. Another advantage of using agents is that
they are more likely to enable the management of hosts using
non-Windows operating systems.

After an
update
has been approved for distribution across an enterprise, patch
management tools
enable IT administrators to selectively choose which systems should
receive
it. Recipients can be chosen individually, or IT administrators can
create pre-defined groups of systems, such as “accounting” or “field
workers,” and
select that group as a target. Most products allow patches to
be
deployed across an entire network, including to hosts that connect via
virtual private networks.

Some
products
also have a “roll back” feature that enables patches to be undone, returning
a system to its previous state in the event that an update
causes problems.
Validating
Patches 		Validating that the
patches are installed and
functioning properly is a natural follow-up to the testing and
deployment. Otherwise, the organization increases
its risk of problems and potential security intrusions and
vulnerabilities that can damage mission-critical systems.

It is
vital to
verify that the patch is correct and originates from the intended
location. Using known, trusted sources helps confirm that a patch
received is
valid and not corrupted or compromised. But this should not substitute
for
authenticating the patch files once downloaded.

Additional
security measures, such as digital signatures on patch files, may also
ensure the patch file’s integrity.

Current View

[return
to top
of this report]

Demand for Patch
Management

Because software
is inherently
imperfect, nearly all commercial
applications require occasional or ongoing updates to fix bugs and to
implement new features. Many software packages offer free, automatic
update services delivered over the Internet. For instance, Windows
operating systems include a built-in update utility that automatically
links to a Microsoft-owned server. Similarly, many types of anti-virus
software can automatically search for updates and install them.

The
opportunity to
reduce the expense of managing patches has
created a market for commercial patch management products. Although
employed for many types of issues, patch management is primarily used
for security updates. This includes updates to operating systems and
other general purpose software to remedy newly found security
vulnerabilities; it also includes updates to security applications to
address new threats, such as updates to anti-virus software to ensure
that it can identify a new
piece of malware. With the growing threat of security breaches and
corresponding hefty losses
and legal liability that organizations face, patch management has
become a critical component in organizations’ attempts to
perform
due diligence in protecting their systems and data.

Best
Practices

IT
administrators could
apply all
patches manually. This process would involve visiting each client
computer and installing the appropriate updates. While practical for
very small, single-office networks, this approach
is impractical for larger, more dispersed environments or for businesses
employing work-from-home protocols. Manual
patching is not only less cost-effective than automated patching, but
it also results in more errors and oversights.

Many
IT administrators
do not
install every new patch that is released for
the software platforms they manage. This may be because of the effort
involved with installing the
updates, because administrators sometimes do not hear about a new
patch, or because problems caused by previous updates have made them
reluctant to apply future patches. The lack of a way to easily test and
apply new patches results in a large number of computers without
current fixes. The majority of computer infections and compromises that
occur are likely preventable, because patches exist for them. When the
patches are not applied, however, hackers can
exploit the vulnerability that the update addresses.

Marketplace

Organizations
should base their
choice of patch management tools on several factors, such as the
number of platforms supported and systems to be patched, existing
expertise and personnel involved, and the availability of existing
system management tools. The
following categories typify the automated patch management systems that
are available:

  • Pure-Play
    Patch Management –     Specialized
    companies
    that focus on patching
    operating systems and applications.
  • Server and Desktop Management – Companies that
    offer asset management
    solutions and have expanded their offerings to include patch management.
  • Network
    and Systems Management –     Companies that offer
    network
    or systems management solutions that also distribute patches.
  • Network Security –
    Companies that offer security products such as anti-virus and
    vulnerability scanning tools, and have enhanced their product suite
    capabilities to address patch management.

Top products on the market include:

Microsoft. Microsoft offers the Endpoint Manager and Azure
Automation Update Management, both with patch-management options.
Endpoint Manager includes options for endpoint security, device management, and
intelligent cloud actions – within a unified management platform – with
Microsoft Intune and Configuration Manager. The Azure Automation Update Management
offering, meanwhile, embraces a scalable model for taking ownership of server
updates and patching operations. The software can be customized to run according
to specific business needs using a centralized, DevOps approach.

HCL BigFix. HCL acquired IBM’s patch-management assets in a December
2018 transaction valued at $1.8 billion. This sale included a number of IBM
Software sets, including AppScan, Unica, Commerce, Portal, Notes, Domino, and
Connections. HCL BigFix serves to address the full system lifecycle, including
asset discovery and inventory, software distribution, OS deployment, migration
and re-imaging, power management, and remote desktop control, as well as patch
management.

Ivanti Windows Patch. This software allows the user to
incorporate complete patch management within an Endpoint Manager environment.
The application offers automatic evaluation, testing, and applying of OS and app
patches, enterprise wide.

Solarwinds Patch Manager. The Solarwinds Patch Manager offering provides intuitive software for more
quickly addressing software vulnerabilities. It comes packaged with
out-of-the-box reports to better manage critical updates, installed statuses,
and failed updates. No SQL knowledge is required.

Additional Offerings. There are dozens of patch-management software
options available in the market, including offerings by Broadcom, NinjaRMM,
Atera, ManageEngine, PDQ, Automox, LogMeIn, Salt Project, Kaseya, SysAid,
ConnectWise, GFI Software, Autonomic Software, and IgniteTech.

Outlook

[return to top of this report]

The key shortcoming of many
commercial patch
management systems is that they are limited to certain platforms or
only work with
some applications, and therefore are not able to carry out patch
management
services for all of the systems within heterogeneous networks. Organizations
can overcome this by adopting more than one patch management system,
such as one for UNIX systems and one for Windows.
Currently, the industry offers multiple commercial and free tools
for automatic patch distribution and management for the
Windows environment but somewhat fewer for
other systems. UNIX systems contain numerous configuration variables
that can make automatic patch deployment difficult.
Therefore,
IT departments are more likely to manually distribute patches to UNIX
and Linux systems and leave automated patch management for the Windows
environment.

Some
organizations continue to manually apply patches on UNIX-based systems
by upgrading to the patch
level of the OS version. The various configuration differences common
to UNIX systems can make automatic patch deployment and management
problematic. Manually installing patches on UNIX-based and Linux
systems usually involves compiling the patch source code
into the application or kernel. This approach undermines the goal of
cutting costs and minimizing IT labor, prompting many vendors marketing
patch management to explore a more heterogeneous approach. Today,
several vendors
support scanning and patching of non-Windows operating systems.

The
availability and maturity of patch management products continues to
grow.
These tools are either agent-based or agentless systems, defined by
whether they require software (“agents”) to be installed on the
target systems or whether the systems can be patched
without agents
residing on them. Many
IT departments hesitate before employing an agent on hundreds or thousands of
devices. 

Best
practices are emerging for patching cloud environments, but work
remains. Different cloud environments demand different approaches.
For instance, PaaS (Platform-as-a-Service) providers can exercise fairly tight
control, while IaaS (Infrastructure-as-a-Service) companies can use software
designed for traditional environments.

Recommendations

[return to top of this report]

Implementing
patches via tools that are built into applications can sometimes be an
impractical approach for large, dispersed organizations that use a
variety of software packages. These organizations
require centralized control of patch updates to ensure that only
approved software is implemented on their networks. In addition,
enterprises aim to reduce the amount of labor required for the process.
Automated patch management tools provide a way to meet these
goals.

Patch
management has grown into an integral, ongoing
part of network
maintenance and management as IT staff must constantly update a variety
of software systems to protect against network intrusions, viruses,
malware, and other threats. Patch management tools deliver a range of
functionality from basic deployment to value-added systems, network,
and security management.
Implementing
patches via tools that are built into applications can sometimes be an
impractical approach for large, dispersed organizations that use a
variety of software packages. These organizations
require centralized control of patch updates to ensure that only
approved software is implemented on their networks. In addition,
enterprises aim to reduce the amount of labor required for the process.
Automated patch management tools provide a way to meet these
goals. Patch
management has grown into an integral, ongoing
part of network
maintenance and management as IT staff must constantly update a variety
of software systems to protect against network intrusions, viruses,
malware, and other threats. Patch management tools deliver a range of
functionality from basic deployment to value-added systems, network,
and security management.

Choosing the appropriate tool
for an organization can be complex. Administrators need to evaluate
products based on many factors, including:

  • Which
    solutions are agentless?
  • Which
    products integrate well with existing systems?
  • Is the solution easy to use?
  • What
    solutions offer comprehensive coverage of installed operating systems?
  • Which
    solutions cover handhelds and mobile systems?
  • Can the solution run in the background to avoid impacting performance?
  • Can patches be alleviated if they cause errors and issues to the network? 
  • What
    licensing options are available?
  • What
    testing and update mechanisms are available?
  • What
    support and maintenance plans are offered?

IT departments must first define what their organization needs before
determining what tool would work best in their infrastructure. Focusing only on
technology to solve the problem is not the answer. Installing patch management
software or vulnerability assessment tools without supporting guidelines,
requirements, and oversight will be a wasted effort that will further complicate
the situation. Instead, good patch management programs will blend technological
solutions with policy and operationally based components that work together to
address each organization’s unique needs.

Patch
management processes function most effectively as part of an overall
network management plan. Before deciding to implement a particular
solution, organizations should establish a comprehensive strategy that
includes asset management, software distribution, availability and
performance monitoring, application management, and network accounting. Small
organizations may only need automated, user-driven tools like
Microsoft Update, whereas large organizations need established policies
on updating each critical system as well as sophisticated software to
distribute, test, and validate the patches.

Most
customers will find that selecting a patch management tool requires
compromises. Dedicated patch management tools provide rich features and
automate many processes, but they have to be operated separately from
other management products. On the other hand, broadly focused products
with built-in patch management capabilities
may be less mature and may automate fewer processes.

Regardless
of which vendor’s solution an organization implements, patch management
software does not automate all processes. This forces administrators to
manually perform certain functions. When evaluating the potential
benefits of patch management software, organizations should not assume
that all costs associated with tracking, testing, and deploying patches
will be eliminated. Although
seemingly a limitation, the lack of total automation is actually
beneficial. IT administrators should remain actively involved in
monitoring software levels, evaluating patches, and installing updates.
Implementing a “raw” patch – that is, an update that comes directly
from a software vendor without being independently tested – is not a
safe practice. Vendors often rush
patches to respond quickly to newly discovered vulnerabilities.
As a result, some contain bugs that could cause problems,
sometimes disabling entire systems. Even in cases in which a vendor
performs its own testing, there is no guarantee that the patch will
work safely within a particular environment. Organizations that test
patches themselves before deploying them within their own networks will
minimize the possibility of malfunctions.

Organizations
will better protect themselves by maintaining non-production systems
for testing patches, an approach known as a “sandbox.” These systems
are configured with the same hardware and software as those that are in
use on the network. Organizations may be required to maintain multiple test
systems for each platform they maintain – for instance, one for file-and-print
servers, one for the mail server, and one for desktop clients – which may look
like an unnecessary expense, but it is much cheaper in the long run than
suffering the production consequences of a defective patch.

Routinely measuring the results of a patch management program, rather, helps
to continually improve it.

[return
to top
of this report]

About the Author

[return to top of this report]

Brady Hicks is an
editor with Faulkner Information Services. He writes about computer and
networking hardware, software, communications networks and equipment, and the
Internet.

[return
to top
of this report]