• Open Access

Unified threat model for analyzing and evaluating software threats

Authors


ABSTRACT

Design-level vulnerabilities are a major source of security problems in software programs. For the purpose of improving the trustworthiness of software designs, this paper presents a unified threat model for representing, analyzing, and evaluating software threats at various design stages. Unified threat models represent software threats via tree structures with AND/OR logical relationships and evaluates software threats in a cost-effective way based on attack paths. Mitigation measures for software threats are designed and prioritized based on the evaluation results, which make it possible to design high-quality software security programs that resist identified software threats. A case study for an online banking system is given to systematically demonstrate the application of unified threat models in software threat analysis and evaluation. The results from the case study demonstrate that the unified threat model is superior to traditional threat trees in accurately evaluating results, designing mitigation measures, and guiding software security testing. Copyright © 2012 John Wiley & Sons, Ltd.

1 INTRODUCTION

In recent years, the poor quality of software has been identified as the root cause of the exponentially increasing software security problems. The CERT statistics [1] indicate that the number of cataloged vulnerabilities has been growing rapidly since 2000; it was 8064 in 2006 and 7236 in 2007, far exceeding 417 in 1999. Design-level vulnerabilities are particularly a major source of security risks in software programs. As reported by Microsoft, about 50% of the security flaws uncovered in its “security push” in 2002 were design-level problems [2]. Microsoft also claims that 70% of companies test and evaluate the security of their products only after release. If software design flaws are postponed to be solved in the closing or release stages, the cost will be several or even a dozen times higher than the original cost. However, sufficient protection of software from attacks is beyond the capabilities of most network-level and system-level security methods, such as firewall, intrusion detection, and so on, because they lack deep knowledge of software semantics and contexts. In comparison, modeling, analyzing, and evaluating software threats can help developers to identify and evaluate security problems at early design stages, and then, mitigation measures can be designed to mitigate security problems as early as possible. Threat modeling therefore has been identified as a significant part of this endeavor [3].

Threat modeling is a formal process of identifying, documenting, and mitigating potential software threats to systems. It helps to determine the highest-level security risks posed to the system [2, 4]. However, research in threat modeling has yet to mature as established techniques, and tools to aid formal analysis and evaluation of software threats are still insufficient. To address this issue, this paper presents a unified threat model to formally represent, analyze, and evaluate software threats. The unified threat tree represents the attack approaches that attackers may use to compromise the system, and the algorithm set provides analysis and evaluation methods of software threats. The unified threat model extends the threat trees [2] by adding semantic attributes, context attributes, and the algorithm set of software threat analysis and evaluation. Semantic attributes (e.g., software deployment information) and context attributes (e.g., attack situation) have been introduced into the unified threat model for software threat analysis. Attack damage and critical degree have been introduced for software threat evaluation and mitigation measure design. Mitigation measures are designed and prioritized according to the evaluation results; they are then applied to mitigate the identified software threats at an early design stage. This makes it possible to reduce the cost and security risks of software development. A case study of an online banking system is given to illustrate the applications of a unified threat model. This case study demonstrates that, in comparison to traditional threat trees, our proposed unified threat model is superior in accurately evaluating results, designing of mitigation measures, and guiding for security testing.

The rest of this paper is organized as follows. Section 2 discusses related work. Section 3 presents the unified threat model, and Section 4 gives a systematic case study of an online banking system. Section 5 concludes the paper.

2 RELATED WORK

Various approaches have been proposed for secure software analysis, evaluation, and design. In this section, we will review the current state of the art in threat analysis, risk analysis, security requirements, and security designs.

2.1 Threat analysis and risk analysis

Threat trees [2, 3] are a way to systematically examine threats. They represent software threats in a tree structure with one goal as the root node and also different ways of achieving that goal as leaf nodes. Attack trees [5] provide a methodical way of describing the security of systems based on varying attacks. These tree structure approaches lack semantic and context information of software threats, so they cannot represent, analyze, nor effectively evaluate software threats.

Petri nets can be used to model attacks and are more expressive than tree structure approaches in capturing complex attacks with multiple steps [6, 7]. Generalized Stochastic Petri nets can exploit the underlying Markov properties and analytically resolve the flaws as seen in the characteristics of the attack [8]. Aspect-oriented Petri nets exploit an aspect-oriented extension to Predicate/Transition (PrT) nets as a rigorous formalism for threat-driven modeling and verification [9]. These net structure approaches are used to analyze the software threats and to verify the properties or behaviors of software against security goals. However, they do not focus on software threat evaluation.

A model-checking [10, 11] tool has been developed for generating and analyzing attack graphs [12, 13]. However, it does not express the security impact of attacks on system functionalities.

Risk analysis [14] techniques have been widely used in security engineering. The CORAS project [15] presents a risk assessment framework based on the Unified Modeling Language (UML) techniques in the process of software development lifecycle. A UML-based architectural-level risk analysis approach is proposed in [16]. Different from these approaches, the proposed unified threat model analyzes software threats on the basis of attack paths and evaluates how the synthetic security impacts of attacks are propagated along attack paths.

2.2 Security requirements and security design

The software cost reduction (SCR) [17] requirements method is a formal method based on tables for specifying the requirements for critical software systems safety. The anti-goal approach that extends the KAOS in the goal-oriented requirements analysis generates attacks that violate security goals [18]. Goal structuring notation [19] is used in critical safety industries to improve the structure, rigor, and clarity of safety arguments. The i* framework extension [20] proposes a qualitative goal model evaluation analysis for assessing the risks of vulnerabilities, exploitation, and analyzing the impact of countermeasures on such risks. Secure Tropos [20] extends Tropos with concepts specific to security, namely ownership, permission, delegation, and trust. Different from these approaches, the proposed unified threat model evaluates software threats in a quantitative way on the basis of attack paths and results in the rank of attack paths as a basis for mitigation measure prioritization. In addition, unified threat model evaluates how the synthetic security impacts of attacks are propagated along attack paths.

A framework for security requirements elicitation and analysis is presented in [21, 22]. It is based on constructing a context for the system, representing security requirements as constraints, and developing satisfactory arguments for the security requirements. Different from this approach, we propose a unified threat model that evaluates software threats in a quantitative way, on the basis of attack paths. The evaluation results are used as a basis for mitigation measure design and prioritization.

The misuse case approach [23] supports integral development of use cases and misuse cases, and thus provides a systematic way for the elicitation of functional and security requirements. Abuse case-based security requirement analysis [24] provides a lightweight means of increasing assurance in security-relevant software. Misuse case and abuse case approaches are useful in identifying and designing mitigation measures; however, they lack the support of representation and evaluation of software threats.

UML Sec [25] is an extension of UML that allows expressing security-relevant information within the diagrams in a system specification. This approach has its strengths during the system design stage. However, it lacks the support for the quantitative evaluation of security risks in the early stage of the software development lifecycle.

3 UNIFIED THREAT MODEL

A unified threat model is a micro-model of software threats. It describes how an attacker could realize software threats using different attack approaches, and it provides a base for the analysis and evaluation of software threats. The UML class diagram 1 shows a meta-model that defines the relationships between the conceptual model elements of a unified threat model (Figure 1).

Figure 1.

Meta-model of unified threat mode.

3.1 Model definition

Definition 1. (Unified threat model). A unified threat model M is a 3-tuple (Tr, Al, H)

where Tr is a unified threat tree, Al is an algorithm set of software threat analysis and evaluation, and H is a set of statistics for historical security information.

In Definition 1, the unified threat tree represents the methods used in identifying a software threat. The algorithm set provides an approach to software threat analysis and evaluation. The statistics of historical security information is used to help in designing mitigation measures.

Definition 2. (Unified threat tree). A unified threat tree Tr is a rooted AND/OR tree defined as Tr = (N, R, At), where

  1. N is a nonempty finite set of nodes in the unified threat tree. The set N can be partitioned into three subsets, root node set Nr, intermediate node set Nm, and leaf node set Nl, such that (a) Nr ∩ Nm ∩ Nl = ∅ and (b) Nr ∪ Nm ∪ Nl = N. Nr contains the unique root node of the unified threat tree. The root node set and intermediate node set constitute the non-leaf node set Nnl, Nr ∪ Nm = Nnl. A non-leaf node is an AND/OR node.
  2. R ⊆ N × N is a set of relations in the unified threat tree. A relation, Rij ∈ R is defined as Rij = (Ni, Nj), where Ni, Nj ∈ N, Ni and Nj denote the precursor nodes and successor nodes, respectively.
  3. At is a set of attributes associated with nodes. The set At can be partitioned into three subsets, semantic attribute set SemA, context attribute set ConA, and evaluation attribute set EA, such that SemA ∪ ConA ∪ EA = At.

In Definition 2, the root node represents the final threat goal and can be decomposed into several sub-goals. A threat goal is the goal that an attacker wants to achieve by compromising the system, such as viewing confidential information, obtaining users' IDs and passwords, and so on. A leaf node represents a single attack action or weakness for an adversary to realize the final threat goal. An intermediate node is between the root node and leaf node, and it represents an intermediate threat goal that is a sub-goal of its parent goal. An intermediate node can also be decomposed into several sub-goals.

Definition 3. (AND/OR node). A non-leaf node is an AND node of which all its sub-node goals must be achieved for the AND node goal to be successful. The sub-nodes of an AND node have an AND logic relationship. A non-leaf node is an OR node; if any of its sub-node goals are achieved, the OR node goal becomes successful. The sub-nodes of an OR node have an OR logic relationship. Let NAND denote a set of AND nodes and NOR denotes a set of OR nodes. □

Definition 4. (Semantic attribute set). SemA is a set of semantic attributes associated with nodes, SemA = {Cpre, Cpost, De, En, T}, where Cpre, Cpost denote preconditions and post-conditions of a threat goal respectively, whereas De denotes software deployment information. En denotes information of a software application environment, T denotes two sources of threats, T = {Ti, To}, where Ti denotes insider threat and To denotes outsider threat.

In Definition 4, the preconditions include assumptions that we make about the attacker or the state of software that make an attack possible, such as the skills or knowledge that the attacker must possess and the level of risk that the attacker must be willing to bear. The post-conditions include that system performs malicious function and is controlled by the attacker. Software deployment information contains security information, such as security goal of deployment, approaches to manage security functions, and so on. Software application environment information contains environment information in which the software may be applied, such as description information of the software runtime parameters, runtime status, and security state. Software deployment information and application environment information are used for investigating the relationships among software threats, software deployment, and software application environments. Insider threat includes misuse, privilege abuse, and information disclosure behavior of an insider user. Outsider threats include all kinds of attacks from outside such as DoS and DDoS attack.

Definition 5. (Context attribute set). ConA is a set of context attributes associated with nodes, ConA = {S}, where S denotes attack situation.

In Definition 5, attack situation is the scenario of carrying out an attack. Security experts can obtain attack situation information from statistics of previous attacks.

Definition 6. (Evaluation attribute set). EA is a set of evaluation attributes associated with nodes, EA = {Eq, Co, P, Da}, where Eq denotes special equipment required versus no special equipment, Eq ∈ {true, false}. Co denotes attack cost, Co ∈ [0, + ). P denotes probability of attack success, P ∈ [0, 1]. Da denotes attack damage, where

display math(1)

Da is directly proportional to P and inversely proportional to Co.

In Definition 6, the value of Eq indicates whether special equipments are required or not in achieving a threat goal (represented by a node). The value of Co indicates the cost of achieving a threat goal; the larger it is, the higher the cost of achieving the threat goal. Attack cost is stated in monetary unit. The value of P indicates the probability of successfully achieving a threat goal; the larger it is, the higher the probability of successfully achieving the threat goal. The value of Da indicates the synthetic evaluation result of achieving a threat goal in the cost-effective perspective, the larger it is, the higher the degree of the security impact. It is worth pointing out the selection range of evaluation attributes in the unified threat model. They contain evaluation attributes that need to be considered when an attacker carries out attacks and focuses on the evaluation of software threats from the attacker's perspective. The evaluation attributes related to the effect of successful attacks are not included in the model, such as reputation loss, revenue loss, and repeatability of successful attacks.

Definition 7. (Attack path). Let Pa denote a set of attack paths, Pa[M] denotes M the attack path. An attack path is the minimum cut set of Tr. A node set is a cut set: (1) if it is a leaf node set of Tr and (2) if all the threat goals of these leaf nodes are achieved. The final threat goal of the root node in Tr can be achieved. Let Cu denote a cut set. A node set is a minimum cut set: (1) if it is a cut set and (2) if any leaf node is removed from the cut set, the cut set is not a cut set anymore. Let Cumin denote the minimum cut set.

In Definition 7, an attack path consists of a sequence of leaf nodes in a unified threat tree that must be met for the final threat goal to be achieved. An attack path represents a potential attack approach for an adversary to realize a software threat.

Definition 8. (Critical degree). Let Cri denote the critical degree of node i in an attack path, Ti denotes the occurrence times of leaf node i in all attack paths of a unified threat tree, and Tall denotes the occurrence times of all leaf nodes in all the attack paths of a unified threat tree, Cri = Ti/Tall. □

Definition 9. (Algorithm set of software threat analysis and evaluation). Al is an algorithm set of software threat analysis and evaluation, Al = {Al1, Al2, Al3}; Al1 denotes the model construction algorithm, Al2 denotes the attack path search algorithm, and Al3 denotes the software threat evaluation algorithm.

The unified threat model can be represented graphically. Figure 2 shows an example of unified threat model.

Figure 2.

An example of unified threat model.

3.2 Algorithm set of software threat analysis and evaluation

In the perspective of attackers, software consists of several threat goals, and every threat goals might have vulnerabilities. Attackers can compromise the software by exploiting the vulnerabilities. The unified threat model describes the decision-making process that an attacker would go through to compromise the software. It demonstrates the attacker's approaches (i.e., attack paths). Therefore, the model construction is an analysis process of software threats and is described as follows.

Take the critical asset as threat goal and the root node of a unified threat tree. Decompose this node into several sub-nodes if possible and determine the logic relationship (AND/OR) between these sub-nodes; iterate step 1 to refine the nodes in a top–down way until they become leaf nodes. End the iteration process and complete the model construction process.

The aforementioned process describes how to decompose the threat goal into sub-goals from root node to leaf nodes iteratively. The model construction algorithm has a time complexity O(n) and a space complexity O(n), where n is the number of nodes in the unified threat model. This algorithm is described in Figure 3.

Figure 3.

Model construction algorithm.

The combination of attacks forms different attack paths to achieve the final threat goal represented by root node. The process of evaluating software threats is divided into two steps: (1) to search all the attack paths that can achieve the root node of a unified threat model and (2) to assign values to evaluation attributes of leaf nodes in attack paths and calculate values to evaluation attributes of attack paths.

In a unified threat model, the root node is decomposed into several sub-nodes and then iterates the decomposition process until it reaches the leaf nodes. The logic relationship between the sub-nodes of a parent node is AND/OR. OR logic relationship obtains several sub-goals from a parent goal and increases the number of attack paths, whereas AND logic relationship extends the parent goal and increases the number of leaf nodes in an attack path. The root node and intermediate nodes are decomposed and refined. Finally, they are substituted by leaf nodes and do not appear in the attack paths.

The attack path search algorithm is designed based on the aforementioned analysis. It consists of searching attack paths that reach leaf nodes (step 2.1), AND nodes (step 2.2), and OR nodes (step 2.3). This algorithm is designed with a breadth-first method and searches the attack paths in a bottom–up way. After processing the root node, the algorithm is terminated. Let pij denote the number of attack paths that achieve Ni's sub-node Nj, j = 1, 2, …, k. If node Ni is a leaf node, OR node, and AND node, the number of attack paths that achieve Ni is 1, math formula, and math formula, respectively. This algorithm has a time complexity math formula and a space complexity math formula, where n is the number of nodes in a unified threat model, pi is the number of attack paths that achieve node Ni. The complexity of this algorithm primarily depends on the size of unified threat model and the number of AND nodes in the model. It is worth pointing out that the attack path search space for a very complex unified threat model may explode because of combinations in step 2.2. However, to our knowledge, if a unified threat model is very complex, it will be unpractical for modeling and difficult to understand. According to our experience from the case study of an online banking system, we recommend that the node number for a practical unified threat model should not be more than 30, and its AND node number should not be more than 15. For a complex unified threat model, we recommend that it should be decomposed into several practical ones. If a unified threat model is constructed following the recommendations, its attack path searching space will not explode. The attack path search algorithm is described in Figure 4.

Figure 4.

Attack path search algorithm.

The assignment for evaluating attributes of leaf nodes in a unified threat model are two types: (1) Boolean value: for example, legal versus illegal, special equipment required versus no special equipment. We choose the attribute of special equipment required versus no special equipment Eq because this attribute is an important factor for an attack. (2) Continuous value: for example, attack cost, probability of attack success, and so on. We choose the attack cost Co and probability of attack success P. These attributes are important factors when attackers determine attack approaches. The values to evaluation attributes Eq, Co, P of leaf nodes are obtained through security expert evaluations. The quantitative standard of Eq, Co, P is determined by practical experience of a security expert, statistical information of security events, and subjective expectations.

According to Definition 7, when all the goals in a minimum cut set are achieved, the final goal of the root node will be achieved. Therefore, the logic relationship between all the leaf nodes of an attack path is AND. This logic relationship determines the calculation methods of evaluation attributes for an attack path. For the Boolean evaluation attribute—special equipment required or not—when any attack represented by the leaf node requires special equipment, the attack approach is represented by the attack path, and the following calculation method can be deduced:

display math(2)

The attack cost for an attack path is the sum of all its leaf nodes. The probability of attack success for an attack path is the product of all of its leaf nodes. Therefore, the following calculation methods can be deduced:

display math(3)
display math(4)

Eq′, Co′, and P′ denote special equipment required versus no special equipment, attack cost, and probability of attack success of an attack path, respectively. Eq, Co, and P denote special equipment required versus no special equipment, attack cost, and probability of attack success of leafs nodes in an attack path, respectively. n is the number of leaf nodes in an attack path. The attack damage can be calculated in terms of Equation (1) in Definition 6. For the purpose of comparing attack damage with a different level of magnitude, we introduced normalization of attack damage to solve this problem, as is shown in Equation (5).

display math(5)

The software threat evaluation algorithm has a time complexity O(n log n) and a space complexity O(n), where n is the number of nodes in the unified threat model. This algorithm is described in Figure 5.

Figure 5.

Software threat evaluation algorithm.

4 CASE STUDY

We have applied our proposed unified threat model to a systematic study of an online banking system.

4.1 Application of a unified threat model

Online banking provides a variety of banking services to millions of users through internet. With the rapidly increasing number of users, online banking has become a major target of Internet crime, and its security problems have become serious [26]. Online banking systems usually provide services such as account management, fund transfer, automatic payments, and investments [26]. Components offering different services may be developed by different parties. In recent years, many online banking systems were attacked because of their security vulnerabilities.

In the case study, we demonstrate the application of unified threat model via the process of identifying, analyzing, and evaluating a typical software threat. This software threat results from the function of account balance inquiry and management, which is a typical service offered by online banking. This function includes actors such as users and managers, physical components such as web server and authentication database, logical components such as account balance inquiry logic, and processes such as account balance inquiry and account management. We elicited and analyzed the function requirements and security requirements in terms of use case and misuse case, and designed the system functions by a UML activity diagram. We adopt UML an activity diagram, which is widely used in object-oriented system modeling, other than the data flow diagram (DFD) [2] for system function modeling, because an activity diagram can model not just data flow but also control flow. DFD focuses on data flow. In comparison, the activity diagram can help developers to find software threats existing in both data flow and control flow. Figure 6 shows the activity diagram of account balance inquiry and management.

Figure 6.

Activity diagram of users accessing online bank.

We employed the STRIDE [2] threat categories to identify and classify software threats. We obtained several software threats from the function of account balance inquiry and management, such as “attacker viewing confidential account data on the wire,” and “an attacker elevating privilege by leveraging the service of a client's request process.”

Take the example of “an attacker who views confidential account data on the wire,” to demonstrate the approach of analyzing and evaluating software threats via unified threat model. For this software threat, the precondition Cpre is that the attacker tries to access routers or switchers in the network of an online banking system or executes some malicious program in the users' computers. The post condition Cpost is that the user's confidential account information is viewed or tampered by the attacker. The software deployment information De is that the online banking system transmits data belonging to internal interaction among different components through intranet and transmits data belonging to external interaction between the system and users through Internet. The software application environment information En is that the online banking system can provide continuous service to users and the security of application environment could be guaranteed. As is shown in Figure 6, account information is the major threat goal. However, the account information is vulnerable to the threat of “as the attacker's views confidential account data on the wire” because of the lack of sufficient protection in the interactions between users and system. To achieve the goal of this software threat (N1), an attacker can view the confidential account information on the wire (N2) or (OR relationship) attack on account password (N3), and so on. Based on the analysis earlier, we can apply algorithm Al1 to obtain the unified threat model “attacker views confidential account data on the wire,” as is shown in Figure 7.

Figure 7.

Unified threat model of viewing confidential account data on the wire.

We evaluated this software threat in terms of attack paths of unified threat models and the evaluation attribute assignment of its leaf nodes. We input the unified threat model shown in Figure 7 into algorithm Al2 and then obtain the output of attack paths of this model. The assignment of leaf nodes are evaluated according to the quantitative standards of corresponding evaluation attributes. The assignment for leaf nodes are listed in Table 1. However, how to quantify the evaluation attributes and obtain the assignment are beyond the scope of this paper because we focus on how these attribute assignments of leaf nodes are propagated along different attack paths and what degree of security impact they impose on the root node of unified threat models. We apply algorithm Al3 to this unified threat model and then obtain the ranking results of attack paths and their corresponding mitigation measures. The ranking results are listed in Table 2. The mitigation measures to attack paths are listed in Table 3. The attack path ranking results are equal to the manual calculation results according to our verification. This indicates that the algorithm set of unified threat model is correct. The results indicate that this unified threat model has four attack paths, and the attack damage value of attack path {N6} is the greatest one among all the four attack paths.

Table 1. Assignment for leaf nodes of unified threat model shown in Figure 8.
Leaf nodeAttack costProbability of attack successSpecial equipment required or not
Unprotect HTTP Traffic51.0False
Attack guess the account password100.8True
Attacker reads confidential cookie data250.9True
Listen to router traffic350.6True
Attack switch400.7True
Table 2. Attack path rank in descending order of attack damage.
Attack pathAttack costProbability of attack successSpecial equipment required or notAttack damageAttack damage (normalized)
{N6}100.8True0.08001.727
{N7}250.9True0.03601.380
{N4, N9}450.7True0.01561.017
{N4, N8}400.6True0.01501.000
Table 3. Attack paths and their corresponding mitigation measures.
Attack pathMitigation measureDescription for mitigation measure
{N6}{K4}Lock out after too many attempts. Use increasing delays for each invalid passwords.
{N7}{K5}Encrypt cookie at the server.
{N4,N9}{K1,K3}(1) Use SSL/TLS to encrypt the channel between the server and the client; could also use IPSec.
(2) Enhance the protection of switch.
{N4,N8}{K1}{K2}(1) Use SSL/TLS to encrypt the channel between the server and the client; could also use IPSec.
(2) Enhance the protection of router.

4.2 Discussion

We take the example of the software threat presented in Section 4.1 to compare our proposed unified threat model with traditional threat trees. We compared the following three aspects: evaluation of results, mitigation measures, and security testing.

4.2.1 Evaluation results

In the traditional threat trees, attack cost and probability of attack success are separately considered in the evaluation of security impact of software threats. In comparison, we introduced attack damage in the unified threat model and then evaluated security impacts in a cost-effective way by synthetically considering both impact of attack cost and probability of attack success on security in terms of attack damage. Attack damage represents the synthetic impact of attack cost and probability of attack success on security, so software threats are evaluated in a cost-effective way in the unified threat model. It makes possible to precisely evaluate the security impact of different attack paths and find the attack path with highest security impact. Table 4 gives the comparison results of attack path rankings in the two models. In threat trees, the attack path with highest security impact is {N4, N9} by only considering the attack cost and {N7} by only considering the probability of attack success. In contrast, the attack path with the highest security impact is {N6} by synthetically considering the impact of attack cost and probability of attack success. In fact, because of the lower probability of attack success in {N4, N9} and higher attack cost in {N7}, the synthetic security impact of the two attack paths decreases. In contrast, attack path {N6} has the lowest attack cost and higher probability of attack success, that is, the best cost effectiveness; it has the greatest degree of security impact in terms of synthetically considering attack cost and possibility of attack success.

Table 4. Contrast of attack path ranking drawn by unified threat model and threat trees.
Unified threat modelThreat trees
Attack path rank in descending order of attack damageAttack path rank in descending order of attack costAttack path rank in descending order of probability of attack success
{N6}{N4,N9}{N7}
{N7}{N4,N8}{N6}
{N4,N9}{N7}{N4,N9}
{N4,N8}{N6}{N4,N8}

4.2.2 Mitigation measures

Mitigation measure design is very important in analysis and evaluation of software threats. There are two key points for designing mitigation measures. First, the developers need to know which attack path has the highest security impact. Second, the developers need to know which nodes are critical for several attack paths. With the evaluation results from Table 2, attack path {N6} has the highest security impact, so it should be mitigated with the highest priority. This attack path can be realized because security vulnerability exists in the original system function design of user login control flow, as is shown in Figure 6. This vulnerability is caused by lack of reasonable limitation measure on the number of attempt times of password for a username, so attackers can try unlimited times of password for a username and guess the password by brute force attack. With the analysis, we designed the mitigation measure K4 for this attack path, the improved function design is shown in Figure 8.

Figure 8.

Improved design of activity diagram of users accessing online bank.

We added a module to detect the attempt times of password use and to be able to lock the account in a situation where the password logged in more than the limit attempt times. The improved design of system function is analyzed and evaluated by unified threat model. Because of the application of mitigation K4, the attack damage of {N6} decrease from 0.0800 (original design) to 0.0050 (improved design). The result indicates that the improved design evidently decrease the attack damage of this attack path. It is worth pointing out that no system is absolutely secure because security features (e.g., SSL) adopted in mitigation measures may suffer from their own security risk risks.

In the process of designing mitigation measures, another key point for developers is to pay attention to the leaf nodes with greater critical degree value. Mitigation measures for these leaf nodes can mitigate several attack paths at the same time. The calculation process of critical degree is described as follows:

  1. Compute the occurrence Tall of all leaf nodes in all attack paths of a unified threat tree.
  2. For each leaf node Ni, compute the occurrence of Ti, and then compute critical degree Cri by equation
    display math
  3. Rank the critical degree of all leaf nodes in a descending order.

By ranking the critical degree of leaf nodes in the unified threat model shown in Figure 8, we found that the critical degree for leaf node N4 is the greatest one (1/3). This node exists in both attack path {N4, N9} and {N4, N8}. If we design mitigation measure K1 to mitigate leaf node N4, both of the attack paths can be mitigated. Through the process of critical degree analysis, critical leaf nodes related to several attack paths can be detected. Mitigating these leaf nodes with higher priority can mitigate several attack paths that contain these leaf nodes, so it makes it possible to mitigate software threats in an effective way.

The unified threat model introduces the attack damage to find the attack path with the greatest degree of security impact and introduces the critical degree analysis to optimize the design of mitigation measures. In contrast, the threat trees cannot determine which attack path has the greatest degree of security impact and which leaf nodes are critical to attack paths, so the unified threat model is superior to threat trees in mitigation measure design.

4.2.3 Security testing

The key point for security testing is a construction of security test cases and enhancement of the test strengths to critical security function modules. Based on the mitigation measures of Table 3, in the software implementation phase, developers should add “judging the attempt times of password” and “locking the account” modules to mitigate the attack path {N6}. In the software testing phase, testers should design corresponding security test scenario for user login part. This security test scenario can be designed on the basis of the attack situation of unified threat model, for example, designing penetration testing of brute force attack and dictionary attack on username and password. In addition, according to the analysis of critical degree for leaf nodes, testers need to enhance the test strength of security function modules for mitigating the leaf nodes with a greater value of critical degree, for example, inputting a larger number of mutant data into the field of username and password for security testing.

The unified threat model introduces the attack situation to help testers design better security test scenario and it also introduces critical degree analysis to point out the security function parts needing in enhancing security testing. In comparison, the threat trees lack necessary information for designing security test scenario, so a unified threat model is superior to threat trees in guiding security testing.

4.3 Summary of the case study

We have implemented a graphical modeling tool to support the application of unified threat model in modeling, analyzing, and evaluating software threats. It is an eclipse plug-in, and its graphical user interface is shown in Figure 9.

Figure 9.

GUI of unified threat model tool.

We utilized the tool to analyze and evaluate the design of account management, fund transfer, automatic payments, and investments of an online banking system. We finally identified 51 software threats, modeled 62 unified threat models, (for clarity and comprehensibility, we modeled several unified threat models for each complex software threat), generated 279 attack paths, and provided 76 mitigation measures. Table 5 lists the statistics of our case study. Because of the complexity of online banking systems, our list of identified software threats was by no means exhaustive.

Table 5. Statistics of case study.
Number of unified threat modelNumber of Attack pathAverage number of attack path per unified threat modelNumber of software threatNumber of mitigation measure
622794.55176

5 CONCLUSION

We have presented a unified threat model to represent, analyze, and evaluate software threats for improving the trustworthiness of software designs. A systematic case study on online banking system is given to illustrate the application of this unified threat model. The case study results demonstrate that the unified threat model is superior to the traditional threat trees in the following three aspects:

  1. The unified threat model can be used to identify, analyze, and evaluate software threats in the early design stage. According to the analysis and evaluation results of software threats, corresponding mitigation measures are designed and prioritized to mitigate software threats at the early design stage. So it is possible to design high-quality software to resist identified software threats.
  2. The attack damage and critical degree that have been introduced into the unified threat model can help to find the attack path with the greatest security impact and determine the priority of mitigation measures.
  3. The attack situation that is introduced into the unified threat model can help to construct security test cases and guide security testing in the early testing stage.

From the case study, we learned that the leaf nodes with a greater value of critical degree are of great importance to the attack paths, and mitigation measures for these leaf nodes can mitigate several attack paths at the same time. Up to this point, the unified threat model is used for analyzing and evaluating design-level software threats in web applications (aiming at security goals of confidentiality, integrity, and availability). In our future work, we will apply the unified threat model to more web applications and consider how to apply it for analysis and evaluation of software threats in other kinds of software (e.g., embedded software).

ACKNOWLEDGEMENTS

This work was supported by the National Science Foundation of China (No. 90718023, 61003080, 91118003 and 61070202), Tianjin Research Program of Application Foundation and Advanced Technology (No. 10JCZDJC15700), and 985 funds of Tianjin University.

Ancillary