Security Requirements Prioritization Based on Threat ... - Springer Link

Security Requirements Prioritization Based on Threat Modeling and Valuation Graph Keun-Young Park, Sang-Guun Yoo, and Juho Kim* Sogang University, Department of Computer Science and Engineering, Seoul, Korea {kypark,sangguun,jhkim}@sogang.ac.kr

Abstract. Information systems manage assets that are critical for the business processes of organizations. Therefore, it is imperative that information systems be guaranteed and secured from the beginning of their development life cycle. Several approaches such as misuse cases, attack tree, and threat modeling have been proposed by way of security requirements. However, these approaches do not prioritize security requirements, though it is necessary in many cases. For example, when the security budget is insufficient, security requirements need to be prioritized to decide what will be developed and what will not. In this paper, we propose an extension to threat modeling by creating a process that allows the prioritization of security requirements via the valuation of assets, threats, and countermeasures modeled in a tree-like structured graph that we refer to as a “valuation graph.” Keywords: Security Requirement Prioritization, Threat modeling.

1

Introduction

Recently, there has been an increase in the number of attacks on information systems because these systems manage important organizational assets. Moreover, the increasing complexity of applications and services implies a greater probability of security breaches [1]. This is why it is essential to guarantee and secure information systems from the beginning of their development life cycle. Although the inclusion of security into the early phases of the development of information systems is cost effective, in majority of software projects, security is dealt with only after the system has been designed, developed, and put into operation. Quite often, this is due to inappropriate management of system security requirements. Many approaches have been proposed to solve this problem, such as the Trustworthy Computing Security Development Lifecycle [2] used by Microsoft, which includes security concepts spanning the whole development process. Other approaches such as misuse cases [3], attack tree [4], and threat modeling [5] help in the elicitation and specification processes of security requirements through an analysis of threats, vulnerabilities, and countermeasures. However, these approaches exclude the prioritization process, which is necessary in many cases. For example, when there is *

Corresponding author.

G. Lee, D. Howard, and D. Ślęzak (Eds.): ICHIT 2011, CCIS 206, pp. 142–152, 2011. © Springer-Verlag Berlin Heidelberg 2011

Security Requirements Prioritization Based on Threat Modeling and Valuation Graph

143

insufficient security budget, it is necessary to prioritize security requirements to decide which requirements will be developed and which will not. Another reason for prioritization of security requirements is when security functionalities of existing systems need to be developed following attacks; in this case, it is very important to first mitigate the most harmful attacks, beginning by developing the modules that have more priority. Prioritization of requirements is often used in software engineering processes, but the same methodologies cannot be used with efficiency when dealing with security requirements because there are additional elements that are unique to security. In this paper, we propose an extension to threat modeling, creating a process that allows for the prioritization of security requirements via the valuation of assets, threats, and countermeasures modeled in a tree-like structured graph referred to as a “valuation graph.” The rest of the paper is organized as follows. In section 2, we briefly explain some terms that are important in security requirements engineering and we detail our approach. Then, in section 3, we illustrate our proposal using a case study. Finally, by way of a conclusion, we review the main points of the paper and discuss possible future works.

2

Proposed Methodology for Security Requirements Prioritization

2.1

Terminology

To specify security requirements, it is critical to first understand the concepts underlying security engineering. The following list defines the security-oriented terms that will be used during the remainder of this paper [10]. – – – – –

2.2

Asset: this is a resource of value such as the data in a database or on a file system, or a system resource. Threat: this is a potential occurrence (malicious or otherwise) that may harm an asset. Vulnerability: this is a weakness that makes a threat possible. Attack (or exploit): this is an action taken to harm an asset. Countermeasure: this is a safeguard that addresses a threat and mitigates a risk. Security Requirements Prioritization Based on Threat Modeling and Valuation Graph

Several publications such as [5], [6], and [7] have analyzed the relationship between existing security requirements and assets to create support mechanisms that aid the software development process. For example, the main components that influence and are influenced by security requirements are detailed in [7]. These authors agree that security requirements are created to protect the assets of organizations, and that between these two elements (assets and security requirements), many other concepts

144

K.-Y. Park, S.-G. Yoo, and J. Kim

play a role, such as vulnerability, risk, threats, and harm. The main idea of our approach is to value the common elements that comprise the relationship between security requirements and assets, and to then draw them in an easy to understand model. Our approach comprises eight steps, organized in three layers (see Fig. 1). Layer 1: Thread Modeling 1) Identify Asset

3) Identify Threats

5) Identify Countermeasures

2) Draw and Value Asset

4) Draw Threats and Calculate their Impacts

6) Draw and Value Countermeasures

Security Requirements

Valuation Graph

Layer 2: Valuation modeling

7) Calculate Priority of Countermeasures

8) Sort Countermeasures

Security Requirements Prioritization

Layer 3: Countermeasures Prioritization

Fig. 1. Steps of security requirements prioritization methodology organized per layers

The first layer follows the traditional threat modeling approach, which deals with security requirements elicitation. The second layer, called valuation modeling, enables the measurement of the main components involved in the security requirements (assets, threats, and countermeasures), thus generating the valuation graph for prioritization purposes. A valuation graph is a diagram that stakeholders and developers can use to easily visualize the relation between the importance of an asset, the degree of harm (impact) associated with threats, and the cost of developing and using the modules that protect the assets from threats. Finally, the third layer, called countermeasures prioritization, allows for the calculation of the priority and the sorting of security requirements according to importance. The eight steps composing these three layers are described below. y Step 1: Identify assets: In this step, a list of all critical assets of the system is created. Assets are very important to the business, so this step is not a stakeholderonly decision. The business users must also participate in determining which assets cannot be compromised and which can be without serious negative consequences. Every piece of information about the organization needs to be collected, categorized, organized, and analyzed. These information assets can comprise databases, data files, archived information, continuity plans, operational and support procedures, etc. y Step 2: Draw and value assets: Once the list of assets requiring protection is recognized, the initial part of the valuation graph can be created. This graph begins with a node containing the name of the system; the assets of the system are drawn in new nodes that are joined to the initial node via edges (see Fig. 2).


145

Fig. 2. Assets in valuation graph

Once the assets have been drawn, it is necessary to value them. Valuation can be performed using different valuation models. The calculated value of each asset must to be expressed as a number between 1 (low importance) and 5 (high importance). This value is very important during security requirements prioritization; therefore, this step needs to be taken seriously. In the case of small organizations, it can be difficult to value assets; in these situations, a simple security oriented asset valuation approach can be adopted (Table 1). Once the value of each asset is recognized, these values are entered into the valuation graph, and the value is written in the node of each asset. Table 1. Default asset valuation Type of asset Restricted

Confidential Public

Description Most sensitive business information. The unauthorized disclosure of this information could have a serious negative impact on the organization. Less sensitive business information. The unauthorized disclosure of this information could have a negative impact on the organization. Information approved for public disclosures.

Value 5

3 1

y Step 3: Identify threats per asset: In this step, the most important task is to adopt the mindset of an attacker, identify possible points of attack, and analyze the vulnerabilities of exposed assets. Existing publications and approaches can be used in this step, such as vulnerabilities lists (e.g. Web Application Security Consortium Threat Classification V1.0) or STRIDE. STRIDE [6], which is an acronym for Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege, is one the most popular threat modeling methodologies. y Step 4: Draw threads and calculate their impacts: Once threats have been identified, they are drawn in the valuation graph using one node per threat and joining them to the assets via edges (see Fig. 3).

146


Fig. 3. Threats in Valuation Graph

The impact is the level of harm that an attack can cause to an asset when the threat is exploited. This is a number between 0 and 5, where 5 is the highest level of harm a threat can cause. The impact of the threat is valued using (1):

Damage+Recoverability+Likelihood (1) 3 Damage is a value that represents the harm caused by an attack when the threat is exploited, and this value is assigned according to Table 2. Recoverability is a value that represents the difficulty in recovering from a successful attack that exploited a given threat. This value is assigned according to Table 2. Likelihood is a value between 1 and 5 that expresses the possibility of the threat being exploited. This value is assigned according to Table 3, which evaluates the effort needed to exploit the threat, and the statistical level of occurrence of this threat in real implementations. Impact=

Table 2. Damage and recoverability valuation Value 0 1 3 5

Damage No damage is caused by the threat Individual user data is compromised or affected Group data is compromised or affected Complete system data is compromised or affected

Recoverability Easy to recover Hard to recover Impossible to recover

Table 3. Likelihood valuation Effort Occurrence Low frequency of occurrence Acceptable frequency of occurrence High frequency of occurrence

Very hard 1 2 3

Several steps required 2 3 4

Easy to perform 3 4 5

Once the impacts of the threats are calculated, these values are entered into the valuation graph (see Fig. 3). y Step 5: Identify countermeasures: Once the possible threats have been recognized, it is necessary to identify countermeasures. In this step, approaches like misuse cases and attack trees can be used to diagram and analyze the relation


147

between threats, vulnerabilities, and countermeasures. Industry standards and case studies of other similar systems also can be used. y Step 6: Draw and value countermeasures: Once the countermeasures are identified, they are drawn in the valuation graph via new nodes between assets and threats, joining the assets that are protected and the threats that are mitigated. When a threat is related to various countermeasures, it is necessary to clarify whether one of the countermeasures is enough to mitigate the threat, or whether all or parts of the countermeasures are necessary to mitigate the threat. In the valuation graph, logical operations (e.g., AND and OR) are used. AND is represented by a line, and OR is represented by a curve in the middle of the edges (see Fig. 4). Once the countermeasures are identified, their cost must be valued. When this value is measured, it is not enough to calculate only the development cost of the countermeasure because this cost is only partial. It is also necessary to calculate the user training cost, maintenance cost, and other important indirect costs of the countermeasure; this implies a calculation of the total cost of ownership (TCO). The TCO, which is a financial estimate designed to help consumers and enterprise managers assess direct and indirect costs, can be calculated using techniques such as those proposed in [8] and [9]. Once each countermeasure’s TCO is calculated, this value is transformed into a number between 1 and 5, where 5 represents the highest cost of ownership. After this transformation, the values are entered into the valuation graph.

Fig. 4. Countermeasure assessment in the valuation graph

y Step 7: Calculate priority of countermeasures: As a result of the first six steps of our proposed methodology, the security requirements (countermeasures) and valuation graph are generated and, using this information, it is possible to prioritize the security requirements. First, the total impact (TI) of threats that a countermeasure mitigates is calculated. TI is the summation of the impacts of each threat related to the countermeasure. If a threat is related to more than one countermeasure, its impact is divided by the number of edges if the relation is an AND; the impact is summed if it the relation is an OR. Next, the gain (G) of each countermeasure is calculated by subtracting the countermeasure TCO from its TI. Finally, the priority (P) of the countermeasure is calculated by summing the G of

148


the countermeasure and the value of assets that the countermeasure protects. Calculated values (P, G, and TI) are organized in Table 4, and these values also are drawn in the valuation graph (see Fig. 4); it is recommended that this option be incorporated into the tool that manages the valuation graph. Table 4. Priority-gain-impact table Countermeasure Countermeasure 1 Countermeasure 2 Countermeasure 3 Countermeasure n

Priority 3 4 10 xxx -2.5

Gain -2 -1 5

Total Impact 3 2 6

-3.5

1.5

y Step 8: Sort countermeasures: Once the priorities of each countermeasure have been calculated, they are sorted according to priority. If two or more countermeasures have the same priority, the second and third fields used to determine the order are the asset value and the countermeasures TCO. With this prioritization, risk management becomes easier, permitting visualization of the importance and impact of assets, countermeasures and threats using a simple model.

3

Case Study

In this section, we demonstrate how our proposed method can be applied to real systems through the specific example of an e-commerce web application that controls the bill-payment data of customers and the catalog of products sold on this site. After eliciting the functional requirements of the system, three main logics were identified: bill payment, administration interface, and product catalog (see Fig. 5). The eight steps of the security requirements prioritization process for this example are noted below.

Fig. 5. Diagram of an e-commerce site


149

y Step 1: Identify assets: The assets that the organization wants to protect were identified based on functional requirements. The identified assets are authentication data, bill payment data, and the product catalog. y Step 2: Draw and value assets: Once the assets have been recognized, they are drawn into the valuation graph. Next, the assets are valued using default asset valuation:

Bill payment data is restricted information, thus the assigned value is 5.

The product catalog is public information, thus the assigned value is 1.

Authentication data is restricted information, thus the assigned value is 5.

Finally, these values are entered into the valuation graph (see Fig. 6).

Fig. 6. E-commerce application assets valuation

Note: In this part of the paper, we will only analyze the bill payment data asset because this is sufficient to understand the use of our approach. y Step 3: Identify threats per asset: Threats for bill payment data were identified using the threat classification for Web application version 1.0, published by the Web Application Security Consortium. The identified threats are as follows: denial of service, brute force, spoofing, SQL injection, eavesdropping and repudiation. y Step 4: Draw threats and calculate their impacts: The identified threats are drawn in the valuation graph and the impact of each threat is calculated using (1): Threats Denial of service Brute force Spoofing SQL injection Eavesdropping Repudiation

Damage 5 1 3 3 3 1

Likelihood 4 5 2 3 3 3

Recoverability 1 1 5 3 1 3

Impact 3.3 2.3 3.3 3 2.3 2.3

Finally, the calculated impact values are entered into the valuation graph (Fig. 7).

150


System E-Commerce Web Application

Asset 5

1

5

Bill Payment Data

Product Catalog

Authentication Data

Threat

...

...

3.3

2.3

3.3

3

2.3

2.3

Denial of Service

Brute Force

Spoofing

SQL Injection

Eavesdropping

Repudiation

Other threats

Fig. 7. E-commerce application threats valuation

y Step 5: Identify countermeasures: The countermeasures to threats were taken from vulnerabilities lists solutions and previous, similar cases. The identified countermeasures for bill payment data were as follows: an authentication system, query validation, a secure channel, and an auditing system. y Step 6: Draw and value countermeasures: Countermeasures and relationships are entered into the valuation graph. Repudiation requires authentication and auditing systems in order to be completely mitigated, so the logical operator AND is used (see Fig. 8). The TCO of each countermeasure was calculated using data from previous, similar projects. TCOs were converted to a value between 1 and 5 and entered into the valuation graph.

Fig. 8. E-commerce application countermeasures valuation


151

y Step 7 and 8: Countermeasure Prioritization: The total impact, gain and priority of countermeasures are calculated and the priority-gain-impact table is created (Table 5). These values are also then stored in the valuation graph (see Fig. 9). Table 5. E-commerce application priority-gain-impact table Countermeasure Authentication system Query validation Secure channel (SSL) Auditing system

Priority 12.05 5 6.5 1.15

Gain 7.05 0 1.3 -3.85

Total impact 10.05 3 2.3 1.15

Fig. 9. E-commerce application valuation graph with prioritization information

Finally, the countermeasures are sorted according to priority, asset value, and countermeasures’ TCOs (Table 6). Table 6. E-commerce application prioritization list Countermeasure Authentication system Secure channel (SSL) Query validation Auditing system

4

Priority 12.05 6.5 5 1.15

Asset value that protects 5 5 5 5

Counter-measure TCO 3 3 1 5

Conclusion

Not every project has sufficient budget to protect itself from all threats; therefore, it is not possible to ensure absolute security. However, we can deal with absolute risk acceptance, managing a balance between what is possible and what is acceptable via the risk management process (accept, transfer, remove, and mitigate the risk). For the purposes of this risk management, the prioritization of security requirements is

152


indispensable. In this paper, we have proposed a methodology for prioritizing countermeasures that significantly aid the risk management process. The use of a valuation graph helps to show stakeholders why countermeasures are necessary, visualizing the danger relationship between threats and assets. On the other hand, a valuation graph also gives the system developer a model to easily understand the threats that a system is exposed to. Additionally, this graph enables the visualization of all the important values of threats, countermeasures, and assets, allowing stakeholders and developers to analyze and prioritize security requirements. In the future, we plan to polish this modeling process and develop a tool with which to manage it.

References 1. Walton, J.P.: Developing an Enterprise Information Security Policy. In: Proc. 30th Annual ACM SIGUCCS Conference on User Services, pp. 153–156. ACM, New York (2002) 2. Lipner, S.: The Trustworthy Computing Security Development Lifecycle. In: Proc. Computer Security Applications Conference, pp. 2–13. IEEE Press, Tucson (2004) 3. Sindre, G., Opdahl, A.: Capturing Security Requirements through Misuse Case. In: Proc. 14th Norwegian Informatics Conference (NIK 2001), Tromso, pp. 26–28 (2001) 4. Diallo, M.H., et al.: A Comparative Evaluation of Three Approaches to Specifying Security Requirements. In: Proc. International Working Conference on Requirement Engineering: Foundation for Software Quality(REFSQ 2006), Luxembourg (2006) 5. Myagmar, S., Lee, A., Yurcik, W.: Threat Modeling as a Basis for Security Requirements. In: Proc. Symposium on Requirements Engineering for Information Security SREIS, Chteseer, Paris, pp. 94–102 (2005) 6. Swiderski, F., Snyder, W.: Threat Modeling. Microsoft Press (2004) 7. Firesmith, D.: Specifying Reusable Security Requirements. Journal of Object Technology 3, 61–75 (2004) 8. Smith, J., Schuff, R., Louis, R.: Managing your IT Total Cost of Ownership. Communications of the ACM 45, 101–106 (2002) 9. MacCormack, A.: Evaluating Total Cost of Software Platforms: Comparing Apples, Oranges and Cucumbers, http://ideas.repec.org/p/reg/wpaper/168.html 10. Threats and countermeasures, http://msdn.microsoft.com/en-us/library/aa302418.aspx