Virtual patching: Cut time to patch from 250 days to <1 day

Unpatched vulnerabilities are responsible for 60% of all data breaches. The Department of Homeland Security has estimated that the proportion of breaches stemming from unpatched flaws may be as high as 85%.

Timely patching is an important aspect of managing vulnerabilities but is not always achievable in every circumstance.

Indusface’s State of Application Security 2022 report findings show that you could block complex attacks by using “virtual patching” through a WAF.

Over 800 million attacks were blocked by AppTrana WAF, even with thousands of vulnerabilities open for over 180 days.

The continuing threat of unpatched vulnerabilities

Let’s first start with what unpatched security vulnerabilities are. Unpatched vulnerabilities are flaws, weaknesses, and misconfigurations in systems, apps, networks, or devices that are yet to be patched.

Are they left unpatched because they are unknown vulnerabilities? No. Not all unpatched flaws are zero-day vulnerabilities. Exploiting known, unpatched flaws is much easier for attackers than developing zero-day threats. So, unpatched flaws could be both known and unknown vulnerabilities.

Facts and figures to understand the gravity of the unpatched vulnerability problem

• In 60% of cases, companies suffered breaches because patches weren’t applied to patchable known vulnerabilities. 62% of breach victims were unaware of vulnerabilities until breaches happened! [source:comparitech]
• 64% of all unpatched vulnerabilities involved known bugs with existing patches dated between 2002 and 2018. [source:packetlabs.net]
• 57% of all flaws observed are 2+ years old, and 17% are 5+ years old. [source:itsecurityguru]
• 1.5% of all known, unpatched vulnerabilities date back to 1999, over 2 decades old!
• 80% of cyberattacks use flaws reported 3+ years ago, while 20% use flaws from 7+ years ago. [source:bitdefender]

The WannaCry ransomware example

The WannaCry ransomware attacks of 2017 demonstrate how attackers use unpatched known flaws to wreak havoc on organizations. The WannaCry attacks were one of the earliest worldwide ransomware attacks. In the early 2017 attack, nearly 200,000 devices were hit. There have been several more victims since. It caused disruptions and financial damage to affected businesses.

The attackers exploited a vulnerability in the SMBv1 network sharing protocol since 2013. The protocol was deprecated in 2013. Only those systems with later versions of SMB enabled or those that blocked SMBv1 requests escaped this attack. Systems that accepted requests from SMBv1 were at risk.

Why would an organization leave known vulnerabilities unpatched?

Patching is a long and arduous process – Developing permanent fixes takes 60 days on average, even for critical vulnerabilities. It may even take more than 150 days in some cases. Deploying even a single patch across the architecture takes 12 days on average.

Every day, 300 new unpatched flaws are announced globally. It is impossible for developers to develop fixes for everything. Organizations don’t have the time, bandwidth, and resources to patch everything.

Patching can disrupt customers – Patching can also introduce new issues or incompatibilities that may impact existing customers. Even small changes can have unintended consequences that may affect customers’ ability to use the product or service. This requires a rigorous change management process that involves identifying the need for a patch, assessing its potential impact, and implementing it to minimize disruption.

Patches don’t exist for third-party components – Organizations use various third-party software, components, and apps. Sometimes, the service provider may not release fixes since the software is old. Or the service provider may have gone out of business. And replacing such components/ software may cause massive operational disruptions. In these cases, organizations are left exposed to threats.

Patch failure due to inadequate testing – The patches should be validated, rolled out, and audited, whether deployed internally or in client environments. Developers are often in a hurry to release patches/ updates. So, they end up releasing patches without adequate testing. This leads to patch failure.

Virtual patching – An effective compensating control

What if vulnerabilities could be patched within 24 hours? That too with ZERO impact on your code and, more importantly, your existing customers.

Virtual patching allows you to do that.

A WAAP or A WAF solution allows you to do just that. In addition, WAFs also incorporate threat intelligence feeds to develop new rules, policies, and processes for thwarting future exploitation attempts.

Indusface extensively analyzed the vulnerabilities blocked across 1400+ websites for Q4, 2022, following the top 10 vulnerability categories identified.

As part of our analysis, we have discovered a staggering 61,000 open vulnerabilities, with each site averaging around 30 vulnerabilities. Of these, 31% have remained open for over 180 days, including more than 1700 critical and high-severity vulnerabilities.

To mitigate these risks, security teams increasingly leveraged WAF’s “virtual patching” capabilities to block attacks while working on fixing the application vulnerabilities.

Virtual patching is a security technique that uses rules on WAF to block known vulnerabilities in an application or system without modifying the actual code.

One prime example: AppTrana’s custom rules based on specific applications blocked 60% of attacks. This is the importance of custom rules or custom virtual patches that are surgically written depending on the underlying code and open vulnerabilities.

WAFs also give detailed reports on attacks blocked by the custom rules that could be used as input to prioritize patching those vulnerabilities that hackers target.

As a best practice, I recommend running DAST scans weekly, if not daily, and performing penetration testing every 6 months. Once the vulnerabilities are found, immediately apply virtual patches on the WAF.

Finally, have dedicated sprints for patching on the code, as every custom rule you add on the WAF will add a small latency (often less than a millisecond) on the application.