For some security professionals, patch management can be boiled down to the Nike slogan: Just Do It. But as anyone who has ever managed a network knows, patch management isn’t as simple as a catchphrase. This is not to say that there aren’t plenty of cases where patches for critical vulnerabilities could be easily applied and aren’t, but there are also valid reasons why a system or software can’t be patched such as the case of production systems that can’t be taken offline for any amount of time (e.g., in a healthcare environment). There’s also the case of legacy systems with dependencies that will break if a patch is applied. Moreover, there are cases of the patch itself introducing additional vulnerabilities which require the IT team to roll back the patch level. With all of this in mind, many notable data breaches can be attributed to a failure to patch. Equifax, WannaCry, the UK National Health Service—all of these breaches have unpatched systems as a root cause.
When organizations do not patch known vulnerabilities, they’re accepting risks—blatantly or tacitly. Just because risk exists doesn’t mean it has to be mitigated at all costs,¹ but it does mean that the people responsible must know or estimate and communicate the risks associated with either action or inaction. In the case of cybersecurity risks introduced because of patch management decisions, the business should be made aware that vulnerabilities in “X” system could result in “Y” being accessed remotely by an unauthorized party, data loss, denial of service, the introduction of malware, etc. Before any of this can happen, however, IT and security teams need better ways of tackling patch management. There are simply too many vulnerabilities reported and published for any organization to “just do it,” and an ad hoc or case-by-case method of handling patches will certainly result in missed critical patches, incorrectly applied patches, involuntary acceptance of unknown/unanticipated/unintentional risks, or worse.
Organizations need a better approach. As Dave Lewis, Advisory CISO at Duo Security, puts it, “companies need to learn how to patch better, patch smarter, and improve patching quality and ease.” The “how to” of managing an entire patch management program is out of scope for this blog post, but one thing that can definitely help IT and security teams wrap their arms around a patch management strategy is implementing a zero trust network.
The challenges of today’s networks
Organizations’ networks are no longer the onsite, internally managed, and flat architectures of the past. The introduction of cloud and virtual environments, bring-your-own-device (BYOD), distributed networks, and more have fundamentally changed the way IT and security teams must operate. Because patch management and other cybersecurity initiatives can affect the availability and reliability of today’s dynamic, auto-scaling networks, technology teams must devise better ways to address the problem head-on.
For as long as I have been around the security space, practitioners have been yelling from the rooftops, “Don’t keep everything in one place!” However, accomplishing network segmentation can be a difficult, lengthy, costly process. As a result, just as with patch management, segmentation (and the newer “microsegmentation”) has been pushed aside for more-easily accomplished tasks. In truth, when using historical or legacy processes and technologies, segmentation/microsegmentation can make even the most skilled networking professional want to pull their hair out. But segmentation can be an effective way to better manage business-critical systems and any necessary updates to those systems.
Enter zero trust
Zero trust flips traditional networking concepts on their heads. Instead of the “trust but verify” method of managing access to and on the corporate network, zero trust says that all traffic, users, applications, hosts, you name it, must be verified through a set of immutable attributes that create a “fingerprint” before being allowed to communicate. Additionally, when an app/process/user/etc. is verified, the trust granted only applies to that one connection; every time a communication is initiated on a zero trust network, the “what” trying to connect must be verified again to ensure that a threat actor hasn’t intercepted the communication, isn’t hiding inside approved controls, or hasn’t dropped malware onto the system.
So what does this have to do with patch management? In a zero trust network, all systems— servers, applications, databases, hosts, etc.—run on the principle of least-privileged access. Only systems/apps/etc. that require access to another system/app/etc. are automatically configured to send and receive communication from other network connections. In contrast, in a traditional network, up to 98% of the network consists of unused and unmanaged communication pathways. This means that both legitimate applications/services and malicious traffic can communicate over these pathways. But zero trust blocks anything unused or unnecessary, therefore reducing the scope of what can communicate. As a result, the probability of an exploit affecting an unpatched system is also reduced because fewer resources are talking to it.
Further, the fingerprints created for a zero trust network include product or device names, versions, and patch levels, which means that system administrators can be alerted on any patch management issues and make the best decision for the organization. For example, security teams could implement a policy that says, “If version 2.3 of Apache isn’t running 2.3.35 or 2.5.17, alert on a connection.” With that information in hand, the security team can make the decision to either segment the application until it’s fixed (which would likely only happen in extreme cases) or accept the risk of not applying the patch and explain why to the business.²
Patch management tools can obviously help organizations stay on top of what’s happening where throughout their diverse ecosystem of networks, but patch management tools cannot keep software from communicating if malware gets into the system before a patch has been applied or even developed. By isolating and containing critical assets in a zero trust network, organizations can identify an unpatched vulnerability before it is exploited. Furthermore, patch management can only help when a patch exists! For zero-day attacks and other unpatchable situations, such as those mentioned at the top of this post, organizations have to “design systems as if there’s always a zero-day and the patch is never coming,” writes Adrian Sanabria, Founder, Security Weekly Labs, in a blog post about the Apache Struts exploit. Zero trust networking accomplishes system hardening regardless of patch levels and gives organizations a smarter way to stay on top of patches that could prevent them from becoming the next Equifax. Zero trust provides the fine-grained control of a distributed network environment that security teams crave while allowing businesses to speed ahead without introducing unnecessary or unmanaged risks.
1. According to Kenna Security and Cyentia Institute, while 23% of published vulnerabilities have associated exploit code, less than 2% of published vulnerabilities have been exploited in the wild, making traditional remediation very inefficient, costly, and time-consuming.
2. It’s important to note that, per the Kenna/Cyentia “Prioritization to Prediction” report, predicting which reported CVEs will become exploits is challenging and will continue to pose problems, even in a zero trust environment. Further, some CVEs are exploited before they’re published, diminishing the effect of remediation by any means.
