Risk Assessment of Identified Vulnerabilities

For an attacker, intruding into IT systems can be very thrilling. However, we should never lose sight of our real goal: the identification of all entry points or security gaps in our target systems. The list of vulnerabilities can get very long and convoluted. But in order to report to our client what vulnerabilities he or she should first address or fix, we need to prioritise vulnerabilities based on their risk. The risk of a vulnerability can be derived from its probability of occurrence and/or the probability of its exploitation and its extent of damage.

We basically have two methods available to illustrate the risk of a vulnerability. We can either determine a specific numerical value (like 1.034,99 €) or make a statement on the severity of the risk (such as low, medium, high). The specific numerical value is the result of a quantitative risk analysis. This is useful, for example, to determine the risk of a hard drive failure, since hard drives have a specific price and an average lifespan. By contrast, we do not usually have enough information about vulnerabilities in IT systems, which is why this kind of risk analysis is not recommended for pentesters. We can perform a qualitative risk analysis instead, because we can always make a statement on the likelihood and extent of a vulnerability occurring and thus assess the severity of the risk.

Not surprisingly, an SQL injection will always be instinctively categorised as higher risk than a PHPInfo page. But how does the risk of an SQL injection compare to a cross-site scripting vulnerability, for example? For a transparent prioritisation of vulnerabilities, we need a rating scheme that divides the probability of occurrence and the extent of damage from vulnerabilities into degrees of severity and assigns them to a risk statement:

Probability of occurrence

[ High ] The vulnerability is obvious or exploits are freely available.

[ Medium ] The vulnerability can be detected in a reasonable amount of time, exploits may need to be adapted.

[ Low ] The vulnerability is very hard to find and exploits must be created.

Extent of damage

[ High ] Violation of security objectives concerning information or IT systems

[ Medium ] Circumvention of protective mechanisms

[ Low ] Information gap

Risk = max( probability of occurrence, extent of damage)

The above schematic example classifies the highest severity from the likelihood of occurrence and the extent of damage (low, medium, high) as the risk of a vulnerability. Let’s take a look at the following scenario: an faulty authorisation allows a merchant to make administrative changes in the backend of the payment gateway of Dubius Payment Ltd. via direct page requests. Exploiting the vulnerability would require knowledge of the administrative interface in the backend, whereby the vulnerability could be found in a reasonable amount of time (medium probability of occurrence). Because unauthorised administrative changes can be made, security objectives such as the integrity of data are violated (high level of damage). Subsequently, this vulnerability would be ascribed a high risk because the severity of the extent of damage (high) outweighs the probability of occurrence (medium).

How would you rate our schematic example to assess the risk of vulnerabilities? Can you potentially find vulnerabilities of Dubius Payment Ltd. which are attributed too much significance when using our scheme, and can you adopt it appropriately?