Security in Continuous Delivery

Depending on the organization and the software product, the iterative and incremental software development have extended the practice of continuous

integration into continuous delivery. The merger of development and oper-

ations is called by the portmanteau DevOps. In continuous delivery models with a special emphasis on software security, the model is sometimes called DevSecOps, or some of its variants (cf. Mohan and Othmane (2016)).

Organizations apply the continuous delivery models and processes to speed up the software deployment, by creating a production pipeline with a high degree of automatization. This level of streamlining calls for good quality code and extensive and highly automatized testing processes, as described by Kim et al. (2016). For software security, this poses both new challenges and opportunities: when a service-type software is published in

the open Internet in a matter of hours, or minutes, the security testing and monitoring tools need to be constantly up to date and able to respond to changes. The changes may occur in the software or its configuration, or in the operating environment in the form of new security threats or even infrastructure changes (Mohan and Othmane (2016)).

The change does not happen only by introducing tools and automati- zation: it requires also change in the organization, bringing the developers and operations closer to each other, often over the subject of testing (Kim et al. (2016)). Also in regulated environments, such as security-critical ones reported by Mohan and Othmane (2016), or safety-critical by Laukkarinen et al. (2018), this results in an increase in effectiveness and flexibility and a decrease in response times. This fully fits the definition of the word “agile”, whether used as an adjective or noun.

Continuous delivery impacts security in the form of requirements for scanning tools, security monitoring, and security logging. The work man- agement tools will also need to be able to accommodate and appropriately prioritize the security-related tasks created from the operations and inserted into the development backlogs as discussed by Mohan and Othmane (2016). For example, Kanban-style work management should allow such flexibility, whereas a scaled agile model, such as SAFe with release plans, may face greater challenges in pushing these changes into production. Moyon et al. (2018) provide a direct example of how to modify SAFe to achieve compli- ance with ISO/IEC security standards. Proper prioritization of the security items is one of the most pressing issues in software security research and practice.

The security assurance engineering is also facing changes in a continuous delivery model. Security assurance may take new forms, such as archiv- ing entire virtualized environments and using them as security evidence (cf. Laukkarinen et al. (2018)). After an incident, they can be used as a source of security forensics. Ideally, technical security assurance consists of elements usable not only in security engineering but also by the software’s developers and operators.

Security Management in Software Development

In a standard-regulated security scheme, the security objectives are norma- tive and formalized. Objectives are translated into requirements and poli- cies, which in turn are implemented by security functionality and verified by security assurance.

Boehm and Turner (2003a) proposed the choice of software development method to take place on an axis between Agile and Plan-driven methods. He proceeds in presenting five dimensions for this selection. Presented roughly from the most quantifiable to the most qualitative, the dimensions are:

1. Size, the number of personnel;

2. Dynamism, or number of requirement changes per month;

3. Criticality, or amount and severity of loss due to impact of defects;

4. Skill of the personnel, as defined by Cockburn (2002) and further de- veloped by Boehm and Turner (2003a);

5. Culture, ranging from “chaos-thriving” to “order-thriving”.

The agile methods evolved to meet the shortcomings of the prescriptive methods, in conformance with the best practices and management values in software engineering. After two decades, the simplest and most flexible methodologies appear to have thrived: Scrum, XP and their hybrid forms still have a strong representation in the industry. A notable trend has been the emergence of various scaled agile frameworks, such as Large Scale Scrum (LeSS), Nexus and the Scaled Agile Framework (SAFe), providing manage- ment models and practices for several coordinated development teams, thus enabling the agile methods to be used in larger organizations.

The developments in agile methodologies have amended the juxtaposi- tions between agile and non-agile methods, described by Boehm and Turner (2003a): scaled methods relax the team size limits, and there are methods introducing a level of pre-planning into the iterative and incremental de- velopment process, while still claiming to retain agile principles. Examples of such methodologies would be Disciplined Agile Development (DAD) by Ambler and Lines (2012a), or the slightly older Crystal family by Cock- burn (2000). Neither of these has acquired significant reported use in the industry, but contain elements useful for producing more secure software through their focus on architecture and requirements management. Boehm and Turner (2003a) also presented the concept of “home grounds” for ag- ile methods, another concept that has been outdated by the methodological developments and at least partially later predicted by Boehm (2006) himself. At enterprises the use of scaled methods appears to be dominated by various “methodology providers”: a true competition of agile or lean man- agement ecosystems, complete with extensive training models and certifica- tion programs. In this competitive landscape, Scrum has fared best, despite being divided into factions of scrum.org4 and Scrum alliance5. As shown in Figure 3.1, among the most popular agile methods are only a few established methodologies. The methods are being morphed into various hybrid models and scaled up into more elaborate product management models.

4_{http://www.scrum.org} 5

Select Method

Inception Transition

Determine organizational capacities and risks

Determine security risks

Determine project

specific risks A Select method B

A Rate environmental, plan-driven and agile risks Establish project strategy integrating risk mitigation Choose method If divisible, encapsulate agile and plan-driven parts Monitor progress and risks, readjust

process

B

Figure 3.4: Decision-making in risk-driven development method selection (adapted from Boehm and Turner (2004))

Despite the near-absolute current dominance of the agile methods, not all projects may warrant using them. While agile methods dominate, there may still be organizations or situations where use of “non-agile” patterns may be justified to achieve the optimal target; markedly, these include projects with fixed schedules and budgets. In a critique to agile methods, Boehm and Turner (2003b) discussed the dimensions the selection process is based on. Boehm and Turner (2004) formalize this approach into a simple decision process, illustrated in Figure 3.4 and set into the context of risk management. In the figure, the risk evaluation process is used to give the necessary insight to the validity of the security objectives, and to help determine the appropriate security assurance. The decisions should also be based on the resources at disposal: skill, tools, workforce and time. Especially the amount of skill is a critical factor in security work; requirement elicitation, risk iden- tification and the mitigation techniques all require extensive knowledge in the security field. The significance of the individual is markedly emphasized in agile software development, coiling back to the significance of skill. A framework for formalizing skill levels in software development has been pre- sented in Cockburn (2006); from the software security perspective, the skill requirement stresses the importance of relevant security training.

In addition to the security processes, also the agility of a process may be a subject of evaluation. Schweigert et al. (2014) identified about 40 models claiming to be agile maturity models. They pointed out significant difficulties in defining the agile processes and metrics in a way that would be commensurable between the agile maturity models. The agile models deal with general organizational processes and are directly applicable to security engineering. To separate fads and buzzwords from solid engineering principles, Séguin et al. (2012) performed an analysis of agile principles. The bulk of them was found to be valid software engineering principles. These findings from both practical engineering and research traditions support the use of agile methods and principles for purposes beyond managing singular projects.

Security objectives are drawn from the environment and the protection target; security objectives are met by setting security policies; these form the concrete security requirements, elicited by a risk-driven process; the security

requirements are further developed into verifiable features and functionality. Security assurance largely ‘emerges’ from this process, but may also require formal reviews, security audits and few pieces of security documentation, most importantly a security architecture. The depth of security assurance depends on the objective, but should always exist to serve the purpose of increasing security and facilitating security management.

Lean methods can be used as a Software Process Improvement method far more flexible and effective than traditional maturity models, as shown by Poth et al. (2018). Heavily biased towards solving the technical and practical, rather than the managerial issues, it can also be an effective way to manage the realization of the security rationale, and production of the appropriate security assurance. According to lean principles, this involves abolishing hierarchical organization, directly managing the people and team dynamics, addressing the faced challenges immediately and focusing on qual- ity. Combined with diligent management of the process and project, based on direct feedback from developers and customers, the lean principles claim to enable the organization to always work on the most valuable item (see Poth et al. (2018) and Poppendieck and Poppendieck (2003)).

3.3

Summary

In software development, security is a collective term, and a means for achieving software reliability, confidentiality, integrity, availability, and com- pliance. Security engineering has direct convergence with those software engineering practices that traditionally have been used to improve software quality. The agile methods aim to the reduction of unessential work, and the improvement of quality. Security engineering, in addition to being a requirement in an increasing number of cases, heavily contributes to the latter. The main mutual contribution of combining the security engineering techniques with effective software development practices is specifically the increased rigor in requirement and risk engineering, and enhancements in the quality assurance techniques.

Excess security compliance requirements may entitle allocating resources towards administrative security. In software development, this is realized in the form of additional security assurance requirements. In an agile or lean process, additional verification-based requirements create potential bottle- necks that need to be addressed. In these cases, instead of being the driving force for e.g. better testing coverage, or more thorough code quality checks during security reviews, security processes may become a hindrance to pro- ductivity. Proper inclusion of security processes into all development stages removes these bottlenecks. Conversely, agile methods help in the valida- tion of security, as the iterative process with tight requirement management

practices has been designed to “build the right product” from the start, including security requirements.

Management of security engineering work in an agile software develop- ment project is a combination of various techniques. These are to be fitted into the iterative and incremental framework and rigorously applied accord- ing to the lean or agile principles. Arguably, any software project would benefit from applying even a light-weight security requirement elicitation process, identifying e.g. 10 security risks and implementing a management plan for those risks; practical programming guides, such as OWASP Top 10 security flaws should also be put to good use in the implementation phase. Also, one of the project’s aims should be the production of appropriate se- curity assurance: Optimally, assurance-producing mechanisms also double as forensic evidence after the occurrence of a security incident. To system- atize the approach to software security, a maturity model, such as SAMM or a light-weight version of the SSE-CMM, could be modified to fit to the organizations’ purposes, providing an ample target for future research.

Research Description

The research objective was to find practical solutions and challenges in pro- duction of secure software. For relevance, the chosen methodologies and the research results reflect the current best practices and state of the art. The steps to ensure both scientific and technical relevance were taken in the form of literature surveys, case study and an industry survey, following the frameworks described by Wohlin et al. (2012). Conceptual models and analytic frameworks were utilized to gain an understanding of the topic and to provide guidance in the empirical studies.

In this chapter, the research structure is presented by describing the individual research articles included in the research. The research methods, key contributions as well as possible limitations and openings for future research are presented for each article.