A Survey on Requirements and Design Methods for Secure Software Development*

A Survey on Requirements and Design Methods for Secure Software Development* Muhammad Umair Ahmed Khan and Mohammad Zulkernine School of Computing Queen’s University Kingston, Ontario, Canada K7L 3N6 {umair & mzulker}@ Technical Report No. 2009–562 Copyright © Muhammad Umair Ahmed Khan and Mohammad Zulkernine 2009 This report should be cited as follows: M. U. A. Khan and M. Zulkernine, A Survey on Requirements and Design Methods for Secure Software Development, Technical Report No. 2009 – 562 , School of Computing, Queen’s University, Kingston, Ontario, Canada, August 2009. i ABSTRACT Traditionally, security of software is not considered from the very beginning of a software development life cycle, and it is only incorporated in the later stages of development as an afterthought. As a consequence, there are increased risks of security vulnerabilities that are introduced into software in various stages of development. To avoid security vulnerabilities, there are many secure software development efforts in the directions of secure software development life cycle processes, security specification languages, security requirements engineering processes, secure design languages, and secure design guidelines. In this paper, we compare and contrast various secure software development processes based on a number of characteristics that such processes should have. We also analyze security specification languages with respect to desirable properties of such languages. Furthermore, we identify activities that should be performed in a security requirements engineering process to derive comprehensive security requirements. We compare different security requirements engineering processes based on these activities. Finally, we investigate the state-of-the-art in secure design languages and secure design guidelines. Our analysis shows that many of the secure software requirements and design methods lack some of the desired properties. The comparative study presented in this paper will provide guidelines to software developers for selecting specific methods that will fulfill their needs in building secure software applications. ii Contents 1 Introduction ........................................................................................................................... 1 2 Definitions Related to Software Security ............................................................................. 2 3 SSDLC Processes ................................................................................................................... 3 3.1 Summary of Existing SSDLC Processes ................................................................................... 3 3.2 Detailed Comparison of Existing SSDLC Processes ................................................................ 6 3.2.1 SSD Activities for Requirements Engineering ......................................................................................... 7 3.2.2 SSD Activities for Design ......................................................................................................................... 7 3.2.3 SSD Activities for Implementation ........................................................................................................... 8 3.2.4 SSD Activities for Security Assurance ..................................................................................................... 8 3.2.5 Resources ................................................................................................................................................. 8 3.2.6 Use of Artifacts of an SSD Activity in the Later Phases of Development ................................................ 8 3.2.7 Usage in the Industry ............................................................................................................................. 10 4 Software Security Requirements Engineering .................................................................. 10 4.1 Security Specification Languages ............................................................................................ 10 4.1.1 Summary of Existing Security Specification Languages ........................................................................ 10 4.1.2 Detailed Comparison of Existing Security Specification Languages ..................................................... 12 4.2 Security Requirements Engineering Processes ...................................................................... 14 4.2.1 Summary of Existing Security Requirements Engineering Processs ...................................................... 14 4.2.2 Detailed Comparison of Existing Security Requirements Engineering Processs .................................. 16 5. Secure Software Design ....................................................................................................... 17 5.1 Secure Design Languages ......................................................................................................... 17 5.2 Secure Design Guidelines ......................................................................................................... 17 6. Summary and Future Research Directions ....................................................................... 19 References .................................................................................................................................... 19 iii List of Tables Table 1. Comparison of SSDLC Processes…………………………………………………………………9 Table 2. Comparison of Security Specification Languages…………………….........................................13 Table 3. Comparison of Security Requirements Engineering Processes………………………………….16 Table 4. Comparison of Secure Design Guidelines based on Peine’s Work [64].......................................18 1 1 Introduction Security of software has become an important issue with the increasing integration of software in various aspects of human society. Software is considered to be secure if it does not allow the confidentiality, integrity, and availability (widely referred to as CIA) of its data, code, or service to be compromised [1]. However, most of today’s software are not secure and contain security vulnerabilities that can be exploited by people with malicious intent to cause financial and/or physical harm. Traditionally, security of software is not considered from the very beginning of a software development life cycle (SDLC), and it is only incorporated in the later stages of development as an afterthought. As a consequence, there are increased risks of security vulnerabilities that are introduced into software in various stages of development. The traditional approach to security of software has led to penetrate-and-patch approaches. In a penetrate-and-patch approach, security of software is assessed by attempting to break into the software from its environment by exploiting known security vulnerabilities. If such a penetration attempt is successful, a patch is developed and deployed for the vulnerability that allowed the break-in. Penetrate-and-patch approaches have many major drawbacks [2-6]. First, developing and deploying a patch to remove an error that causes a security vulnerability can be up to 200 times more expensive [7] than if the error had been removed as soon as it was introduced during development. Second, there is no assurance that the developed patch itself does not have any new security vulnerabilities (assuming that the traditional approach of software development was followed). Third, there is no guarantee that all the existing security vulnerabilities have been identified. Finally, major harm could have already occurred before a security vulnerability is even detected [6]. Secure software engineering aims to avoid security vulnerabilities in software by considering security aspects from the very beginning and throughout the SDLC. Secure software engineering is the process of designing, building, and testing software so that it becomes secure. Software security concerns are different from “application security” issues. Application security is about protecting software after it is developed and deployed. It usually includes input filters, intrusion detection systems, firewalls, and other protection mechanisms [2-5]. Software security includes secure software development life cycle (SSDLC) processes and secure software development (SSD) methods. A SSDLC process is either a SDLC process augmented with various SSD methods or a set of independent SSD methods. An SSD method provides ways to incorporate security in software during its development. An SSD method maybe a security specification language, security requirements engineering process, secure design specification language, set of secure design guidelines, secure design pattern, secure coding standard, and software security assurance method (e.g., penetration testing, static analysis for security, and code reviews for security). In this paper, we analyze the existing SSDLC processes, requirements methods, and design methods for secure software development based on their strengths and weaknesses. We first identify a number of characteristics of a SSDLC process that make it complete and effective. These characteristics are then used to compare and contrast various SSDLC processes. We also present a detailed comparison of security specification languages based on a number of desirable properties. This comparison focuses on identifying languages that can effectively specify security requirements. Moreover, we identify activities that should be performed as part of any security requirements engineering process. Based on these activities, we compare various security requirements engineering processes and identify their strengths and weaknesses. Finally, we provide an analysis of the state-of-the-art of different secure design languages and guidelines. The analysis presented in this paper can be useful in a number of ways. The comparison of various SSD methods will help software developers in selecting a particular SSDLC process, security specification language, security requirements engineering process, or secure design language for their particular development scenarios. The identified properties of software security specification and design languages can be useful to translate one specification language into another. Such a translation is particularly useful when a user of one language intends to use security tools developed for other languages. The rest of this paper is organized as follows. Chapter 2 defines the software security terms used in this paper. Chapter 3 presents an in-depth critical analysis of SSDLC models or processes. Chapter 4 analyzes methods for 2 software security requirements engineering. Methods for secure software design are discussed in Chapter 5. Chapter 6 concludes this paper by summarizing our findings and identifying the corresponding open research issues. 2 Definitions Related to Software Security A number of terms are used in software security literature, sometimes with varying meanings. In this chapter, we explain the major terms used in this paper. Asset An asset can be anything considered valuable [8] and should be protected. An asset is the “target of threats, the possessors of exposures, or the beneficiary of countermeasures” [9]. According to Verdon and McGraw [10], an asset can be a system component, data, or a complete system. The National Institute of Standards and Technology [11] defines an asset to be “a major application, general support system, high impact program, physical plant, mission critical system, or a logically related group of systems”. We consider something as an asset that can be harmed. An asset can be code (binary or source) of the software, data or information used or stored by the software, and the service provided by the software. Successful exploitation of these assets can lead to financial loss, physical injury, and sometimes even death. SSD Activity We define an SSD activity as the use or execution of a SSD method (as defined in Chapter 1). Vulnerability Flechais et al. [12] define a vulnerability as a part of the software which is prone to undesirable action. A vulnerability is the result of a software defect that an attacker can exploit to cause harm [10]. More precisely, “a software vulnerability is an instance of an error in the specification, development, or configuration of a software such that its execution can violate the security policy. … a software vulnerability can result from many errors, including errors in the specification, design, or coding of a system, or in environmental assumptions that do not hold at runtime” [8]. Software Security Error The term error has been very rarely used in software security literature. Most of the authors use the term vulnerability and do not distinguish between vulnerability and error. Sometimes the term flaw is also used instead of error [13]. In software reliability engineering, the term error is defined as an incorrect or missing action by a person that results in a fault [14]. A software security error is a tangible manifestation of a mistake in any of the SDLC artifacts (requirement specifications, design, or source code) of a piece of software that leads to a vulnerability [8, 13, 15]. A software security error can be one of the following, if it is related to security threats. a) Requirement specification error - An incorrect or missing requirement in the requirement specifications due to a mistake made in the requirement specification phase of the SDLC. b) Design error - An incorrect logical decision (the decision itself or the representation of a decision) in the design due to a mistake made in the design phase of the SDLC. c) Source code error - An incorrect representation of the design decisions in the source code due to a mistake made in the implementation phase of the SDLC. Software Security Requirement A software security requirement [15], sometimes also referred to as a countermeasure or safeguard [9-11], can be defined as a requirement needed to avoid a specific software security error during development. More specifically, a software security requirement is a control or constraint which if not implemented may lead to a vulnerability. As a