Secure Software Development Lifecycle

shape
shape
shape
shape
shape
shape
shape
shape

Secure Software Development Lifecycle

Testing is often started very late in the software development lifecycle shortly before it is deployed. It has turned out that this is a very ineffective and inefficient practice. One of the best methods to prevent security bugs from appearing in production applications isto improve the software development lifecycle by including security in each of its phases, thereby extending it to a secure software development lifecycle. A software development lifecycle is a series of steps, or phases, that provide a model for the development and lifecycle management of an application or piece of software. It is a structure imposed on the development of software artefacts. A generic software development lifecycle model considering testing as an orthogonal dimension comprises the phases analysis, design, development, deployment, and maintenance [99]. Each phase delivers specific artefacts, i.e., the analysis phase results in requirements, the design provides design models, development delivers code, deployment results in a running system, and finally, all artefacts are maintained.

A secure software development lifecycle takes security aspects into account in each phase of software development. A crucial concept within the secure software development lifecycle is a risk. A risk is the likelihood of an unwanted incident and its consequence for a specific asset [84]. Taking into account the negative nature of many security requirements, the concept of risk can be employed to direct the selection or application of security counter-measures like testing [84, 102]. In all phases of the secure software development process, but especially at the design level [127], risk analyses provide effective means to guide security testing and thus detect faults and vulnerabilities.

Major security development processes are the Security Development Lifecycle (SDL) [57] from Microsoft and the Open Software Assurance Maturity Model (OpenSAMM) [97] from OWASP.

Microsoft SDL is an established security lifecycle for software development projects pursuing the following major principles [57]:

• Secure by Design: Security is a built-in quality attribute affecting the whole

software lifecycle.

• Security by Default: Software systems are constructed in a way that potential

harm caused by attackers is minimized, e.g. software is deployed with the least necessary privilege.

• Secure in Deployment: software deployment is accompanied by tools and guidance

supporting users and/or administrators.

• Communications: software developers are prepared for occurring threats communicating openly and timely with users and/or administrators.

The SDL is composed of security practices attached with the major activities of a software lifecycle, i.e., requirements, design, implementation, verification and deployment in case of SDL, which are extended by the two activities training and response. For instance, the security practice “establish security requirements” is attached to requirements analysis, “use threat modelling” to design, “perform static analysis” to implementation, “perform fuzz testing” to verification, and “certify release and archive” to release.

Similar to the SDL, OpenSAMM attaches security practices to core activities, i.e., governance, construction, verification, and deployment in the case of OpenSAMM, within the software development lifecycle. For instance, verification includes the security practices design review, code review, as well as (dynamic) security testing.

In particular, OpenSAMM attaches each security practice with three maturity levels and a starting point of zero:

• Level 0: Implicit starting point representing the activities in the practice being unfulfilled

• Level 1: Initial understanding and ad-hoc provision of security practice

• Level 2: Increase efficiency and/or effectiveness of the security practice

• Level 3: Comprehensive mastery of the security practice at scale

For each security practice and maturity level, OpenSAMM does not only define the objectives and activities but also gives support to achieve this particular level. This comprises assessment questions, success metrics, costs and personnel needed to achieve the targeted maturity level.

if u need more help please contact us at +91- 93 92 91 89 89 or sales@qaprogrammer.com, www.qaprogrammer.com

Leave a Reply

Your email address will not be published. Required fields are marked *

    Call Now Button