Do I need to fix all the discovered vulnerabilities?

After years of doing penetration tests and working with many companies, I have started to notice that this question start to become more frequently asked especially from those with complex apps. Therefore, here is my response to the question Do I need to fix all the discovered vulnerabilities?

Fixing a vulnerability is not always a feasible action, and this is due to multiple parameters related to the company budget, the severity of the discovered vulnerability, and the needed time to fix it.

If you want to know more about what makes this action not always possible, please just keep reading …

Fixing a vulnerability in an application is not a simple or a quick task. Actually, it is the hardest work performed just after the penetration test mission is done. In addition, according to statistics, the process of fixing just one vulnerability takes a lot of money from companies. Furthermore, the more complex the application is, the more money and time it will take to fix vulnerabilities.

Therefore, all the elements that I am going to discuss in the following sections of the blog post, directly impact the cost of fixing the vulnerability, which means impacting the fixing decision.

The severity of the vulnerability

Before fixing any sort of vulnerability in the scanned or pentested app or network, the first thing that should be done is a severity study. Every discovered vulnerability in the scope should be studied to know its severity level. Knowing this gives the owner the ability to estimate the financial impact of the successful exploitation of this vulnerability.

In general, to determine the severity level of a vulnerability two scores are involved according to the OWASP methodology and need to be calculated first. You can use this Excel sheet to better calculate what I am going to discuss in the following sections.

Likelihood score

This score helps you identify the probability of a vulnerability being found and successfully getting exploited by an attacker. Therefore, knowing the following information about the vulnerability is necessary to calculate this score:

• The required skills to successfully exploit this vulnerability
• What would be the reward after successfully exploiting the vulnerability? (important data leak, accounts hack …)
• What level of access is needed to be able to exploit the vulnerability? For example, did the attacker need to be connected to the local network to be able to exploit it or simple remote access to the application interface is sufficient …
• What are the required skills to discover this vulnerability and is it a publicly known vulnerability or it is an unknown one (for example discovered after a pentest)
• Is this vulnerability already get detected by the IPS of IDS or even the web application firewalls? Or it can be exploited without being detected?

Impact score

The impact of a vulnerability is one of the elements that are reviewed every time any developer or application owner tries to fix a vulnerability. Therefore, having a numerical representation of this element is a necessary factor in determining the severity of a vulnerability. Then, to calculate this score you will need to answer the following questions based on a very good knowledge of both the technical and business impact of the vulnerability.

• Did the application has an impact on the confidentiality of the user’s data?
• Did the application has an impact on the integrity of the user’s data?
• Did the application has an impact on the availability of the user’s data?
• Did the application has an impact on the accountability of the user’s data?
• Is there any financial or reputation damages that could happen to the company?
• Is the vulnerability presence make you non-compliant with some lows or standards?
• Is there any impact on the privacy of the clients?

After determining these two scores, then their intersection in the following table gives you the real severity of the vulnerability:

The complexity and cost of the patch

The second element that needs to be analyzed while taking the decision of fixing a vulnerability or not is the complexity and the cost of the patch. Sometimes, some big companies find that leaving the vulnerability without any patch while accepting the risk of exploitation is way better and cost-effective than making a fix for it. This is due to the complexity of the application and the severity of the discovered vulnerability.

This is why a patch cost study needs to be discussed first while taking into consideration the complexity of the application.

The future projects

In some cases, the company strategies aim to remove or leave an application. However, after doing a penetration test a critical vulnerability gets discovered in this application. In this situation, fixing a vulnerability or not will definitely depend on the real impact of the discovered vulnerability.

If the severity of this vulnerability is not very important and the risk could be accepted for a short period until the clean next generation of this application gets distributed. Therefore, it might be a good idea, to leave the vulnerability while putting in place all the technologies to monitor and stop the exploitation of this vulnerability to the best. I have already discussed this situation in a previous blog post and I have explained in detail what should be done to protect the app when fixing the vulnerability is not the right choice.

Personally, I don’t recommend leaving any critical vulnerability, especially when the application is intended for a large public. As, even by putting in place the most powerful systems to secure and monitor the app, the detection and exploitation of a vulnerability in the app is just a matter of time.