Quantifying Security in Secure Software Development ... - IEEE Xplore

Annual IEEE International Computer Software and Applications Conference

Quantifying Security in Secure Software Development Phases Muhammad Umair Ahmed Khan and Mohammad Zulkernine School of Computing, Queen’s University Kingston, Ontario, Canada, K7L3N6 {umair, mzulker}@cs.queensu.ca artifact (requirements specification, design document, and source code). During SSD, it is essential for the developer to know, for each phase that, how many vulnerabilities are present, what is the potential damage vulnerabilities can cause to various assets of the system the software is going to be a part of, what security requirements have to be incorporated to remove these vulnerabilities, and what is the cost effectiveness of each security requirement. Very little work has been done to help the developer in this direction. In this paper, we propose a methodology, which will enable developers to evaluate the security state of a particular SDLC artifact. We propose to perform this evaluation in an additional SDLC phase “security assessment” after requirements, design, and implementation phases. This would allow developing more secure software and particularly, prioritizing vulnerabilities based on the potential damage they can cause. Quantified information about vulnerabilities is important because if an error leading to vulnerability is not corrected in an early phase, the cost of correcting it might increase tenfold with every additional development phase [1]. In our proposed methodology, we first identify and quantify security related aspects such as number of errors, number of vulnerabilities, risk, relationships between errors and vulnerabilities, security requirements needed to remove errors, cost of implementing security requirements, assets, value of assets, and the damage that can be incurred to an asset if a vulnerability is exploited. We use the aforementioned security aspects to calculate a vulnerability index which depends on the number of existing and removed vulnerability occurrences. Moreover, we calculate a security index based on risk factors and the probable damage that can be caused to an asset in the worst case. This paper is organized in the following way. Section 2 presents the related work. Section 3 elaborates the procedure of quantifying security by presenting examples. Section 4 concludes the paper by

Abstract Secure software is crucial in today’s software dependent world. However, most of the time, security is not addressed from the very beginning of a software development life cycle (SDLC), and it is only incorporated after the software has been developed. Even when security is considered since the inception of the software development, there is no concrete way to quantify security of an SDLC artifact. This quantification is necessary to know about the security state of an SDLC artifact after each phase of software development. Moreover, this could help the software developers in allocating further resources to increase security and decrease the vulnerabilities in any software. In this paper, we use vulnerability occurrences to calculate a vulnerability index of an SDLC artifact that provides an indication about the existing vulnerabilities. Moreover, we calculate a security index by using the combined potential damage that can be caused due to vulnerabilities.

1. Introduction Secure software is becoming more and more important. However, most of the time security is dealt with in a reactive manner, where it is incorporated in a software after its development. Unfortunately, a reactive approach increases software development costs and may leave security loopholes in the software. A less common, although more cost-effective approach, is a proactive way, where security concerns are addressed throughout the software development life cycle (SDLC). For example, attack trees, misuse cases, abuse cases, and UMLSec [3, 9-12]) are used in the requirement and design phases to analyze security loopholes. Even when a pro-active approach to secure software development (SSD) is followed, there is no concrete technique to quantify security of an SDLC

0730-3157/08 $25.00 © 2008 IEEE DOI 10.1109/COMPSAC.2008.173

955

Step 1. Identify existing error and vulnerability occurrences in the SDLC artifact Step 8. Calculate Security Index

Step 2. Identify relationships between error and vulnerability occurrences

Step 7. Prioritize vulnerabilities based on the potential damage they can cause

Step 3. Identify security requirements needed to remove the errors causing existing vulnerabilities

Step 6. Calculate the total potential damage that can be caused by each vulnerability occurrence

Step 4. Calculate Vulnerability Index

Step 5. Identify assets, asset value, relationships between assets and vulnerability occurrences, potential damage to each asset, risk or likelihood of each vulnerability being exploited, and the cost of implementing security requirements

Figure 1. Overview of Security Quantification Methodology discussing the future work and conclusions.

developed and deployed, whereas our work concentrates on assessing security during the SDLC. The work presented in [6] proposes metrics such as the number of data validation checks per information flow, and the number of authentication/authorization checks per usage scenario. These metrics can indicate the number of security requirements implemented but fail to identify the security state of the overall system or an SDLC artifact. Severity and plausibility of vulnerabilities, threats, and attacks are used to calculate a weakness index, an exposure index, and an exploitability index, respectively [4]. Moreover, they also define parameters for countermeasures. In our work, we propose how to calculate the vulnerability index (corresponding to the weakness index in [4]) based on the total number of existing and removed vulnerabilities. Moreover, we propose that assessment should be done after each SDLC phase. The major differences between our work and the one described in [4] are that we define more quantification parameters, identify the interrelationships between these parameters, and propose an assessment method based upon which software developers can make sound decisions as to how the development should proceed.

2. Related Work A number of SSD processes and models have been proposed in the literature such as Comprehensive Lightweight Application Security Process (CLASP) [13], Microsoft’s Security Development Lifecycle (SDL) [15], and McGraw’s SDL [16]. Nearly all of these models and processes propose to have a risk analysis and assessment phase, after some or all of the SDLC phases. However, these SSD models do not have an explicit security assessment phase. Appropriate and Effective Guidance in Information Security (AEGIS) [14] proposes a vulnerability analysis process that is very similar to our proposed methodology. However, AEGIS does not quantify the number of vulnerabilities and the potential damage caused by them. In contrast, our methodology first quantifies vulnerabilities and the potential damage, and then uses them to calculate vulnerability and security indices that can be used to assess the vulnerability and security state of an SDLC artifact, respectively. These indices can help the developer in deciding whether the current artifact is secure enough or if rework is needed. A security requirements engineering framework that is very similar to AEGIS is proposed in [21]. However, they too like AEGIS do not provide a mathematical formalism to actually specify security state of any SDLC artifact. Moreover, the work presented in [21] concerns only the requirement engineering phase. Many vulnerability and security assessment tools have been developed [17-19]. However, nearly all of these efforts are concentrated in finding vulnerabilities in the software that is developed and deployed. Moreover, most of these tools (e.g., Nessus [17]) find vulnerabilities in network-based systems. Clearpoint [20] is one of the methodologies to assess the overall security state of a software system that also takes into account the organizational security policies. The main difference between our work and the ones in [17-20] is that they can only be used after the software has been

3. Quantification Methodology An overview of our proposed methodology is given by the activities in Figure 1. In our methodology, we first identify all the vulnerabilities and errors that cause these vulnerabilities in a particular SDLC artifact (Step 1). Next, we define the many-to-many relationship that exists between error and vulnerability occurrences (Step 2). After that, we identify security requirements that are needed to remove errors (Step 3). Next, we calculate the vulnerability index based on the number of vulnerabilities that were removed and the total vulnerabilities found initially (Step 4). To make more sound decisions about which vulnerability should be in a higher priority to be removed, we take into account the likelihood of each vulnerability being exploited, the potential damage that can be caused to each asset, and

956

the implementation cost of each security requirement needed to remove errors leading to a particular vulnerability (Step 5). Next, we calculate the total potential damage that may be caused by each vulnerability occurrence in the worst case (Step 6). After this, we prioritize all the vulnerabilities based on the difference between the total possible damage that each vulnerability can cause and the implementation cost of the security requirements needed to remove the errors that cause the corresponding vulnerability (Step 7). In the last step, we calculate the security index of the SDLC artifact under question by using the total damage that can be caused to the assets before and after the removal of vulnerabilities (Step 8). We further explain the steps of our methodology in the following subsections using examples.

VSQLO1, VBOO1, VBOO2 and EIVO1, EIVO2, EIVO3, respectively. Table 1. Relationships between vulnerability and error occurrences Error Occurrences

EIVO1 EIVO2 EIVO3

Vulnerability Occurrence VSQLO1 VBOO1 VBOO2 X X X X

3.3. Step 2: Identify vulnerability and error occurrence relationships We need to represent the many-to-many relationships that exist between each vulnerability and error occurrence as presented in Table 1 for the vulnerabilities and errors mentioned in Step 1. This relationship information is needed to find which errors should be fixed to remove a particular vulnerability.

3.1. Preliminaries Before quantifying security, we need to have a list of all the possible vulnerabilities and their corresponding errors that could be present in any software. We define vulnerability as a weakness in the software that can be exploited to cause harm, and an error as a defect or flaw in any SDLC artifact. It should be noted that although all vulnerabilities can only be exploited when the software is in its operational phase however, each vulnerability can be traced back to at least one or more errors in any of the SDLC artifacts. Much work has been done on identifying vulnerabilities and their corresponding errors [e.g., 1, 2, 5, 7, 13]. The vulnerabilities and errors can be denoted as V1, V2, …, Vn and E1, E2, …, Em, respectively (where Vi is the ith vulnerability and Ei is the ith error). The vulnerabilities and errors can be further sub-categorized based on the time of introduction proposed in [5] which may serve as checklists while looking for them in a particular SDLC artifact. We recommend to use the checklist-based inspection technique [8] to find vulnerabilities.

3.4. Step 3: Identify security requirements A security requirement can be defined as a requirement in the requirement specification phase, a design decision in the design phase, or a best code practice in the implementation phase, required to remove an error that leads to any vulnerability. We need to identify all the security requirements that have to be satisfied to remove the errors leading to vulnerabilities. One or more security requirements are needed to remove each error occurrence. These can be represented by SR1E1O1, SR2E1O1, …, SRnE1O1 (where SRiEkOj is the ith security requirements to remove the jth occurrence of the kth error). For example, three separate occurrences of the input validation security requirement are required to be met to remove the error occurrences mentioned in Step 1. These requirements can be represented as SRIVEIVO1, SRIVEIVO2, and SRIVEIVO3.

3.2. Step 1: Identify vulnerabilities and errors

3.5. Step 4: Calculate vulnerability index

Any vulnerability or error can occur more than once in any SDLC artifact and all such occurrences need to be identified. We can represent vulnerability and error occurrences as VXO1, VXO2, …, VXOn and EYO1, EYO2, …, EYOm, respectively (where VXOi is the ith occurrence of vulnerability X and EYOi is the ith occurrence of error Y). Suppose that one SQL injection (SQL) and two buffer overflow (BO) vulnerability occurrences exist in the source code of a software due to input validation (IV) errors in the source code. We can represent these vulnerabilities and errors as

The total number of vulnerability occurrences in the requirements specification, design document, and the initial source code can be represented by VRT, VDT, and VCT, respectively. Moreover, the total number of vulnerability occurrences in the requirements specification, design document, and the source code that have been removed, can be represented by VRR, VDR, and VCR, respectively. We can calculate the vulnerability index of the requirements specification, design document, and the source code using Equations 1, 2, and 3, respectively.

957

VRR * 100 VRT VDR VIDES = * 100 VDT VCR * 100 VICOD = VCT VIREQ =

exploitation of the vulnerabilities VSQLO1, VBOO1, and VBOO2 is 0.1, 1, and 1, respectively. The maximum possible damage that can be caused by a vulnerability occurrence to an asset can be represented as DAnVXOY (where DAi VjOk is the damage caused to the ith asset by the kth occurrence of the jth vulnerability). DAnVXOY is the product of the value of an asset and the risk of the vulnerability being exploited to cause harm to that asset (based on vulnerability plausibility in [4]). Hence, the values of DAOSVSQLO1, DAPFVBOO1, and DACAIVSQLO1, DAOSVBOO2 would be 100,000,000, 10,000, 100, and 100,000, respectively.

(1) (2) (3)

The vulnerability index indicates the percentage of vulnerability occurrences that have been removed from the corresponding artifact. The index can have a value between zero and hundred, where zero means that none of the initial vulnerabilities have been removed, while a value of hundred means that all the vulnerabilities that were identified have been removed. Assuming that only SRIVEIVO2 and SRIVEIVO3 (from Step 3) were implemented, VCT and VCR will have a value of 3 and 2, respectively. Hence, VICOD will be 66.66% (as we are considering the source code artifact of the SDLC).

Table 2. Relationships between assets and vulnerability occurrences Vulnerability Occurrences VSQLO1 VBOO1 VBOO2

ACAI

Write Attack, DACAI VSQLO1 = 100,000,000 and CVSQLO1 = 1,000

AOS

Denial of Service Attack, DAOSVSQLO1 = 10,000 and CVSQLO1 = 1,000

3.6. Step 5: Identify damage to assets and implementation cost of security requirements Assets

The overall security state of an SDLC artifact indicated by the vulnerability index does not help in making any informed decisions about the remaining vulnerabilities. To be able to decide effectively about the remaining vulnerabilities, we need to identify assets and their values, the relationships between assets and vulnerabilities, risk or likelihood of each vulnerability being exploited, the potential damage caused by each vulnerability occurrence to each asset, and the cost of implementing security requirements to remove a vulnerability occurrence. An asset can be defined as a resource belonging to the system the software is going to be a part of. An asset can be information (e.g., data) or service (e.g., online service). Assets can be represented as A1, A2, …, An (where Ai is the ith asset). For example, a software has customer account information (CAI), online service (OS), and printing facility (PF) as assets. These assets can be represented as ACAI, AOS, and APF, respectively. Moreover, assume that the maximum damage that can result from misusing ACAI, AOS, and APF is 1,000,000,000, 100,000, and 100, respectively. Assume that for the vulnerabilities identified in Step 1, VSQLO1 threatens ACAI and AOS, VBOO1 threatens APF, and VBOO2 threatens AOS (VSQLO1, VBOO1, and VBOO2 are vulnerabilities from Step 1). We define risk as the probability or likelihood of any vulnerability being successfully exploited. The value of risk can range between 0 and 1 (0 meaning no probability and 1 meaning highest probability). Suppose that the risk of

APF

TDVXOY

100,010,000

Denial of Service Attack, DAOSVBOO2 = 100,000 and CVBOO2 = 1,000 Write Attack, DAPFVBOO1 = 100 and CVBOO1 = 1,000 100

100,000

The implementation cost of all the security requirements needed to be met for removing errors causing a vulnerability occurrence can be represented as CVXOY (where CVi Oj is the implementation cost of all the security requirements needed to remove the errors causing the jth occurrence of the ith vulnerability). Suppose that the value of CVSQLO1, CVBOO1, and CVBOO2 is 1,000 each. All the above information can be summarized in Table 2. The table also provides information about the worst type of attack (write attack, read attack, or denial of service attack) that a particular vulnerability occurrence can allow for a particular asset.

3.7. Step 6: Calculate total damage The total potential damage caused by a vulnerability occurrence can be represented as TDVXOY (where TDVi Oj is the total potential damage caused by the jth occurrence of the ith vulnerability) and calculated as shown in Equation 4.

958

where Y is the total number of occurrences of vulnerability X. The total damage caused by all the vulnerabilities can be represented as TD and calculated as

m

TDVXOY =

∑ DA V O n X

(4)

Y

n=1

In Equation 4, m is the number of assets. Hence, in the case of our example the values of TDVSQLO1, TDVBOO1, and TDVBOO2 will be 100,010,000, 100, and 100,000, respectively as shown in Table 2.

X

TD =

SI =

(5)

If the value of PVXOY is positive for any vulnerability occurrence VXOY, then it is cost-effective to remove it. Moreover, a higher value of PVXOY means a higher priority for removal. In case of our example, the priorities will be 100,009,000, -900, and 99,000 for VSQLO1, VBOO1, and VBOO2, respectively. It is evident from the priorities that VSQLO1 deserves much more attention as compared to VBOO1. To remove a vulnerability occurrence, it is not necessary that the cost of removing should be less than the potential damage. This decision will depend on the level of security needed for that particular software and the availability of resources. It might be the case that a vulnerability occurrence is removed even if the cost of removing it is 100 times more than the potential damage.

The overall security state of a specific SDLC artifact at the end of every iteration can also be defined. As mentioned earlier, a secure software is the one that cannot be exploited to cause any harm. Therefore, we need to know the difference between the damage (harm) that would have been caused before and after the removal of vulnerabilities. As already defined, total damage that can be caused by one vulnerability occurrence is TDVXOY. The total damage that can be caused by all the occurrences of the vulnerability VX can be represented as TDVX and can be calculated as m

(8)

4. Conclusions and Future Work Security is a crucial aspect of software in today’s world. A better way to develop secure software is to incorporate security from the very beginning of software development. Moreover, the developer should be able to know about vulnerabilities in different artifacts of SDLC during development so that these can be removed as soon as possible. Otherwise, removing the vulnerabilities in a later phase will increase the cost significantly. This paper provides a methodology to quantify vulnerabilities in the requirements specification, design document, and source code, during the development life cycle. Using this methodology, the developers can visualize the relationships between errors, the

Y

X

TDFirstIteration − TDLastIteration TDFirstIteration

The value of SI can range from 0 to 1. If it is closer to one, then the software is more secure (one being most secure), while a value closer to zero represents less secure software. Assuming that only SRIVEIVO2 and SRIVEIVO3 were implemented, and hence only VBOO1 and VBOO2 were removed till the end of the last iteration of our methodology on our example, we can calculate the SI of the source code as follows SI = (100,110,100 – 100,010,000) / 100,110,100 SI = 0.0009 As the value is very close to 0, according to our defined criteria, our example source code is extremely insecure with respect to the damage that can be caused. It should be noted that while the vulnerability index indicates how many vulnerabilities are remaining in an SDLC artifact, the security index measures the extent of the damage that may be caused due to the remaining vulnerabilities.

3.9. Step 8: Calculate security index

∑ TDV O

(7)

where X is the total number of unique vulnerabilities. TD indicates the total damage that can be caused by the vulnerabilities that exist in any SDLC artifact. If TD is calculated before any vulnerability is removed and after the rework has been completed on that particular SDLC artifact (some or all vulnerabilities have been removed), their difference can indicate the security state of the system. We define a Security index (SI) as

Vulnerabilities can be prioritized based on the damage they can cause and the cost-effectiveness of their removal. The priority of a vulnerability VXOY can be represented as PVXOY (where PVi Oj is the priority of the jth occurrence of the ith vulnerability) and calculated as

TDVX =

n

n1 =

3.8. Step 7: Prioritize vulnerabilities

PVXOY = TDVXOY - CVXOY

∑TDV

(6)

m=1

959

vulnerabilities caused by errors, corresponding security requirements, the cost of implementation of security requirements, and the damage each vulnerability can cause to each asset. The above information allows the developer to, in general, make the software more secure, and in particular, prioritize the vulnerabilities based on the damage they can cause. One argument against such a methodology can be that security is a non functional requirement that cannot be completely quantified. This is partially true. However, we have tried to link security to some tangible entities such as cost of implementation, damage caused to assets, and error occurrences, which can easily be quantified. Our plan for future work includes extending this methodology for generating security test cases based on the implemented security requirements. More extensive test cases will be generated for the vulnerabilities which are known to cause excessive damage.

Languages and Systems (TOOLS-37’00), Sydney, Australia, 2000, pp. 120 –131. [11] I. Alexander, “Misuse Cases: Use Cases with Hostile Intent”, IEEE Software, 2003, vol. 20(1), pp. 58–66. [12] J. McDermott, and C. Fox, “Using abuse case models for security requirements analysis”, In Proc. of the 15th Annual Computer Security Applications Conference (ACSAC '99), AZ, USA, 1999, pp. 55 – 64. [13] CLASP http://www.owasp.org/index.php/Category:OWASP_CLASP _Project. Last Accessed March 2008. [14] I. Flechais, M. A. Sasse, and S. M. V. Hailes, “Bringing Security Home: A process for developing secure and usable systems”, In Proc. of the 2003 New Security Paradigms Workshop, Switzerland, 2003, pp. 49-57. [15] M. Howard and S Lipner, The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software, Microsoft Press, 2006. [16] B. Chess and G. McGraw, “Software security”, IEEE Security and Privacy Magazine, 2004, Vol 2(2), pp. 53–84. [17] Nessus .Configuring Nessus to perform local security checks on Unix hosts. http://nessus.org/documentation/index.php?doc=ssh Last Accessed 30-01-2008. [18] STAT Scanner. http://www.lumension.com/ Last Accessed 30-01-2008. [19] F. Guo, Y. Yu, and T. Chiueh, “Automated and Safe Vulnerability Assessment”, In Proc. of the 21st Annual Computer Security Applications Conference,Tucson, AZ, USA, 2005, pp. 150-159 . [20] Clearpoint. http://www.clearpointmetrics.com Last Accessed 30-01-2008. [21] C. Haley, R. Laney, J. Moffett, and B. Nuseibeh, “Security Requirements Engineering: A Framework for Representation and Analysis”, (to appear in) IEEE Transactions on Software Engineering, 2007.

Acknowledgement This research work is partially supported by the Natural Sciences and Engineering Research Council (NSERC) of Canada

5. References [1] S. Bosworth and M. E. Kabay, Computer Security Handbook, 4th Edition, Wiley, NY, USA, 2002. [2] M. A. Hadavi, “Vulnerability Prevention in Software Development Process”, In Proc. of ICCIT, Dhaka, Bangladesh, 2007. [3] J. Juerjens, Secure Systems Development with UML, Springer, Berlin, Germany, 2005. [4] M. Masera and I. N. Fovino, “Parameters for Quantitative Security Assessment of Complex Systems”, In Proc of the 37th Annual IEEE/IFIP International Conference on Dependable Systems and Networks. Workshop on Assurance Cases for Security: The Metrics Challenge, Edinburgh, UK, 2007. [5] C. E. Landwehr, A. R. Bull, J. P. McDermot, and W. S. Choi, “A Taxonomy of Computer Program Security Flaws with Examples”, NRL Report 9591, Naval Research Laboratory, November 1993. [6] R. Scandariato, B. De Win, and W. Joosen, “Towards a Measuring Framework for Security Properties of Software”, In Proc. of QoP’06, VA, USA, 2006, pp. 27-29. [7] M. Dowd, J. McDonald, and J. Schuh, The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities, Addison Wesley, MA, USA, 2007. [8] T. Gilb, and D. Graham, Software Inspection, Addison Wesley, MA, USA, 1993. [9] B. Schneier, Secrets and Lies: Digital Security in a Networked World, John Wiley & Sons, New York, NY, USA, 2000. [10] G. Sindre, and A. L. Opdahl, “Eliciting Security Requirements by Misuse Cases”, In Proc. of the 37th International Conference of Technology of Object-Oriented

960