Buying Decisions

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Seven tips for buying automated patch management products

Expert Earl Follis explains how to effectively evaluate and purchase automated patch management products for your enterprise.

Patch management products provide organizations with the ability to comply with industry best practices while fulfilling any applicable regulatory requirements -- such as those set by SOX, FRCP and HIPAA -- for regularly patching software.

Further, when the patch management products are automated, an organization can more easily guarantee all IT systems remain up to date with the latest patches from application software and operating system vendors, making the sometimes mind-numbing process of patch management easier.

This feature examines the steps necessary to effectively evaluate and procure patch management software for an organization. As with any IT project, we strongly recommend the process use established IT project management techniques, including the appointment of a project manager, project sponsor and inclusion of all stakeholders. By following existing project management processes, organizations will ensure all aspects of patch management products under consideration are properly evaluated.

An old IT adage is: "failing to plan is planning to fail." An organization's patch management project should be just that: a chartered and sponsored IT project. It is critical that the process of buying patch management products is managed to ensure all pertinent IT processes, rules and guidelines are observed throughout.

Identifying stakeholders

One of the first steps is to identify the relevant stakeholders. Stakeholders can include end users, IT management, and lines-of-business leaders who rely on IT to keep software up to date so revenue generation can continue unabated. There may also be corporate compliance stakeholders -- all the way up to the CEO of a company -- who must be considered stakeholders due to regulatory and compliance regulations that define appropriate automated patch management services. Once an organization has identified the stakeholders for the patch management project, be sure to include those stakeholders on all future project communication updates and stage checks.

Define automated patch management product requirements

An organization should want to see the patch management pudding in action as part of the evaluation process.

After an organization has identified stakeholders, it is time to begin the process of gathering requirements for those stakeholders. Collection, verification and ranking of automated patch management product requirements create an objective foundation that will serve the organization well for the duration of the procurement project.

Utilize a project requirements list due to another old IT adage: "You can't manage what you can't measure." Examples of questions to ask when creating a list of requirements include:

  • Does the product work as advertised in all applicable situations?
  • Is it within our budget?
  • Does it easily integrate with our existing system -- management products or solutions?
  • Is it easy to use? IT strives to do more work with less manpower, ease-of-use is a critical consideration.
  • Does the company offer 24/7 support? Patch management may happen during overnight hours, so being able to get competent tech support anytime you need it is important.
  • Does it support all of the devices and platforms currently in use, as well as those on the organization's roadmap?
  • Will it run in the background in a way that does not impact production computing or business performance?
  • Can IT easily schedule and automate my patching efforts?
  • Can IT easily back out patches that cause issues?
  • Can IT easily test patches before it rolls them out to servers and end users?

A requirements list ensures all foreseeable useful features and functions will be included in whichever automated patch management products the organization procures. The requirements list will include items that are marked "mandatory," some that are "nice-to-have," and some that are jettisoned from the project as "not applicable" or "not feasible." Don't forget to include any financial requirements in the list, such as total acquisition budget or yearly maintenance and support budget.

Identifying qualified options

Once an organization has its requirements list approved by stakeholders and locked down, it can then begin to research appropriate automated patch management products that it believes meet those requirements. Obviously, the best place to start the search is on the Web, including the myriad of patch management articles, product reviews and overviews right here on techtarget.com. Also, contact your top five vendors to arrange for product demos of their automated patch management products. Be sure the product demo is performed in a live environment; don't rely on white papers, glossy brochures and other vendor marketing collateral.

The proof is in the pudding, and an organization should want to see the patch management pudding in action as part of the evaluation process. First off, it'll want to see demos of at least its top five identified products, and later it'll want to install one or two of the best matching products in a test environment in order to verify product operation and features in a hands-on situation (more on this below).

Gauging functionality

If an organization has spent the appropriate amount of time and effort in building a requirements list, gauging functionality of the top five candidates can be as easy as checking off product functionality and features in a spreadsheet. Once again, do not take vendor performance, features and functionality claims at face value. Be sure to carefully evaluate each software candidate via an initial demo, then via hands-on testing later in the process. Here is a list of features organizations should look for and consider when purchasing automated patch management products:

  • Ease of use -- This is one of the top priorities. If it's not easy enough for a relative novice to use out of the box, it's probably going to be too complicated for the organization to use on a regular basis.
  • Integration with existing systems management infrastructure -- If a company already owns a comprehensive systems management suite (e.g., Microsoft System Center Configuration Manager), verify that the patch management product of choice readily and easily integrates into that existing infrastructure. In many cases, if a company already owns a systems management product that addresses other areas within IT, the best bet will be to utilize the patch management features of that solution because the integration work will already be done.
  • Support for all applicable platforms (current and future) -- Be sure the product you choose addresses all current IT infrastructure platforms, including operating systems and applications. Also, be sure to choose a product that can adapt to needs that aren't currently in use but are on the organization's IT roadmap, including support for BYOD and mobile devices that might be supported in the future.
  • Does it work well in the current IT environment? -- There is no better way than a hands-on proof-of-concept (POC) to verify that a patch management tool will address specific requirements and computing platforms. Most automated patch management vendors are happy to provide unlimited licenses for a well-defined POC period. During that POC period, be sure to have an explicit test plan in place to verify all critical operations and functionality. If the product doesn't meet or exceed requirements, it's better to find that out in advance rather than waiting until the organization has purchased a patch management product and implemented it.
  • Impact on performance -- End users and server admins generally will not accept any tool that adversely affects their ability to do their job in a timely fashion. Ensure the patch management product of choice performs well on all of the platforms in the company without a noticeable impact on production or end-user systems. Does it run in the background? Can the user postpone installation of a patch, if needed? Will the patch process run unattended without the need for user interaction? Can the organization prevent the installation of patches when a user is on a slow network link, say at a remote office or in a hotel room? These are all important questions to ask and get answered, either through communication with patch management vendors or through POC testing.
  • Software support -- Does the patch management vendor offer 24/7 tech support that is both accessible (they answer the phone) and accurate (they can solve my problem quickly and efficiently)? Always call a vendor's tech support line (not the vendor sales engineer assigned to POC testing) as part of a POC, to ensure their day-to-day support meets the organization's needs for timely, competent assistance.

Evaluating interoperability and integration

As part of the evaluation of automated patch management products, organizations may also need to ensure the products under consideration interoperate with or integrate with other products already running in their IT environment. For instance, if it is already running Microsoft's System Center Operations Manager (SCOM) or Symantec's Software Deployment Agent, there is a natural synergy in evaluating the product from each vendor's portfolio. Why? Because it will not require the installation of an additional agent to support automated patch management activities on target PCs. Meanwhile, if an organization is choosing a standalone automated patch management product, it should be sure to test integration of that software with its other IT software, including software distribution and malware protection solutions.

Weighing price vs. cost

Money is not everything, but certainly the financial aspects of automated patch management products will be an important consideration. Ensuring the product chosen is within the current capital budget for path management software, or is within an organization's expenses budget for software leases, is critical for success. Choosing software that is outside the company's budget, without securing approval in advance, is a surefire way for the project to sustain a serious black eye -- or perhaps to fail altogether. Be sure to consider both the direct costs (e.g. initial licensing costs, implementation costs -- including vendor-provided professional services, if necessary -- and ongoing maintenance costs), but also any indirect costs involved (e.g., additional training for the internal help desk to support and troubleshoot ongoing patch management activities). IT and company management expect that all procurements are completed in a timely manner and within foreseeable budget constraints.

Trial and error: Trying before buying

The best way to learn about specific automated patch management products is by working with them in a test or sandbox environment. Recognizing that IT pros like to see in order to believe, most patch management vendors will gladly offer a trial period of their products. Note time restrictions to the trial period and be sure to have a repeatable testing procedure defined and approved by stakeholders before the trial period starts. Organizations cannot afford to waste time on a shifting or incomplete set of test criteria during a trial evaluation period. Be sure that the trail period includes a fully-functional version of the software. Software vendors who will not allow organizations to conduct a hands-on test should be eliminated from consideration.

As part of any trial or hands-on test of automated patch management products, be sure to include testing and evaluating the effectiveness of vendor support processes and personnel. Even if an organization is engaged in a short-term hands-on trial, it should still contact the vendor's support personnel by phone, email or chat session. If it doesn't have any actual support issues that need resolution, ask basic operational questions as well as questions about more advanced functionality. Patch management support processes should be clear, timely and accurate in order to pass muster during the hands-on evaluation testing phase.

Ranking and filing: Sandboxing

Once an organization has completed various software evaluations, requirements matrices and budget estimates, it's time for a hands-on evaluation of the top two or three contenders. In some situations, such as when anticipating using the patch management component of a larger software platform such as Microsoft SCOM, an organization might initially perform a hands-on test of only that software package, due to financial and/or operational advantages. But no matter how confident it is that a specific software product is right for the company, always be sure to test candidate(s) in a test bed environment.

With cheap, on-demand cloud hosting from the likes of Rackspace, Amazon Web Services and Microsoft Azure, there is simply no excuse for not testing automated patch management products before purchase. Another possible way to test patch management may be via an organization's disaster recovery (DR) or data protection service or software.

Many online data protection and DR products now support a temporary restoration of virtual machines and networks in an isolated sandbox. Organizations may be able to leverage this sandbox feature to test its patch management candidates in an environment that will very closely match its production environment. Plus, it can usually quickly initiate this sandbox environment from within its DR or data protection software with nothing more than a few mouse clicks.

Automated patch management products: Evaluate and purchase

The evaluation and purchasing process for automated patch management products should be a chartered IT project, including appropriate financial, technical and human resources to appropriately and effectively evaluate product candidates. The end-goal of this purchasing process should result in an implementation that meets all relevant requirements, while also respecting ongoing budget constraints and stakeholder expectations.

Sticking to an organization's existing internal IT project management guidelines and processes ensures that it will succeed in its search for automated patch management nirvana. We define patch nirvana to be a (mostly) self-sufficient tool that ensures all applicable patches on applicable systems are up to date without requiring daily intervention and management from the IT pro responsible for patching. For instance, receiving, distributing and installing routine monthly Microsoft operating system and application patches via their so-called Patch Tuesday should be a process that can be automated with a minimum amount of administrative intervention.

Next Steps

In part 1 of this series, learn about the basics of automated patch management software in the enterprise

In part 2 of this series, find out what the business cases for automated patch management products are

Take a walk through the six steps for security patch management best practices

This was last published in October 2015

Dig Deeper on Microsoft Patch Tuesday and patch management

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What are the main criteria your organization is looking for in an automated patch management tool?
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close