As reported software vulnerabilities are reaching record levels, IT teams are grappling with the ongoing grind of keeping endpoints patched and up-to-date. Recent reports detail that while some attacks rely on newly discovered exploits, 50 percent of attacks target vulnerabilities reported before 2017. The never-ending cycle of discovered exploits and the ongoing time, resources and employee hours used to deploy patches to devices places a considerable burden on staff aiming to enhance organizational security. Automated patch management would free up team members to focus on more critical vulnerabilities, but organizations may find that getting to that point may be a bit more challenging than expected.
So what are common barriers to success and what do organizations need to do have in place to effectively implement automated patch management?
Barriers to automated patch management
1. Organizations get in their own way
Unfortunately, organizations can be their own worst enemies when it comes to getting automated patch management in place. Every organization has its own individual culture and way of executing initiatives. Of course, some processes require checks and balances, but sometimes businesses get in their own way of efficiency and productivity.
In the example of patch management, there’s often a significant gap between when a patch update is released versus when it’s applied to endpoints in an environment. That gap to patch in some organizations can unfortunately span months or even years simply due to internal factors like approvals or navigating exceptions. If organizations are willing to take a hard look at their current processes when it comes to patching, automating their patch management will be a much easier task.
2. Poor IT hygiene
The very base assumption when it comes to handling patch management is that organizations will have the ability to update endpoints on some sort of recurring basis. Perhaps lower-level patches are tested and issued on a weekly, bi-weekly or monthly basis, while higher-level patches are deployed on a more ad-hoc timeframe. However, this assumption is based on the idea that companies have the infrastructure and controls in place to fully handle their endpoints.
Companies without inventory and asset management entirely are on the brink of breach. Organizations with inventory and asset management tools but poor inventory control are almost as vulnerable as companies without inventory and asset management entirely.
For example, consider a user who needs to have a laptop replaced. They ask to hang on to the old device for a week or two to make sure all files are transferred over. Without good inventory control, that week or two turns into months, and then somehow that laptop gets back on the network, unpatched and vulnerable. It’s incredibly difficult to make sure patches are implemented if basic IT hygiene isn’t a common practice in the organization.
3. Team members have more involved roles
The role of IT admins has shifted. They not only need to make sure critical technology is maintained to keep the business running and make sure endpoints are patched. IT admins are now being pulled into more business-centric planning and strategy conversations.
While it’s great that stakeholders are reaching across the aisle to get teams more involved, the expanding role of the IT team can lead to teams being stuck in a reactive mode, becoming under-resourced and patching can suffer as a result. Putting automated patch management in place to at least execute in a relatively seamless manner takes tasks off the to-do list and frees up the team to focus on more business-centric initiatives.
4. No plans to address unsupported technology
Beyond not having a clear picture of the inventory deployed across an organization, another barrier to automated patch management is having no plans to address outdated or unsupported systems. Firmware updates, operating system updates, applications, databases, all need to be accounted for and have an update strategy at each level. Outdated applications, outdated systems, devices that have outlived support contracts, and systems that are no longer vendor-supported must be examined. Teams must have tough conversations across the business with stakeholders to address these gaps and develop plans to refresh systems and get something in place that is able to be patched and updated.
5. Patch fatigue
Patch Tuesday is a faithful standby across IT departments. However, patching can often feel like an endless cycle of reactive prioritization, testing, and deployment. With an ever-growing number of updates to deploy it can be overwhelming. If everything is deemed a priority, nothing is a priority. Teams should examine what about the patch management process is burning them out, because if it’s a repeatable process it is ripe for automation.
Components needed for automated patch management and deployment
1. Effective inventory management
One unpatched device can expose an entire network. To have a chance at automating any part of a patch management process requires having visibility into all endpoints, and plans to address outdated or unsupported systems. Lack of visibility leaves organizations vulnerable and hinders security and any automation attempts.
2. Understand that automation must start with a mapped process
Automation can start on paper. Any sustainable and repeatable processes are a great starting point for effective automation. When IT departments zoom out and take a big picture look at their tools, current processes, policies and technology, they can start putting together a roadmap to enable automated patching. Can the team schedule things? How frequently are we able to schedule these updates? Can we make sure that when an event executes, we don’t have to repeatedly rebuild parts of the process? Can we build upon past work? Are we able to use libraries and other components we’ve used before? Can we put something in place that just goes and does a task effectively?
Making moves to answer these questions puts organizations on a path to achieve automated patch management.
3. Identify opportunities to proactively keep devices and applications updated
If you have an inventory of your entire technology stack including firmware, operating systems, virtual machines, containers, devices etc., teams should look for conflicts and dependencies, but also make note of potential areas to proactively keep endpoints and applications updated.
4. Patch prioritization standards
Many patch management best practices talk about prioritizing the patches that need to be issued. In theory, prioritizing the patches and updates to deploy makes sense. In practice, it can be a much bigger ask for teams to execute.
For example, some organizations are required by regulation to apply critical security patches within a particular time frame. Adhering to this compliance framework is a non-starter for businesses, and hopefully teams operate within that time frame to maintain compliance. Organizations can’t take 30 or 60 days beyond the regulation time frame to implement those patches. Without some sort of established prioritization around which patches must be issued immediately versus the ones that need tested or are lower priority, teams can find themselves in a situation where everything is a priority, therefore nothing is a priority.
Teams that identify and establish categories of patches that can be issued on a more automated basis lay the groundwork for successful automated patch management.
5. Identify potential points of failure
For teams looking to automate their patch management process, it’s important to consider potential points of failure. If there is going to be failure somewhere, where do we estimate it will be, and what’s the plan if something does go wrong? Instead of spending time on investigation, an idea of potential failure points allows teams to respond or at least react with a plan if things go wrong. A plan for rollbacks if needed is crucial.
Patch, secure, and manage every endpoint
6. Documentation and validation
While having automated patch management is great, checks and balances are key. Documentation and insights into what will happen and reports related to what did happen are crucial to establish trust and accountability in automated systems. If stakeholders have questions about what happened in a particular update, that documentation helps to provide context.
7. Advocacy for automation needs to come from across the team
The actions team members can take to get automated patch management in place will look different across roles. CIOs must communicate with upper management to reinforce that it’s about investing in protecting and preventing against organizational breaches. They should also look at current policy, at procedures, make sure infrastructure is in a good spot and that resources and budget are allocated effectively. Directors can help pave the way for cross-department communications to make sure necessary patches don’t disrupt the work of other departments. Admins can be much more tactical and dig into the particulars around what is realistic and able to be automated.
8. Security training for employees
An automated patch management process may involve issuing patches automatically across wide swaths of an organization. Though the topic of keeping devices up-to-date is commonly mentioned, it may not be a cultural workplace norm. Taking steps to make that a cultural workplace norm makes it much easier to issue patches in the future, and a much easier task to keep an organization secured.
Conclusion
Patch management in general is an investment in protection and prevention against potential breaches. The sheer number of updates needed can be overwhelming, and a drag on team time and resources. In a complicated landscape of updates, patches, devices and competing priorities, an automated patch management process is a powerful tool that helps to secure endpoints while freeing up IT resources and bandwidth.
