What is a cybersecurity risk in software development?

Author avatar
by Martin Hell
2020-02-06
7 min
What is a cybersecurity risk in software development?

The term risk is often misused and misunderstood. Still, in today’s software-driven landscape, devices, systems, and critical infrastructure are increasingly exposed to adversarial threats. When designing and implementing systems, products, and services, it is more important than ever to understand and efficiently mitigate risks.

In this article, we look at the risk concept, how organizations can work with assessing security risks, and also give pointers to useful resources.

Cyber security risk

Basically all businesses today are exposed to some kind of cyber security risk. With the increasing complexity of system hardware, software, firmware, and protocols, we also see an increasing attack surface exposed to potential adversaries.

A risk can here be seen as the expected loss, i.e., a function of the likelihood of an event and the impact when the event occurs. In RFC 4949, IETF defines it as “An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result.” The standard way of expressing it is 

Risk = Likelihood x Impact.

However, it must be noted that it should not necessarily be interpreted as the mathematical multiplication operator. It should rather be seen as that the risk increases with the likelihood, and it also increases with the impact. Determining the risk is part of the risk assessment process.

This process consists of a few steps that, when executed, provide an organization with a prioritized list of measures that should be taken in order to mitigate risks. The risk assessment process is part of risk management, where the latter takes a more holistic view and incorporates e.g., describing the system and building a strategy for managing risks.

It also includes implementing and assessing the security controls and monitoring changes to the system that can affect the risks.

Risk assessment

Risk assessment is part of risk management. As defined in ISO 27001, it is the overall process of identifying, analyzing, and evaluating risk.  These main steps can be further specified as follows:

  • Identify. Determine risks that are associated with loss of confidentiality, integrity, and availability. Also, identify who is exposed to the risk. Is it the organization, its employees, the customers, or someone else?
  • Analyze. What is the likelihood of the events related to the risks occurring, and what are the consequences? This will allow you to determine the risk level.
  • Evaluate. The analysis results are compared to the acceptable risk levels of the organization allowing countermeasures to be prioritized.

A risk assessment process is needed in order to avoid implementing countermeasures to events that are extremely unlikely to occur, or events that do not have any noticeable impact on your business or organization. To be compliant with ISO 27001, the organization must retain documentation about this process.

NIST SP 800-30 (Guide for Conducting Risk Assessments) uses a more high-level view to divide risk assessment into four steps. The identify-analyze-evaluate steps from ISO 27001 are here seen as the step when the risk assessment is conducted, but NIST also includes three other steps in order to facilitate a more comprehensive process. The steps defined by NIST are:

  • Preparation. This includes identifying the purpose and the scope of the assessment, as well as under which assumptions and constraints the assessment is conducted. It also identifies the information sources to use and which approach to take.
  • Conducting. This step consists of identifying threats, determining their likelihood of being realized, and the impact such an event would have on the organization and its assets. It also includes determining the risk based on the likelihood and impact. This can be seen as the three steps of risk assessment as defined by ISO 27001.
  • Communicating. This includes communicating the results to decision-makers and to share the gathered information with relevant people in the organization. Information sharing supports maintaining the risk assessment.
  • Maintaining. This includes monitoring the risks and updating them if needed. Maintaining the risk assessment allows the risk analysis to be up-to-date and facilitates continuous well-informed decisions.

In SP 800-30, these steps are further detailed. They also provide a threat enumeration and guidelines for both likelihood and impact estimation, giving organizations a good starting point for the assessment.

Assessment approach

There are three main approaches that can be taken when assessing the risk. These are qualitative, quantitative, or semi-quantitative. The qualitative approach is based on a number of categories or levels, e.g., none, very low, low, medium, high, and very high.

While they can be easy to understand and communicate, there are often very few levels, making it difficult to prioritize between risks. 

The quantitative approach instead uses numbers, e.g., monetary values and probabilities. Such values might require more effort to determine, analyze, and interpret. They are also dependent on the analysts making correct judgments.

On the other hand, the numbers, if interpreted as expected yearly monetary loss, support prioritization and decisions since they can easily be compared to the cost of the countermeasure. Moreover, real data of e.g., historical events can be used when assigning probabilities and impact.

The semi-quantitative approach is somewhere in-between. Numbers are used for likelihood and impact, but they are instead typically in the range 1-10, or 1-100, where a range of values represents a qualitative term. The resulting score can be used for prioritization with higher granularity than the qualitative approach. This approach is used by e.g., the CVSS score.

Analyzing the security risk

There are several ways to analyze the risk, but the end result always serves as a support for prioritizing the addition of security controls. One commonly used methodology for risk rating is the one proposed by OWASP. In their model, the risk is a qualitative measure expressed as one of “note”, “low”, “medium”, “high”, or “critical”.

The risk is based on likelihood and impact, which in turn are rated as “low, “medium”, or “high”. 

The likelihood is divided into scores related to both the threat agent and the vulnerability itself. Do the envisioned attacker want to do this and do they have the possibility of doing it? How easy is it to find and exploit the vulnerability?

The impact is divided into technical impact and business impact. The technical impact is given as an impact in terms of the CIA triad (confidentiality, integrity, and availability) together with accountability. Business impact measures damage in terms of financial, reputation, non-compliance and disclosure of personally identifiable information.

Both the likelihood and the impact is taken as the arithmetic mean of the subscores. This is converted into the qualitative measures “low, “medium”, or “high”. Combining the two qualitative measures, the risk can be obtained as shown in the following table.

This method of risk analysis provides an excellent start to understanding the risks that a business is exposed to. More subscores and properties can trivially be added. It is also straightforward to use different weights for each subscore in order to align the risk measure with the business needs. 

At the same time, even though a 3-level ordinal scale can provide useful input to a prioritization decision process, it does not capture the actual potential loss that is related to e.g., a vulnerability. By assigning actual probabilities and ranges of monetary value to each individual property, it is possible to understand how much money a design decision or vulnerability will cost the company each year.

This is an example of a quantitative risk analysis. Some will argue that it is not possible to set a monetary value on e.g., business reputation since we can’t reasonably know it. On the other hand, then we can not know the qualitative measure either the argument being that we at least do not lose any information in the quantitative setting, but we potentially gain a lot.

Mitigating risk comes with a cost, and that cost does have to be compared to the cost of allowing the risk. In that sense, quantitative risk analysis benefits from comparing apples with apples. The book How to measure anything in cybersecurity risk” by Hubbard and Seiersen provides an in-depth discussion on the advantages of quantitative risk analysis, as well as statistical methods that can be used in such an approach.

Residual and acceptable risk

If and when the decision has been made to mitigate a certain risk, such mitigations come with a cost. The mitigation can consist of updating software to the newest version, add additional authentication factors, change to other cryptographic algorithms, install physical controls such as turnstiles or mantraps, or any other type of security control.

All these come with some cost, and in many cases result in the risk being lowered but not fully eliminated. Enabling multi-factor authentication will reduce the risk of account hijacking and awareness training will reduce the likelihood of e.g., phishing attacks.

The portion of the original risk that still remains after countermeasures have been applied is the residual risk. Such risk can perhaps still be mitigated, but the cost of doing is often much higher than the risk itself. In that case, it does not make economic sense to add additional countermeasures. Such a residual risk is known as the acceptable risk.

Another definition of security risk

Sometimes you might encounter a slightly different definition of risk. Instead of the Risk = Likelihood x Impact definition, some texts define it as

Risk = Threat x Vulnerability x Impact.

Comparing the two definitions, and understanding that the operator is not mathematical multiplication, we can see that they are really equivalent. Look at how e.g., OWASP determines the likelihood. It is divided into subscores describing both the threat and the vulnerability.

NIST defines it in a similar way, where the likelihood should consider both threat characteristics and identified vulnerabilities (though they also explicitly state that countermeasures should be taken into consideration). Thus, the above definition is just a somewhat more verbose version of the more common one which only states likelihood and impact.

Applying countermeasures

Ok, so we have a list of risks that we need to mitigate and find countermeasures for. What do we do now? Applying a countermeasure is to apply a security control in the right place and in the right way. 

In NIST SP 800-53, a set of security controls is enumerated and discussed. The controls are divided into 20 categories, with quite many individual controls in each category. Some controls are to be implemented on an organizational level, while others are implemented as system components.

It can be noted that risk assessment in itself is one of the categories. NIST also provides a suggested prioritization among the controls for systems of low, moderate, and high impact. However, the actual controls to implement are still very system dependent and the result of a risk assessment should be used to make organization-specific prioritization of controls.

Another resource for security controls is ISO 27002, which provides a similar set of guidelines. NIST SP 800-53 is more comprehensive and can be seen as a superset of ISO 27001. Which one to use will typically depend on which type of organization you are and where you need to be compliant.

While compliance is out of scope in this article, we simply wish to provide useful resources, it can be noted that companies doing business with the US federal government should be more interested in the NIST guidelines. Other companies might want to settle with the more lightweight ISO 27002.

The security can either focus on lowering the probability of the event, i.e., managing the threat or removing the vulnerability, or it can focus on minimizing the impact. A list of security controls is of course not only helpful when mitigating risk and finding countermeasures. It is also a very useful resource when identifying parts of the system and organizations that are exposed to risk.

Where to start? 

Performing a solid risk assessment is not easy. It requires a good understanding of the organization and its assets. Still, we recommend that you just go ahead and do it. You may not capture everything in the first iteration or the second, but just doing the activity of identifying and analyzing risks will help your organization in the direction of improved information security processes and more secure products and services.

If you need help getting started, need assistance on the way, or want a third party to lead you through the process, do not hesitate to contact us at Debricked. We have long experience in several areas of cyber security and can provide guidance throughout the risk assessment process.