Software Security Engineering 215

Click Here & Upgrade Expanded Features PDF Unlimited Pages CompleteDocuments

Chapter XIV

Software Security Engineering: Toward Unifying Software Engineering and Security Engineering

Mohammad Zulkernine, Queen’s University, Canada

Sheikh I. Ahamed, Marquette University, USA

Abstract

The rapid development and expansion of network-based applications have changed the computing world in the last decade. However, this overwhelming success has an Achilles’ heel: most software-controlled systems are prone to attacks both by internal and external users of the highly connected computing systems. These software systems must be engineered with reliable protection mechanisms, while still delivering the expected value of the software to their customers within the budgeted time and cost. The principal obstacle in achieving these two different but interdependent objectives is

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Click Here & Upgrade Expanded Features PDF Unlimited Pages CompleteDocuments

216 Zulkernine & Ahamed

that current software engineering processes do not provide enough support for the software developers to achieve security goals. In this chapter, we reemphasize the principal objectives of both software engineering and security engineering, and strive to identify the major steps of a software security engineering process that will be useful for building secure software systems. Both software engineering and security engineering are ever-evolving disciplines, and software security engineering is still in its infancy. This chapter proposes a unification of the process models of software engineering and security engineering in order to improve the steps of the software life cycle that would better address the underlying objectives of both engineering processes. This unification will facilitate the incorporation of the advancement of the features of one engineering process into the other. The chapter also provides a brief overview and survey of the current state-of-the-art of software engineering and security engineering with respect to computer systems.

Introduction

With the proliferation of connectivity of computer systems in the applications where the quality of service depends on data confidentiality, data integrity, and protection against denial-of-service attack, the need for secure networks is evident. In these applications, the consequences of a security breach may range from extensive financial losses to dangers to human life. Due to heavy dependence of computer network-based applications on various software and software controlled systems, software security has become an essential issue. Almost every software controlled system faces potential threats from system users, both insiders and outsiders. It is well accepted that “the root of most security problems is software that fails in unexpected ways when under attack” (McGraw, 2002, p. 101). Therefore, software systems must be engineered with reliable protection mechanisms against potential attacks while still providing the expected quality of service to their customers within the budgeted time and cost. Software should be designed with the objective not only of implementing the quality functionalities required for their users, but also of combating potential and unexpected threats. The principal obstacle in achieving these two different but interdependent objectives is that current software engineering processes do not provide enough support for the software developers to achieve security goals. Some of the principal software engineering objectives are usability, performance, timely completion, reliability, and flexibility in software applications (Finkelstein & Kramer, 2000; IEEE, 1999; Pressman, 2001). On the other hand, some of the major objectives of security engineering are customized access control and authentication based on the privilege levels of users, traceability and detection, accountability, non-repudiation, privacy, confidentiality, and integrity (Pfleeger & Pfleeger, 2003; Viega & McGraw, 2001). Having stated that, software security engineering objectives are to design a software system that meets both security objectives and application objectives. However, software security engineering is still considered a difficult task due to inherent difficulties associated with the addressing of the security issues in the core development and

Software Security Engineering 217

maintenance of software systems. Both software engineering and security engineering are ever-evolving disciplines and software security engineering is still in its infancy. A precise and well-accepted understanding of software security engineering does not yet exist (ISSEA, 2003; Wolf, 2004). The principal objectives of software security engineering need to be reinvestigated, and a methodology is required that can be employed for building secure software systems. Software security engineering is a practice to address software security issues in a systematic manner. We believe that the security issues must be addressed in all the stages of software system development and the maintenance life cycle, such as requirements specifications, design, testing, operation, and maintenance, to provide secure software systems. This chapter identifies some possible ways to adapt readily the current practices of security engineering into a software engineering process model. In other words, this chapter suggests a unification of the process models of software engineering and security engineering. The unification is desirable between the two processes because it removes the unnecessary differences in their corresponding steps that obscure the fundamental principles of the development and maintenance of secure software systems. This unification will help system designers to employ the techniques and tools of software engineering and security engineering in a complementary fashion. It will also help to incorporate the advancement of the features of one engineering process into the other. In our attempt, we suggest the incorporation of new, more intuitive but well-defined steps in the software security engineering process in order to build secure software systems. It may be noted here that a number of studies have already proved that “end-to-end integration” of security aspects in the software life cycle have significant benefits with respect to the quality of the end software products (Devanbu & Stubblebine, 2000; Viega & McGraw, 2001). In this chapter, we describe a software security engineering process that is primarily based on the famous waterfall software development process model (Royce, 1987). The major steps of the proposed software security engineering process model are described in detail. The rationale for choosing the waterfall model as a basis for the description is that it contains most of the fundamental steps present in all other software process models that currently exist in the literature. Therefore, our idea of a software security engineering process that incorporates security issues in all the steps of software life cycle will work fine in other software process models. For example, the incremental model is widely used in industry with a view to reducing the delay in delivering software products. It consists of several increments or builds, where each increment follows the waterfall model. Similarly, in an incremental model-based software security engineering process, each increment may adopt the steps described in this chapter. The rest of the chapter is organized as follows. The next section provides a brief overview of software engineering and security engineering and presents a brief synopsis of the current state-of-the-art of other related efforts towards software security engineering. The details of the proposed software security engineering process model are then provided. Finally, the chapter concludes with a summary of current research and future recommendations.

218 Zulkernine & Ahamed

Background

A Glimpse of Software Engineering

In the IEEE Standard Glossary of Software Engineering Terminology (IEEE Std. 610.12- 1990), software engineering is defined as follows: “(1) Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)” (IEEE, 1999, p. 67). It primarily focuses on applying an engineering approach to the design, implementation and maintenance of software systems. Software engineering is an engineering discipline that is concerned with all aspects of software production — from the early stages of system specification to maintenance of the system after it has been deployed for use (Finkelstein & Kramer, 2000). Software engineering is a subset of system engineering that focuses on the overall system (both software and hardware), while software engineering only focuses on the software aspects of the system development. There are different software development life cycle models, such as the waterfall, incremental, spiral, and rapid prototyping (Pressman, 2001). Among these models, the waterfall model (Royce, 1987) is the most widely used and discussed. Most models consist of steps for requirement gathering and analysis, software architecture, implementation, and testing. Stakeholders involved in a software engineering process influence software engineers to follow certain process models to address and solve different issues of the software in an effective way. The stakeholders include analysts, designers, programmers, testers, maintenance personnel, project managers, and end-users or customers. The project manager leads the whole software development group of analysts, designers, programmers, testers, and maintenance personnel. An analyst collects and analyses the requirements, and a designer forms the architecture with a view to leading the requirements towards the implementation. A programmer implements the architecture or design provided by the designer, and testers test the software for ensuring a high-quality end-product. Maintenance personnel deploy and maintain the software so that the operators can use the software effectively. Software engineering refers to techniques intended for making software development more orderly, systematic, and organized. It also helps to reduce the time and cost of developing software in a scientific way. In summary, low cost, high quality, and rapid software development are the key goals of software engineering. The rapid development and expansion of the software are possible with effective use of a software engineering process; however, security issues have not yet been incorporated or addressed in the software development processes.

A Glimpse of Security Engineering

TheInternational Federation for Information Processing (IFIP) Working Group WG10.4 on Dependable Computing and Fault Tolerance considers security as one of the

Software Security Engineering 219

attributes of software “dependability,” where dependability is defined as the “trustworthiness of a computer system such that reliance can be justifiably placed in the service it delivers” (Laprie, 1992, p. 4). The other principal attributes of dependability are reliability, availability, and safety, while security professionals usually consider safety and reliability as attributes of security. The threats to security are identified as intercep- tion, interruption, modification, and fabrication of data (Pfleeger & Pfleeger, 2003). The threats are usually defined based on some security policy of the organization, while the violations of any security policy are combated using different security mechanisms such as encryption, authentication, authorization, and auditing. Security engineering is a discipline for “building systems to remain dependable in the face of malice, error, or mischance,” where the discipline “emphasizes the tools, processes, and methods needed to design, implement, and test complete systems, and to adapt existing systems as their environment evolves” (Anderson, 2001, p. 3). Security engineering deals with a number of issues such as intrusion protection and detection. It ensures that a system is secure from both software and hardware perspectives. System security is becoming increasingly more important due to the new trend of ubiquitous/ pervasive computing that has evolved during the last few years; numerous mobile or embedded devices such as PDAs and cell phones are connected via the Internet, incurring enormous security vulnerabilities. Security engineering addresses the complete life cycle for building a secure system: requirements specification and analysis, design, development, integration, operation, maintenance and re-engineering (ISSEA, 2003). It requires expertise in interdisciplinary areas such as computer system management and development, software and hardware security, networking and cryptography, applied psychology, organizational management, and law. Without incorporating the security engineering principles derived from the relevant cross-disciplinary areas to every level of a software development process, it is nearly impossible to deliver a secure software system in its first release.

Related Effort to Address Security Issues in Software Engineering Context

We begin this section with the following question that was asked by Wolf (2004, p. 1): “Is security engineering really just good software engineering?” We also believe in Wolf’s concluding observation that security engineering cannot be differentiated from software engineering if “the underlying mathematics and higher level policy and human factor issues” are not considered. Our approach to software security engineering is along the line of the following research challenges outlined in Finkelstein and Kramer (2000) and Devanbu and Stubblebine (2000): integration of security requirements with software requirements into initial development life cycle; design of adaptive software systems to handle new attacks and changing security policies of any organizations; testing security requirements of software systems; and derivation of intelligent and responsive framework for operational stage monitoring and maintenance. A number of other related efforts towards incorporating security engineering principles into software development life cycles are discussed in the following paragraphs.

220 Zulkernine & Ahamed

In Viega and McGraw (2001), a software risk management process is proposed for assessing, quantifying, and establishing an acceptable level of risk in an organization. The proposed process is inspired by Boehm’s spiral software process model (Boehm, 1988). In this process, security aspects are considered when software requirements are derived. The most severe security risks are evaluated and strategies are planned for resolving those risks. The risks are addressed through prototyping and validation that the risks of those security violations are eliminated. Then, the solution to the security risks is applied for the next version of the software requirements, design, or source code. Finally, the planning for the next phase is outlined. In Flechals, Sasse, and Hailes (2003), a process for usable and secure software systems called appropriate and effective guidance in information security (AEGIS) is proposed. AEGIS involves the context in which the system is going to be used, and analyzes the potential risks to help developers handle security related issues. Similar to the risk management process proposed in Viega and McGraw (2001), AEGIS is also based on Boehm’s spiral software process model. It requires communication among a system’s stakeholders in the risk analysis and the selection of appropriate defense mechanisms so that the developers gain a better understanding of the security and usability requirements. AEIGS employs Unified Modeling Language (UML) (Jacobson, Booch, & Rumbaugh, 1999) to describe a way to perform “risk-usability-design” simultaneously. The Software Security Assessment Instrument (SSAI) Project (Gilliam, Wolfe, & Sherif, 2003) identifies five important entities with respect to software security engineering: software security checklist (SSC), vulnerability matrix (Vmatrix), flexible modeling framework (FMF) for verification of requirements, property-based tester (PBT) for testing vulnerabilities, and security assessment tools (SATs). Similar to our objective in this chapter, the SSC incorporates “security as a formal approach in the software life cycle” (p. 243). The system security engineering capability maturity model (SSE-CMM) (ISSEA, 2003) proposes a unified process of practicing security engineering in the context of software development. In the systems security engineering process, the security engineering task is divided into three interrelated but separate basic process areas: the risk process, engineering process, and assurance process. The risk process identifies and prioritizes the risks inherent to the product under development; the engineering process interfaces with the other engineering disciplines to provide solution to the identified risks; and the assurance process improves the level of confidence of the product developer and the customers with respect to the proposed security solutions. The SSE-CMM describes the characteristics of five capability levels that are inspired by the CMM used to evaluate software engineering practices. The Unified Modeling Language (Jacobson, Booch, & Rumbaugh, 1999) has currently become the de facto standard to specify, visualize, and document models of software systems including their structure and design. More specifically, it is suitable for object- oriented analysis and design. The UML defines 12 types of diagrams of three categories. Nevertheless, the UML does not provide a framework that can address the issues with respect to developing secure software system. A number of efforts are taking place in order to enrich the UML-based software development processes. Some of them are: UMLSec (Jürjens, 2003), Misuse and Abuse cases (Sindre & Opdahl, 2000; Dermott &

Software Security Engineering 221

Fox, 1999), Secure UML (Basin, Doser, & Lodderstedt, 2003; Lodderstedt, Basin, & Jurgen, 2002), and Security integrated rational unified process (Oikinomopoulos & Giritzails, 2004). To address security issues in the context of software development processes, some of the elements of UML, such as use case, class, sequence, state chart, package and deployment diagrams, are extended (Jürjens, 2003). This UML extension for secure software development is called UMLSec. The extensions included in the UMLSec are based on using stereotypes and tag values, which enrich the existing UML diagrams with security-related information. Standard use case diagrams are often useful for eliciting functional requirements, while they are not that suitable for describing security requirements (Jacobson, Booch, & Rumbaugh, 1999). The security requirements are usually related to prohibited activities. Therefore, an extension to standard UML use case notations is proposed in Sindre and Opdahl (2000) in order to include unwanted use case scenarios. A use case describes a sequence of actions that represents a service to the user. On the other hand, a misuse case in the context of security requirements is defined as a sequence of actions that results in security violations for the organization or some specific stakeholder. They also define “mis-actor” as just the opposite of an actor, and it initiates the misuse cases. In Dermott and Fox (1999), a use case-based object-oriented modeling technique is used to represent significant forms of abuses that need to be prevented. However, security issues are not addressed in every phase of the software engineering process. SecureUML (Basin, Doser, & Lodderstedt, 2003; Lodderstedt, Basin, & Doser, 2002) describes a methodology for modeling access control policies and integrating it into a model-driven software development process. This work is inspired by the idea of using UML to model role-based access control (RBAC) policies. The unique feature of the SecureUML is that it also includes elements to be used in behavioral models. A number of extensions of the UML for the purpose of security are compared and contrasted by Oikinomopoulos and Giritzails (2004). We agree with their view that most of those extensions are concerned with the presentation (notational) issues of security- related information rather than a methodology, which emphasizes the activities to be performed for software security engineering. In most of their work, Oikinomopoulos and Giritzails provide very little or no guideline about how and in what phase of the development cycle the extended UML notations will be utilized; they incorporate security engineering in the rational unified process (RUP). The RUP divides the software development effort into phases and major workflows. The authors extend each workflow with additional security-related activities and identify the artifacts that should be produced. To support these activities, they also introduce the role of a “security engineer” in their methodology.

Software Securiy Engineering

Having discussed both software engineering and security engineering, it is important to note that “while software engineering is about ensuring that certain things happen,

222 Zulkernine & Ahamed

security is about ensuring that they don’t” (Anderson, 2001, p. 3). Nevertheless, following the IEEE Standard 610.12-1990 (IEEE, 1999, p. 67) definition of software engineering, software security engineering can be defined as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of” secure software; i.e., “the application of engineering” to obtain secure software (Anderson, 2001, p. 67). In the software security engineering process, the principles and specialties of other engineering disciplines with respect to software and security are integrated to achieve the “trustworthiness” in software systems. This process will help software development to proceed in a way where it will have less chance of exposing itself to security-related loopholes. It will endorse low cost, high quality, and a rapid software development process where the security issues will be addressed in every phase of the process. Software security engineering involves the stakeholders of software engineering, while actively involving security engineers in most of its phases. Similar to both software engineering and security engineering, software security engineering incorporates expertise from several other cross-disciplinary areas such as computer system management and development, software and hardware security, computer networks, organizational management, psychology, and law. We describe a software security engineering process that is primarily based on the famous waterfall software development process model (Boehm, 1988). The waterfall model contains most of the fundamental steps present in other software process models currently used in industry and academia. The major steps of the proposed model are: system engineering, requirements specification, software design, program implementation, and system operation. The steps are presented schematically in Figure 1. While the following paragraphs provide a brief introduction to the steps, all of the steps are further detailed in the subsections that follow. • System engineering The software concerns of a system development are separate from its hardware concerns. Then both functionality issues and security issues are identified based on the users’ or stakeholders’ needs and in the context of other system elements such as hardware, software, people, database, documentation, and procedure. • Requirements specification The security requirements of a software system are specified, analyzed, and integrated along with the other functional and nonfunctional requirements of the software system. It is recommended that both security requirements and the other software requirements should be specified using the same formal language.1 The requirements are expressed as a set of scenarios. • Software design Both functionality and security issues should be considered when deciding where the application components are deployed and how they communicate with each other. A scenario-based software architecture is designed based on functional scenarios from users’ perspective and attack scenarios from intruders’ perspective. The architecture should be compositional so that whenever a new attack is encountered, the system architecture can easily adapt to defend against the attack.

Software Security Engineering 223

Figure 1. A waterfall-based software security engineering process model

System Engineering Informal software and security requirements

Requirements Specification Combined formal software and security requirements specification

Software Design Scenario-based compositional architecture

Program Implementation Refactored code for security Monitor for failure and intrusion detection System Operation

Figure 1. A waterfall based software security engineering process model.

• Program implementation The system is implemented to meet the specified requirements, and the correctness and effectiveness of security mechanisms, along with functional characteristics, are verified with respect to the requirements specification. When the required functionalities are implemented, the source code is refactored (changed) to control any number of vulnerabilities against threats from attackers, while still meeting all of the functional acceptance tests. • System operation The software is monitored for security violation or conformance to its functional requirements based on the specification formalized in the requirements specification phase. In other words, the software monitor is equipped with different intrusion-detection capabilities. The monitor also measures whether the operational impacts due to security vulnerabilities or residual software faults in a system are acceptable or not.

System Engineering

Software engineering deals with the software aspects of system engineering while security engineering focuses on the overall system engineering (both software and hardware). Similar to software engineering, the end-product of the software security engineering process is software. The system engineering phase of the software security engineering process identifies the software aspects of the system to be developed. Obviously, this phase focuses equally on both functionalities and security issues of the software system based on the users’ or stakeholders’ needs and in the context of other

224 Zulkernine & Ahamed

system elements, such as hardware, software, people, database, documentation, and procedure. Both software engineers and security engineers work closely in this phase. Similar to IEEE Standard 1220-1998 for system engineering (Thayer, 2002), this phase of the software security engineering process involves defining the system requirements that determine the needs and constraints of the software and hardware. This is accom- plished through analyzing the functional requirements and all the aspects of security related threats (see Figure 2). The outcomes of this phase are the informal functional and security requirements. These informal requirements then become the input of the requirements specification phase.

Requirements Specification

Software requirements are usually referred to as functional requirements that specify the behavior of the system; that is, the relationship between inputs and outputs. A nonfunctional software requirement describes not what the software will perform, but rather how effectively the software will perform. For example, usability, reliability, interoperability, scalability, and security are some of the nonfunctional properties of software systems. Like most other nonfunctional requirements, security is regarded as an important factor to the success of any software project, and it is usually incorporated in the system development in a subjective manner. There are some inherent difficulties associated with security requirements specification: security requirements are often difficult to specify in the early phases of the software development life cycle, since the software model tends to be very abstract and is usually presented in an informal manner. In addition, security risks are difficult to estimate, and as the software development progresses, developers receive new information about the system security (Zhang & Zulkernine, 2004). Given that, it is often difficult to specify security measures and integrate them into the actual system from the very beginning of the software development process. In most cases, security requirements are not addressed at all during the early design phases.

Figure 2. The system engineering phase of the software security engineering process

Analyze Informal functional functional requirements requirements

Needs and constraints Software w.r.t. the software and aspects of the hardware system

Analyze Informal security security threats requirements

Figure 2. The system engineering phase of the software security engineering process.

Software Security Engineering 225

Figure 3. The requirements specification phase of the software security engineering process

Informal Identify Formal security security attack specification requirements scenarios Formal requirements Reconciliation (security & functional) & integration specification Informal Formal Identify functional functional usage requirements specification scenarios

Figure 3. The requirements specification phase of the software security engineering process.

In the software security engineering process, both security and functional requirements are specified in the requirements specification phase (see Figure 3). We believe that the weaknesses of software-controlled systems with respect to the software security can be alleviated by specifying functional and security requirements using formal methods, and then by reconciling and integrating the two sets of formal specifications at an abstract level. As the software design evolves, the specifications are refined to reflect the progressive changes towards the end-product. In this way, security requirements get closely involved in the later stages of software development. Scenarios have been widely used as a technique for elicitation, analysis, and documentation of software requirements. A scenario is a sequence of a limited number of related events or actions that represents some meaningful high-level operation in a system. The length of a scenario may vary from a single event to all the events of a system. However, all the events of a single scenario must occur during a particular run of the system. In this phase of the software security engineering process, two types of scenarios are identified based on the corresponding requirements: usage scenarios and attack scenarios. The usage scenarios are selected based on the operational profile of the intended software system. The attack scenarios can incorporate expert knowledge on security, and they may be ranked based on their importance in the system being implemented. For example, defending against a denial-of-service attack in a client machine may not be as important as it is in a server machine. A scenario can be represented in various forms: natural language, pseudo code, data flow diagrams, state machine-based notations, communicating event-based notations, and so forth. To avoid inconsistency and redundancy, it is highly recommended that both usage scenarios and attack scenarios be defined using the same specification language. In the literature, we find a number of formal software specification languages and a relatively fewer number of attack languages to describe attack scenarios (Eckmann, 2001; Vigna, Eckmann, & Kemmerer, 2000). However, currently available software specification languages are not completely suitable for specifying the security-related aspects of software systems, nor are attack specification languages suitable in specifying functional requirements. As an initial attempt, software specification languages can be translated to attack languages and vice versa. For example, in Zhang and Zulkernine (2004), a formal software requirements specification language of Microsoft called

226 Zulkernine & Ahamed

Abstract State Machine Language (ASML) (Barnett, Grieskamp, Gurevich, Schulte, Tillman, & Veanes, 2003) is automatically transformed to a high-level attack specification language called State Transition Analysis Technique Language (STATL) (Vigna, Eckmann, & Kemmerer, 2000), which can be preprogrammed and loaded into an intrusion- detection system at runtime. The translation scheme will initially help to close the gap between security requirements and functional requirements with respect to their modeling and implementation.

Software Design

A software architecture or software design defines the software components of a system and the interactions among these components. The examples of application components include user interfaces, databases, and middleware (Kazman, Carriere, & Woods, 2000). Both functionality and security issues are interconnected to where the software components are deployed and how they communicate with each other. For example, the architecture and its protection mechanisms depend on whether the system will operate as a centralized or a distributed one. The software components should be deployed based on the trustworthiness and information flow among them, following the principle: “what needs to be protected and from whom those things need to be protected, and for how long protection is needed” (Viega & McGraw, 2001, p. 34). In the software security engineering process, a software system should be designed based on the following two principles: compositional software architecture and scenario- based software architecture. The following paragraphs discuss these two principles in the context of software security engineering. New attacks are made to the software systems and security loopholes may be discovered at any point during the life of software. Flexible software architectures are desirable to make the design changes in those situations. A compositional software architecture is one in which the changes required for the whole system can be obtained by applying the changes to its components. As a result, whenever a new attack is encountered, the system architecture can be easily adapted to defend against the attack if a clear and clean notion of component is present. This is only possible if the principle of compositionality and the security concerns were taken into consideration in defining each software component in the software design phase. This adaptive architecture is very useful for rapidly evolving security policies in the post-deployment system administration period, and to facilitate the re-engineering of security features into legacy systems. We define the concept of compositionality with respect to software security engineering following the definition of compositional specification and verification (de Roever, 1997). Assume

that a system C is composed of the components C1, C2,..., and Cn by employing a set of

composition operators. Let the security requirements ofC1, C 2,..., andCn be S1, S 2,..., and

Sn respectively. A compositional design implies that the whole system C satisfies the

complete specification S if each component Ci satisfies Si for i= 1,...,n. Therefore, any change of security requirements in any of the components can be addressed and verified without modifying the other components (in a true compositional case).

Software Security Engineering 227

Scenarios are employed to build the software architecture of a system with a view to incorporating different features described by each scenario (Kazman, Carriere, & Woods, 2000). Scenarios are very useful to compare design alternatives and to understand a legacy system by analyzing the system responses in the context of different environ- ments. Jacobson et al. (1999) compared scenario-based design to “making a film.” However, scenario-based design of a software system is more than making a single movie, as scenarios may be composed in parallel, alternative, or iterative manner in order to build the desired composite system. Similarly, the potential attacks to a system can be specified using attack scenarios, which initially may be abstract, and are refined as the design evolves by considering all security-relevant issues.

Implementation

Security requirements define the behavior of a system that should not occur. A programmer working for a particular implementation or an intruder who somehow manages to gain access to the source code can initiate certain actions in the program that may cause target system behavior that should not be allowed. During programming, we should ensure that potential security flaws, identified as security requirements and avoided in the earlier phases of the software security engineering process, are not reintroduced in the source code. Any unexpected behavior with respect to program security is called a “security flaw,” while “vulnerability” is considered as a special security flaw2 (Pfleeger & Pfleeger, 2003). In Landwehr, Bull, McDermott, and Choi (1994), the surveyed “program security flaws” are divided into two categories: intentional and inadvertent. Intentional flaws are categorized as malicious and non-malicious, while inadvertent flaws are divided into the following six types: incomplete or inconsistent validation error, domain error, serialization or aliasing, insufficient identification or authentication, boundary condition violation, and other potential exploitable logic errors. Given the varying and intricate nature of the above-mentioned security flaws, security engineers should participate in coding or understand the code well enough to identify potential security flaws and convey them to software developers. Security engineers may participate in formal code inspection and review processes to document any security- relevant issues present in the source code. More specifically, in the software security engineering process, we propose to follow the principle of code refactoring successfully employed in the context of extreme programming (Beck, 1999). In extreme programming, code refactoring refers to the practice of restructuring the source code without changing the intended functionalities of the system, such as removing any duplicate or unreach- able code and re-organizing code for simplicity and flexibility. It is important to confirm that refactoring does not introduce any new faults or security flaws into the code. Therefore, individual refactoring steps should be small to address the above-mentioned security flaws, and each change should be tested to ensure that the implementation is as functional and self-protected as it was before the refactoring. Note that refactoring is not intended to replace testing in the software security engineering process, but rather to complement testing by increasing the confidence in the source code of security critical applications. Once the functionalities required for the system are implemented, refactoring

228 Zulkernine & Ahamed

is employed to change the program so that the software can control its vulnerabilities against attacks from intruders while still passing all of the functional requirements tests. The software should be tested for both functional and security requirements. Based on these requirements, along with other nonfunctional requirements such as performance and quality of service identified in the early phases of the software security engineering process, the test cases for the software system are derived. Vulnerability scenarios of the software that can be exploited for intrusions or security violations are tested. A “red teaming” approach may be used where a system is tested using simulated scenarios under which it may be attacked (Viega & McGraw, 2001). We have to ensure that the system is tested in the network environment in which the system will actually run. Keeping that in mind, the testing of the software can be divided into two steps: unit testing that tests a host for security; and integration testing that tests the whole system by deploying the system in the target network configuration guided by the applicable security policies.

System Operation

A number of studies have shown that professionally written programs may contain between one and 10 faults per 1,000 lines of codes. Moreover, despite rigorous use of different “protective shields,” there exist security loopholes that elude those protective efforts, and unauthorized intrusions may occur when the network is operational. The difficulty in releasing correct and secure software has resulted in a growing interest in the usefulness of operational stage monitoring of software systems. However, existing intrusion detectors cannot monitor the behavior of software systems, while the current software monitors cannot detect security violations in the target systems. In software security engineering, a software monitor should also have the capability of detecting intrusions (see Figure 4). The monitor passively observes some of the actual events occurring in a software application at runtime and reports the occurrences of intrusions or behavioral failure. To detect any intrusion or behavioral failure in a target system, the monitor must have the knowledge of what is the ideal or normal behavior of the monitored system. This knowledge can be obtained from the system’s formal (behavioral and security) specification identified in the requirements specification phase. Note that this requirements specification was originally used to design and implement the software application, as shown in Figure 4. During system operation, the behavior of the monitored system when it is under attack by the intrusions known later on can be specified. Similar to previously considered intrusions, it is also obvious that the newly discovered intrusions may change the behavioral profile of a host or a network. Therefore, new attack specifications are reconciled with the existing formal requirements specification. The monitor interprets the formal specification using the observed events of the monitored host or the network in order to generate a report on intrusive activities as well as unexpected behavior.

Software Security Engineering 229

Figure 4. Monitoring an operational software application using a specification-based monitor

Formal requirements Reconciliation & integration New attack specification specification

Acquire knowledge Design & implement

Failure & Observation results intrusion report Software Specification Based Application Monitor

Figure 4. Monitoring an operational software application using a specification based monitor.

Conclusions and Recommendations

In this chapter, we have presented a software security engineering process based on the waterfall software process model. The adaptation of the proposed process into other existing software engineering process models is straightforward. It is worth mentioning here that many new engineering disciplines, such as software engineering and security engineering, have incorporated many concepts and principles from other mature engineering disciplines. Similarly, the individual concepts and techniques suggested in the proposed process are not completely new. What is new in this chapter is their systematic integration and organization into a process that will lead to secure software systems. It is very difficult to achieve two sets of desired objectives while they “trade off against one another” (Viega & McGraw, 2001, p. 29). For example: an application software may require root-level access privileges in a system to run the application, while in some cases it may mean weakening the security of the target system. We believe that the trade-off among these goals is very application-dependent. The potential conflict between software characteristics and network defenses should be resolved early in the development phase; that is, in the requirements specification phase. In other words, security measures must not hamper the expected quality of service of a system, but at the same time any functionality should not be achieved at the cost of weakening security. Given that, a software security engineering process should be employed, where functionalities of a system must be specified and defined by considering the security concerns or requirements with respect to the system. Currently available specification languages are not completely suitable for defining security-related aspects of software behavior. The standardized formal software speci-

230 Zulkernine & Ahamed

fication languages used in industry should be investigated and extended (if needed) for expressing security-related features of target systems. However, it may not be always feasible to formally specify all of the suspicious activities occurring in the target system. Therefore, the formal specification may be supplemented by the statistical components of the operational profiles of the system, users, or intruders. Statistical analysis may be performed to detect any additional intrusions. History of well-established engineering disciplines shows the key role that automatic development tools played in their advancement. Automatic tools can play a similar role in the area of software security engineering to improve the productivity and quality of the software with respect to security. Existing computer-aided software engineering (CASE) tools cannot be used for software security engineering, since their focus is solely on software not security. Both security and software along with productivity and quality, need to be addressed in the CASE tools. The availability of such tools is likely to provide support to further the evolution of software security engineering. Though we have described the proposed process independent of current software development paradigms, such as procedural, object-oriented, or component-based, it is worth mentioning the issue of trustworthiness of software components. With the increase in component-based software development, the security of components has become an important issue due to the design of software systems composed of untrusted components from independent sources. It is still an open question as to the level of security one can achieve when integrating third-party components of a software system (Lindqvist & Jonsson, 1998). In component-based software development, components interact to accomplish the functionalities of software systems. In the future, a metadata- based approach can be used to address the security issues in component interactions, since metadata describes the static and dynamic aspects of the components including the accessibility by their users (Orso, Harrold, & Rosenblum, 2001).

References

Anderson, R. (2001). Security engineering - A guide to building dependable distributed system, New York: John Wiley & Sons. Barnett, M., Grieskamp, W., Gurevich, Y., Schulte, W., Tillman, T., & Veanes, M. (2003, May). Scenario-oriented modeling in AsmL and its instrumentation for testing. In Proceedings of the 2nd International Workshop on Scenarios and State Machines: Models. Algorithms, and Tools, Portland, OR (pp. 8-14). Basin, D., Doser, J., & Lodderstedt, T. (2003). Model-driven security for process-oriented systems. In Proceedings of the 8thACM symposium on Access Control Models and Technologies, Como, Italy(pp. 100-109). Beck, K. (1999). eXtreme programming explained: Embrace change. Reading, MA: Addison Wesley. Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61-72.

Software Security Engineering 231

Dermott, J., & Fox, C. (1999, December). Using abuse case models for security requirements analysis. In Proceedings of the 15th Annual Computer Security Applica- tions Conference, Phoenix, AZ (pp. 55-66). IEEE Computer Society. Devanbu, P. T., & Stubblebine, S. (2000, June). Software engineering for security: A roadmap. In A. Finkelstein (Ed.), The Future of Software Engineering. Proceed- ings of the International Conference on Software Engineering (pp. 227-239). Limerick, Ireland: ACM. Eckmann, S. T. (2001, October). Translating snort rules to STATL scenarios. In Proceed- ings of the 4th International Symposium on Recent Advances in Intrusion Detec- tion (RAID 2001), Lecture Notes in Computer Science (pp. 69-84). Germany: Springer-Verlag. Finkelstein, A., & Kramer, J. (2000, June). Software engineering: A roadmap. In A. Finkelstein (Ed.), The Future of Software Engineering, Proceedings of the Inter- national Conference on Software Engineering (pp. 5-22). Limerick, Ireland: ACM. Flechals, I., Sasse, M. A., & Hailes, S. M. V. (2003, August). Bringing security home: A process for developing secure and usable systems. In Proceedings of the New Security Paradigms Workshop, Ascona, Switzerland (pp. 49-57). ACM. Gilliam, D. P., Wolfe, T. W., & Sherif, J. S. (2003, June). Software security checklist for the software life cycle. In Proceedings of the Twelfth IEEE International Work- shop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE ’03) (pp. 243-248). IEEE. Institute of Electrical and Electronics Engineers, Inc. (IEEE). (1999). Software engineering: Customer and terminology standards, Vol. 1. New York: Institute of Electrical and Electronics Engineers, Inc. International Systems Security Engineering Association (ISSEA). (2003). SSE-CMM: Model Description Document, Version 3.0, SSE-CMM – ISO/IEC 21827, Interna- tional Systems Security Engineering Association. Retrieved November 2005, from http://www.sse-cmm.org/docs/ssecmmv3final.pdf Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The unified software development process. Reading, MA: Addison Wesley. Jürjens, J. (2003). Secure systems development with UML. New York: Springer-Verlag. Kazman, R., Carriere, S. J., & Woods, S. G. (2000). Toward a discipline of scenario-based architectural engineering. Annals of Software Engineering, 9, 5-33. Landwehr, C. E., Bull, A. R., McDermott, J. P., & Choi, W. S. (1994). A taxonomy of computer program security flaws. ACM Computing Surveys, 26(3), 211-254. Laprie, J. (1992). Dependability: Basic concepts and terminology - In English, French, German, and Japanese. Vienna: Springer-Verlag. Lindqvist, U., & Jonsson, E. (1998). A map of security risks associated with using COTS. IEEE Computer, 60-66. Retrieved November 2005, from http://downloads. securityfocus.com/library/cots98.pdf

232 Zulkernine & Ahamed

Lodderstedt, T., Basin, D., & Doser, J. (2002, September). SecureUML: A UML-based modeling language for model-driven security. In Proceedings of the Fifth Interna- tional Conference on the Unified Modeling Language: The Language and Its Applications. Germany: Springer Verlag. McGraw, G. (2002). Managing software security risks. IEEE Computer, 99-101. Oikinomopoulos, S., & Giritzails, S. (2004, September). Integration of security engineering into the rational unified process –An early iteration. In Proceedings of the Workshop on Specification and Automated Processing of Security Requirements - SAPS’04, Linz, Austria (pp. 167-176). Austrian Computer Society. Orso, A., Harrold, M. J., & Rosenblum, D. (2001). Component metadata for software engineering tasks. In Proceedings of the EDO 2000, Lecture Notes in Computer Science, 1999 (pp. 129-144). Springer-Verlag. Pfleeger, C. P., & Pfleeger, S. L. (2003). Security in computing. Upper Saddle River, NJ: Prentice-Hall. Pressman, R. P. (2001). Software engineering: A practitioner’s approach. New York: McGraw Hill. de Roever, W. (1997). The need for compositional proof systems: A survey. In Compositionality: The Significant Difference (COMPOS ’97), Lecture Notes in Computer Science, 1536 (pp. 1-22). Berlin: Springer-Verlag. Royce, W. W. (1987). Managing the development of large software systems: Concepts and techniques. In WESCON Technical Papers, 1970, (Reprinted), Proceedings of the Ninth International Conference on Software Engineering (pp. 328-338). Monterey, CA: IEEE Computer Society Press. Sindre, G., & Opdahl, A. L. (2000, November). Eliciting security requirements by misuse cases, In Proceedings of the 37th International Conference on Technology of Object-Oriented Languages and Systems (pp. 174-183). Sydney, Australia: IEEE Computer Society. Thayer, R. H. (2002). Software system engineering: A tutorial. Computer, 35(4), 68-73. Viega, J., & McGraw, G. (2001). Building secure software: How to avoid security problems the right way. Reading, MA: Addison-Wesley. Vigna, G., Eckmann, S. T., & Kemmerer, R. A. (2000, October). Attack languages. In Proceedings of the IEEE Information Survivability Workshop, Boston (pp. 63- 166). IEEE. Wolf, A. L. (2004, October). Is security engineering really just good software engineering? Keynote Talk, ACM SIGSOFT ‘04/FSE-12, Newport Beach, CA. Zhang, Q., & Zulkernine, M. (2004, September). Applying AsmL specification for automatic intrusion detection. In Proceedings of the Workshop on Specification and Automated Processing of Security Requirements – SAPS’04, Linz, Austria (pp. 221-223). Austrian Computer Society.

Software Security Engineering 233

Endnotes

1 For brevity, functional software requirements are mentioned as software requirements or functional requirements. 2 IEEE definitions (IEEE, 1999) of “fault” and “failure” are defined from a different perspective. However, Wolf (2004) views “vulnerability” as a “fault,” since an attack cannot cause a security failure if no vulnerability exists.