In this article, the authors contrast the results of a series of interviews with agile software development organizations with a case study of a distributed agile development effort, focusing on how information security is taken care of in an agile context. The interviews indicate that small and medium-sized agile software development organizations do not use any particular methodology to achieve security goals, even when their software is web-facing and potential targets of attack. This case study confirms that even in cases where security is an articulated requirement, and where security design is fed as input to the implementation team, there is no guarantee that the end result meets the security objectives. The authors contend that security must be built as an intrinsic software property and emphasize the need for security awareness throughout the whole software development lifecycle. This paper suggests two extensions to agile methodologies that may contribute to ensuring focus on security during the complete lifecycle.
Top2. Background
Enabling information systems to communicate via open networks such as the Internet will always be associated with elements of risk. (Mavridis, Georgiadis, Pangalos, & Khair, 2001) correctly state that “Security risks cannot be entirely removed when transmitting information over the Internet”. The European Parliamentary Technology Assessment (EPTA) network has made similar considerations and specifically expressed concerns that privacy is challenged by the increase in development of ICT applications for the healthcare sector (EPTA, 2006). Such concerns are also raised by others, such as (Ilioudis & Pangalos, 2001) and (van der Haak et al., 2003).
(Boström, Wäyrynen, Bodén, Beznosov, & Kruchten, 2006) detail an extension to the XP planning game that is intended to establish a balance between the conventional (document-centric and plan-driven) way of doing security engineering, and the iteration-centric, feedback-driven XP practices. This is relevant as they try to solve a problem closely related to ours. The main difference is that they are specific to the XP methodology and only try to integrate the security requirements engineering (software security) activity, where as our approach is more generic for Agile methods and not focusing on just one specific security activity.
(Beznosov & Kruchten, 2004) attempt to find the pain points between agile methods and security assurance, and suggest some means on how to alleviate them. They group the problems and evaluate how good they match up against activities from security assurance. They focus on a specific problem, like Boström et al.’s approach, and do not seek to solve a more general problem.
(Siponen, Baskerville, & Kuivalainen, 2005) provide an example on how to integrate some security activities into agile development methods. They focus on four key security elements: security-relevant subjects, security-relevant objects, security classification of objects and subjects, and risk management. In the provided example where they apply their technique, it becomes apparent that it requires a lot more effort than what can be expected from an average developer. We therefore consider this too heavy for general applications with agile software development. Their result gives us an indication of what makes a process too thorough.