A Survey on Design Methods for Secure Software Development

Software provide services that may come with some vulnerabilities or risks. Attackers perform actions that break security of system through threats and cause a failure. To avoid security vulnerability, there are many security-specific concepts that should be determined as requirements during software development life cycle in order to deliver a strong and secure software. This paper first, survey a number of existing processes, life cycle and methodologies needed for developing secure software based on the related published works. It starts by presenting the most relevant Secure Software Development Lifecycles, a comparison between the main security features for each process is proposed. The results of the comparison will give the software developer with a guideline which will help on selecting the best secure process. Second, the paper list a set of the most widely used specification languages with the advantages and disadvantages for each


Introduction
A secure software is the software where unauthorized person cannot access it, modify it, or attack it.The degree of such security is measured by the existing number of security vulnerabilities.The software with no vulnerabilities is a high secure software, where the software with at least one vulnerability is insecure software [1].
In order to include security in the software engineering, the security aspects should be included from the beginning of the software development life cycle.The secure software engineering is the process of designing, building, and testing software so that it becomes secure, this includes secure software development life cycle (SSDLC) processes and secure software development (SSD) methods.A SSDLC process considers security aspects of the software during the development life cycle by using SSD methods.SSD methods include, among others, security specification languages, security requirements engineering processes, and software security assurance methods [24].
The importance of including security on the software developing comes from the high cost of removing system errors which may cause a security vulnerability after developing.This paper survey a set of secure software development life cycle processes, identify the characteristics for each one, and presents a comparison between them based on the security activities that are included in the development lifecycle, this will be useful for the software developers by helping him choosing the correct process.2. Vulnerability: A weakness in the design, operation, implementation or any process in the system which expose the system to a threat.[10] defined it as a weakness of an asset or group of assets that can be exploited by one or more attacker.

Threat:
A possible danger that may result in harm of systems and organization.
4. Attack: An actual event done by a person; attacker to harm as asset of the software through exploiting a vulnerability.
5. Risk: a potential for loss, damage, or destruction of an asset as a result of a threat exploiting a vulnerability.
6. Software Security Requirement: is a non-functional requirement that elicit a control, constraint, safeguard, or countermeasure to avoid or remove security vulnerabilities from requirements, design or code [24][25][26].
7. Confidentiality: means to disclose information to people or programs that are authorized to have access to that information.
8. Integrity: assures that a system performs its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorized manipulation of the system.9. Availability: assures that systems work promptly, and service is not denied to authorized users.
10. Process: is an instance of a computer program that is being executed.
11. Secure software process: is a set of activities used to develop and deliver a secure software solution.

Secure Software Development Life Cycle processes
The stages of the software development are: 1. Requirements definition and specification 2. Design document containing system abstraction and their relationships 3. Coding, Programming components of the system 4. System testing

Implementation and Maintenance
Adding the security activities to software development life cycle will in general include the following in Figure 1.

Microsoft's Trustworthy Computing Security Development Lifecycle (MS SDL)
Microsoft's Trustworthy Computing Security Development Lifecycle (SDL) is a process developed be Microsoft to add a series of secure activity to each phase of Microsoft's software development process as follows: during requirement phase, the security feature requirements are defined based on the customer demands, in the design phase the MS SDL suggests a set of activities to be performed such as threat modeling for security risk identification, identifying components that are critical to security or needs special attention during testing.In the implementation phase, use of static analysis code-scanning tools and code reviews.After completing implementation, the complete software is tested focusing on the security critical components of the software during the testing phase.A final code review of new as well as legacy code is used during verification phase.And finally, during the release phase, a Final Security Review is conducted by the Central Microsoft Security team [4,12,13].The overall process is shown in Figure 2.  TCP process is specifically designed for software teams, to build a high-performance team and help them in plan their work to achieve the best performance.The TSP Secure focuses directly on the security of software in three ways: planning, development and management, and training for developers about security related aspects and other team members.In the initial phase; planning, the team identify security risks, security requirements, secure design, code review, use of static analysis tools, unit tests, and Fuzz testing, and produce a detailed plan to be used in the development phase during a series of meetings.Next, the plan is executed, and the team ensure that all the security activities are taken place [14].TSP security strategy has multiple defect removal point during SDLC, which enables problems to be easily removed.Figure 3 shows defect removal activity in the software development life cycle.TSP-Secure includes training for developers, managers, and other team members [33].

Agile Methods
Agile is a new family in the software engineering which include extreme programming, scrum, Crystal Methodologies, Lean Software Development, Feature Driven Development, and Dynamic Systems Development Methodology.All of these methods that fall under the umbrella of "Agile", are different in their methodology, but they are all have some common principles, such as short development iterations, minimal design upfront, emergent design and architecture, collective code ownership and ability for anyone to change any part of the code, direct communication and minimal or no documentation (the code is the documentation), and gradual building of test cases [15].In order to add security to the agile method, the security requirements must be adaptable and simple.[16]  Is a strategy oriented process model that provide the developers and software engineers from beginners to experts with a guidance support that cover most resources and knowledge need to develop a secure software.The process provides two level of guidance, the first one is strategic which helps the developers choosing one among several strategies.The second level guidance is tactical helping developers achieving their selection for producing secure software [17].
It gives the developers with more than one option while advancing from one phase to another in order to achieve flexibility and extensibility in the secure software development process [17].The security development process here is intention oriented.At any moment, the engineer has an intention, a goal in mind that he wants to fulfill.

Comprehensive, Lightweight Application Security Process (CLASP)
Is a lightweight process, consists of 24 top-level security related activities that can be fully or partially incorporated into software that is being constructed during software development life cycle [18].Each CLASP Activity is divided into discrete process components and linked to one or more specific project roles, this provides a guidance to project participant and results in incremental improvements for security in the software life cycle.For example, threat modeling and risk analysis are performed during requirement and design phase [19].In the design and implementation phase, it suggests secure design guidelines and secure coding standards [20][21][22][23].inspections, static code analysis, and security testing are performed in the assurance phase.The Correctness by Construction methodology developed by Praxis Critical Systems is a process for developing highintegrity software [33].It has been used to develop safety-critical and security-critical systems with a great degree of success [34].Correctness by Construction is based on the following tenets: do not introduce errors in the first place and remove any errors as close as possible to the point that they are introduced.
The process is based on the strong belief that each step should serve a clear purpose and be carried out using the most rigorous techniques available to address that particular problem.Specifically, the process almost always uses formal methods to specify behavioral, security, and safety properties of the software.The belief is that only by using formality can the necessary precision be achieved.
The seven key principles of Correctness by Construction are: 1. Expect requirements to change.Changing requirements are managed by adopting an incremental approach and paying increased attention to design to accommodate change.Apply more rigor, rather than less, to avoid costly and unnecessary rework.
2. Know why you're testing.Recognize that there are two distinct forms of testing, one to build correct software (debugging) and another to show that the software built is correct (verification).These two forms of testing require two very different approaches.
3. Eliminate errors before testing.Better yet, deploy techniques that make it difficult to introduce errors in the first place.Testing is the second most expensive way of finding errors.The most expensive is to let your customers find them for you.
4. Write software that is easy to verify.If you don't, verification and validation (including testing) can take up to 60% of the total effort.Coding typically takes only 10%.Even doubling the effort on coding will be worthwhile, if it reduces the burden of verification by as little as 20%.
5. Develop incrementally.Make very small changes, incrementally.After each change, verify that the updated system behaves according to its updated specification.Making small changes makes the software much easier to verify.
6. Some aspects of software development are just plain hard.There is no silver bullet.Don't expect any tool or method to make everything easy.The best tools and methods take care of the easy problems, allowing you to focus on the difficult problems.
7. Software is not useful by itself.The executable software is only part of the picture.It is of no use without user manuals, business processes, design documentation, well commented source code and test cases.
These should be produced as an intrinsic part of the development, not added at the end.In particular, recognize that design documentation serves two distinct purposes:


To allow the developers to get from a set of requirements to an implementation.Much of this type of documentation outlives its usefulness after implementation.


To allow the maintainers to understand how the implementation satisfies the requirements.A document aimed at maintainers is much shorter, cheaper to produce and more useful than a traditional design document.

Appropriate and Effective Guidance for Information Security (AEGIS)
This process based on the spiral model, it integrates into normal software engineering lifecycles, as can be seen in its application to the Spiral model of software development as shown in Figure 5.The process identifies security requirements first by determining system assets and their relationships, then risk analysis in which vulnerabilities, threats and risks are identified [5,31].This model initially focuses on building security concepts at the early stages of the software development cycle.It provides a means for eliciting, categorizing, and prioritizing security requirements for information technology systems and applications.The final output of SQUARE is a security requirements document that is designed to satisfy the security goals of the organization [7].Then, it has been enhanced into SQUARE+R [8] to incorporate risk analysis in all phases of the development to ensure security.It uses a static and dynamic code analysis tools for the security assurance phase.

Comparison of existing secure software development life cycle process SSDLC
This section presents the strengths and weakness point for each SSDLC with a comparison between them according to the activities that should be added during development life cycle to develop a secure software.The secure activities that can be added to each phase in the software development life cycle are listed below in table 1.The details of each activity are: 1. Secure software development activities for requirement engineering A Software Requirement Specification or SRS is a document which records expected behavior of the system or software that needs to be developed.
Each SSDLC should specify the use of SSD activities for each (i.e., requirements engineering, design, implementation, and security assurance), in order to develop a secure software, the recommended activities should be added to each phase in the software development life cycle phases.For requirement engineering phase different secure activity must be found as follow 1) Threat modeling activity which refers to identify possible threats that can attack the software, so that appropriate security feature must take into consideration through requirement specification phase.
2) Requirement specification review activity, through this activity security error was specified.
3) Use of security requirement specification language to specify security requirement which can help to remove identified language.
4) Evaluation for security state of requirement specification using risk analysis to prioritize the identified security requirements.
All upper activities must be used through first phase of software development life cycle to achieve secure requirement specification, some of current models used some of these activities and some other model does not use them, and many processes recommend a similar set of SSD methods to be used during requirements engineering.Almost all the SSDLC processes (except SSAI [27] and MS SDL [4,13]) perform threat modeling and/or risk analysis during the requirements specification phase.Moreover, all processes except SSAI and SSDM recommend defining security features to mitigate identified threats.
2-secure software development through design phase.
Second phase of software development life cycle refer to design phase, through this phase different activities must be take into account to be found through this phase to achieve secure software development, these activities are as follow: 1) Through entail design development the secure design guideline and secure design pattern must be followed, and secure design decision should be specified using secure design specification language.
2) Must identify possible software threats by performing threat modeling on the initial design phase, where this activity was different from that which found on requirement phase because the data or information through this phase was more than that on previous requirement phase.
3) Design review activity which refers to review design phase to make sure that no security error was found, where error that can be found here on this phase was caused by requirement specification phase error, for that all error on previous phase must be fixed.
4) Errors and threats identifications must be used as a basis to security requirement specification for design phase.

5)
To prioritize security requirements for design phase the risk analysis should be performed [2,26].
Some processes take into consideration these activities during its design phase such as MS SDL [29] and CALSP [18], both provide comprehensive set of SSD methods for design phase.

3-Security activity in implementation phase
Secure programming language selection is the important step to achieve secure implementation phase, through following a secure coding standard and standard guideline, some model suggest that implementation using secure language to achieve secure implementation, like Apvrille and Pourzandi [11], and S2D-ProM [17], where some other suggest to use secure coding standard guideline to achieve secure implementation like MS SDL [4,13], SecSDM [6,30], McGraw's SSDLC process [2], S2D-ProM, CLASP [18], MS SDL goes further and suggests that certain security assurance activities should be performed during implementation.

4-SSD Activities for Security Assurance and Testing
Some activities must be taken into account through testing and security assurance process, vulnerability assessment and fuzzing must be implemented on testing phase also security static analysis using code scanning tools and security code review after finishing the coding or implementation phase.We must note that all these activities do not guarantee security of software but identify errors and vulnerability.Different models of SDLC models use these activities for testing phase such as the exception of AEGIS [5,31], SSDM [6], and SecSDM [30], all the processes recommend using multiple security assurance methods such as security testing, code reviews, static code analysis.
To achieve secure software development, a secure resource should be available for development process, where the resources can be possible mitigations for each error or vulnerability, where this knowledge will be helpful to avoid errors that can lead to vulnerabilities in the first place [31].Other important point on secure development resource phase to review different resources as do server configuration review and network configuration review, these two steps avoid vulnerability which come from the network and resources.
Figure 7 summarize the secure activities that can be added to the software development life cycle.Table 3 summarize a comparison of SSDLC processes according to security activities in each phase of the development cycle phases.

Ten ways to infuse security into your software development life cycle
Implement security measure should be a top of priority to ensure the security level of the developed software; the following ways can help on producing secure software as follow: -Asses Land Space, by do requirement gathering and good understood what the customer need by determine scope and boundaries, and by identify the stockholder to define what they want, and other by identify the process gaps.
-Incorporate industry standard security model for software development process through requirement gathering process, based on this step secure software will be built from the beginning of development and this way will be cost effective to not repeat the test of the program more than one time if this development does not achieve security level recommended from the customer.
-Educate personal on software security; this can be done through training or deployment phase to educate the customer who will use the software for security property of software and how to avoid unsafe actions which will affect the security level for the program.
-Perform security on the phase of requirement gathering, though this step we must incorporate security on initial steps of security development phases to insure of producing secure software as performing initial risk analysis during requirement gathering phase to promote security activities in addition phases within SDLC.
-Initiate institute for a comprehensive risk management analysis, this institute will help on identifying major risk and execute a mitigation plane, this institute have responsibility like ensure proper security design, ensure effectiveness guide in SDLC execution.
-Perform architecture review and threat modeling, this way implemented through design phase of SDLC phases, this step is important to identify different threats and risk on early stage of development which will be cost effective when identify it here rather than identity it later one software was developed, different critical tool for detect design flaws as analyzing fundamental design principle and assign the attack surface, enumerating various threat agents and other identifying weakness and gaps in security controls.
-Doing code review during implementation phase, this step is complete step for using secure coding standard and static code analysis performing secure coding review as a condition for pass of development of software as secure software development.
-Execute test plane and perform penetration test through verification phase of software development life cycle phases, this step other important to make sure that the developed product perform as expected in runtime scenario.
Last step refers to Deploy Software product through deployment phase of SDLC this is essential to successful release to production through QA and acceptance testing are completed

Specification languages for software security
The specification languages are a way used to detect existing vulnerabilities by simulating different conditions of attacks and its securities.In this section, we introduce some of these specification languages.

Definitions related to specification languages 1. Use Case Diagram
Is a graphic description that defines system's user and activities and the interaction between them.

Activity Diagram
Is a behavioral diagram that represent the workflow of the system.It describes the flow from one activity to another.

Class Diagram
Is a structural diagram for a particular system.It describes classes, packages, associations and interfaces.It is widely used in the object-oriented system

Abuse case
It describes the interaction between actor and activity, where interaction is harmful.

Misuse Case
The case that should not be happening in the system.It is used to detect system vulnerabilities.

Attack Language
Is the language that is used to describe, recognize, react and report an attack.

Specification Language
Describes what the system should do.what data to be processed.Check requirements and verify system validation.

Specification Languages
In this section, we will introduce the most widely used specification languages.

STATL
Is an extended finite state machine-based executable attack specification language, proposed in 2002 by Eckmann et al [35], it an attack by using states and transitions where states represent a different characteristic of an attack and transition connects two states.Each transition must have associated event which when occurs fires the transition.And each transition may have code to be executed when fired.STATL is a language to support misuse detection and is widely used in network-based attacks and host-based attacks [36].

UMLSec
UMLSec is an extension of UML language, it is developed by Jurjens et al [37] in 2002.Its main purpose is to focus on specifying role-based access control policies which can be considered as security requirements to help in the development of a security-critical system.It provides 9 stereotypes to turn normal UML language into security purpose language.

UMLIntr
UMLintr is an extension of UML, proposed in 2006 by Hussein et al., and uses use case diagrams, class diagrams, state charts, and package diagrams to specify attacks [38].The attack scenarios are described in misuse state machine.

Abstract State Machine Language (AsmL)
Is an extended finite state machine-based executable software specification language, and used to specify attack scenario.This attack scenarios can be automatically translated into Snort rules which can then be used with an extension of the IDS Snort.Such attack scenarios are able to capture more attacks with multiple steps using context information [41].

AsmlSec
Is an extension of specification language Asml [39], and proposed by Raihan et al. in 2007 [40].Some features were missing in Asml to represent different attacks.AsmlSec integrated those missing features with Asml by adding states and transitions.
States are different situations of an attack and transitions are different events that trigger another state.A transition can only take place if guard or condition is satisfied.If a system reaches any state, which is an attack state then the system generate an alert [36].It uses attacks scenarios specified as rules to detect attacks over the network.It specifies what action should be taken if the rule is matched to a network packet, the source and destination IP addresses and ports, the protocol of the observed network, and direction of network packet.A number of options can also be specified.These options range from logging a message to searching for a particular string in the packet [42].

Comparison of Existing Security Specification Languages
I S S N 2 2 7 7 -3061 V o l u m e 1 6 N u m b e r 7 I n t e r n a t i o n a l j o u r n a l o f C o m p u t e r s a n d T e c h n o l o g y 7048 | P a g e D e c e m b e r , 2017 http://cirworld.com/DOI: 10.24297/ijct.v16i7.6467

Figure 1 : 3 ]
Figure 1: Security in the SCLCThere are a set of secure software development methods that had been proposed to add security concept to the software.The software development life cycle is used to develop software and the security activities are added in different phases according to the specific method.This section summarizes a literature review for the most popular secure software development process.

Figure 1 :
Figure 1: McGraw's Secure Software Development Life Cycle Process

I S S N 2 2 7 7
-3061 V o l u m e 1 6 N u m b e r 7 I n t e r n a t i o n a l j o u r n a l o f C o m p u t e r s a n d T e c h n o l o g y 7050 | P a g e D e c e m b e r , 2017 http://cirworld.com/DOI: 10.24297/ijct.v16i7.6467

Figure 2 :
Figure 2: Microsoft's Trustworthy Computing Security Development Lifecycle 3. Team Software Process for Secure Software Development (TSP Secure)

Figure 3 :
Figure 3: Vulnerability Removal FiltersEvery time defects are remove, they are measured.The measurement points help the team to know where they stand against their goals, helps them decide whether to move to the next step or to stop and take corrective action, and indicates where to fix their process to meet their goals.The team considers the following questions when managing defects:

Figure 4
shows the 24 activities of CLASP.I S S N 2 2 7 7 -3061 V o l u m e 1 6 N u m b e r 7 I n t e r n a t i o n a l j o u r n a l o f C o m p u t e r s a n d T e c h n o l o g y 7052 | P a g e D e c e m b e r , 2017 http://cirworld.com/DOI: 10.24297/ijct.v16i7.6467

Figure 5 :
Figure 5: AEGIS Spiral Model of Software Development

9 .
The Secure Software Development Model(SSDM)    This model incorporates various security activities into a waterfall software development life cycle model, as shown in Figure6.The security training provides adequate security education to stakeholders in software development.Threat model identifies attackers and their capabilities and is performed during requirements phase.After that, security specification must be defined by stating the guidelines on how security will be achieved.Penetration Testing is the only SSD activity for the security assurance phase where Capabilities of the software in preventing attacks are tested here[6,30],IS S N 2 2 7 7 -3061 V o l u m e 1 6 N u m b e r 7 I n t e r n a t i o n a l j o u r n a l o f C o m p u t e r s a n d T e c h n o l o g y 7054 | P a g e D e c e m b e r , 2017 http://cirworld.com/DOI: 10.24297/ijct.v16i7.6467

I S S N 2 2 7 7
-3061 V o l u m e 1 6 N u m b e r 7 I n t e r n a t i o n a l j o u r n a l o f C o m p u t e r s a n d T e c h n o l o g y 7055 | P a g e D e c e m b e r , 2017 http://cirworld.com/DOI: 10.24297/ijct.v16i7.6467

I S S N 2 2 7 7
-3061 V o l u m e 1 6 N u m b e r 7 I n t e r n a t i o n a l j o u r n a l o f C o m p u t e r s a n d T e c h n o l o g y 7056 | P a g e D e c e m b e r , 2017 http://cirworld.com/DOI: 10.24297/ijct.v16i7.6467

Figure 7 :
Figure 7: secure development for software development life cycle u m e 1 6 N u m b e r 7 I n t e r n a t i o n a l j o u r n a l o f C o m p u t e r s a n d T e c h n o l o g y 7060 | P a g e D e c e m b e r , 2017 http://cirworld.com/DOI: 10.24297/ijct.v16i7.6467 listed in his article "Towards Agile Security Assurance," a table that shows the compatibility of common security assurance activities with Agile methods.It shows that almost 50% of traditional security assurance activities are not compatible with Agile methods (12 out of 26), less than 10% are natural fits (2 out of 26), about 30% are independent of development method, and slightly more than 10% (4 out of 26) could be semiautomated and thus integrated more easily into the Agile methods. 5. Secure Software Development Process Model (S2D-ProM)

Table 1 :
security activities for each phase in the software development life cycle

Table 3 :
comparison of SSDLC processes
1. Can not directly read HTTP packets