Patch management is a fundamental part of IT security. Regularly patching your infrastructure and applications and keeping systems up to date is vital to vulnerability remediation.
Lack of regulated, cyclical patching events increases risk of hackers exploiting vulnerabilities and leaving systems compromised. Without proper tracking of patching efficacy through regular vulnerability scans and detailed reporting, it’s almost impossible to evaluate security levels. With non-structured patching practices, the business is more likely to receive unexpected or last-minute notices of patching-related downtime, which doesn’t help IT’s reputation.
The patching process tends to be unstructured in many companies, including large corporations with infrastructure hosting highly-critical systems. As cyberattacks increase, it’s even more crucial to have strong and proactive patch and vulnerability management programs with accurate reporting.
If IT coordinates the patching process well, communicates internally and with business customers, and performs activities in a controlled manner, it’s possible to successfully stack patching and reboot activities across multiple support teams into a consolidated time period—even a single weekend.
These are the three things to prioritize:
Hosting in-depth facilitated workshops with representation from each application and device support team is a great way to begin development of a complex patching process. General best practice is to standardize patching activities into a monthly schedule and stack as many reboots as possible to reduce application downtime. Create a detailed implementation plan with tasks, points of contact, support teams, and estimated timing.
Patching schedule considerations:
When workshopping the sequencing of tasks, the primary focus should be on identifying dependencies between activities. For example, X server needs to be down for Y application patching (certain batch jobs require completion before reboots can occur). Take advantage of any HA (high availability) capabilities that allow patching to occur without end user impact. The more investment going into HA and increasing redundancy, the easier it will be to consolidate patching activities into a singular time frame.
When scheduling patching events into a standardized time frame (i.e. bi-monthly), make sure to plan around key events such as month-end close or year-end close.
Complex patching schedules require several streams of communication. Newly implemented patching cycles require an extra level of care in distributing messages across the organization.
You can split communications for each cycle into three simple categories: what’s about to happen, what is happening, and what has happened.
What’s about to happen: Not only should IT be fully aware of scheduled patching activities, but the business should be alerted on applications that may be impacted and have methods to defer non-critical patches to avoid downtime. Top-down communication across the enterprise should emphasize the importance of patching systems, encourage support of IT’s patching program, and discourage deferrals. End-users should also be informed of impact on key processes (i.e. payment systems).
What is happening: Throughout patching events, regular updates on activity completion should be sent from a single source (one person or team) for consistent messaging. It’s important to note in these communications how far ahead or delayed activities are so teams can prepare to start at a different time than scheduled.
What has happened: After the implementation of a new patching process (hypercare period), ensure lessons learned or changes in the process are communicated. As a team, evaluate successes and failures to drive improvement across your environment’s architecture and design.
If you want to stack patching into a tight timeframe such as a singular weekend, there are a few things to plan for:
Coordination: There are a couple of different ways to coordinate patching events. If IT has a good change management system and typically tracks projects through change requests, the event could be coordinated by change tasks. This method is recommended only for developed processes where everyone is fully aware of their responsibilities. For newly implemented processes, it’s beneficial to have a singular coordinator (project manager) responsible for tracking progress, providing updates, paging out teams to begin tasks, leading a bridge call for issue resolution, and escalating issues to management.
Escalation: Strong patch management programs require a core team of individuals who are knowledgeable about the process and inner workings of the IT environment. During hypercare, at least one person from this group should be available to troubleshoot issues and provide guidance when systems are unexpectedly impacted. Support team leadership should also be available for escalation in case the primary POC is non-responsive.
Tracking: If you’re running a security-based patching process, tracking vulnerabilities from identification to resolution will help IT determine the efficacy of deployed patches. The vulnerability management process should feed into patching, but don’t underestimate the importance of continuing to track the targeted vulnerabilities after patch deployment.
At Trenegy, we help organizations develop efficient patch management programs to ensure IT stays predictable, reliable, secure, and cost-effective. Email us at info@trenegy.com to hear more.
