Developing secure software - In an agile process

Research Area

Most software development organizations have some desire or goal to create secure software that insure their products' availability and robustness. How software security is achieved varies greatly in terms of commitment, approach and actual result. Common for all are the possible consequences of poor software security. While some companies suffer direct financial loss all would suffer from poor reputation. A stained security reputation can follow a company for a long time, creating a negative image for all future products. Microsoft's products were early labeled as insecure and the company had to invest large sums to improve its products and repair its reputation. Whatever the reason, companies are today looking to improve their products' software security. Unfortunately, the demand of quick release and constant flow of new products has forced companies to move away from methodical and big design upfront waterfall processes and also most Security engineering processes. Companies and developers have instead adopted agile processes, which are iterative and incremental, and can easier adapt to new changes and release small changes to customers at a faster rate. The agile process creates new problems for the security engineer that need to be addressed.

http://www.bth.se/fou/Forskinfo.nsf/17e96a0dab8ab6a1c1257457004d59ab/937ef1036ac6b559c12579dc00310ffd!OpenDocument

Papers

Prioritizing Countermeasures through the Countermeasure Method for Software Security (CM-Sec)

- PLAS (2010) Product-Focused Software Process Improvement

Abstract:

Software security is an important quality aspect of a software system. Therefore, it is important to integrate software security touch points throughout the development life-cycle. So far, the focus of touch points in the early phases has been on the identification of threats and attacks. In this paper we propose a novel method focusing on the end product by prioritizing countermeasures. The method provides an extension to attack trees and a process for identification and prioritization of countermeasures. The approach has been applied on an open-source application and showed that countermeasures could be identified. Furthermore, an analysis of the effectiveness and cost-efficiency of the countermeasures could be provided.

 

An Industry implementation of Countermeasure Graphs

- Manuscript submitted to Journal of Systems and Software

Abstract:

Risk and threat analysis are an important part of early vulnerability prevention. Risk analysis, threat models and abuse cases are different methods of identifying and preventing risks. However, none of these methods integrated well with agile process that the examine company used. Because of the small iterations and incomplete designs many of the traditional methods did not aid the risk assessment process. Through an action research approach and with the aid of several industrial projects, this paper has improved a novel risk analysis method. The countermeasure graph focuses on identifying and ranking protective measures against attacks product. By creating a model of the attack surface against the product it aids the developers in identifying attacks and ways of preventing them. The model also allows for incremental work and makes it easier to transfer the knowledge to future increments and reuse previous work.

 

Static Code Analysis to Detect Software Security Vulnerabilities - Does Experience Matter?

- ARES (2009) Availability, Reliability and Security

Abstract:

Code reviews with static analysis tools are today recommended by several security development processes. Developers are expected to use the tools’ output to detect the security threats they themselves have introduced in the source code. This approach assumes that all developers can correctly identify a warning from a static analysis tool (SAT) as a security threat that needs to be corrected. We have conducted an industry experiment with a state of the art static analysis tool and real vulnerabilities. We have found that average developers do not correctly identify the security warnings and only developers with specific experiences are better than chance in detecting the security vulnerabilities. Specific SAT experience more than doubled the number of correct answers and, a combination of security experience and SAT experience almost tripled the number of correct security answers.

 

Improving Software Security with Static Automated Code Analysis in an Industry Setting

- Journal Software: Practice and Experience

Abstract:

Software security can be improved by identifying and correcting vulnerabilities. In order to reduce the cost of rework, vulnerabilities should be detected as early and efficiently as possible. Static automated code analysis is an approach for early detection. So far, only few empirical studies have been conducted in an industrial context to evaluate static automated code analysis. A case study was conducted to evaluate static code analysis in industry focusing on defect detection capability, deployment, and usage of static automated code analysis with a focus on software security. We identified that the tool was capable of detecting memory related vulnerabilities, but few vulnerabilities of other types. The deployment of the tool played an important role in its success as an early vulnerability detector, but also the developers perception of the tools merit. Classifying the warnings from the tool was harder for the developers than to correct them. The  correction of false positives in some cases created new vulnerabilities in previously safe code. With regard to defect detection ability, we conclude that static code analysis is able to identify vulnerabilities in different categories. In terms of deployment, we conclude that the tool should be integrated with bug reporting systems, and developers need to share the responsibility for classifying and reporting warnings. With regard to tool usage by developers, we propose to use multiple persons (at least two) in classifying a warning. The same goes for making the decision of how to act based on the warning

 

Agile development with Security Engineering activities

- ICSSP (2011) International Conference on Software and Systems Process

Abstract:

Agile software development has been used by industry to create a more flexible and lean software development process, i.e making it possible to develop software at a faster rate and with more agility during development. There are however concerns that the higher development pace and lack of documentation are creating less secure software. We have therefore looked at three known Security Engineering processes, Microsoft SDL, Cigatel touchpoints and Common Criteria and identified what specific security activities they performed. We then compared these activities with an Agile development process that is used in industry. Developers, from a large telecommunication manufacturer, were interviewed to learn their impressions on using these security activities in an agile development process. We produced a security enhanced Agile development process that we present in this paper. This new Agile process use activities from already established security engineering processes that provide the benefit the developers wanted but did not hinder or obstruct the Agile process in a significant way.

 

Integrating security engineering in an agile process

- Manuscript submitted to Transactions on Software Engineering and Methodology

Abstract:

In this paper we examine how the software development transition, from a former waterfall model to a more flexible agile software development process, expounds security issues. In the studied industrial case, software development projects are investigated involving 5 different phases (requirement, design, implementation, test and release). Within originally a waterfall model three external tools (Cigatel Touchpoints, Common Criteria and Microsoft Security Development Lifecycle Process) for improving quality and security aspects, are investigated. Three different teams within an agile setting were identified for improving the security of the end product; the software product manager (SPM), the development project teams (DP) and latest stable version test team (LSV). Developers working within an agile development process were interviewed and the results were implemented forming a new agile software engineering process. Some activities, compared to the waterfall model, are rejected as too time consuming or being too restricted in a simplified agile setting.
In all 31 activities were investigated originally developed within a waterfall model. For the agile setting 20 of these activities were used, 6 directly and 14 in a modified version representing 7 different agile activities, i.e. in all 13 different agile activities. In total, we found 3 SPM activities covering requirement and design, 7 DP activities within design, implementation, test and release and finally 3 LSV activities within test and release. Instead of having a pro-active waterfall model the agile activities are reactive, i.e. development instead of trying to solve very complex problems before the full understanding of the product.


----------------------------------------------------------------------------------------------------------------------


Licentiate - Defended 2009

Department of Systems and Software Engineering
School of Engineering
Blekinge Institute of Technology
ISBN 978-91-7295-161-7

Automated static code analysis - A tool for early vulnerability detection

Research area

Software vulnerabilities are added into programs during its development. Architectural flaws are introduced during planning and design, while implementation faults are created during coding. Penetration testing is often used to detect these vulnerabilities. This approach is expensive because it is performed late in development and any correction would increase lead-time. An alternative would be to detect and correct vulnerabilities in the phase of development where they are the least expensive to correct and detect. Source code audits have often been suggested and used to detect implementations vulnerabilities. However, manual audits are time consuming and require extended expertise to be efficient. A static code analysis tool could achieve the same results as a manual audit but at fraction of the time.

Through a set of cases studies and experiments at Ericsson AB, this thesis investigates the technical capabilities and limitations of using a static analysis tool as an early vulnerability detector. The investigation is extended to studying the human factor by examining how the developers interact and use the static analysis tool.

The contributions of this thesis include the identification of the tools capabilities so that further security improvements can focus on other types of vulnerabilities. By using static analysis early in development possible cost saving measures are identified. Additionally, the thesis presents the limitations of static code analysis. The most important limitation being the incorrect warnings that are reported by static analysis tools. In addition, a development process overhead was deemed necessary to successfully use static analysis in an industry setting.

-> Donwload the Licentiate <-

 

Papers

Software Security Analysis - Execution Phase Audit

- EuroMicro (31:st) 2005 IEEE

Abstract:

Code revision of a leading telecom product was
performed, combining manual audit and static analysis
tools. On average, one exploitable vulnerability was
found for every 4000 lines of code. Half of the located
threats in the product were buffer overflows followed by
race condition, misplaced trust, and poor random generators.
Static analysis tools were used to speed up the
revision process and to integrate security tests into the
overall project process. The discussion analyses the
effectiveness of automatic tools for auditing software.
Furthermore, the incorporation of the software security
analysis into the development process, and the results
and costs of the security analysis is discussed. From the
initial 42 workdays used for finding all vulnerabilities,
approximately 16 days were needed for finding and
correcting 91,5 % of the vulnerabilities. So, proportionally
small investments improve the program code security
by integrating an automatic auditing tool into the
ordinary execution of source code revision.

 

Evaluating the Cost Reduction of Static Code Analysis for Software Security

- PLAS (3:rd) 2008 ACM

Abstract:

Automated static code analysis is an efficient technique to increase the quality of software during early development. This paper presents a case study in which mature software with known vul-nerabilities is subjected to a static analysis tool. The value of the tool is estimated based on reported failures from customers. An average of 17% cost savings would have been possible if the static analysis tool was used. The tool also had a 30% success rate in detecting known vulnerabilities and at the same time found 59 new vulnerabilities in the three examined products.

 

Static Code Analysis to Detect Software Security Vulnerabilities: Does Experience Matter?

- ARES - SECSE (3:rd) 2009 IEEE

Abstract:

Code reviews with static analysis tools are today recommended by several security development processes. Developers are expected to use the tools’ output to detect the security threats they themselves have introduced in the source code. This approach assumes that all developers can correctly identify a warning from a static analysis tool (SAT) as a security threat that needs to be corrected. We have conducted an industry experiment with a state of the art static analysis tool and real vulnerabilities. We have found that average developers do not correctly identify the security warnings and only developers with specific experiences are better than chance in detecting the security vulnerabilities. Specific SAT experience more than doubled the number of correct answers and, a combination of security experience and SAT experience almost tripled the number of correct security answers.

 

Static analysis as a security touch point: An industry case study

- Journal (Systems and Software)

Abstract:

In this paper, we have studies a company's usage of a static analysis tool. We have observed what types of vulnerabilities the tool detects, how the tool is used and how developers handle the tool. We identi ed that the tool is capable in detecting memory related vulnerabilities but few vulnerabilities of other types. The deployment of the tool played an important role in it success as an early vulnerability detector, but also the developers' perception of the tools merit. Classifying the warnings from the tool was actually harder then to correct them and the correction of false positives created in some cases created new vulnerabilities in previous safe code. The tools ability to pinpoint vulnerabilities down to the source code line was both strength and a weakness, as developers perceived the warning as simple and unimportant.

§

 

Redigera
Share Dela