Security healthiness as a risk metric of IT assets

Simple math for lots of tricky vulnerabilities. Measure the risk of IT assets in an agile way and take quick actions

After a security review campaign, the teams that have responsibility for the security of the IT assets, usually focus on solving the vulnerabilities of the highest severity, or that have been used in conjunction with others to achieve a compromise during a pentest.This is due to the normal optimization of resources, where time and money are invested in the resolution or mitigation of those vulnerabilities that involve an increase in the level of risk of IT assets, and whose remediation implies a reduction in the level of risk until it is acceptable.

This approach is correct and legitimate. It is not always necessary to fix all vulnerabilities, or it is not necessary to fix all of them immediately. So resources can be set aside to mitigate other risks or take advantage of opportunities reising for the company.

However, in the reality of many organizations, vulnerabilities accumulate over time without correction or mitigation. These are identified through different sources of information, such as: web security reviews, penetration tests, technology watch, vulnerability scanning tools, third party audits for regulatory needs, bug bounty, attack simulators and many others.

These activities can have different perspectives on the same IT asset, and in few cases they can have a holistic view of the IT asset as a whole and thus identify the relationships between the different vulnerabilities and determine exactly the impact that their conjunction has on the level of risk.

For example, a vulnerability scan in most cases fails to identify vulnerabilities in the business logic of applications, or an external black box pentest could fail to identify vulnerabilities exposed in the internal network, or a review code would not take into account vulnerabilities in the application deployment environment.

When it has been demonstrated through a pentest that a set of vulnerabilities can be concatenated to compromise a system, it is clear that you have to act quickly to remediate these vulnerabilities independently from their severity. These can have critical or high severity, or even medium, low or informational.

However, it is not as easy to decide to act on vulnerabilities of low severity, when found through different sources, since they do not have a contextual analysis as a whole.

This means that to determine the level of risk of IT assets, it would always be necessary to carry out a detailed technical analysis of all the vulnerabilities in the inventory.

This is surely the best way to determine the impact on the level of risk generated by all applicable vulnerabilities, although it requires a significant effort from the security team, which could take resources away from other important tasks, and significantly delay action taking.

Unfortunately, what happens in most cases is that only critical and high severity vulnerabilities are remediated, while medium, low and informational severity vulnerabilities pile up without a short-term action plan, or in the worst cases they lead up to a security incident.

To prevent this from happening, and to provide our clients security officers with a quantitative metric that helps identify those IT assets that need attention to improve their security status, we have defined the Security healthiness of an IT asset. This work complements the dynamic cybersecurity risk assessment developed by Tarlogic .

The Security healthiness is a metric with values ​​between 0 and 10, with 10 being the best state of health in the event that no vulnerabilities have been identified, and 0 the worst state, when vulnerabilities have been identified that, in the event of an attack, would most probably materialize in a security incident.

This metric is proportional to the level of risk, where risk in this context defines the probability of an incident due to the exploitation of a vulnerability multiplied by the impact generated on the business by this incident:

The probability in cybersecurity is a very volatile concept because it cannot be based on historical data, and would have to take into account a multitude of parameters such as the probability of the threat, the awareness of the users, the maturity of the organization, the experience of the technical support and many others that make creating a detailed probabilistic model complicated and useless. With the security healthiness, we want to reduce this complexity through a simple and agile model that aims to dedicate more resources to action and less to analysis.

The calculation of the metric is based on the assumption that the probability of a vulnerability causing an incident is proportional to its severity. We calculate the severity with the CVSS (or with any other similar methodology, such as OWASP Risk Rating). This is still an approximation and in no case should probability and gravity be confused.

For example, in the case of an IT asset with a single vulnerability with CVSSv3.1 base score 6.3, the probability of an incident occurring would be P (Incident) = 6.3 / 10 = 0.63. And the probability that it does not materialize is P (No incident) = 1 – 0.63 = 0.37.

Thus, the probability that an incident does not materialize on an IT asset, which has an N number of vulnerabilities can be defined as the product of the N independent probabilities that an attacker will not be able to exploit any of these N vulnerabilities PN(No incident ).

Clearly, the more vulnerabilities N there are, and the more serious they are, the lower the probability that an incident will not occur in the event of an attack.
The probabilities of exploitation are considered independent, since it is assumed that the exploitation of a single vulnerability is sufficient to cause an incident.

Stochastic probabilities have not been used because vulnerabilities exploitation sequences would have to be defined, requiring an effort consuming analysis of their relationships. This would not be a good solution to obtain in an agile and economical manner a representative metric.

A problem with the formula defined in (1) is that the contribution to the probability of vulnerabilities of different levels (e.g. critical and low) is of the same magnitude. To correct for this model distortion, the contributions of the different severity levels are calculated separately. This ensures that the use of this model continues to prioritize resolution of critical and high vulnerabilities.

The contribution of each severity level “G” is calculated as a power of the average:

Where NG is the number of vulnerabilities for the severity level. The sum is defined over all probabilities at the severity level.

So, considering the five levels defined by CVSS (Critical, High, Medium, Low, Information), the calculation of IT asset health is as follows:

This number can be very small depending on the number of vulnerabilities. So to be more usable as a metric, security healthiness is defined using a logarithm to base 10, as follows:

The function of Maximum (MAX) between 0 and the result of the logarithm is necessary to avoid negative numbers, in the case that an IT asset has a high number of critical and high severity vulnerabilities (this undoubtedly requires remediation). The difference is made between 10 and the result of the logarithm so that the security healthiness is defined between 0 and 10.

We have defined the following levels of security healthiness:

10 – Excellent
9 – 9.9 – Good
6 – 8 9 – Need attention
2 – 5.9 – Need immediate attention
0 – 1.9 – Unreliable

The following table shows an example of calculating security healthiness for five IT assets with a different number of vulnerabilities and criticalities.

This table shows that clearly Asset E requires immediate actions, having high and critical vulnerabilities. But it also shows that Asset A, which does not have high and critical vulnerabilities, also needs immediate attention to improve its security posture.

The security healthiness is an effective metric to help organizations in defining action plans for the improvement of IT assets security. It changes the focus of improvement actions from vulnerabilities to IT assets. Identifying the IT assets that need attention helps to define whether it will be sufficient to technically remediate the vulnerabilities, or if an action plan will be necessary to improve security requirements and policies that apply to the IT asset. This in the long term avoids continuing to accumulate vulnerabilities and reduces risk.

A possible extension of the security healthiness metric is to normalize it to the impact on the organization’s business, caused by an incident on the IT asset (criticality of the IT asset). This topic will be covered in the next article on security healthiness.

Discover our work and cybersecurity services at www.tarlogic.com