Software vulnerabilities are a major threat to organizations today. The cost of these threats is significant, both financially and in terms of reputation.

Vulnerability management and patching can easily get out of hand when the number of vulnerabilities in your organization is in the hundreds of thousands of vulnerabilities and tracked in inefficient ways, such as using Excel spreadsheets or multiple reports, especially when many teams are involved in the organization.

Even when a process for patching is in place, organizations still struggle to effectively patch vulnerabilities in their assets. This is generally because teams look at the severity of vulnerabilities and tend to apply patches to vulnerabilities in the following severity order: critical > high > medium > low > info. The following sections explain why this approach is flawed and how it can be improved.

Why is Patching Difficult?

While it is well known that vulnerability patching is extremely important, it is also challenging to patch vulnerabilities effectively. Vulnerabilities can be reported from sources such as pentest reports and various scanning tools. Scans can be performed on your web applications, APIs, source code, infrastructure, dependencies, containers, etc.

The total number of reports that need to be sifted through to prioritize patches can increase drastically even in a short period of time, and when multiple teams are involved, this can further increase the complexity and time required to coordinate and prioritize patches.

To make matters worse, new exploits keep on surfacing almost daily, and keeping track of new exploits and available patches can become a mammoth task that can quickly get out of hand if not addressed properly. Unless an organization has a very mature security program in place, it is complicated to manage patching effectively.

Taking the Risk-Based Approach to Patching Vulnerabilities

Simplifying patching requires you to simplify prioritizing first. "Risk-based approach" means that you'll weigh the potential impact of a vulnerability against the likelihood of its exploitation. This allows you to determine whether or not it's worth taking action.

To simplify prioritizing, you have to consider the following things:

• The exposure of the asset,
• The business sensitivity of the asset,
• The severity of the vulnerability reported against the asset,
• The availability of an exploit for the vulnerability reported,
• The complexity of the exploit, if it is available,
• The taxonomy of the vulnerability reported.

* Asset could be anything within your organization, like a web application, mobile application, code repository, router, server, database, etc.

Simplifying Prioritization

This approach helps in drastically reducing the time spent to prioritize vulnerabilities. Let's discuss each point in detail:

Exposure: If your asset is public-facing the Internet, or private, i.e., behind a firewall within the network with controlled access. Public assets usually carry a higher risk, but that does not always mean they should be prioritized. The reason is that not every public asset is sensitive. Some public assets may simply be static pages that do not contain user data, while other public assets could be handling payments and PII information. So even if an asset is public, you must consider its sensitivity.

Asset sensitivity: Categorize the business sensitivity of all your assets based on how important that asset is to your business. An asset that contains sensitive information about users or processes payments may be categorized as a critical business sensitivity asset. An asset that provides only some static content can be classified as an asset with low business sensitivity.

Severity of the reported vulnerability: This one is self-explanatory; you have to prioritize vulnerabilities in order of critical > high > medium > low > info severity.

Exploit availability: Vulnerabilities for which public exploits are already available should be prioritized over vulnerabilities for which no exploits are available.

Exploit complexity: If an exploit is very easy to exploit and requires little to no user interaction, then vulnerabilities for this type of exploit should be prioritized over vulnerabilities with very complex exploits that typically require high privileges and user interaction.

Taxonomy: The classification of the vulnerability reported also has to be taken into consideration and should be mapped with industry standards like OWASP or CWE. An example would be that a remote code execution impacting a server should be prioritized higher than a client-side vulnerability, say a Reflected Cross Site Scripting.

Time spent to prioritize vulnerabilities

An example of a high prioritized vulnerability would be if the asset which is affected is publicly exposed, has a critical business sensitivity, the vulnerability severity is critical, an exploit is available, and does not require user interaction or authentication/privileges.

Once all vulnerabilities are prioritized, addressing the most critical vulnerabilities will dramatically reduce the risk to your organization.

So what issues should a vulnerability management report measure to assure your application security satisfactorily? - Check out the Whitepaper.

How to get the information about patches?

You can get information about patches from various advisories like NVD. In these reports, you can find multiple references on how to patch the vulnerabilities. Also, the websites of the products you use usually provide this information. While it is possible to manually go through all the sources and get the information about the patches, if there are many security vulnerabilities in your organization, getting all the information from multiple sources can be tedious.

The Solution:

Strobes can significantly help organizations of all sizes dramatically reduce the time it takes to prioritize vulnerabilities and provide patching information within the platform. Prioritization is also easy because Strobes automatically prioritizes vulnerabilities for you based on the metrics described in the Risk-Based Approach to Patching Vulnerabilities section.

Strobes Security is leading the way to disrupt the vulnerability management space with its flagship products VM365 and PTaaS. If you're not yet a Strobes Security's user, what are you waiting for? Sign up for free here, or Schedule a demo.