How do you manage third-party application and plugin patches?

Having a great patch management is critical to securely running your company especially when it comes to dealing with 3rd party applications as your enterprise patching most likely wont cover it. For example: Most companies focus on diligently applying MS Security patches that are released on monthly basis but may not have the right systems in place to search and patch 3rd party applications such as ERP or middleware running within the company. Onus for patching 3P applications will be on the group who hosts those applications such as HR or Finance or Legal departments. So, the IT folks in those departments shall have a well defined strategy in-place to identify and apply the appropriate patches to keep the applications secure.

In order to manage third-party applications and plugin patches, one must keep an exhaustive inventory of all installed software, regularly check vendor websites and security advisories for patches, prioritize patches according to severity and impact, set up a testing environment for assessment, use automated patch management tools for efficient deployment, and enhance overall system security by combining patching efforts with extra security measures like network segmentation and access controls.

Managing third-party application and plugin patches involves establishing a comprehensive patch management process. Start by maintaining an inventory of all third-party applications and plugins used within the IT environment. Regularly monitor vendor websites, mailing lists, and security advisories to stay informed about available patches and updates. Prioritize patches based on severity and potential impact on system security and functionality. Test patches in a controlled environment before deploying them to production systems to mitigate the risk of compatibility issues or unintended consequences. Automate patch deployment where possible and ensure timely implementation to minimize the window of vulnerability to known exploits

Managing patch requirement requires IT teams to strike a fine balance between system security and resource allocation. Wouldn't it be great to keep all systems up-to-date all the time but think of these - 1. Resource Allocation: Applying patches demands time, effort, and financial investment involved with identifying, planning, testing and applying these changes. 2. User Impact: Frequent changes due to patching can disrupt user workflows and cause downtime for applications. As the saying goes, “There are no solutions, only trade-offs.” Deciding what to patch and when requires thoughtful consideration of risks, benefits, and operational realities which will be unique for each organization within the companies and their customers.

Few pointers on patch deployment for 3rd party applications: 1. Effective Communication: Communicate with end users to manage expectations during and after the change to avoid delays/escalations. 2. Testing: Thoroughly test patches in a prod-like environment, including unit, load, and integration tests for critical components. 3. Automation: Utilize tools like Ansible, AWS SSM, or shell scripts to automate patch deployment and reduce human errors. 4. Minimum to no Outage: Perform rolling patches as much as possible and leverage standby databases to minimize user impact during downtime. Avoid patching during your application's peak usage. 5. Rollback Strategy: Have a Go/No-Go strategy. Be prepared to rollback quickly if patching fails.

Focus on below points during communication about patching to create a bridge between confusion and clarity - 1. Call out Benefits. What's in it for them ? Will the application perform better, have new features or be more secure. 2. Call out any impacts to the application and the outage duration. Are there any alternatives for users during that time ? 3. Call out risks of not doing the patching. What will be at stake if you don't perform this patching. Could the code be remotely exploitable or a product version coming to end of support ? One thing which worked great in my past experience is having a monthly or yearly Events Calendar for planned maintenance activities so that you have a buy-in from leaders/stakeholders in advance.

Focus on these documents to have an efficient and continuously improving patching process: 1. Implementation document to ensure all team-members are aware of their exact role and steps to be performed during patching. 2. Create a run-book for your on-call to handle tickets during the deployment so that the core team won't have to field tickets. 3. Create a document for your IT Help-desk (if applicable) so that they can handle end-user calls accordingly and not panic if there is a planned outage due to patching. Finally, there should always be an issue document that documents as what issues came during or after patching and how were they resolved. This should be converted to action items during next round of patching.