Dealing with the challenges of patch management [Q&A]
Patching is an essential part of keeping systems secure and it has been for almost as long as computers have existed.
Why then is it something that many organizations still seem to struggle with? We talked to Tom Bridge, principal product manager at JumpCloud to find out and to learn how companies can get to grips with patch management.
BN: Why is patching still a problem?
TB: The biggest problem around patching is that it is dull. It's a thankless and repetitive task that has to be taken very seriously, and we don't tend to like those kinds of problems. However, getting patching right can have a huge impact on how well we keep users secure, and how efficiently we manage IT over time.
BN: What issues come up around patching?
TB: The first issue is when companies don't have an accurate list of what they have to keep updated. Either the complete inventory does not exist, or it's owned by several different teams in an organization and things fall through the cracks. Making sure that you can see everything you have ahead of time is therefore step one to improving.
The second issue is that many organizations today have a multi-OS environments. This is increasingly common with remote working when companies give employees the flexibility to choose either a Mac or Windows device to allow them to work efficiently and effectively. Managing Windows, Mac and mobile devices is done best when it’s done from one place, rather than from separate tools.
Gathering the data and reports across an entire infrastructure and device fleet is not an easy task. This places additional pressure on IT and requires significant time and effort to manually gather the data. This can adversely affect IT's productivity. Incidentally, IT is usually given the task with no additional help from anyone or any other department within the organization. This can make it harder, and move it down the to do list.
Lastly, there is the process itself. Do you test all the patches coming in to check that they work, and that there are no issues in them? It's not unknown for the patches themselves to have issues that can break other software, for example. How do you manage that roll-out, and how do you ensure that all those patches get deployed effectively too? How do you build out an approach that is repeatable? How do you make sure that a problematic patch is tested and cleared?
BN: How can teams improve their patching approach?
TB: The first step to improve patching is to look at how you manage those updates in one place, rather than carrying out manual work to collate data. Consolidating your approach helps your team be more efficient, particularly if you have to support both Windows and Mac machines.
The second step is to look at how you prioritize your patches based on risk. This means looking at potential security problems, but also how much impact the patch would have on users if it has to be rolled back. For the majority of patches, rolling these out faster can be achieved through automation, but you should have that roll back plan in place just in case. The biggest improvements here can be delivered by helping sysadmins understand how much impact a patch might have, and how much their change management process will be needed.
The third step is around the users -- how can you see who has updated, and who still needs help or support? You can improve this by setting up more specific windows for patches to be installed, and by stopping users from continually putting those updates off. This relies on having accurate data and reports available.
BN: How much of a risk is there around software vulnerabilities?
TB: In the last year, security researchers found more than 20,000 software vulnerabilities, ranging from critical severity faults that affected millions through to annoying issues in niche projects. In total, more than 166,000 issues have been detected since 1999 according to CVE Details.
The US Department of Homeland Security Binding Operational Directive 22-01 released research on the risks of security vulnerabilities getting attacked -- four percent of these issues, around 6657 vulnerabilities, have been targeted by attackers over time. 50 percent of these vulnerabilities were targeted within two days of being announced, which shows how quickly exploits can be put together.
The DHS guidance is to patch critical issues within 15 days, while the UK's new Cyber Essentials security framework calls for patches rated as critical and high severity to be deployed within 14 days. According to research from Ponemon Institute, it takes around 43 days to patch vulnerabilities on average. That figure covers all patches, so the time to deal with lower severity vulnerabilities will be included alongside the critical ones, but it shows that patching as a whole needs more attention.
BN: What other challenges are there around patch management, and how can it tie into wider IT management problems?
TB: Getting status updates on patching is another challenge for many teams. For instance, you may want to tell at a glance if your targeted patches are being successfully applied and any problems that have come up. Should there be a failure to deploy, you need to drill down on the problem and get the troubleshooting information so that you can resolve the task quickly.
This can help show up any wider issues around IT services and change management too. This can help sysadmins and service desk staff to be more efficient, but also improve how they support the business. Getting patching right is not just about improving security and risk management -- it's about freeing up time to deliver services as a team, and making IT that effective partner to the business. Consolidating processes and making it easier to deploy services fits nicely alongside the other common IT tasks that sysadmins have to consider like security and identity management.