The primary goal of vulnerability management
is to reduce the risk to an organization.
This is most effectively achieved
by solving the latter’s security issues.
In this blog post,
we define vulnerability remediation,
talk about its implementation and importance,
and differentiate it from vulnerability mitigation and acceptance.

What is vulnerability remediation?

The definition of vulnerability remediation is pretty straightforward.
Still,
we might have to agree on what a vulnerability is in the first place.
Broadly speaking,
it can be defined as a characteristic
that renders an individual’s
or an organization’s asset(s) (e.g., information systems)
open to exploitation or susceptible to a given hazard.
The vulnerability could be of the security posture,
design,
security procedures,
internal controls,
or the implementation of any of them.

Remediating a vulnerability is then to successfully repair it.
Even though the National Institute of Standards and Technology (NIST)
in its special publication 800-40r4
classifies what we call remediation
into mitigation as a type of risk response,
we argue there is a difference between vulnerability remediation
and mitigation.
We’ll see the latter,
along with vulnerability acceptance,
as alternatives to remediation in vulnerability treatment,
on which we expand below.

Vulnerability remediation steps

Treating vulnerabilities
(either remediating, mitigating, or accepting them)
is a stage of the broader vulnerability management
cycle.
Before this stage,
the vulnerabilities,
detected by automated security testing tools
or manual techniques like penetration testing,
should each have gone through evaluation and prioritization.
There should then be an understanding
of how exploitable each verified vulnerability is.
It should also be known how easy it is to exploit it,
whether the way to exploit it has been publicly available,
and what the impact of its exploitation is.
Basically,
the risk it represents heavily guides the decision
on how to treat the vulnerability.

When searching for steps in vulnerability remediation,
you can find sources
that mention not only the actual remediation as one of those steps
but also actions previous to it,
like identifying the vulnerability
and evaluating its prioritization,
and later actions,
like monitoring for new weaknesses.
We consider those other actions
to be stages in a vulnerability management cycle
rather than steps in remediation.
Vulnerability remediation involves the appointed individual(s)
repairing the issue in the previously agreed time frame.
Following this,
vulnerability reassessment should be performed
to verify the effectiveness of remediation.
Read a previous blog post
to learn about the stages of vulnerability management.

Remediation may be done by repairing the characteristic
so that it complies with security requirements.
Examples are fixing proprietary source code
and updating third-party software or libraries to their patched versions.
Remediation may also involve making changes to configurations
that are insecure.
Such is the case when cloud services’ configurations do not restrict access
to sensitive resources,
among other problems that may appear.

Remediation of high-risk vulnerabilities is especially important.
Note that we’ve found
using vulnerable software components
to be the weakness
that has exposed our client organizations the most to risk.
So,
patching third-party software and libraries should be at the top of the list.
We also reported
that our ethical hackers
found critical severity vulnerabilities,
whereas vulnerability scans couldn’t.
This suggests
that it’s these highly skilled security professionals who can give directions
on how to remediate those vulnerabilities
that deserve the most to be prioritized.

In our Documentation,
we have our own standardization of security vulnerabilities,
which we search for in our assessments.
For every entry,
we provide an example of compliant code and one of noncompliant code.
This makes it a valuable resource when looking to remediate vulnerabilities.

Why is vulnerability remediation important?

Today’s organizations being permanently exposed to threats
is a major argument in stressing the importance of vulnerability remediation
for system security.
More than a thousand vulnerabilities are publicly disclosed every two weeks
in the bulletins
of the Cybersecurity and Infrastructure Security Agency (CISA).
Further,
malicious attackers are on the hunt all the time,
looking to exploit the flaws found in software either recently or ages ago.
Basically,
Internet-facing assets are exposed to untrusted sources,
and as the former grow in number,
the chances to get breached increase.
Organizations (and individuals)
should perform continuous vulnerability assessment
and remediation cycles
to keep on resisting threats,
which are constantly evolving.

Vulnerability remediation is also important
as a key performance indicator (KPI)
of an organization’s vulnerability management program.
For example,
by tracking how much of the associated risk is being taken care of
in a given time frame.

If it were not enough an incentive for organizations to secure their data
and that of their users
plus the availability of digital assets,
there’s also the motivation to comply with industry security standards.
Compliance enables businesses to maintain their customers’ trust,
avoid fines and operate legitimately.

Granted,
a challenge to vulnerability remediation is
that organizations can see it as a process
that is time consuming
and therefore negatively affects productivity.
However,
they need to realize
that taking the time needed to effectively manage risk
can help them avoid incidents
that end up being way more costly.

Vulnerability treatments while not remediating (yet)

Vulnerability mitigation

In order to most effectively manage the risk associated with a vulnerability,
the most desirable course of action is to remediate the latter.
But several factors may impede remediation.
Maybe
the patch for a vulnerable third-party software product is not yet available.
Or maybe
the limited resources need to be allocated
to the remediation of some vulnerabilities in proprietary source code,
delaying the remediation of others.
Then,
an option could be to deploy additional security controls
(e.g., using technologies to isolate assets)
to reduce the chances of exploiting the vulnerability
whose remediation is being delayed.

The above option is a form of mitigation.
Another one is,
for example,
in the case of a specific software feature that is flawed,
to just disable the problematic characteristic.
Yet another option could be to avoid risk,
as NIST explains it,
that is,
eliminating the attack surface in question.
A way to achieve this is by ditching vulnerable third-party software
or libraries.
Further,
these components could be replaced with ones that are not vulnerable.

Vulnerability acceptance

In the course of managing a vulnerability,
it might be the case
that the risk it represents has to be accepted,
either temporarily or permanently.
The former is an option
when other vulnerabilities need to be addressed first
or a solution to the issue in question is not yet available.
How much risk it represents may also be a reason for acceptance.
If the risk is deemed low and therefore tolerable,
according to the specific organization’s policies
or even compliance requirements of external entities,
then the organization may choose to accept it for a while.

If in managing limited resources,
the costs of remediation of the aforementioned vulnerability surpass
those associated with its exploitation,
then the organization may choose to tolerate that risk permanently.
Yet another scenario is when the organization plans
to stop offering a vulnerable software functionality
or using a vulnerable third-party software or library,
so it accepts the associated risk
in the short period of time it takes to implement this change.

Accepting vulnerabilities is no taboo.
Nevertheless,
organizations should aim at reducing risk exposure as much as they can,
and this is best achieved by remediating every vulnerability.

Manage vulnerability remediation from our platform

At Fluid Attacks,
we perform security testing continuously
and send vulnerability alerts to inform our client organizations
of new issues in their systems found by our tool or ethical hackers.
On our Attack Resistance Management (ARM) platform,
stakeholders,
including the developers responsible for remediation,
can read detailed information about each vulnerability
to understand how to go about remediating it.
They can immediately take action.
We help vulnerability treatment
by letting them assign the remediation of individual vulnerabilities
to members of their teams.
Moreover,
they can decide to accept a vulnerability temporarily
and schedule its remediation
or report that they are accepting it permanently
or that it represents zero risk to them.
In the most comprehensive of our plans,
clients have access to several support options,
one of which allows them to schedule meetings with our hackers
to get advice on how to solve the most challenging vulnerabilities.
(Learn about Continuous Hacking Squad Plan).

Want a taste of our Vulnerability Management solution?
Start the 21-day free trial
of our Continuous Hacking Machine Plan,
in which you can detect vulnerabilities in your software with our scanner
and access our platform to manage them,
among other things.