The process of vulnerability management

The very first step is to identify the need for action. One of the most common sources for this is a vulnerability alert. Nowadays there are many ways to receive an alert. TrustSource may alert you, but also Nexus, Github or some other tooling may update you on the latest vulnerability news.

The matching of your components with the vulnerability information gathered is a critical step. At TrustSource we cover this by enhancing CVE-information with repository data and an extensive semantic matchmaking from component environment analysis. This allows a fast and pretty reliable matching in both diretions (CVE=>component and back).

However, assuming a match was successfully made, what next? We do suggest a four step approach to cope with the challenge, as depicted in the diagram below and outlined in the following paragraphs:

1. Assess alert information

Before freaking out due to a vulnerability alert in your critical system, take some sober steps to verify the information you gathered. The first you need to verify is the status of the vulnerability information.

Some CVEs are announced when in analyzed status. For example the Heads-up-section in the TrustSource dashboard provides a feed with the latest CVE entries assigned. Typically these are not yet confirmed. The information may help you to stay ahead of the hunters and assess potentially critical components even before exploits become available.

To derive a real picture of the impact, research the given information. Whenever a CVE is assigned, it will get published in the CVE assignment stream. The status varies depending of the reporting organization. Some just have a glimpse of the fact, others already provide an exploit implementation.

We suggest to assess the information carefully and make yourself a picture of the status. Visit the project / vendor site and see what evidence for the existence has been given. Based on the information collected, you may want to derive a vulnerability score (CVS = common vulnerability score). This link provides a simple calculator, so that you do not need to bother with the details of the CVSS (CVSS = common vulnerability scoring system).

A CVS is a figure on the scale 0-10, with 9-10 interpreted as critical. Following table outlines the possible scores and their meaning:

2. Prioritize your action by assessing the background

After getting a first impression on the criticality of the CVE we highly recommend to spend a few minutes researching the information background. What evidence is given, that the vulnerability really exists or is it just a hoax? Unfortunately nowadays reporting a vulnerability is a kind of accolade, so sometimes people are keen on reporting vulnerabilities, but not too precise in verifying it.

Therefor the source reporting the vulnerability is an important indicator for its seriousness. Some sources report more often than others, some already supported by references and / or accompanying materials giving proof to the evidence.

Additional references from alternative reports on the same vulnerability typically would be good indicator, if they are not copying each other. A detailed description of reproduction also is important. If there is an exploit already available, then you may be sure of the existence.

If the status of exploit already has been reached, you may want to search for an existing remediation. Either the project / vendor already publishes already a patch or a big fix or sometimes a workaround to prevent the vulnerbaility being triggered can be achieved or is available.

Given you would have derived a base CVS, you might want to derive now a so called "temporal CVS". This is a modification of the base CVS taking into consideration the status of information you were able to collect.

This gives you a list of prioritized vulnerabilities. Thus you my focus on treating the most critical first.

3. Understand the attack vector

In treating a vulnerability, it is important to understand its attack vector and its impact. The attack vector describes the potential attack, the impact focus on the damage that may occur given the vulnerability gets exploited.

Given you decide to take care of a vulnerability, you must understand that a particular CVE with a given base or temporal score does not mean the same criticality through all appearances. There might be parts of te solution where you decide to leave even a critical vulnerability untreated, if the attack has a very low probability.

Assuming an attack vector requires physical access to a device but the impacted devices all are mounted in a secured building behind electrical fences it might not require urgent attention despite being critical. The CVS v3 already takes these aspects into consideration, but the

So determine position of affected component in your system and compare it with the information about the attack vector. Determine the potential C, I and A requirements (C=Confidentiality, I= Integrity, A= Availability) of your component and finally calculate the environment score.

TrustSource already allows you to define the C, I and A requirements of each module as well as it architecture position. Thus starting from v2.1 TrustSource will make use of this information and be calculating the environment score automatically.

If the situation remains critical, it is really urgent to do something about the issue.

4. Determine how to act 

For sure there is no better solution than to get rid of any vulnerability. Unfortunately reality does not always allow to strictly eliminate all risks under given resource and time restrictions. To help focus resources, we have developed a set of norm strategies giving orientation.

- Accept, do nothing (Probability=low, Impact=low)

This is the cheapest way of mitigation: do nothing. It is not always necessary to prevent everything. Given your threat analysis is reliable, this vulnerability will not do any harm. So focus on monitoring that you will be notified, if it occurs. If you see any occurrence, you still might want to think about further mitigation.

- Hinder: (Probability=high, Impact=low)

Given there is no fix available, focus on increasing the barriers. You may reduce the probability by reducing the accessibility or wrapping the component, if you might not drop it.

From v1.6 on TrustSource provides a dependency diagram that allows you to determine the position of the vulnerable component in the dependency tree. Thus it becomes pretty simple to understand the relevance of the component for the complete module. 

We also recommend to introduce monitoring, e.g. if you would have proxied access keep the original port under monitoring for potential access and get alerted early in case of an attack.

- Prevent (Probability=low, Impact=high)

In case the impact is higher, you do not have much alternatives than to prevent the vulnerability from being misused. We suggest to always prevent high impact, low probability options. Preventing does not mean to really eliminate them but to ensure it to be most unlikely that the attack will be possible to be executed.

We also recommend to provide an attack handling pattern (AHP). An AHP describes on hwat to do in case such an attack happens. This starts with how to detect and the provisioning of attack monitoring options capable of detecting ans alerting an attack. Then it is important to define the steps to take to minimize the damage form the attack and/or probably to take measures to identify the attacker.

- Eliminate (Probability=high, impact=high)

If your vulnerability falls into this category, there is no doubt, you need to eliminate it. If there is no fix / upgrade available, you will need to go into the application code and make it safe! Prevet the defected routines to be initiated by wrapping them or replacing them with you own coed (beware of the consequences of code modification!)  Depending on the risk (C,I or A) you must at least provide additional encryption, backup or scalability / fail over resources to overcome such a potential attack.

As long as you are not able to eliminate such a threat, make sure you have the appropriate attack handling pattern in place.

PLEASE NOTE: All these suggestions are just there to give you a frame, a methodology for managing the risks associated with known vulnerabilities. Without detailed information about your application it is not possible to make more precise suggestions. However, feel free to consider TrustSource Risk Mitigation Support on a subscription base.