Since software products are heavily used in today’s connected society, design and implementation of such software products to make them resilient to security threats become crucial.

This thesis addresses some of the challenges faced by software vendors when developing secure software. The approach is to reduce the risk of introducing security weaknesses to software products by providing solutions that support software developers during the software lifecycle.  Software developers are usually not security experts. However, there are methods and tools, such as the ones introduced in this thesis, that can help developers build more secure software.

The research is performed with a design science approach, where the risk reducing method is the artifact that is iteratively developed.  Chronologically, the research is divided into two parts. The first part provides security models as a means of developing a detailed understanding of the extent of potential security issues and their respective security mitigation activities. The purpose is to lower the risk of introducing vulnerabilities to the software during its lifecycle. This is facilitated by the Sustainable Software Security Process (S3P), which is a structured and generally applicable process aimed at minimizing the effort of using security models during all phases of the software development process. S3P achieves this in three steps. The first step uses a semi-formal modeling approach and identifies causes of known vulnerabilities in terms of defects and weaknesses in development activities that may introduce the vulnerability in the code. The second step identifies measures that if in place would address the causes and eliminate the underlying vulnerability and support selection of the most suitable measures. The final step ensures that the selected measures are adopted into the development process to reduce the risk of having similar vulnerabilities in the future.

Collaborative tools can be used in this process to ensure that software developers who are not security experts benefit from application of the S3P process and its components. For this thesis, proof-of-concept versions of collaboration tools were developed to support the three steps of the S3P.

We present the results of our empirical evaluations on all three steps of S3P using various methods such as surveys, case studies and asking for expert opinion to verify that the method is fully understandable and easy to perform and is perceived by developers to provide value for software security.

The last contribution of the first part of research deals with improving product security during requirements engineering through integration of parts of S3P into Common Criteria (CC) and in this way to improve the accuracy of CC through systematically identifying the security objectives and proposing solutions to meet those objectives using S3P. The review and validation by an industrial partner leading in the CC area demonstrate improved accuracy of CC.

Based on the findings in the first part of the research, the second part focuses on early phases of software development and vulnerability causes originating from requirements engineering. We study the challenges associated with introducing a specific security activity, i.e., Security Risk Assessment (SRA), into the requirements engineering process in a large-scale software development context. Specific attention is given to the possibility of bridging the gap between developers and security experts when using SRA and examines the pros and cons of organizing personnel working with SRA in a centralized, distributed, or semi-distributed unit. As the journey of changing the way of working in a large corporation takes time and involves many factors, it was natural to perform a longitudinal case study - all the way from pilot studies to full-scale, regular use.

The results of the case study clarify that introduction of a specific security activity to the development process must be evolved over time in order to achieve the desired results. The present design of the SRA method shows that it is worthwhile to work with risk assessment in the requirements phase with all types of requirements, even at a low level of abstraction. The method aligns well with a decentralized, agile development method with many teams working on the same product. During the study, we observed an increase in security awareness among the developers in the subject company. However, it was also observed that involvement of security experts to ensure acceptable quality of the risk assessment and to identify all risks cannot be totally eliminated.

Context: Passive testing is a technique in which traces collected from the execution of a system under testare examined for evidence of flaws in the system.

Objective: In this paper we present a method for detecting the presence of security vulnerabilities bydetecting evidence of their causes in execution traces. This is a new approach to security vulnerabilitydetection.

Method: Our method uses formal models of vulnerability causes, known as security goal models and vulnerabilitydetection conditions (VDCs). The former are used to identify the causes of vulnerabilities andmodel their dependencies, and the latter to give a formal interpretation that is suitable for vulnerabilitydetection using passive testing techniques. We have implemented modeling tools for security goal modelsand vulnerability detection conditions, as well as TestInv-Code, a tool that checks execution traces ofcompiled programs for evidence of VDCs.

Results: We present the full definitions of security goal models and vulnerability detection conditions, aswell as structured methods for creating both. We describe the design and implementation of TestInv-Code. Finally we show results obtained from running TestInv-Code to detect typical vulnerabilities in severalopen source projects. By testing versions with known vulnerabilities, we can quantify the effectivenessof the approach.

Conclusion: Although the current implementation has some limitations, passive testing for vulnerabilitydetection works well, and using models as the basis for testing ensures that users of the testing tool caneasily extend it to handle new vulnerabilities.

Incident post-mortem analysis after recovery from incidents is recommended by most incident response experts. An analysis of why and how an incident happened is crucial for determining appropriate countermeasures to prevent the recurrence of the incident. Currently, there is a lack of structured methods for such an analysis, which would identify the causes of a security incident. In this paper, we present a structured method to perform the post-mortem analysis and to model the causes of an incident visually in a graph structure. This method is an extension of our earlier work on modeling software vulnerabilities. The goal of modeling incidents is to develop an understanding of what could have caused the security incident and how its recurrence can be prevented in the future. The method presented in this paper is intended to be used during the post-mortem analysis of incidents by incident response teams.

Within the field of software security we have yet to find efficient ways on how to learn from past mistakes and in- tegrate security as a natural part of software development. This situation can be improved by using an online reposi- tory, the SHIELDS SVRS, that facilitates fast and easy inter- change of security artefacts between security experts, soft- ware developers and their assisting tools. Such security artefacts are embedded in or represented as security mod- els containing the needed information to detect, remove and prevent vulnerabilities in software, independent of the ap- plied development process. The purpose of this paper is to explain the main reference architecture description of the repository and the more general tool stereotypes that can communicate with it.

Security of software systems has become one of the biggest concerns in our everyday life, since software systems are increasingly used by individuals, companies and governments. One way to help software system consumers gain assurance about the security measures of software products is to evaluate and certify these products with standard evaluation processes. The Common Criteria (ISO/IEC 15408) evaluation scheme is a standard that is widely used by software vendors. This process does not include information about already known vulnerabilities, their attack data and lessons learned from them. This has resulted in criticisms concerning the accuracy of this evaluation scheme since it might not address the areas in which actual vulnerabilities might occur.

In this paper, we present a methodology that introduces information about threats from vulnerabilities to Common Criteria documents. Our methodology improves the accuracy of the Common Criteria by providing information about known vulnerabilities in Common Criteria’s security target. Our methodology also provides documentation about how to fulfill certain security requirements, which can reduce the time for evaluation of the products.

Currently, security is frequently considered late in software life cycle. It is often bolted on late in development, or even during deployment or maintenance, through activities such as add-on security software and penetration-and-patch maintenance. Even if software developers aim to incorporate security into their products from the beginning of the software life cycle, they face an exhaustive amount of ad hoc unstructured information without any practical guidance on how and why this information should be used and what the costs and benefits of using it are. This is due to a lack of structured methods.

In this thesis we present a model for secure software development and implementation of a security plug-in that deploys this model in software life cycle. The model is a structured unified process, named S3P (Sustainable Software Security Process) and is designed to be easily adaptable to any software development process. S3P provides the formalism required to identify the causes of vulnerabilities and the mitigation techniques that address these causes to prevent vulnerabilities. We present a prototype of the security plug-in implemented for the OpenUP/Basic development process in Eclipse Process Framework. We also present the results of the evaluation of this plug-in. The work in this thesis is a first step towards a general framework for introducing security into the software life cycle and to support software process improvements to prevent recurrence of software vulnerabilities.

In this paper we present a security plug-in for the OpenUP/Basic development process. Our security plug-in is based on a structured unified process for secure software development, named S3P (sustainable software security process). This process provides the formalism required to identify the causes of vulnerabilities and the mitigation techniques that prevent these vulnerabilities. We also present the results of an expert evaluation of the security plug-in. The lessons learned from development of the plug-in and the results of the evaluation will be used when adapting S3P to other software development processes.

Security has become a necessary part of nearly every software development project, as the overall risk from malicious users is constantly increasing, due to increased consequences of failure, security threats and exposure to threats. There are few projects today where software security can be ignored. Despite this, security is still rarely taken into account throughout the entire software lifecycle; security is often an afterthought, bolted on late in development, with little thought to what threats and exposures exist. Little thought is given to maintaining security in the face of evolving threats and exposures. Software developers are usually not security experts. However, there are methods and tools available today that can help developers build more secure software. Security modeling, modeling of e.g., threats and vulnerabilities, is one such method that, when integrated in the software development process, can help developers prevent security problems in software. We discuss these issues, and present how modeling tools, vulnerability repositories and development tools can be connected to provide support for secure software development

When vulnerabilities are discovered in software, which often happens after deployment, they must be addressed as part of ongoing software maintenance. A mature software development organization should analyze vulnerabilities in order to determine how they, and similar vulnerabilities, can be prevented in the future. In this paper we present a structured method for analyzing and documenting the causes of software vulnerabilities. Applied during software maintenance, the method generates the information needed for improving the software development process, to prevent similar vulnerabilities in future releases. Our approach is based on vulnerability cause graphs, a structured representation of causes of software vulnerabilities

Security is often an afterthought when developing software, and is often bolted on late in development or even during deployment or maintenance, through activities such as penetration testing, add-on security software and penetrate-and patch maintenance. We believe that security needs to be built in to the software from the beginning, and that security activities need to take place throughout the software lifecycle. Accomplishing this effectively and efficiently requires structured approach combining a detailed understanding on what causes vulnerabilities, and how specific activities combine to prevent them.In this paper we introduce key elements of the approach we are taking: vulnerability cause graphs, which encode information about vulnerability causes, and security activity graphs, which encode information about security activities. We discuss how these can be applied to design software development processes (or changes to processes) that eliminate software vulnerabilities.