Risk Centric Activities in Secure Software Development in Public Organisations

Risk Centric Activities in Secure Software Development in Public Organisations

Inger Anne Tøndel (Department of Computer Science, Norwegian University of Science and Technology (NTNU), Trondheim, Norway & SINTEF Digital, Trondheim, Norway), Martin Gilje Jaatun (Department of Software Engineering, Safety & Security, SINTEF Digital, Trondheim, Norway), Daniela Soares Cruzes (Department of Software Engineering, Safety & Security, SINTEF Digital, Trondheim, Norway) and Nils Brede Moe (SINTEF Digital, Trondheim, Norway)
Copyright: © 2017 |Pages: 30
DOI: 10.4018/IJSSE.2017100101
OnDemand PDF Download:
No Current Special Offers


When working with software security in a risk-centric way, development projects become equipped to make decisions on how much security to include and what type of security pays off. This article presents the results of a study made among 23 public organisations, mapping their risk-centric activities and practices, and challenges for implementing them. The authors found that their software security practices were not based on an assessment of software security risks, but rather driven by compliance. Additionally, their practices could in many cases be characterised as arbitrary, late and error driven, with limited follow up on any security issues throughout their software development projects. Based on the results of the study, the authors identified the need for improvements in three main areas: responsibilities and stakeholder cooperation; risk perception and competence; and, practical ways of doing risk analysis in agile projects.
Article Preview

1. Introduction

Today, nearly all sectors of society depend on software systems to operate efficiently. As the dependency on software has grown, so have the threats towards these systems and the potential consequences of incidents. Though network security measures (such as firewalls and anti-virus software) can improve the security of the software systems, these only address the symptoms of the real problem: software that is crippled with vulnerabilities (McGraw, 2006).

Building security into the software, through adopting software security activities and measures in the development process, is a direct and effective way of dealing with cyber threats towards software systems. This, however, adds to the development time and cost, and this addition needs to be justified. Working towards 100% secure systems is not feasible, thus it is necessary to identify which part of the software is more critical regarding security and which activities will be most efficient and effective in securing the software product. Taking a risk centric approach to software security means to identify what are the major risks of the particular software that is developed, and use this knowledge of risk to guide decisions regarding software security. This is commonly recommended by current secure Software Development Lifecycles (SDLs), frameworks and maturity models (Chandra, 2008; Howard & Lipner, 2006; McGraw, 2006; McGraw et al., 2016).

In many ways, security can be considered to be in conflict with the current trend of “continuous development” (Fitzgerald & Stol, 2017), reducing efficiency by delaying delivery of new features (at least in the shorter term, though costs may be saved through having to provide fewer fixes later). Agile software development uses an iterative approach to software construction, aimed at reducing development time, and prioritising value, while improving software quality and inherently reducing risk (Cockburn and Highsmith 2001). It is clear that people issues are the most critical in agile projects and that these must be addressed if agile is to be implemented successfully (Cockburn and Highsmith 2001). Even though agile methods claim to be risk driven (Beck, 2000; Eclipse, 2016), some authors have observed that risk management has been neglected in project management of agile projects (Hijazi et al., 2012; Ibbs & Kwak, 2000; Junior et al., 2012; Raz et al., 2002). It may be more difficult to establish a working process for software security activities in agile development compared to waterfall-based development, where you could more easily have mandatory or recommended security activities for the different software development phases (ben Othmane et al., 2014; Jaatun et al., 2015; Microsoft, 2009). Oyetoyan et al. (2017) provide a brief overview of secure SDLs and conclude that traditional approaches to software security do not necessarily work well with agile development processes. Additionally, security is largely a systemic property, and with agile development it can be more of a challenge to have a complete view of the final system (ben Othmane et al., 2014). At the same time, agile development may come with some opportunities regarding security, e.g. to adapt to new security threats and to have ongoing interaction with customers about security.

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 8: 4 Issues (2017)
Volume 7: 4 Issues (2016)
Volume 6: 4 Issues (2015)
Volume 5: 4 Issues (2014)
Volume 4: 4 Issues (2013)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing