An old IT adage states, "failing to plan is planning to fail." An organization's patch management project should be just that: a chartered and sponsored IT plan. It is critical that the process of buying patch management tools be managed to ensure all pertinent IT processes, requirements, rules and guidelines are observed throughout.
There are steps to effectively evaluate and procure patch management software for an organization. As with any IT project, it's strongly recommended that the evaluation process follow established IT project management techniques, including the appointment of a project manager, project sponsor and the inclusion of all stakeholders, both internal and external. By following existing project management processes, organizations can ensure that all the relevant aspects of the patch management tools under consideration are properly evaluated.
Know the key players
One of the first steps in assessing patch management tools is to identify the relevant stakeholders, which can include end users, IT management, e-commerce partners and line-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 controls that define appropriate automated patch management services. Once you have identified the stakeholders for the patch management project, be sure to include them in all future project communication updates and stage checks.
Define patch management product requirements
After an organization has identified stakeholders, it is time to begin the process of gathering requirements for those stakeholders. The collection, verification and ranking of automated patch management product requirements can create an objective foundation that can serve the organization well for the duration of the evaluation and procurement project.
Always utilize a project requirements list, as per another old IT adage: "You can't manage what you can't measure."
A requirements list ensures that all foreseeable useful features and functions are included in whichever automated patch management products the organization procures. The requirements list should include items that are marked mandatory, some that are nice to have and some that are jettisoned from the project as not applicable, out of scope, out of budget or not feasible. Don't forget to include any financial requirements on the list, such as the total acquisition budget, plus yearly maintenance and support costs.
If an organization has spent the appropriate amount of time and effort building a requirements list, gauging functionality of the top candidates can be as easy as checking off processes and features on a spreadsheet. Do not take vendor performance, features and functionality claims at face value. 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 a tool is 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 tools readily and easily integrate 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 is to utilize the patch management features of that tool because the integration work is already done, and it likely uses the same agent that is already deployed.
- Support for all applicable platforms -- current and future -- Be sure the product you choose addresses all your current IT infrastructure platforms, including hardware, operating systems and applications. Also, choose a product that can adapt to needs that aren't currently in use, but that are on the organization's IT roadmap, including support for tablets and mobile devices that might be used 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 addresses your 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 a well-defined test plan in place to verify all of the critical operations, compatibility and functionality. If the product doesn't meet or exceed the stated 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 human and computer performance -- End users and server admins generally won't accept any tool that adversely affects their ability to do their job in a timely fashion. Ensure your patch management product of choice performs well on all of the platforms in the company without a noticeable performance impact on production or end-user systems. Does it run in the background? Can the end user temporarily postpone installation of a patch, if needed? Can the patch process run unattended, without the need for any user interaction? Can the chosen solution automatically postpone the installation of patches when it detects that 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, their reference accounts or through POC testing.
- Software support -- Does the patch management vendor offer 24/7 tech support that is both accessible and accurate so they can solve problems quickly and efficiently? Always call a vendor's tech support line -- not the vendor sales engineer assigned to POC testing -- as part of the POC to ensure its 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 tools, organizations may also need to ensure the solutions under consideration interoperate or integrate with other products already running in their IT environment. For instance, if Microsoft's System Center Operations Manager (SCOM) or Symantec's Software Deployment Agent is already in use, there is a natural synergy in evaluating the patch management tool from each vendor's product portfolio. Why? Because it doesn't require the installation of an additional agent to support automated patch management activities on target PCs.
Meanwhile, if an organization is choosing a stand-alone, 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 that usually require that their own agents be installed.
Weighing price vs. cost
Money is not everything, but certainly, the financial aspects of automated patch management tools are important considerations. Ensuring the product chosen is within the current capital expenditure budget for patch management software purchases, or is within an organization's operational expenditure 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 to perhaps fail altogether.
Be sure to consider both the direct costs (e.g., initial licensing costs, admin training 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 and implementations be 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 tools 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 gladly offer free trial period installations of their products. Note any time restrictions on 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 trial period includes a fully functional version of the software. Software vendors who do not allow you to conduct a full-function, hands-on test in your sandbox should be eliminated from consideration.
Ranking and filing: Sandboxing
Once an organization has completed all the software evaluations, requirements matrices and licensing 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 suite, due to the financial or operational advantages of utilizing a solution that is already running in house. But no matter how confident you are that a specific software product is right for your 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 tools before purchase. Another possible way to test patch management is through an organization's disaster recovery (DR) or data protection service or software, whether cloud-based or physical.
Many online DR and data protection 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 their patch management candidates in an environment that very closely resembles 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.
As part of any trial or hands-on test of automated patch management tools, evaluate 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 you don't have any actual support issues that need resolution, ask basic operational questions, as well as questions about more advanced functionality. Patch management software support processes should be clear, timely, available 24/7 and should provide accurate assistance in order to pass muster during the hands-on evaluation testing phase.
Automated patch management tools: Evaluate and purchase
The end goal of this purchasing process should be an implementation of a patch management tool that meets all relevant requirements, while also respecting ongoing budget constraints and stakeholder expectations.
Adhering to an organization's existing internal IT project management guidelines and processes ensures success in the 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 pros managing the patch process. For instance, receiving, testing, distributing and installing routine monthly Microsoft operating system and application patches through Patch Tuesday should be a process that is automated, with a minimum amount of administrative intervention.
Following these common sense guidelines can ensure that the product that is deployed meets all the organizational, governance, operational and budget requirements identified at the outset.
Know the business cases for patch management tools
See how organized crime attacks new technology
Don't believe these patching myths