Taking the Risk-Based Approach to Vulnerability Patching

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^[1]. 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.^[2]

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^[3]
and PTaaS^[4]. If you’re not yet a
Strobes Security’s user, what are you waiting for? Sign up for free here^[5], or Schedule a
demo^[6].