Change search
Link to record
Permanent link

Direct link
BETA
Baca, Dejan
Publications (3 of 3) Show all publications
Baca, D. & Petersen, K. (2013). Countermeasure graphs for software security risk assessment: An action research. Journal of Systems and Software, 86(9), 2411-2428
Open this publication in new window or tab >>Countermeasure graphs for software security risk assessment: An action research
2013 (English)In: Journal of Systems and Software, ISSN 0164-1212, Vol. 86, no 9, p. 2411-2428Article in journal (Refereed) Published
Abstract [en]

Software security risk analysis is an important part of improving software quality. In previous research we proposed countermeasure graphs (CGs), an approach to conduct risk analysis, combining the ideas of different risk analysis approaches. The approach was designed for reuse and easy evolvability to support agile software development. CGs have not been evaluated in industry practice in agile software development. In this research we evaluate the ability of CGs to support practitioners in identifying the most critical threats and countermeasures. The research method used is participatory action research where CGs were evaluated in a series of risk analyses on four different telecom products. With Peltier (used prior to the use of CGs at the company) the practitioners identified attacks with low to medium risk level. CGs allowed practitioners to identify more serious risks (in the first iteration 1 serious threat, 5 high risk threats, and 11 medium threats). The need for tool support was identified very early, tool support allowed the practitioners to play through scenarios of which countermeasures to implement, and supported reuse. The results indicate that CGs support practitioners in identifying high risk security threats, work well in an agile software development context, and are cost-effective.

Place, publisher, year, edition, pages
Elsevier, 2013
Keywords
Countermeasure graphs, Risk analysis, Software security
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-6675 (URN)10.1016/j.jss.2013.04.023 (DOI)000323870300017 ()oai:bth.se:forskinfoEA9523F0735CA7C0C1257B750045013C (Local ID)oai:bth.se:forskinfoEA9523F0735CA7C0C1257B750045013C (Archive number)oai:bth.se:forskinfoEA9523F0735CA7C0C1257B750045013C (OAI)
Available from: 2014-07-17 Created: 2013-05-24 Last updated: 2018-01-11Bibliographically approved
Baca, D., Carlsson, B., Petersen, K. & Lundberg, L. (2013). Improving software security with static automated code analysis in an industry setting. Software, practice & experience, 43(3), 259-279
Open this publication in new window or tab >>Improving software security with static automated code analysis in an industry setting
2013 (English)In: Software, practice & experience, ISSN 0038-0644, E-ISSN 1097-024X, Vol. 43, no 3, p. 259-279Article in journal (Refereed) Published
Abstract [en]

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.

Place, publisher, year, edition, pages
Wiley, 2013
Keywords
Software security, Static analysis, Static code analysis, Vulnerabilities
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-7006 (URN)10.1002/spe.2109 (DOI)000314926900001 ()oai:bth.se:forskinfo3B2CC72BC40A4F02C1257AC900348970 (Local ID)oai:bth.se:forskinfo3B2CC72BC40A4F02C1257AC900348970 (Archive number)oai:bth.se:forskinfo3B2CC72BC40A4F02C1257AC900348970 (OAI)
Available from: 2013-03-15 Created: 2012-12-03 Last updated: 2018-01-11Bibliographically approved
Baca, D. (2012). Developing Secure Software: in an Agile Process. (Doctoral dissertation). Karlskrona: Blekinge Institute of Technology
Open this publication in new window or tab >>Developing Secure Software: in an Agile Process
2012 (English)Doctoral thesis, comprehensive summary (Other academic)
Abstract [en]

Background: Software developers are facing increased pressure to lower development time, release new software versions more frequent to customers and to adapt to a faster market. This new environment forces developers and companies to move from a plan based waterfall development process to a flexible agile process. By minimizing the pre development planning and instead increasing the communication between customers and developers, the agile process tries to create a new, more flexible way of working. This new way of working allows developers to focus their efforts on the features that customers want. With increased connectability and the faster feature release, the security of the software product is stressed. To develop secure software, many companies use security engineering processes that are plan heavy and inflexible. These two approaches are each others opposites and they directly contradict each other. Objective: The objective of the thesis is to evaluate how to develop secure software in an agile process. In particular, what existing best practices can be incorporated into an agile project and still provide the same benefit if the project was using a waterfall process. How the best practices can be incorporated and adapted to fit the process while still measuring the improvement. Some security engineering concepts are useful but the best practice is not agile compatible and would require extensive adaptation to integrate with an agile project. Method: The primary research method used throughout the thesis is case studies conducted in a real industry setting. As secondary methods for data collection a variety of approaches have been used, such as semi-structured interviews, workshops, study of literature, and use of historical data from the industry. Results: The security engineering best practices were investigated though a series of case studies. The base agile and security engineering compatibility was assessed in literature, by developers and in practical studies. The security engineering best practices were group based on their purpose and their compatibility with the agile process. One well known and popular best practice, automated static code analysis, was toughly investigated for its usefulness, deployment and risks of using as part of the process. For the risk analysis practices, a novel approach was introduced and improved. As such, a way of adapting existing practices to agile is proposed. Conclusion: With regard of agile and security engineering we did not find that any of the investigated processes was agile compatible. Agile is reaction driven that adapts to change, while the security engineering processes are proactive and try to prevent threats before they happen. To develop secure software in an agile process the developers should adopt and adapt key concepts from security engineering. These changes will affect the flexibility of the agile process but it is a necessity if developers want the same software security state as security engineering processes can provide.

Place, publisher, year, edition, pages
Karlskrona: Blekinge Institute of Technology, 2012
Series
Blekinge Institute of Technology Doctoral Dissertation Series, ISSN 1653-2090 ; 5
National Category
Software Engineering Computer Sciences
Identifiers
urn:nbn:se:bth-00525 (URN)oai:bth.se:forskinfo937EF1036AC6B559C12579DC00310FFD (Local ID)978-91-7295-229-4 (ISBN)oai:bth.se:forskinfo937EF1036AC6B559C12579DC00310FFD (Archive number)oai:bth.se:forskinfo937EF1036AC6B559C12579DC00310FFD (OAI)
External cooperation:
Available from: 2012-09-18 Created: 2012-04-10 Last updated: 2018-01-11Bibliographically approved
Organisations

Search in DiVA

Show all publications