High-Definition API Risk Ranking

Enhancing OWASP’s Methodologies for Comprehensive API Security

Zooming in on a closer, crisper picture of API risk

 

Everywhere you turn, vendors are talking about risk ranking capabilities. Practically every cybersecurity solution claims to provide risk ranking, and enterprise customers are attracted to its benefits; frankly anything that will help navigate the mountains of data they must manage in the digital era. What’s missing from the discussion is an honest assessment of just what constitutes an adequate risk rating regimen and an acceptance that not all solutions can live up to the definition. Risk ranking should be done properly because the alternative can lead to catastrophic consequences.

The negative implications of bad risk ranking methodologies should be obvious: either producing a false sense of security, or increasing urgency where it isn’t needed. But what exactly distinguishes poor risk ranking methods from good ones, and are there industry norms we ought to stick to when performing such ranking?

Any serious scrutiny of the API security market soon reveals that while most solutions offer some variety of risk score for APIs, most carry inherent flaws in their approach. Typical examples include statements like, “Since this API endpoint includes sensitive data in the request, it poses a critical risk to your organization,” and “The vulnerability found on this API endpoint is considered to be of very low severity, so there’s no real cause for concern regarding this API endpoint.” By completely dissociating the likelihood from the impact, these ranking methods can potentially lead organizations astray.

A recent OWASP publication on Risk Ranking methodologies demonstrates both the complexity required to reliably provide risk score as well as the simple fact that risk cannot be separated from context and impact, and technical checks and tests will not suffice to conclude risk score and severity.

OWASP describes several steps that are required to perform risk ranking, which can be simplified into two essentials:

• The ability to understand the context and impact to the business
• The likelihood for anything malicious to occur and succeed while considering the probability of it happening, based on the threat agent and vulnerability factors which guide us regarding how to analyze both the motives of an attacker to attack, and the skills they must have to succeed.

In recognition of this gap between common substandard risk ranking approaches and the practical needs of daily reality, Wib Security has introduced its “High-Resolution Risk” Solution, focusing on the need to enable organizations to zone-in on the most important issues, providing granular, comprehensive risk ranking for APIs in the context of their business objectives.

Wib‘s API Security High Resolution Risk Score is the first to accomplish fully fit-for-purpose risk ranking in accordance with the following 5 best practice steps.

 

Step 1: Multi lens approach for intelligence collection‏‏‏

Why ‘high definition’ risk scores? When we think of high definition or in the technical term – resolution, we often associate it with visual imaging. A high-resolution image contains more pixels per inch, offering a greater pixel information which provides better definition and a sharper image. In comparison, lower resolution with fewer pixels per inch can lead to larger pixel size and occupy more space. Consequently, stretched and enlarged pixel can cause blurriness and lack of definition and clarity in the image. In the context of risk scoring posture management and similarly to how high resolution enhances definition and visual quality, it is crucial to prioritize high-resolution risk scores for improved accuracy and precision as part of any risk posture strategy and management practice.

The only way to achieve this when it comes to risk scoring, is by drawing upon as many data sources as possible, spanning the life-cycle of APIs from code development, through testing, and into production. Any risk assessment conducted without factoring in all these dimensions will inevitably lead to blind spots and insufficient information, thus compromising the accuracy of our risk score.

So, gathering information from each data source, digesting, evaluating, and fusing it into an integrated view of each API endpoint will be the first step toward correct risk ranking.

 

 

Step 2: Context is everything

It would be absurd to claim that because a lion is a dangerous animal, it will be risky for me to visit the zoo. That’s because, in the context of the zoo, the lion is well separated from the crowd and will not pose the same risks as if the lion (and I) were wandering around its natural habitat of the African savanna.

To analyze the context of an API Endpoint, we would like to understand the type of data the API is handling, the consumer of it, and the direction of which the data is transformed into or out of the organization. For example, an API that exposes sensitive and personal information about employees of a European organization will be in the context of Privacy and will be linked to the GDPR compliance framework. Because this is simply the first step, we are not discussing the impact or risk that this outcome may pose.

Classifying context for an API will allow us to examine the motivations for attacking the API as well as the impact that it represents for the organization. Factors that will be discussed in the following sections.

Step 3: Estimating the likelihood of anything bad happening

Although this is mainly a technical stage involving the analysis of some security aspects of the API endpoint, such as misconfiguration, access control attributes, and vulnerabilities or incidents detected on the relevant API endpoint, the outcome of this stage is very rational and logic-based, dictating the chances of an attacker being motivated to attack this API asset and what skills they must have to succeed in attacking it.

At the Threat agent level, we will essentially attempt to anticipate what motivates an attacker to target an API and whether they will be highly rewarded for such an attack e.g., exposing many data records or gaining access to money delivery channels, etc., or is it going to be a low-rewarding endpoint that will not be as beneficial for an attacker to deal with? Another issue to examine is what skills the attacker must have to exploit this API. For example, an internal API that requires authentication and access to an organization’s private environment will be far more difficult to exploit than a publicly exposed API endpoint, implying that only a highly trained attacker will be able to harm this type of API.

Then, at the Vulnerability Factors level, we will decide whether there are vulnerabilities on the endpoint, the severity of those vulnerabilities, and how easy it will be to identify and take advantage of those flaws.

Combining those characteristics will allow us to predict the possibility of anything malevolent occurring and succeeding, which will lead us to the next step of determining the impact on the organization based on the worst-case scenario of a successful assault.

Step 4: Estimating the business impact

Disconnecting ourselves for a minute from the likelihood analysis we just made, the business impact of any API is independent on the technical aspects and relies solely on the logical and contextual aspects of the API, meaning, as long as the API is keep serving the same logic and purpose, the business impact will be the same.

Having information about the metadata together with the perspective of the API endpoint behaving in production will enable us to conclude what kind of impact this API might have on the business, ranging from Financial Loss to Compliance Violation, and categorize the APIs accordingly in order to provide another dimension of priority.

In the context of risk ranking, using the information about the business impact will produce a deterministic severity score based on the combination of likelihood and business impact.

Step 5: Producing a weighted Risk Score

When dealing with APIs, its ineffective and in fact a mistake to handle all potential risks as equals. Being able to analyze and prioritize what is a crucial risk versus what can be actioned at a later date is imperative for an effective risk posture management strategy. These decisions and prioritization must always be driven by several factors. For example, the type of data that is being transmitted by the API, the understanding and validation of the access control policy and so forth…

Taking a more agile and diligent approach will help organizations achieve the right risk management decision at the right time, which in turn will support a robust risk posture management practice.

In other words, risk can present itself in many shapes and forms, and providing a static, non-agile risk score strategy will leave us mostly vulnerable and unaware of the actual posture of our APIs.

 

 

What should I do with Risk scores?

The essence of the risk ranking method is to enable any organization to prioritize and execute, clearing noise and allocating resources for the important and urgent stuff that is under their control. Obviously it makes no sense to fix issues with low risk, as the ROI of fixing them will be lower than the alternative cost of fixing the critical issues.

Taking into account that fixing everything is not a viable option, organizations must start from the highest, most critical and urgent cases, and prioritizing those first in order to improve their overall posture. Continuous investigation and monitoring for risk changes are essential in this process, as every action organizations make should impact the risk score and change the order of prioritized assets they must action at any given time. What you prioritize should always be driven by the business context, in other words –  ‘what’s going to hurt us the most’ versus what can be labeled as an acceptable risk level and could be prioritized later.

 

 

Summary

In the intricate landscape of API security, developing a comprehensive and reliable risk ranking strategy is paramount. However, it is not enough to simply adopt a risk ranking strategy; the methodology employed must be robust, encompassing, and contextually aware. A poorly executed risk ranking system can have severe implications, leading to false positives, misallocated resources, and unaddressed threats.

Wib’s High-definition risk ranking, as we’ve discussed, is a strategy that builds upon the foundations laid by OWASP, but further refines the approach with detailed and multi-faceted analysis. By evaluating an API’s lifecycle, understanding its context, and estimating both its threat likelihood and business impact, organizations can achieve a weighted risk score that truly reflects the potential dangers. This proactive approach to risk management not only mitigates threats more effectively but also enhances the overall security posture of the organization in the long run.

View more blogs