The practice of secure software development in ... - Wiley Online Library

SECURITY AND COMMUNICATION NETWORKS Security Comm. Networks (2016) Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/sec.1700

RESEARCH ARTICLE

The practice of secure software development in SDLC: an investigation through existing model and a case study Nor Shahriza Abdul Karim1, Arwa Albuolayan1, Tanzila Saba1* and Amjad Rehman2 1 2

College of Computer and Information Sciences, Prince Sultan University, Riyadh, 11586, Saudi Arabia College of Computer and Information Systems, Al-Yamamah University, Riyadh, 11512, Saudi Arabia

ABSTRACT Software security is an essential requirement for software systems. However, recent investigation indicates that many software development methodologies do not explicitly include methods for incorporating information security into the software development life cycles (SDLC). This research investigates, using case study, the methodologies being used in software development in Saudi Arabia and describes a model for integrating security into the SDLC. The aim is to identify the appropriate means of introducing security measures much earlier in the SDLC. This model is designed to be an extension to the existing SDLC. For achieving the research objectives and answering the research questions, the research followed a case study research design in an information-based organization. The research identified various important elements as security standards, policies, processes being practiced, and tools used within SDLC projects. In this regard, recommendations and verification were gathered to elicit the actual activities that are appropriate to be conducted at each phase of SDLC. The non-functional security requirements were also found, to the use of FORTIFY and HP ALM for source code review and web application testing. Copyright © 2016 John Wiley & Sons, Ltd. KEYWORDS secure software development; secure engineering; software security *Correspondence Tanzila Saba, College of Computer and Information Sciences, Prince Sultan University Riyadh 11586, Saudi Arabia. E-mail: [email protected]; [email protected]

1. INTRODUCTION An effective software application is one that is written to achieve its intended purpose and to ensure that it provides a pleasant user experience in a completely safe environment. Oftentimes, it is highly challenging to write applications that meet all the success criteria defined [1,2]. The crucial question is how could, a software will be resilient to security flaws? Engineers are often less aware of security approaches leading to functional software, but highly vulnerable to security threats at the end of the project. Owing to various flaws in the development approach, security issues are likely to occur when emphasis is placed on the functional role of the software, while many security concerns are ignored during the process. Many engineers attempt to improve security aspects by revisiting the work after the development process has been completed [3,4]. Unsurprisingly, many software products undergoing live testing are vulnerable to threats and fail to provide a

Copyright © 2016 John Wiley & Sons, Ltd.

safe environment to users and clients. This is probably due to the lack of systematic measures such as reviews, procedures, or frameworks; these measures can help developers and project managers (PMs) ensure that security processes are consistently followed throughout the development process, according to a set of rules or procedures [5]. Therefore, an approach or framework that can be utilized from the beginning of a project and consistently followed throughout is required for building security measures [3,6]. To effectively handle the security issues that exist in many development projects, it is considered necessary to incorporate security-minded thinking throughout the development process. This reduces the risk of missing important security requirements or making critical mistakes in software design. Using this strategy, problems can be discovered much earlier, instead of at the end when they are very difficult and costly to fix [7]. Vulnerabilities associated with the system may be reduced to a minimum level during the SDLC. It may not be possible to eliminate

The practice of secure software development in SDLC

vulnerability, but it might be reduced to a minimum level if security is treated as an ongoing process [8,9]. Therefore, this research looks at the software development process as a whole, from the perspective of each development phase (SDLC), and seeks to determine important secure measures that must be employed at each phase to ensure highly secure products.

2. BACKGROUND Mouratidis, Giorgini, and Manson [10] have reported that software engineers consider security as a non-functional requirement. However, unlike other non-functional requirements, such as reliability and performance, security has not been fully integrated within the development lifecycle. In many cases, it is only considered after the design of the system is completed or when a significant issue must be addressed. Currently, no software development processes or practices exist that consistently produce secure software [8,11–13]. Therefore, it is recommended that developers adopt practices that can reduce software defects and, as a result, minimize any potential risk because of the lack of security attention during the process. Software security is one of the fastest growing research areas [11,14–16]. This area investigates software designing rules that could be utilized in the building of secure frameworks, or to improve the security of programming frameworks, and to take care of issues that obstruct the advancement of secure software [17]. Evoking security prerequisites is a basic stride in embracing a safe programming improvement handle. The two principle purposes behind troubles around there are fragmented prerequisites and miscommunication between programming engineers. Along these lines, it is important to evoke precise suspicions amid the necessities stage; subsequently, further research is expected to focus this area. Additionally, existing test methodologies, for example, unit testing or incorporation testing work for testing usefulness. These must be stretched out keeping in mind the end goal to suit express security testing [14,18]. All software faces threats from various potential malicious adversaries that are becoming more numerous every day. Threatened software includes internet-aware applications running on personal computers, complex telecommunications, power systems accessible over the internet, and commodity software with copy protection mechanisms [19,20]. These threats, and many others, can impose a significant challenge to software engineers, who must design security measures as part of their risk management activities; in addition, they are expected to design appropriate security requirements and policies. This challenge stems from the degree of subjectivity in how security is perceived, and is subject to different levels of concern. Moreover, many applications have been developed without considering security services such as confidentiality, integrity, access control, and non-repudiation [21]. Security is necessary to provide integrity, authentication, Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec

N. S. A. Karim et al.

and availability. Secure software can function correctly under malicious attacks. In addition, building secure software by incorporating security best practices will leverage good software engineering practices [22]. Because security holes in software are common, and the threats are increasing, it is important to consider security early in the software development life cycle and apply security principles as a standard component of that lifecycle [23,24]. Research gaps can be found in many areas in software security [15]. Agile methods have received criticism because of the unavailability of security in their processes. In addition, detailed information about the usage of secure software is rarely published. One important area, as noted by Ahmad et al., [8], Arbain et al., [25], and Devanbu and Stubblebine [19] in more than a decade ago, is that focused on the non-functional requirements of software security, are not well defined in software security research. The area place emphasizes on effective design and the use of policies and a framework for security requirements, to sufficiently address software security concerns in various software development projects. Therefore, this research shall explore security practices and concerns among engineers in various software development projects within Saudi Arabia by focusing on each phase of the software development lifecycle. The result is expected to enhance software security practices and produce software with fewer defects and vulnerabilities, through common understanding of standards, policies, procedures, and a framework. 2.1. Secure software development life cycles and related research Works, such as McGraw [24] and Wongthongtham et al., [26], characterized what should be included as part of the security requirements, and others such as Islam and Islam and Falcarin [27], Russell, Jones, and Rastogi [7], and Pohl and Hof [15], stressed on technical issues and methodology. Developing high-quality software is a labor-intensive, complex task. It involves additional security-dedicated activities that are usually omitted in traditional SDLC [18]. Because most developers are not trained in software security, Daud [28] also stressed the importance of security requirements at each phase of the software life cycle in iterative development. The proposed model suggests that security engineers should elicit security requirements using different methods. Once these requirements are refined, the design phase can begin. Security vulnerabilities are identified, documented, and forwarded to the development team. Developers will consider all vulnerabilities and design their mitigation plan during the design phase. The testing team should then receive the developed software along with the documentation, in order to find design and development bugs. At the end of the process, the software is ready for deployment. Bokhari and Siddiqui [29] proposed a tool for secure software requirement management. The tool, known as


Tool for Secure Software Requirements, is designed to manage risk analysis, system requirements, system and project security, user and group restrictions, encrypted databases, and traceability. The Tool for Secure Software Requirements has four components: Planner, Modeler, Prover, and Documenter. PLANNER module incorporates hazard investigation and errand analysis, which will be useful in analyzing the software security. The MODELER underpins framework demonstrating, engineering, and confirmation. The PROVER gives astute administration hypothesis, proficient thinking, evidence support, and theorem demonstrating for check of scientific models. The Documenter supports power indexing, structural views, technical document editing, and provides an interface to external tools. It also manages a central repository database, which uses hill cipher encryption and decryption security techniques to provide database security. McGraw [24] stressed that security should be explicitly defined at the requirements level. Security requirements must cover both functional security and emergent security features. Defining abuse cases that describe the system’s behavior under attack is a good strategy to cover the emergent security space. This should also require explicit analysis of what should be protected, who to protect against, and for how long [26]. Software engineers must document all their assumptions and identify possible attacks. Moreover, risk analysis must be performed to discover and rank risks so that mitigation control can be initiated. External review of the design is often necessary [30]. As for the code, we should focus on implementation flaws, especially those that static analysis tools can discover. Code review is a necessary practice for achieving secure software but is only part of the solution. Security testing should cover two strategies: (i) testing security functionality with functional testing techniques; and (ii) risk-based security testing based on attack patterns and threat models [26]. A security test plan that can be traced back to requirements, and that uses both strategies, can be considered a good testing plan. Penetration testing is useful as well, if it considers the software architecture. In another paper, McGraw [31] established a compilation of 10 best practices for secure software development that reflect the experience and expertise of several stakeholders of the SDLC. These stakeholders include software engineers, auditors, operational personnel, and management. The 10 best practices suggested by McGraw are as follows: (i) Protect the Brand Your Customers Trust; (ii) Know Your Business and Support it with Secure Solutions; (iii) Understand the Technology of the Software (iv) Ensure Compliance to Governance, Regulations, and Privacy; (v) Know the Basic Tenets of Software Security; (vi) Ensure the Protection of Sensitive Information; (vii) Design Software with Secure Features; (viii) Develop Software with Secure Features; (ix) Deploy Software with Secure Features; and (x) Educate Yourself and Others on How to Build Secure Software. McGraw [31] concluded that implanting these practices will ensure the building of secure, hack resilient, and compliant software.


Islam and Falcarin [27] stated that creating secure software requires mitigating risks to achieve business goals, and that security depends on the context in which software is deployed. Actually, properties & metrics to measure software security goals are not well defined in advance rather authors proposed a strategy to identify security requirements via asset based risk management process. However, authors claim that measure software security could be measured through their proposed approach [32]. Russell, Jones, and Rastogi [7] stressed the importance of testing and highlighted its role in verifying that the system design and code can resist attack. A security test plan is essential to producing secure software. It should validate that software meets the security requirements, ensure that countermeasures are implemented, and verify that code is developed using coding standards and best practices. In addition, serious attempts to penetrate and break software security and a scan for common vulnerabilities should be included. McGraw [33] found that software practitioners are becoming aware of software security issues, and that additional work is necessary in this area. Pohl and Hof [15] discussed the increased use of agile software development methods and the current attack landscape. Hence, developing secure software should be the main concern in all software development projects. 2.2. Preliminary research model The reviews indicate that both academics and industry researchers have made only limited efforts to treat this topic systematically. However, many professionals acknowledge the importance of having such requirements for S-SDLC. This review aims to provide an understanding of a framework that can help developers by exploring software security best practices in the literature. Thus, contributions from the disciplines of information security, requirements engineering, organizational behavior, and software application engineering are explored to provide an accurate picture of the complexity that security poses [34]. As shown in Figure 1, the preliminary research model was developed from the suggested work of Davis [11], Khan and Zulkernine [23], and Daud [28]. Instead of focusing on the “what is,” the framework suggests the necessary actions as a set of guidelines for every phase in the SDLC, in a sequence flow that is easy followed by developers. The framework could be adopted by organizations and is based on adding security best practices to all phases of software development. It can also be used in conjunction with any software development process.

3. PROPOSED RESEARCH METHODOLOGY A literature review was conducted to investigate the work of authors who either conducted research or provided expert views on secure SDLC. The existing framework was used as a preliminary framework for further investigation Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec



in the case study. Case studies are used for exploratory investigations that attempt to understand and explain a phenomenon. They are generally observational or descriptive in nature and well-suited to “how” and “why” questions. They can also be used to validate research results. To address the validity of the proposed model, an expert review was conducted. It is the primary evaluation strategy used in summative assessments (How does the data help answer the research questions?). Experts use instruments or guides to provide their critiques [35]. Additional information is provided in Chapter 6.

3.1. Case study

a rich understanding of the frameworks and the processes being adopted. Another qualitative survey approach was chosen for this study. Fink [38] identifies several cases for which a qualitative survey design is appropriate. Therefore, the literature review was used to guide the selection of relevant theory from security best practices for software development. And then, to validate the proposed model, a structured and unstructured questionnaire was conducted. Because this research is qualitative, a small sample of responses is considered adequate. The challenge was reaching a representative sample, in order to ensure a valid response rate. 3.2. Unit of analysis

This research method is designed to investigate the practices and perceptions described in the cases, as they relate to the importance of, and appropriate requirements at, each SDLC phase. This enables the research to produce a model that will help software engineers to adopt a secure software development life cycle and provide PMs with software security guidelines that can be used as a project management tool. The overall design of the study followed the qualitative paradigm. This approach was chosen because qualitative research aims at developing a multifaceted understanding of complex phenomena in their natural context [36]. In this research, primary data sources are used. A case study was conducted by interviewing main members in every team responsible for the achievement of a particular phase in the SDLC. Besides interviews, direct observation and document analysis were viable data collection techniques for the purposes of this study [37]. The strategy was chosen for the investigation of software development projects in Saudi Arabia, because it is useful for gaining

Software engineers and PMs play an important role in incorporating security-minded thinking throughout the development process. Other factors can also leverage on software security, including security standards, policies, followed processes, and the tools and skills of the engineers. The conceptual framework (Figure 2) explains the territory investigated by the research. 3.3. Data collection Interviews were conducted in order to understand how software security is being considered in the context of the case study. Data was collected by interviewing main members in every team responsible for the achievement of a particular phase in the SDLC. Interviewee profiles are shown in Table I. In addition to interviews, relevant documents were analyzed to find evidence of any security policies and guidelines, in order to gain more understanding of the current

Figure 1. Preliminary research model. SDLC, software development life cycles. Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec


situation and practices. As a result, three documents were analyzed: (1) Project Planning Procedure (2) Case Analysis Document (CAD) (3) Business Requirements Document


3.5.3. Structured and unstructured questionnaires Online and hardcopy surveys were used to interview more than fifteen (15) expert informants; their roles included: • • • • •

Project manager Security professional Business analyst Developers Software architect

Moreover, a conceptual model from the literature was also developed, and validated by field experts. This was achieved through structured and unstructured survey research design. Responses were collected from 15 professionals working in software development in three industries: Finance, Government, and Information Technology and Services.

The Microsoft spreadsheet tool is again used for data analysis. Content analysis and statistical analysis was conducted for descriptive purposes.

3.4. Research instruments

4. RESULTS AND DISCUSSION

The research instruments used in this study are described in the succeeding discussions.

4.1. Analysis of in-depth interviews

3.5. Data analysis 3.5.1. Interviews The content analysis technique, based on the work of Miles and Huberman [39], was used to analyze interview results. The coding used is a purposeful coding directed by research questions. Two iterations were completed to analyze interviews responses. The first iteration involved transcribing everything the interviewee communicated using their own words. The main points were categorized in the second iteration; anything not directly related to the question was removed. Finally, the researcher’s notes were added; these contained viewpoints about the software security practices in the organization being studied. The Microsoft Excel (part of MS Office) was used for data analysis. The text was categorized according a coding scheme and the interviewee’s responses. 3.5.2. Document analysis Document analysis was conducted to uncover information that would not be included in the interview. Therefore, analysis of relevant documents was performed for evidence of any security policies and practices as exhibited in Figure 3.

The interviews seek to answer the research objective by asking the following questions: (1) Are there any formal policies in place? (2) What approaches or processes are being practiced? (3) What tools or techniques are being used within the SDLC in the case study project? (4) What are the requirements for the secure software development process? The interview results were transcribed and analyzed using content analysis. The profiles of the respondents indicate that all have between 2–8 years of experience. P1 is a service change manager and acting business analysis manager. She was certified by HP for attending the Edge Program, which trains professionals to manage the entire SDLC. Requirements gathering and elicitation is part of this program. P2 is a project coordinator. She received PMP and ITIL training and is currently about to finish her MBA. P3 has three years’ experience as a developer. P4 is certified as an international software tester and has received training in ITIL, SQL, and Java. Analysis of the results led the researcher to establish the following discussion categories for the domain, similar to the proposed framework illustrated in Figure 4: • • • •

Figure 2. Conceptual framework.

Project management Requirements analysis Development Testing

These categories emerged from discussions in which the respondents were asked to describe the flow of SDLC activities in their organization. First, it starts with change management. The process starts with requirement elicitation. In this process, teams may have a one-to-one meeting, a brain storming session, or a question and answer (question and answer by email) in order to gather the Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec



Table I. Interviewee profiles. Respondent

Work experience (years) Job position

Gender Age group

P1

P2

P3

P4

7 Service change manager and acting business analysis manager Female 30–35

2 Project coordinator

3 Developer

8 Service validation-tester

Female 20–25

Female 30–35

Female 35–40

Figure 3. Part of Project Planning Procedure Document.

requirements. Therefore, there are different techniques to obtain stakeholders requirements. Once the teams obtained the requirements, the analysis phase began by using business analysis. The process involved analyzing the requirements and then defining solutions to these requirements. Once business analysis finalizes these requirements, the teams start a process known as writing a CAD. Within the CAD document, all requirements are provided, including the acceptance criteria, testing, and description of each step of this phase. And then, according to the respondents“ ,… we start with a go-through process and there are many ways to go through …. So, if it’s small we just send an email otherwise we hold a walk-through session. Then we initiate the approval process. First, an internal approval is obtained, then approvals are obtained from the client and the requester. The requester could be any team, including the Security Team. Once approved we go to the next phase of the SDLC.”

Figure 4. Part of Case Analysis Document. Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec

Next, the PM role comes into play, in order to plan for the approved change. In this case, the PM assigns the resources and handles the budget. The remaining steps cover typical PM tasks: planning, defining the scope, and setting the schedule. And then, upon receiving the finalized and approved CAD, developers start the coding process. They use Fortify, an application that allows them to review and comment on the written code. The developers consider these as suggestions, so they may or may not change the code accordingly. In addition, manual reviews are conducted, in which one member of the team reviews the code of another member. Once completed, the process then goes to the Quality Assurance (QA) team to test the new release using the HP ALM tool. As explained by one participant: “Once we receive the document, which is the CAD, from the business team, we analyze the problem and create test cases that cover positive and negative scenarios. And then after completing the implementation by the developers we execute our test cases.”

Quality Assurance performs functional testing and performance testing; each has its own environment. When the team finds an issue, they document it and notify the development team. After the issue is corrected, the QA repeats the same test case to ensure that the problem is solved. This is mainly for functional testing. In performance testing, which is conducted for each release, QA compares the test result with the previous test results. Again, QA performs the integration testing with the



organizational partners affected by the release. Once this cycle is completed, the release is certified. Finally, the team performs the user acceptance testing with the client before they can confirm that the release is accepted and deployed. The organization under study uses Microsoft SharePoint to store its documentation. In addition, the HP Web Inspect application is used to perform automated dynamic testing that mimics real-world hacking techniques and attacks; In addition, the HP Fortify Static Code Analyzer is used to automate static application security testing. This research also investigates the skill level required for practicing effective security in software development. Responses to these questions indicate that many developers lack understanding about what should and should not be considered as security and security-related requirements. According to a PM: “In terms of defining security requirements the organization lacks security understanding about what should be considered as security-related and what is not. What should be encrypted and what should not as it is currently left for personal judgment.”

From another angle, the security team in this organization also lacks understanding about the developed system. Therefore, when starting work on a new release, a significant amount of effort is necessary to help them understand the case at hand. Nonetheless, the engagement of the security team is almost not apparent until the later stages of development. Although this organization is considered a mature one, with all of its processes and procedures defined and documented, evidence from the respondents indicates that they are generally unaware of any clear, well-defined security policies. In addition, the processes being practiced do not

incorporate security best practices. A tool is utilized in the development project that performs a static code review (Fortify). Table II provides a summary of the findings in the areas of security tools and techniques. 4.2. Analysis of documents In this section, three relevant documents were further investigated for security-minded considerations and tasks: (1) Project Planning Procedure Document (2) Case Analysis Document (3) Business Requirements Document

4.2.1. Project planning procedure document This document is produced and maintained by PMs. It contains planning activities to be followed by managers when planning any new project. The project risks section shows that PMs manage all project risks. It also shows in the work breakdown structure that project management includes activities for security management as well. The Information Security Manager is one of the target readers, along with other software engineering departments. Captures of the mentioned document are in the succeeding discussions (Figure 3). 4.2.2. Case Analysis Document The business analyst produces this document for each project, whether for a new release or a patch. In the analyzed CAD, the responsible, accountable, consented, informed (RACI) model shows that the Information Security Manager is informed of the content (Figure 4). It also includes an impact analysis section, which documents

Table II. Summary of interview responses.

Security policies Security process Tools and techniques

P1

P2

P3

P4

Requirements

Project management

Development

Testing

“There is no formal policy.” NA NA

“There is no formal policy.”

“There are none.”

“There is no formal policy.” NA NA NA “The security testing is part “We use Fortify to review “We use HP ALM for the of the functional test. Things and comment to the written defect model and test like money laundering, data code. We consider these as case model. Unified leakage are flagged at this suggestions so we may or functional test tool.” stage. The application we may not change the code use is Fortify. This test is accordingly.” performed by the Quality Assurance team. In case the issue that was discovered cannot be fixed during the same project, it can be handled even separately in a new release dedicated for security issues.”

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec



the impact of implementing the solution requirements listed for each affected component. However, no impact analysis is conducted to support application security. 4.2.3. Business requirements document This document contains the details for business requirements. The non-functional requirements section contains a description for message digital signing, which is a security feature of the software (Figure 5). The RACI model shows that the Information Security Manager is consulted. As a result, the document analysis revealed that this organization has documented their security activities within its SDLC. In addition, responsibilities are defined among the different stakeholders. 4.3. Findings from structured and unstructured questionnaire A structured and unstructured questionnaire was administered to professionals who play an active role in software development in their organizations. The purpose was to further verify and investigate the framework suggested earlier. Fifteen professionals participated in structured and unstructured questionnaires, which were administered based on the questions. Based on the preliminary model, the questionnaires were also designed to verify if the

Figure 5. Part of Business Requirements Document.

perspective of the professionals was in line with the suggested preliminary framework. The following sections provide the report based on the analysis of the responses, according to security measures or activities that are specified at each phase of the SDLC. 4.3.1. Requirement phase In the requirements phase, respondents were asked to rate their answers based on a few questions. The purpose is to verify if the suggested activities can enhance software security at the requirements phase: • Elicit security requirements from all stakeholders [3]. Figure 6 indicates that the activity of eliciting security requirements from the majority of stakeholders is highly important at the requirement stage. Therefore, this confirms the need to gather all security requirements at the early stage in the SDLC, as suggested in the framework. • Defining applicable regulations [40]. Figure 7 also indicates that defining applicable regulations is an important measure to be taken at the requirement level. To ensure that security is considered early in the development process, experts were also asked how their organizations’ development processes could be improved at the requirements phase. Based the analysis of the contents, many responded as follows: • “More external overviews are needed for security. Sometimes we become too insular and subjective when considering security requirements.” • “Security starts with the people involved; the software development team should be aware of security requirements. Secondly, SDLC as a person should take into account the security policies defined by the development.”

Figure 6. Survey response security requirements. Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec



Therefore, the respondents expressed the opinion that awareness of security requirements and policies, and the presence of external reviews, are highly necessary and important. This also confirms the importance of the framework’s suggestion to define applicable regulations and elicit security requirements at the early stage of development.

developers to develop defensible applications; and (iv) conduct source code assessments. The responses are discussed as follows:

4.3.2. Design phase When the professionals were asked how they could improve their organizations’ processes at the design phase in order to ensure security, no one answered. However, the three key activities suggested in the framework were rated as highly important. These activities are: maintain a list of recommended software frameworks, explicitly apply security principles to design, and provide external reviews of the design. The findings are reported in the figures as follows:

4.4. Proposed model validation

• Maintain a frameworks;

list

of

recommended

software

Figure 8 indicates that maintaining a list of recommended software frameworks is important for the design phase. • Explicitly apply security principles to design [41]; Figure 9 also indicates the need to explicitly apply security principles to design. • External review of the design [24]. Figure 10 shows that an external review of the system design is highly important. Therefore, this confirms the three key activities suggested for the design phase to ensure an S-SDLC.

• Follow a secure coding checklist [42] (See Figure 11);

The opinions provided by the survey respondents exhibit a conformity to the preliminary model, in addition to two activities that were suggested and added to Figure 12. The proposed model is further validated and defined in the following section. 4.4.1. Validation through expert review The proposed model has been further validated in this section, through an expert review of the revised version. The purpose is to obtain formal expert opinions on the viability of the proposed model, to enhance software security based on the experts’ guidance. The proposed model was presented to three software engineers. They were then asked to fill out the evaluation forms. The feedback was provided through discussion and brainstorming sessions. The first question sought their opinion about whether this model could enhance software security. The second question asked how adopting this model could affect software security. Engineers are generally in full agreement that using this proposed model can enhance software security. However, answers to the second question varied: 4.5. Define applicable regulations

4.3.3. Implementation phase In this section, respondents were asked to rate the list of suggested activities, in terms of whether they can enhance software security at this phase. These activities were the following: (i) follow a secure coding checklist; (ii) use a programming language that is more immune; (iii) train

According to the respondents, there were incidents where failure to define applicable regulations had caused losses to the company, owing to the costs incurred and additional time and effort needed to re-develop a release. This is due to the need to add new features to the system based on a

Figure 7. Survey response applicable regulations. Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec


Figure 8. Survey response of software need.

Figure 9. Survey responses of security principles design.

Figure 10. Survey response of external review. Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec




Figure 11. Survey response coding checklist.

Figure 12. Proposed model.

client request made during a later phase of development. In one case, this occurred immediately before the go-live date; the team was alerted to the regulation, which they were not aware of earlier. This resulted in the cancellation of the release. A similar case occurred because the development process did not consider applicable regulations in the early phases of projects. Hence, a developed portal showed a client’s sensitive information; in this case, such information needed to be masked.

conducting security tests; a serious design flaw was discovered later. By exploiting this flaw, an attacker could leverage their access permission from the user to obtain administrative access to the system. The elevated access could enable the attacker to perform any task an administrator could perform.

4.6. Elicit security requirements from all stakeholders, apply security design principles, and conduct penetration testing

The discussion exposed an incident in which an organization’s Marketing Department stated that an application, which was ready to be deployed, could not go live without a few changes. Some of the error messages were against the organization’s approach for promoting its business. As a result, these error messages were changed

According to the respondents, there was an incident in which a web application (portal) was released without

4.7. Development and enforcement of security policy




to satisfy this rule. However, the impact could have caused a significant loss to the organization, owing to a re-development process that could have been avoided if there were security policies in place with proper enforcement. By considering security problems that could have been avoided if the recommended measures were taken much earlier in each phase of the development process, these expert reviews provide additional evidence to support the importance of the new proposed framework.

5. CONCLUSION The research has identified various important elements as security policies, processes being practiced, and tools used within the SDLC through the review of the literature and the case study investigated. The evidence gathered from the field indicates the lack of clear policy and guidelines that are in place at the project management level within each phase of the SDLC. In this regard, recommendations and verification were gathered to elicit the actual activities that are appropriate for inclusion at each phase of the SDLC. To achieve the main research objective, a software security framework is proposed and validated in order to incorporate best security practices into the SDLC. By applying the proposed model, the SDLC can be governed and security can be incorporated in different phases; hence, various security issues and problems can be overcome with much earlier. This research contributes significantly to knowledge and practices by proposing a model that allows researchers to continue its development and verification in different settings. Moreover, managers and developers can use the model to engineer software that is more secure and well-prepared early in the development process. Many incidents of flaws and breaches of security measures and standards occur toward the end of development processes. As a result, these incidents become too costly for the company and the stakeholders to bear. Therefore, this model can promote the idea that security measures can be established much earlier in the development process and used for all software engineering projects, regardless of whether a waterfall or agile approach is used. In addition, for a start, this model was developed primarily by analyzing theory-based frameworks, and then fortifying them through research conducted with an established set of methodologies in a real research setting. Therefore, the model can contribute significantly to research in the software engineering field, where additional research can help enhance the framework. This model aims to incorporate security best practices into different SDLC phases along with project management. Moreover, future research can also aim at expanding the proposed model and suggest the use of additional tools. Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd. DOI: 10.1002/sec

REFERENCES 1. Rehman A, Saba T. Evaluation of artificial intelligent techniques to secure information in enterprises. Artificial Intelligence Review 2014; 42(4):1029–1044. doi:10.1007/s10462-012-9372-9. 2. Sodiya AS, Onashoga SA, Ajayi OB. Towards building secure software systems. In Issues in Informing Science and Information Technology, Vol. 3. 2006. 3. Gilliam DP, Wolfe TL, Sherif JS, Bishop M. Software security checklist for the software life cycle. In Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on. 2003, June; 243–248 IEEE. 4. Neamah K, Mohamad D, Saba T, Rehman A. Discriminative features mining for offline handwritten signature verification. 3D Research 2014; 5(3). doi:10.1007/s13319-013-0002-3. 5. Nunes FJB, Belchior AD, Albuquerque AB. Security engineering approach to support software security. In SERVICES. 2010, July; 48–55. 6. Mundher M, Muhamad D, Rehman A, Saba T, Kausar F. Digital watermarking for images security using discrete slantlet transform. Applied Mathematics and Information Sciences 2014; 8(6):2823–2830 doi: 10.12785/amis/080618. 7. Jones RL, Rastogi A. Secure coding: building security into the software development life cycle. Information Systems Security 2004; 13(5):29–39. 8. Ahmad Z, Asif M, Shahid M, Rauf A. Implementation of secure software design and their impact on application. International Journal of Computer Applications 2015; 120(10). 9. Rehman A, Alqahtani S, Altameem A, Saba T. Virtual machine security challenges: case studies. International Journal of Machine Learning and Cybernetics 2014; 5(5):729–742. doi:10.1007/s13042-013-0166-4. 10. Mouratidis H, Giorgini P, Manson G. When security meets software engineering: a case of modelling secure information systems. Information Systems 2005; 30(8):609–629. 11. Davis N. Secure Software Development Life Cycle Processes. Carnegie-Mellon Univ. Pittsburgh, PA Software Engineering Inst., 2013. 12. Joudaki S, Mohamad D, Saba T, Rehman A, Al-Rodhaan M, Al-Dhelaan A. Vision-based sign language classification: a directional review. IETE Technical Review 2014; 31(5):383–391. doi:10.1080/ 02564602.2014.961576. 13. Futcher L, von Solms R. SecSDM: a model for integrating security into the software development life


14. 15.

16.

17.

18.

19.

20.

21.

22.

23.

24. 25.

26.

cycle. In Fifth World Conference on Information Security Education. Springer: US, 2007, January; 41–48. Offutt, Jeff. Quality attributes of web software applications. IEEE software19.2 (2002): 25–32. Pohl, C., & Hof, H. J. (2015). Secure scrum: development of secure software with scrum. arXiv preprint arXiv:1507.02992. Saba T, Rehman A, Altameem A, Uddin M. Annotated comparisons of proposed preprocessing techniques for script recognition. Neural Computing and Applications 2014; 25(6):1337–1347. doi:10.1007/s00521014-1618-9. Shreyas, Doshi. "Software engineering for security: towards architecting secure software." Term paper, University of California, Irvine (2002). Essafi M, Ghezala HB. Meta-modeling based secure software development processes. International Journal of Secure Software Engineering (IJSSE) 2014; 5(3):56–74. Devanbu PT, Stubblebine S. Software engineering for security: a roadmap. In Proceedings of the Conference on the Future of Software Engineering. ACM, 2000, May; 227–239. Firdaus A, Ghani I, Jeong SR. Secure feature driven development (SFDD) model for secure software development. Procedia-Social and Behavioral Sciences 2014; 129:546–553. Shin ME, Gomaa H. Software requirements and architecture modeling for evolving non-secure applications into secure applications. Science of Computer Programming 2007; 66(1):60–70. Nuseibeh, B., & Easterbrook, S. (2000). Requirements engineering: a roadmap on the future of software engineering, 1, 35–46. Retrieved from http://dl.acm. org/citation.cfm?id=33652 Khan, M. U. A., & Zulkernine, M. (2009). Activity and artifact views of a secure software development process. In Proceedings - 12th IEEE International Conference on Computational Science and Engineering, CSE 2009 (Vol. 3, pp. 399–404). McGraw G. Software security. Security & Privacy, IEEE 2004; 2(2):80–83. Arbain AF, Ghani I, Jeong SR. A systematic literature review on secure software development using feature driven development (FDD) agile model. Journal of Internet Computing and services 2014; 15(1):13–27. Wongthongtham P, Chang E, Dillon T, Sommerville I. Development of a software engineering ontology for multisite software development. IEEE Transactions on Knowledge and Data Engineering 2009; 21(8):1205–1217.


27. Islam S, Falcarin P. Measuring security requirements for software security. In Cybernetic Intelligent Systems (CIS), 2011 IEEE 10th International Conference on. 2011, September; 70–75. 28. Daud MI. Secure software development model: a guide for secure software life cycle. In Proceedings of the International MultiConference of Engineers and Computer Scientists, Vol. 1. 2010, March; 17–19. 29. Bokhari MU, Siddiqui ST. TSSR: a proposed tool for secure software requirement management. International Journal of Information Technology and Computer Science (IJITCS) 2014; 7(1):1. 30. Nodehi A, Sulong G, Al-Rodhaan M, Al-Dhelaan A, Rehman A, Saba T. Intelligent fuzzy approach for fast fractal image compression. EURASIP Journal on Advances in Signal Processing 2014. doi:10.1186/ 1687-6180-2014-112. 31. McGraw, Gary. "The ten best practices for secure software development." 2009. Web. 12 Feb. 2015. 32. Islam S, Mouratidis H, Jürjens J. A framework to support alignment of secure software engineering with legal regulations. Software and Systems Modeling 2011; 10(3):369–394. 33. McGraw, G. (2003). Building secure software: a difficult but critical step in protecting your business. Cigital, White Paper, Available from: http://www. cigital. com/whitepapers. 34. Crook, R., Ince, D., Lin, L., & Nuseibeh, B. (2002). Security requirements engineering: when antirequirements hit the fan. In Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on (pp. 203–205). IEEE. 35. Simon MK. Dissertation and Scholarly Research: Recipes for Success (2011 edn). Dissertation Success. LLC: Seattle. WA, 2011. 36. Robson, "Real world research: a resource for users of social research methods 2011. 37. Hox J, Boeije H. Data collection. Primary vs. Secondary. Encyclopedia of Social Measurement 2005; 1:593–599. doi:10.1016/B0-12-369398-5/00041-4. 38. Fink. Analysis of qualitative surveys. In The Survey Handbook, Fink A (ed). 2003. 39. Miles M, Huberman A. Qualitative Data Analysis: A Methods Sourcebook (Third edn). 2014. 40. Hamou-Lhadj, A. (2015). Regulatory Compliance and its impact on software development. 41. Barnum, S., & Gegick, M. (2005). Design Principles. Build Security In: Setting a Higher Standard for Software Assurance, Cigital Inc. 42. OWASP secure coding practices: quick reference guide, Version 2.0, 2010.
