Adapting Agile Practices to Security Context – Practitioners’ Perspective

Łukasiewicz, Katarzyna; Cygańska, Sara

doi:10.1007/978-3-030-37534-8_4

Katarzyna Łukasiewicz⁸ &
Sara Cygańska⁹

Part of the book series: Lecture Notes in Business Information Processing ((LNBIP,volume 376))

Included in the following conference series:

1011 Accesses

Abstract

In this paper we explore the problem of introducing agile practices to projects dealing with systems with high security requirements. We also propose an approach based on AgileSafe method and OWASP ASVS guidelines, that could support such introduction. What is more, we present the results of two surveys aimed at analyzing IT practitioners’ views on applying agile methods to security reliant systems as well as evaluating the set of agile security-oriented practices which are a part of the proposed approach. This paper is an extended version of the paper “Security-oriented agile approach with AgileSafe and OWASP ASVS” that was published as a part of LASD 2019 conference proceedings [36].

Access provided by Autonomous University of Puebla. Download conference paper PDF

How to Integrate Security Compliance Requirements with Agile Software Engineering at Scale?

Secure Agile Software Development: Policies and Practices for Agile Teams

S-SCRUM—Methodology for Software Securitisation at Agile Development. Application to Smart University

Keywords

1 Introduction

The concern for providing secure systems has become increasingly important throughout the years. With the rapid progress in the IT domain, expansion of the internet solutions and the level of general computer science knowledge, the problem with security is no longer restricted to government organizations and banking, it involves even small companies that store any private data or engage in the IoT projects.

At the same time, the changing markets and need for flexibility encourages many companies to adopt agile approach [1]. While such approach is known for its benefits concerning effectiveness and client satisfaction [1], when it comes to the security aspect the potential advantages are not that obvious. The core agile methods, such as Scrum [2], eXtreme Programming [3] or Kanban [4] do not mention explicitly security-oriented practices. On the other hand, most of the readily available security frameworks were created with a more disciplined approach in mind.

Taking into consideration the unflagging popularity of agile methods and an increasing concern for security in the IT domain, an approach that would allow to incorporate more security-oriented practices into agile software development would be of value [5].

The goal of the research described in this paper was to identify security-focused agile practices, evaluate their usability and impact so that the positively assessed practices could be incorporated into an OWASP ASVS [6] compliant process, as a part of AgileSafe method [7].

2 Background

2.1 Agile Methods

Ever since the announcement of the Agile Manifesto [8], the agile methods have been growing increasingly in popularity. The reports of the benefits experienced by numerous companies [9, 10] encouraged the trend to shift from traditional, plan-driven methods to the agile ones. What is important, this shift has not only concerned small and evolving companies which are considered a target of the agile approach. Bigger organizations with larger teams or corporate structures have also sought the ways to incorporate agile approach, which resulted in methods such as SAFe [11] or DevOps [12].

2.2 Security Frameworks and Standards

Since the 1990’s there have been attempts to formalize guidelines and standards concerning software security. In 1999 ISO [13] proposed Common Criteria for Information Technology Security Evaluation – ISO 15408 [14]. Recognizing the value of unified security standard, governments of Canada, France, Germany, Netherlands, United Kingdom and United States were involved in the creation of this document. The main goal of ISO 15408 was to present formal criteria for security assessment of computer systems. There are other standards that address more specific security concerns such as ISO 27032 [15] and NIST Cybersecurity Framework (NIST CSF) [16] which focus on cybersecurity.

While providing vital information and formal methods to assess security in computer systems, these standards are not directly applicable to agile software development processes. Agile methods are not inherently equipped with security assurance practices. Should such methods be applied in their basic forms, they would struggle to provide conformance evidence for security standards. At the same time, adding traditional security-oriented practices to agile software development process might weigh it down and advantages of the agility could be lost. This opens a room for researching towards a solution which enables to meet the recommendations and to follow the related best practices of secure software development processes while still not backing down from being agile unless it is necessary.

2.3 OWASP ASVS

The name of the OWASP Application Security Verification Standard (OWASP ASVS) comes from the organization with same name, which created it - The Open Web Application Security Project [17]. OWASP is a non-profit organization whose goal is to improve software security. Its mission is defined as improving the visibility of the security problem, both among individuals and organizations, so that they can make decisions on this subject consciously [17]. The organization operates as an open community in which anyone interested in security issues can participate. It publishes tools and documents that are available under open licenses. Due to the lack of connection with commercial companies, OWASP describes itself as impartial.

OWASP ASVS is directed both to people involved directly in the development process (developers, architects, testers, security experts) as well as their clients. Its two main goals are to help creating and maintaining secure software and help in defining requirements between service providers and their clients. A straightforward language and accessibility make it a practitioners’ friendly standard.

The standard distinguishes three levels of requirements for various purposes and the degree of security provided: Level 1: Opportunistic, Level 2: Standard and Level 3: Advanced.

OWASP ASVS has been chosen for this research based on its versatility, open access and popularity among practitioners [18]. The domain of web applications is at the forefront of security issues, with frequent news about major security breaches [19]. For this reason, catering a solution that would allow combining agile security practices with OWASP ASVS requirements could be of interest to many organizations.

2.4 Related Work

Attempts to address the new hybrid approach for security aware agile development are carried out in various ways. One of the ideas is to create new, extended methodologies based on the existing agile ones. An example of this is the Secure Scrum method 20, which extends Scrum. It’s been created as an extension to Scrum to support the security assurance. This method presents some valuable practices (such as S-Tag and S-Mark) but focuses only on Scrum and does not address the norms and standards conformance aspect.

Other propositions include frameworks that can be used with any agile methodology - this approach has been used by the aforementioned AgileSafe method but in the safety aspect as well as the method proposed by Veracode. It involves performing Veracode services on user’s code to detect vulnerabilities. The service is offered in the cloud and the details of the tests are not visible to the users. Veracode allows security verification to be carried out in several different ways.

The operation of this type of solution is based on the observation that agile methodologies are a set of certain practices. It is possible, therefore, to extend them to new practices, as long as they do not conflict with the existing ones.

3 AgileSafe

The need for hybrid approaches that would allow reconciling regulatory requirements with agile practices is not exclusive to the security context. Safety-critical software development is another, if only more so, highly constrained domain. In the safety context, quite similarly to the security one, norms and standards are vital to ensure the level of trust and quality of high-integrity systems. In order to enable safety-critical software companies to adopt hybrid agile approach while satisfying the regulatory requirements of applicable standards, AgileSafe [21] method has been proposed. It presents a framework for collecting and suggesting the most suitable agile practices for a given project, as well as the means for managing and monitoring conformance with the applicable regulatory requirements. In this article we present how AgileSafe can be adapted to the security aspect of software development projects and support introduction of hybrid agile approach to such projects while ensuring the compliance with security norms and standards, using OWASP ASVS as an example.

3.1 Overview

As shown in the Fig. 1, as an input to AgileSafe takes the characteristics of a project in which the new approach will be implemented (Project Characteristics) as well as a list of regulations (Regulatory Requirements), which the project needs to comply with.

Based on this information, the user is guided through the process of practices suggestion as well as the process of preparing a set of assurance arguments [22] that will help the user to maintain conformance with given norms and standards. As a result, the user obtains a tailored Project Practices Set, which would suit best a project with given characteristics and regulation restrictions as well as a set of assurance arguments to monitor compliance with the chosen regulations.

3.2 Project Practices Knowledge Base

The information about practices available in AgileSafe, their capability to answer given Project Characteristics and Regulatory Requirements, is kept in the Practices Knowledge Base. Each practice is described using the same template that is then translated into OWL and managed using Protégé tool [23].

An example of a practice description and its capability (type of project for which it works best) for different project factors is presented in the Fig. 2.

At the moment of this research, there were 50 software development practices in the Practices Knowledge Base, including safety-oriented ones.

3.3 Assurance Arguments

In order to ensure that the Regulatory Requirements will be met when applying the new agile approach, AgileSafe uses a set of assurance arguments. The highest level of abstraction is represented by Practices Compliance Argument (and its template Practices Compliance Argument Pattern). It is created separately for each standard added to the method and collects all of the practices from Practices Knowledge Base that have a potential to answer the standard’s requirements. Such practices are arranged accordingly in the argument structure for a given standard requirements. Based on these arguments, Project Practices Compliance Arguments are created for each standard that a given project need to comply with, leaving only these practices that will be used in this project. Project Compliance Argument serves as an argument for collecting actual artifacts of the planned practices that serve as evidence in a conformance process. The arguments structure is presented in the Fig. 3.

3.4 AgileSafe in the Security Context

The potential of applying AgileSafe to the projects concerned with security issues has already been presented in [24] based on a case study for clinic appointment/queue management system and IEC 62443-4.1 standard [25]. The promising results of this case study allowed to form another step to further adapt AgileSafe method to cater for security-critical projects and present hybrid security-oriented practices to the Practices Knowledge Base.

4 Security-Oriented Agile Practices

In order to propose agile security practices that could extend the Practices Knowledge Base of the AgileSafe method, a review of the scientific literature and articles on blogs and industry portals was carried out.

4.1 Identification of Security-Oriented Agile Practices

While there are many well-known security-oriented practices such as threat modelling or attack trees, in this research we wanted to expand this list and focus on less obvious, agile inspired practices, to enrich the Practice Knowledge Base of AgileSafe method.

The first step to identify the practices was to develop queries that allowed finding suitable sources. The following queries: “secure agile practices”, “xp security”, “scrum security” were selected through the elimination and trial searches. The search was carried out in the IEEE Xplore digital library, ResearchGate portal and Google Scholar and Google search engines. The initial selection of articles was performed based on the following criteria: titles, summaries (if available) and access to the entire text. The sources were selected based on the fact whether they addressed the subject of security in agile methodologies. The next step was to inspect them for the presence of the agile practices. For further analysis, those articles that described such practices or those that only mentioned them were selected, provided they contained a reference to the source with further information about the practice. A similar selection process was carried out for articles found on the basis of sources obtained in the previous step. As a result, 10 articles were selected to be used in further work [20, 26,27,28, 30,31,32,33,34].

4.2 Selected Practices Description

Based on the articles identified in the research, 10 hybrid agile security-oriented practices were identified:

Abuser Stories.

They describe, using a form similar to regular User Stories, how the system might be attacked and how assets might be put in risk. They should be estimated in accordance to how much damage they may potentially cause and probability of a successful attack [26].

Evil User Stories.

This practice describes actions of malicious user (e.g. “As a hacker I want to steal payment information of other clients, so I can sell it.”). They may be used as a starting point for threat modelling [27].

Misuse Cases.

They are negative use cases. They illustrate behavior not wanted in the system, that can cause a security breach and can be described using UML diagrams [28].

Protection Poker.

This is a software security game intended to create a list of each requirement relative security risk. It derives form Planning Poker technique of estimation [29].

Second Delivery.

This is a process, that aims to integrate security related solutions to the project that already satisfies functional requirements. It is based on XP methodology [30].

Security Engineer.

It calls for adding an expert role, that brings up-to-date security knowledge to developers’ team. His insight is useful during multiple phases and actions in project.

Security Sprint.

This is a practice inspired by Scrum. It’s similar to regular Sprint except that it focuses on security issues [31].

Security-Focused Code Reviews.

Such reviews should be performed for every story separately – no story can be completed without security review, fixing findings from review and then passing re-review [32].

S-Mark and S-Tag.

Originating from Secure Scrum, they are a way to document identified security issues in Scrum Backlog by creating system of tags (security issues) and markings for stories related to respective tags [20, 34].

Spikes.

They are a way to include security analysis and design within Scrum. They accommodate activities that don’t produce customer-valued product, like security analysis or system designing [33].

5 Surveys

In order to evaluate the usability and accessibility of the selected security-oriented agile practices in projects with high security requirements two surveys were conducted. The first one (Survey A), analyzing more general security in agile aspects, was focused on gaining information about expected average user awareness of problems and chances related to using agile approach in such projects. The second survey (Survey B) tackled 10 specific agile security-oriented practices, asking the respondents to rate their respective ease of use and security enhancement potential.

Subjects chosen to participate in the surveys were 24 IT practitioners (both development and operations) from 7 different software companies, ranging from small to corporate ones, from Poland and UK. The questionnaire was distributed mostly by emails and direct messages in social networks, eliminating probability of acquiring responses from random, unrelated to the field respondents. The survey was created using Google Forms infrastructure, utilizing both open and closed questions. The respondents were also provided with the practices detailed descriptions.

5.1 Survey A

First three survey questions were used to evaluate participants’ experience in agile methods and security related topics. The next two questions assessed benefits and problems related to using agile practices in projects with security requirements. Then respondents were asked about their preferred methodology. All of 24 participants answered those questions.

First question was about years of experience in agile methodologies. The results are presented in the Fig. 4. Almost half of participants declared 1–3 years of experience in agile. Less than ¼ had experience of up to 1 year. Almost 40% had been working with agile methodologies for more than 3 years. Those results suggest that most of the survey participants had at least basic knowledge about agile.

The second question, which results are presented on Fig. 5, was about experience in security reliant projects. Similarly, to the previous questions result, largest group had 1–3 years of experience. ¼ of participants declared experience shorter than 1 year. 17% had more than 3 years of experience, but none had more than 10 years. According to those results participants should have had some knowledge about security related issues.

The third question was about participation in projects with security requirements and utilized methodologies. 75% of respondents participated in such project and out of those 83% used agile methodologies, 11% used traditional methodologies, and 11% worked with different solutions (e.g. hybrid methodologies). For agile practices users, results are shown on Fig. 6. Among agile participants the most popular methodology was Scrum, then Kanban ex-aequo with agile methodologies modification. 13% of respondents didn’t mention any specific agile methodology. It’s worth noting, that none of the respondents who used traditional methodologies had less than 3 years of experience in security.

The next question was an open one about threats related to use of using agile practices in projects with security requirements. The most popular answers were:

problems with documentation and conforming to security standards (21%),
allowing client to prioritize features (17%),
using User Stories to express security requirements (17%),
using TDD (due to problems with defining appropriate tests) (17%),
slowing down development (17%),
pressure to release product early (13%),
difficulty to keep some parts of the system secret (13%).

Half of respondents mentioning slow down blamed for it security requirements and only some noticed that it’s not dependent on the methodology. Among other mentioned threats were uneven level of knowledge in the team, lot of refactoring and usage of external tools. Also, worth noting is the fact that 17% of the respondents didn’t come up with any problem – all of them had less than 3 years of experience in security.

Fourth question was complementary to the third one – it was about the benefits of using agile practices in projects with security requirements. The most popular answers where:

frequent deployments, pair programming (25%),
increased speed of development (25),
increasing security knowledge level in the team – better communication (21%),
User Stories and Backlog to document security requirements and raise awareness of security issues (21%),
fast security patches release (17%),
continuous integration (17%),
addressing changes in requirements (17%).

Among other answers were also TDD, DDD, preventing errors and rising team awareness. 17% of respondents didn’t see the difference in benefits for security and non-security projects and 4% didn’t see a possibility to use agile practices in projects with security requirements at all.

Respondents were also asked about their preferred methodology for security related projects. Results are presented on Fig. 7. The vast majority chose agile methodologies, but most did not provide any justification except for curiosity. In that group the most popular was Scrum, then Kanban and their modified versions. The rest didn’t mention any specific agile method. 17% of all respondents would use more traditional approach (e.g. V model or Waterfall) due to importance of documentation and planning for security. 75% of them had less than 3 years of experience in both agile and security. 8% would use hybrids of traditional and agile solutions. 4% of participants would match the methodology to project characteristic and the same amount answered that it makes no difference to the developer.

The results of the first survey showed that a lot of projects with security requirements are currently developed using agile methodologies, despite the fact that they are not perfectly suited for the task. Traditional methods created to fit this very purpose are rarely used anymore among the respondents of the survey. Also, most of the participants would like to use agile methodologies for future projects. This shows the need to develop new, more agile methods of secure software development. The threats that respondents noticed in agile practices were mostly related to using unmodified versions of those practices, not adjusted to security needs – a place for improvement in this area is clearly visible. Also, it’s important to notice that a lot of participants had little or no knowledge of security issues, despite their study and work in IT field. That calls for an effort to popularize the topic among both students and professionals.

5.2 Survey B

For each practice two closed questions were asked about its ease of use and if it’s improving security in the project. In total, 15 of the participants made their choices in those questions. Also, each practice was open to comments from the respondents. The results are presented in the Figs. 8 and 9.