Overcoming Patching Pitfalls (Virsec blog)
Patching is an incredibly important and vital component in IT, but perhaps we overestimate its ability to solve security problems. There’s often an assumption that if your IT team is not keeping up with patching it’s always going to be their fault when there is a vulnerability in your infrastructure. Let’s explore this thought process, discuss this model of security-by-patching, some of the limitations and weaknesses, and how Virsec tackles these challenges.
The Patching Conundrum
Software patches and updates are of paramount importance and they help to remedy vulnerability, bugs, malware, and other major issues. Currently, flaws in software are happening much more frequently, and patching is a way to keep everything up to date. So what’s the issue with patching?
We all remember the Equifax fiasco, where it was discovered that patching was not taking place on a particular server for months, and this ultimately became the culprit for the breach, as well as the IT team responsible for this vulnerability. While this wasn’t the only mistake that Equifax made, the idea that patching alone would have solved their problem is too simple-minded.
As we will discuss below, patching is often easier said than done. In fact, if there is a patching dilemma, less than half of organizations can patch quickly enough to defend against zero-day attacks. It’s an alarming statement that needs to be reevaluated. If that is the only solution, there must be a better way. The good news? Virsec can reduce urgency for patching and help bridge the gap between when exploits arrive.
Top 7 Problems with Patching
While simple in nature, most growing businesses struggle to identify critical patch updates, test and install patch releases to fix problems as they occur. For a medium to large organization, it takes about 102 days on average to patch. The main criticism that Equifax received was not patching the server within a couple months, but technically that is well within this window of time. Even with best practices carried out by competent organizations that are diligently deploying patches, it can take over three months. We know that patches can have unintended consequences, so let’s review some of the major complications that come with them.
1. Time Consuming
It takes hundreds of hours to patch endpoints, and if servers are restarted, the issue of the business downtimes arises.
2. Not Reliable
Many people think of patching as just Patch Tuesday with Microsoft, but there are hundreds of other applications that are running, and patches can vary in quality quite a bit. We know of customers that have experienced problems with Microsoft patches, and that is one of the most well-known companies. Unfortunately, other patches tend to be created very quickly, and are not tested thoroughly, which can create additional problems.
3. Bundled Tools
The two main tools, Java and Flash, are often bundled with other software, so it’s not always known which version is running. If a patch is found that needs to be deployed, you must first figure out which version is currently running, how you obtained it, and the correct patch to apply.
4. Structured Schedules vs Critical Fixes
Microsoft Patch Tuesday is a great idea, but other organizations hold their patching on other days and there always seems to be critical problems that arise where difficult decisions must be made. In the situation where an emergency patch is needed, but not able to be carried out, there are serious repercussions including disrupting business, creating breaches, and potentially causing even more problems.
5. Which Version Is Running?
An interesting challenge with code branching, that often happens with Microsoft and other products, is holding a long-term service branch when a current branch becomes available. You often must make tough decisions such as, do you want the minimum to patch problems, or are you interested in new features as well? Ultimately, this adds to the complexity of the problem.
6. No Desire to Deploy Every Patch
Most companies do not want to deploy every patch, and often only the more critical patches will be prioritized. This alone is tough to manage, and if certain patches are being deferred, they will be added to a waiting list to be addressed later.
7. Patching ≄ Vulnerability Management
Finally, it’s important to remember that patching is not equal to managing vulnerabilities. Even if all the correct patches are deployed, there are always new vulnerabilities, and that ultimately becomes the base for many of these challenges. Patching is a catch-up game, where you are always going to be starting from behind. By the time patching is finished, multiple new vulnerabilities have most likely appeared, and this presents a fundamental problem.
Exploding Vulnerabilities and The Dangers of Patching
One of the drivers behind the problem of playing catch-up with patching is the explosion of vulnerabilities. The eruption of numerous applications breeds more and more vulnerabilities. This remains a prominent issue, and in fact it was calculated by the National Vulnerability Database from NIST that there were over 25,000 verified vulnerabilities detected last year.
There is a process in identifying vulnerabilities and all are assigned a number as soon as they are detected, but on average only about 80% are verified. The list of vulnerabilities from NIST is incredibly daunting and is extremely tough to work through. This is a large-scale problem that’s difficult for even the most capable organizations to keep up with.
Patching is not just difficult, it’s often impossible. For example, the industrial control space, SCADA systems are a mixture of modern software and legacy equipment that’s designed to last 30 years or more. It goes without saying that software designed 30 years ago does not have the same level of security that modern software does, and it comes with the added challenge of legacy systems.
Legacy systems are not unique to the ICS environment, as many organizations, enterprises, and government agencies also have many legacy systems. Legacy systems by nature are difficult to patch and sometimes impossible. Patching these systems must be carefully planned out, including scheduled downtime.
Time Between Threats and Accompanying Patches
A threat is created long before it’s usually discovered. While everyone likes the term zero-day protection, it’s important to note that it can take weeks, months, or even years from when the threat was created and is likely being exploited.
If a vulnerability has been discovered, reported, and cataloged and contains malware, some of the anti-malware vendors might have the capability to deploy a signature within a week to ten days. If the same signature is used in the malware, there could be interim coverage. While that’s a step in the right direction, it certainly does not solve the broader problem. The exposure from a particular vulnerability can be exploited in many ways, not just through the known malware that can be identified with a signature. Which is how we inevitably reach well over 100 days dwell time.
Even with best case scenarios, on average it takes that long to deploy these patches, and this is happening with responsible, capable organizations. It’s easy to see how the window of exposure is enormous, and this isn’t even including the unidentified un-patchable applications, as well as fileless threats that exploit vulnerabilities even without going through traditional malware routes.
The risk exposure is dramatically larger than the area of coverage we currently experience now with conventional models. By the time patching has taken place, an organization is already most likely several thousand vulnerabilities behind.
Virsec’s Solution
Protecting Faster Limits Exposure
The Virsec Security Platform detects and stop attacks within milliseconds with no prior information, no tuning, and no signatures. Virsec’s unique AppMap® technology maps the expected performance of each application on a workload and protects the memory those applications use to execute. Virsec ensures that the components of those applications are correct and unmodified before they are allowed to execute. Any deviation from the norm is instantly detected, treated as a threat, and blocked.
Most conventional security tools are looking to stop all threats that might be coming in. This is an infinite problem – a game of endless whack-a-mole. Instead, Virsec focuses on what an application is supposed to do, what it’s allowed to do, and then rigidly enforces that during runtime.
Looking at firewalls, IPS, and WAF that are constantly being deployed, it’s important to recognize how porous they are. These systems are based at the perimeter and are focused on limited pieces of information they can glean, but we’re seeing that code is increasingly corrupted during runtime by these advanced attacks.
This means attackers are injecting code, things that are not discovered with the perimeter, and are attempting to hijack the application while it’s running. Some tools like EDR and other machine-learning tools are after the fact, so they may discover strange anomalies or learn to detect patterns, but it’s always after the attack, after damage is done.
Runtime Protection
Virsec effectively provides virtual patching across the whole application stack because we can effectively stop vulnerabilities from being exploited by ensuring that only the proper execution happens. We all know it’s an uncomfortable situation if there is a breach, which happens often, unfortunately, and it turns out that a patch was available and you hadn’t gotten around to patching it, and this is not because IT is being negligent, it’s because it’s difficult and time consuming.
This is very much breakthrough technology, and we think this is crucial to get ahead of this vulnerability and patching conundrum. Vulnerabilities are inevitable whenever software is released, but with Virsec we can effectively deliver compensating controls.
When new vulnerabilities arise, organizations are fully covered due to our runtime protection and because the solution enforces proper behavior. Essentially, Virsec is bridging between that long window of time when a new threat has appeared and the months or years before that problem is completely patched at the software level.
The solution is easy to manage because this process is happening automatically. This does not require writing complex policies, it doesn’t require updating signatures, it doesn’t require tuning or tweaking or a learning period when restarting the system. All of this happens immediately and automatically. We make the software self-defending because we’re understanding what’s happening as the application is running and protecting it from the inside.