Let’s face it, all software eventually has vulnerabilities, it always has and always will. No matter how good developers are at writing software, there will inevitably be mistakes, and there will continue to be threat actors looking to exploit those vulnerabilities. The need for patching software vulnerabilities, aka effective patch management, is never going away and continues to become more complex as we deploy solutions with increased functionality to a growing, distributed workforce.
Let’s dive deeper into the importance of proactive patch management and the risks of missing patches.
What is patch management?
Patch management is the process for identifying, acquiring, installing, and verifying patches for products systems and features. Patches correct security and functionality problems in software and firmware.
Why is patch management so critical?
When we look at how government agencies are breached, the attack vector is typical because they are running out of date or unpatched software that threat actors exploit. Whether malware is phished in, distributed online, or a server is targeted, the adversary is taking advantage of vulnerable software.
A single missed patch can wreak havoc on an organization; there is no better example than the 2017 Equifax breach. On Wednesday, September 13, Equifax acknowledged that a patch for the Apache Struts CVE-2017-5638 vulnerability—the culprit—was available in March, well before the attacks began. However, Equifax had not updated the vulnerable software at the time of the breach more than two months later.
This single missed patch led to one of the largest data heists in history and resulted in the loss of 143 million American’s data, the theft of over 200,000 credit card accounts, and cost Equifax over $600 million in fines, not including the tremendous haircut in the equity markets and lost consumer confidence in the company. Something as simple as applying a basic patch almost destroyed one of the largest credit ratings companies in the world.
Let’s also not forget the compliance risk of not patching. Every compliance framework and regulation includes a requirement to ensure security patches are applied promptly; the risk of not meeting this requirement can destroy an organization’s compliance status and result in significant financial penalties. Yet, we continue to see organizations fail in such a fundamental area because they don’t implement robust patching solutions and processes.
The complexities of modern patch management
Patching, for the most part, used to be fairly easy. Government agencies would push out updates monthly with Group Policy to desktops and laptops connected to the agency network or VPN. That has changed significantly as the workforce has adopted a diverse set of hardware, software, operating systems, mobile devices and shifted many employees to remote or hybrid work models.
Users now may never actually connect to the agency network or VPN, and their technology may not even interoperate with Active Directory. This ambiguity creates a complex dilemma for system admins and support teams responsible for keeping devices up to date with the latest patches and are required to do this before attackers can exploit unpatched software.
So how can we address this challenge and keep software current and patched when vulnerabilities are released so often? Let’s walk through some essential best practices.
Best practices for approaching patch management
1. Identify and inventory your systems and network
A network is only as strong as its weakest link, whether you’re considering security, stability, or functionality. In other words, it takes only one unpatched computer to make the entire network vulnerable. Therefore, patch management is about bringing the entire network — every computer and device, including unmanaged or rogue devices — up to an acceptable state. To do so, you have to start by knowing exactly what’s on your network. The lack of visibility or lack of awareness of dangerous blind spots can leave poorly managed assets completely vulnerable to attack, undermining even the best attempts to ensure standard adherence to security policies.
2. Scan systems to identify non-compliant, unpatched and vulnerable systems
Scanning computers and assessing their patch status isn’t a one-time activity that you do to find out what’s on your network; it’s an ongoing activity and an essential part of patch management. The idea here is straightforward: once you have an effective patch management process in place, it should be automated. Periodic scans and patch assessments help you identify computers where automated patch management isn’t working so that you can manually address those computers and correct the problem. The purpose of a regular process of scanning and assessment is to focus your attention where it’s needed, minimizing wasted effort.
3. Prioritize and use a phased approach for patches
Not every patch needs to be treated the same. Critical patches may need to be pushed out immediately to computers that are more sensitive to whatever problem the patch addresses. Less critical patches might be able to wait for a regular maintenance period. Some critical patches might apply only to specific servers or departments; others might need to be quickly pushed out to the entire government agency.
4. Conduct phased patch releases via a policy-driven targeting system
Centrally controlled, top-level policies define target populations, enabling the IT team to be in control at all times. This makes it easier to plan schedules, user communications and other aspects of the overall patch management process.
5. Deploy patches immediately
It’s often asked how quickly systems should be patched. This used to be an easy answer of monthly or even quarterly. However, over the years, we have seen a dramatic compression of time between a release of a vulnerability/patch to attempted system compromise or public exploit. Previously, we expected to have weeks to months before exploitation occurred; that time has now shrunk to mere hours, which further adds to the burden of deploying patches.
It is recommended that patches be deployed almost immediately or as quickly as possible, especially for systems exposed to the internet. While testing of patches is still required for most environments, we must always weigh the risk of how much testing should be done vs. the risk that the system poses in an unpatched state. When hours matter, we cannot wait days or weeks to deploy a patch to a highly critical system sitting out on the internet. A quality patching system enables you to quickly deploy patches to your test groups and immediately pivot to production once you are satisfied that the patches operate as expected.
6. Test patches before releasing them
Roll out patches first to trusted users, like members of the IT team or users who’ve volunteered. That way, technologically proficient users act as part of the patch testing phase since they’re better equipped to deal with patch-related problems and communicate them to IT for resolution. Later phases can target the significant user populations in the organization. This best practice helps identify issues with patches, ensures that adverse events don’t happen and validates that a patch is successfully applied. Failure to test patches before implementation can lead to disastrous consequences and leave government agencies vulnerable to attack.
7. Patch with user experience in mind
Users who don’t realize a patch is coming might be very surprised and frustrated when their computer abruptly restarts in the middle of the workday. A good user experience gives users some control over the patching process. Set deadlines that define when a patch must be installed but allow users to postpone the installation up to that deadline—or to opt to conduct the installation right away. For example, end users, particularly remote and mobile users with limited time on the actual network, can prioritize their work using now/later/snooze options for patches requiring reboots.