Models for secure software development

Ruparelia (2010, p. 8) writes that a model describes what to do and methodolo-gy describes what and how to do it. SSDL models can be categorized under three wide categories: linear, iterative and a combination model of the precious two categories. Linear model is sequential meaning that one phase leads to an-other phase. An iterative model sees development as a constant process, where all phases are repeated multiple times. A combination of linear and iterative endeavors to end the repletion of the iterative model at some point.

Baskerville (1993, p. 411) tells that the initial security methods concentrat-ed on checklists and simple risk analysis to support decision making. Those methods evolved a focus on mechanistic partitioning of intricacy in the coveted system. They entailed critical control checks which offered the barest acceptable protection for the comprehensive information system. Later the interest in de-velopment methods focused to abstract models. The key feature of this kind of an abstract model was to comprehend the information system’s diverse security requirements.

Ruparelia (2010, p. 8) adds that software development lifecycle (SDLC) model considers all the phases of software from the initiation; requirements engineering phase, all the way through to maintenance. McGraw (2006, p. 34) adds that a company can create its own secure development lifecycle by im-plementing security touchpoints to the existing software development lifecycle.

McGraw (2006, p. 35) dictates that software security’s main pillars are knowledge, software security touchpoints and risk management. He highlights the need for prescriptive, diagnostic and historical knowledge about software security, current research and best practices for a stable foundation of software security practices. If these pillars are applied gradually, in an evolutionary manner and equally the resulting software is cost-effective and secure.

Various secure software development models exist, and the most suitable models were chosen for further inspection during the literature review (annex 4). This forms the foundation for the comparative study, so the six models out of 41 that were chosen in co-operation with the commissioner are briefly repre-sented here.

McGraw (2006, 83-84) has developed a Touchpoints model which exam-ines an assortment of software security best practices which McGraw has

de-termined. He states that integration into existing software development is pos-sible and this forms one of the center pillars of software security. Touchpoints are organized into a liner model but can be applied to any existing model and done iteratively as presented in the FIGURE 16.

FIGURE 16 Touchpoints- model

McGraw (2017, p. 1) has also been a central influencer to the development of BSIMM model. BSIMM stands for the building security in maturity model and it is the result of multiyear study. Over 100 firms were included to compile the BSIMM version eight, which entails 113 real-world software security initiatives.

(McGraw et al., 2017, p. 5). McGraw et al. (2017, p. 8) write that BSIMM is di-vided into four domains which are formed from 12 main activities (FIGURE 17).

FIGURE 17 BSIMM- model

The next model focuses especially to the requirements engineering process.

SQUARE means secure quality requirements engineering (Gedam & Meshram, 2019, p. 3) and it was developed by Mead, Padmanabhan, Raveendran and Viswanathan (2008) as a part of CERT program in 2008. Therefore, it is a secure software development model, which focuses purely on integrating security into requirements process. It is based on coordination between stakeholders and requirements engineers and it contains nine process steps (FIGURE 18) (Gedam

& Meshram, 2019, pp. 1–3).

FIGURE 18 SQUARE- model

SQUARE considers all the software’s life-cycle development phases from the initial phases to the end-of-life. Thus, it is a security requirements engineering model and a model for SDLC improvements (Gedam & Meshram, 2019, p. 1).

Another maturity model besides BSIMM is a SAMM model. Shoemaker and Sigler (2014, p. 224) have described SAMM as a benchmark to evaluate the progress of its security assurance initiatives and create a scorecard. These score-cards provide a way to trace and demonstrate organization’s improvements where an iterative software assurance integration process into existing policies and procedures is evaluated. SAMM can also be used as a map to aid in build-ing or improvbuild-ing a security assurance initiative. SAMM has 12 security practic-es (TABLE 16) with three maturity levels and each level has a criterion that specifies the critical success factors to implement and assess to reach the desired level. Those levels have an assigned objective and it is a general statement of goals for achieving the desired level.

FIGURE 19 SAMM- model

SAFe is the scaled agile framework established by Dean Leffingwell and his collaborators. It combines agile and lean practices through four levels of organi-zation including team, program, value stream and portfolio. Every level con-tains its own activities and is tied together. (Alqudah & Razali, 2016, p. 830).

SAFe’s activities are a mix of Scrum, Lean, DevOps, Kanban and XP (FIGURE 20 SAFe- model). It supports especially large enterprises confronting difficulties

in Agile practice adopting by offering a structure that eases the transition from traditional framework to agile. (Alqudah & Razali, 2016, p. 835).

FIGURE 20 SAFe- model

Stage-Gate as it was originally called by its developer Cooper (1990) defined a framework which is applied to an existing development process. It aids the pro-cess and ensures that the new product proceeds without difficulty through idea phase to launch. It combines project management disciplines and those pro-cesses that are needed for new product realization. It is often implemented to aid in problems related to product performance, cost increases and time slip-page during the development and is thus, a tool for risk reduction. Each stage has a product development element which is often a set of activities. Each gate stands for a review point for the preceding stage and as a decision point based on the conclusions of the previous phase’s activities. (Broughton, Neailey &

Phillips 1999).

In his conference publication Thamhain (2000) presents a Stage-gate based Phase-gate model that proceeds step-by-step through the five process phases (FIGURE 21). Each phase is outlined with principle scope, objectives, activities, deliverables and functional responsibilities. After this each phase ends up in a gate which defines the exact criteria and mandatory outcomes for success in the next phase and beyond. When accomplished and designed correctly gates vali-date with multifunctional reviews all success conditions.

FIGURE 21 Phase-Gate process

3 RESEARCH METHODOLOGY

This chapter describes the combination of research problems, methods, and the gathering of empirical research material. First subchapter describes the aim and scope of the research, what is being examined, what are the research questions and material to which the research is founded on. Second subchapter focuses on methodological choices, how the material was gathered, analyzed, and refined.