Software Life Cycle Models and Methods

Over the years, various attempts have been made to define the most effective model for organizing the technical, management, and organizational activities of the SDLC.

Table 5-4 lists all the major SDLC models, with examples of each.

Software Security Assurance State-of-the-Art Report (SOAR)

120

Section 5 SDLC Processes and Methods and the Security of Software

Table 5-4. SDLC Models

Model Implementation Examples

Waterfall

(Linear Sequential) Winston Royce, [14 Scope.5 Assumptions and Constraints.] DoD-STD-216 Context.7A [14 Scope.6 Context.]

Iterative and

incremental Joint Application Design (JAD), [14 Scope.7] MIL-STD-4 Scope.98 [14 Scope.8]

Evolutionary [14 Scope.9] Tom Gilb’s original Evolutionary Life Cycle (which has evolved into Evolutionary Systems Delivery, or Evo), [15 Assumptions and Constraints.0] Rapid Iterative Production Prototyping (RIPP), Rapid Application Development (RAD), [15 Assumptions and Constraints.1] Genova [15 Assumptions and Constraints.2]

Spiral Barry Boehm [15 Assumptions and Constraints.3 Intended Audience.]

Concurrent Release Cascade Model or Reparenting Model [15 Assumptions and Constraints.4 Scope.]

Unified Process [15 Assumptions and Constraints.5 Assumptions and Constraints.] Rational Unified Process (RUP), [15 Assumptions and Constraints.6 Context.] Agile Unified Process (AUP), [15 Assumptions and Constraints.7] Enterprise Unified Process (EUP) [15 Assumptions and Constraints.8]

Agile See Appendix F

For Further Reading

David Russo (University of Texas at Dallas), Software Process Planning and Management, Process Models.

Available from: http://www.utdallas.edu/~dtr021000/cse4381/processOverView.ppt John Petlicki (De Paul University), Software Development Life Cycle (SDLC).

Available from: http://condor.depaul.edu/~jpetlick/extra/394/Session2.ppt

5.1.8.1 Agile Methods and Secure Software Development

Agile methods are characterized by achievement of customer satisfaction through early and frequent delivery of workable and usable software (i.e., short iterations), iterative development, acceptance of late requirements changes, integration of the customer and business people in the development environment, parallel development of multiple releases, and self-organizing teams.

According to Philippe Kruchten and Konstantin Beznosov, [159] agile methods are iterative in nature; they do not follow the traditional linear development method of requirements development, design, implementation and testing phases. Instead, agile methods repeat the “traditional” development sequence many times. In this way, agile methods can be likened to the spiral model. However, agile methods also emphasize an evolutionary approach to software production (“build a little, test a little, field a little”), with many life cycle activities occurring concurrently.

As characterized by the Agile Manifesto, all agile methods have a single overriding goal: to produce functionally correct software as quickly as possible.

For this reason, agile methods avoid life cycle activities that—

Software Security Assurance State-of-the-Art Report (SOAR) 121

Section 5 SDLC Processes and Methods and the Security of Software

u Do not directly involve the production of software, (i.e., other artifacts such as documentation, which is needed for most security evaluations and validations).

u Cannot be performed by members of the software team, and

concurrently with other life cycle activities. For example, agile methods do not accommodate IV&V.

u Require specialist expertise beyond that expected from the developers in the software team. Agile methods do not allow for the inclusion of security experts or other non-developer personnel on software teams.

u Focus on any objective other than producing correct software quickly.

Agile projects have difficulty incorporating other nonfunctional objectives, such as safety, dependability, and security.

u Must be performed in an environment with constraints on who works on the project, in what role, and under what working conditions. Agile projects do not include or easily accommodate concepts such as separation of roles and separation of duties, least privilege, and role-based access control of development artifacts.

Much discussion and debate has occurred regarding whether it is possible for software projects using agile methods to produce secure software. Appendix F discusses the security issues frequently cited in connection with agile

development, as well as counterarguments for how agile methods can benefit software security. Appendix F also describes some efforts to define “adapted”

agile methods that are more security supportive.

For Further Reading

Rocky Heckman, Is Agile Development Secure?, CNET Builder.au., August 8. 2005.

Available from: http://www.builderau.com.au/manage/project/soa/Is_Agile_development_secure_

/0,39024668,39202460,00.htm or

http://www.builderau.com.au/architect/sdi/soa/Is_Agile_development_secure_/0,39024602,39202460,00.htm M. Siponen, R. Baskerville and T. Kuivalainen, Extending Security in Agile Software Development Methods, In: Integrating Security and Software Engineering: Advances and Future Visions, Idea (Group Publishing, 2007).

X. Ge, R.F. Paige, F.A.C. Polack, H. Chivers and P.J. Brooke, “Agile Development of Secure Web Applications”, in Proceedings of the ACM International Conference on Web Engineering, 2006.

L. Williams, R.R. Kessler, W. Cunningham and E. Jeffries, “Strengthening the Case for Pair-Programming”, in IEEE Software 17, no.4 (July-August 2000): 19-25.

5.1.8.2 Security-Enhanced Development Methodologies

A security-enhanced software development methodology provides an integrated framework, or in some instances, phase-by-phase guidance for promoting security-enhanced development of software throughout the life cycle phases. The methodologies described here either modify traditional SDLC activities, or insert new activities into the SDLC, with the objective

Software Security Assurance State-of-the-Art Report (SOAR)

122

Section 5 SDLC Processes and Methods and the Security of Software

of reducing the number of weaknesses and vulnerabilities in software and increasing software’s dependency in the face of threats.

The methodologies described in Sections 5.1.8.2.1 through 5.1.8.2.5 have been used successfully in either multiple real-world development projects or multiple academic pilots. Appendix G provides an overview of how the main security enhancements in these five methodologies map into a standard life cycle model.

Section 5.1.8.2.6 describes additional methodologies that have been developed by researchers, but that have not yet had extensive enough use in pilots or real-world development projects to justify confidence in the researchers’ claims for their effectiveness.

For Further Reading

Noopur Davis (CMU SEI), Secure Software Development Life Cycle Processes, (Washington, DC US CERT, July 5, 2006).

Available from: https://buildsecurityin.us-cert.gov/daisy/bsi/326.html?branch=1&language=1

5.1.8.2.1 Microsoft Trustworthy Computing SDL

Microsoft’s formally established its security-enhanced software development process, the SDL, during its “security pushes” of 2002 [160] as a means of modifying its traditional software development processes by integrating tasks and checkpoints expressly intended to improved the security of the software produced by those processes. SDL’s goals are twofold:

1. To reduce the number of security-related design and coding defects in Microsoft software

2. To reduce the severity of the impact of any residual defects.

Microsoft has stated that its software developed under the SDL process initially demonstrated a 50-percent reduction in security bulletins on its major products compared with versions of the same products developed prior to SDL; more recent Microsoft estimates claim up to an 87-percent reduction in security bulletins.

The SDL method proceeds along phases, mapping security-relevant tasks and deliverables into the existing SDLC. The following describes each of the phases:

1. Requirements—The team reviews how security will be integrated into