From time to time, IT companies that produce complicated applications and operating systems need to update the code to quickly address a problem in the application. With issues such as a security vulnerability, software incompatibility or code bug most application developers cannot wait to roll out a full updated release version of the application. In the IT world, small fixes are called “patches”. Like the real-world, IT patches tend to operate as a stop-gap to a particular issue, but may not be a seamless fit with the rest of the application. That’s where patch management comes in. Patch management is the systematic testing and control of software patches in an organization’s IT environment. Patch management consists of five main activities:
Research: At a minimum, when an organization is considering whether to install a patch on a system, the organization should understand the issue(s) the patch is trying to address. They also need to be aware of any potential documented effects the patch may have on the operating environment. Moreover, while most software companies will automatically push out their patches or notifications to registered users, some developers either do not track their user base as carefully. Other companies may not have a fully developed system of patch notification and distribution. All these cases require thorough research to help an organization decide if installing a patch is absolutely necessary (corrects a critical functionality or security flaw that cannot be resolved by other means), desirable (addresses an issue that may be resolved through other, more cumbersome means), neutral , or undesirable (using the patch is more problematic than the the issues resolved by the patch).
Testing: Patch Management includes testing the patch in a controlled environment is an important second step. In many cases, patches are designed to address a critical flaw. But, the high speed of development and rush to release means the patch may not have been fully tested by the developer. Therefore, the patch may contain unknown side effects to an operating environment. Even known side effects may be omitted from the documentation. Therefore, whenever possible, testing is critical. A good test regimen determines that the patch repairs or enhances the functionality it is intended for, does not create new security vulnerabilities in the IT environment, can be reliably deployed within an organization, and is worth the trouble that deployment would take. The test should also document what environmental settings may require readjustment and possible beneficial side effects of installing the patch. The desirability of installing a patch may improve or degrade based on the test results.
Deployment: Once an organization makes the decision to proceed with a patch installation, good management of the process is crucial. The main considerations are: scheduling patch installation to minimize its impact on IT operations and ensuring patch installation on remote disconnectable devices (such as laptops). In most cases, a patch should be deployed throughout the system. Occasionally the testing may reveal that a patch deployment should not extend to a specific class of device or some parts of a mixed operating environment. Also important is a good communication plan. The plan should tell users when the patch will be installed, what changes, if any, to expect from the post-patch system, and who to report any issues to follow the patch installation. Note that for users, it is important to communicate items even as trivial as “users will need to re-login to the system following the patch installation. Otherwise, users will inundate the patch manager with calls about “abnormalities”.
Verification: Even testing does not catch all the effects of patch installation. Therefore, administrators should carefully monitor the IT environment after deploying the patch. In some cases, environments using Next-Gen Endpoint Protection may receive a number of environmental warnings as the AI adjusts to the new “normal”. To complete patch management system verification, the IT staff should proactively confirm with users that their systems function normally, to the best of their knowledge. Only then may the organization consider the patch fully and successfully implemented.
Documentation: IT professionals should thoroughly document every patch they install into a system. The documentation should cover all the other activities and is best performed alongside each other activity. If an organization decides not to install a patch, the documentation should include the rationale for that decision. This rationale is particularly important for patches designed to reduce a security vulnerability. In this case, staff should report what workaround adjustments, if any, were made to the environment to mitigate the vulnerability. In the interest of IT professionalism, it is good practice to forward documentation of anticipated side effects and any installation difficulties to the patch manufacturer. This information will permit the manufacturer to improve the company’s patch documentation.
ETTE uses a rigorous process that addresses the important considerations for patch management and installation to your organization’s IT systems and applications. Remember that the thorough process above must be repeated each time you consider a patch. For application-heavy or high-security IT environments, the patch management process may occur weekly. For major manufacturers such as Microsoft, ETTE has a process to carefully review ongoing technical bulletins. These bulletins come out with patches, but also just for recommended settings adjustments to optimize and secure network systems. With midsize firms that produce applications such as database and directory programs, ETTE provides enhanced patch management by applying experience gained throughout our client base, for the benefit of all. For boutique software providers, ETTE’s testing environment can uncover operating issues that these smaller firms often miss in the rush to develop a patch. Finally, ETTE can apply patch management principles on either an ad-hoc or ongoing basis for proprietary software and applications developed internally. Contact ETTE to find out more about how we do it, how we can help you.