Five steps to an easier patch management process

Patching your systems isn’t something that the average IT admin wants to do. It’s a dull task, and it risks disrupting IT services and causing trouble. It’s also one of the most effective, government-mandated ways to stop intruders getting into your infrastructure. So if you haven’t already, it’s time to step up, take your medicine and hold your nose… and get your patch management process under control.

Statistics suggest that many companies haven’t patched their software properly for a long time. In its 2016 Cyber Risk report, HPE revealed that the top 10 vulnerabilities exploited by attackers were over a year old (and almost half of them were five years older or more). This tells us that there are plenty of unpatched products languishing on desktops and servers today, broadening the attack surface substantially.

Patch management best practices

Those products aren’t just core Microsoft ones, either. It’s easy to take a high-level approach to security patch management, relying on Microsoft’s patch Tuesday and calling the job done. The reality is more complex. At the time of writing, NIST’s National Vulnerability Database shows 4,315 vulnerabilities in total between January and September 2016. Just 367 (8.5%) of those were Windows vulnerabilities, while slightly more were vulnerabilities in Adobe products. Oracle products accounted for 520 (12%) of the total. If you’re using a multi-vendor application portfolio, there will probably be many holes to seal.

So, how can you manage this rats’ nest of software patches effectively, when dealing with limited resources? Here are five steps to bring your security patch management up to speed, and keep it there.

1/ Evaluate your portfolio

You won’t be able to do much without a solid software inventory first, so that you know what you’re dealing with. Using decent IT asset management software to discover and baseline your installed software is crucial (and it will also help you with license compliance).

Once you understand what you have, build a list of open issues that require patching. Vulnerability assessment software can help here by identifying relevant vulnerabilities in its own list or in the NVD.

2/ Prioritize your patches

IT admins/technicians probably won’t be able to patch all of these things at once, because patches typically have an impact on the IT resources involved and may even involve a system restart. Prioritizing patches to deal with the critical vulnerabilities first can at least mitigate the largest risks and set you up to deal with the smaller risks over time.

Another overhead to consider when patching software is the effect of the patch on the target application and on other systems that it interacts with. The dangers here are real. Microsoft has brought Azure to its knees in the past by failing to follow adequate patching procedures.

In an ideal world, administrators will test patches to identify any adverse effects before deploying them. Virtualized systems can make the testing process a little easier.

3/ Create consistency

Once you’ve tested your patches, ensure that they’re rolled out consistently via a single channel. This can be harder than it looks. In an unrestricted IT infrastructure, patches can be deployed by specialist patch management servers, or by update functions within a vendor’s own product. Users can pull down patches independently, or attempt to block deployment on their machines.

IT departments need to set and enforce policies that keep everyone on the same page. Consistency is key here to avoid the installation of untested patches or partial deployment across your infrastructure. Lock down users’ ability to tamper with their systems, via Group Policy settings or your operating system’s equivalent.

4/ Cover everything

Patching your modern servers and desktops is only the start. There are other systems to patch, including mobile devices, embedded systems and legacy systems. Each of these may have to be dealt with in a separate way.

Application and operating system versioning for mobile users may need to be managed with an enterprise mobile management server, for example, while embedded and legacy equipment may need manual management, or at best a series of custom scripts. This may incur a productivity overhead, which also makes them prime targets for attackers looking for an overlooked way into a network.

5/ Formalize the process

Once IT administrators have brought their software patching up to speed, they can use the same formalized processes to move forward with a consistent and regular patching process that is part of a broader change management strategy. Checking regularly for vulnerabilities and patches to fix them should be a standard process for any competent IT or information security team. Vendors often tend to try and make this easier for companies by rolling up patches into bundles, often released at regular intervals. The earlier that you apply these patches – and protect your users – the better.