The Security Software Development Lifecycle is the idea that security must be integrated into every stage/phase of the SDLC in order for our operating systems, programs, products, networks and to some, even our people, to ever achieve application confidentiality, integrity and availability.

That latter phrase is known by the acronym CIA triad. Everything we are seeking to accomplish can be summarized with this triangle.

When we look at how the SDLC and Secure SDLC map together, we can see we are just looking to keep our systems available, the data confidential and the systems integrity valid.

And at the heart of all that is the capabilities of our processes. By developing processes, maturing them through following them, regularly reviewing them and updating them, the goal of developing secure software can be achieved.

CMM

The capability for a mature model of software development can really be defined as:

Capability Maturity Models provide a reference model of mature practices for a specified engineering discipline. An organization can compare its practices to the model to identify potential areas for improvement. The CMMs provide goal level definitions for and key attributes of specific processes (software engineering, systems engineering, security engineering), but do not generally provide operational guidance for performing the work. In other words, they don’t define processes, they define process characteristics; they define the what, but not the
how.

Carnegie Mellon University SEI

A number of CMM models exist, including the Capability Maturity Model Integration Development or CMMI-DEV, and the FAA-iCMM co-developed by the FAA and the DOD.

The FAA-iCMM has been organized as three categories and 23 process areas. The FAA-iCMM addresses everything from project management to design and testing, all areas of secure software development. The diagram below graphically displays the process areas and which line up almost perfectly to the processes of the SDLC.

The FAA and DoD found that some additional gaps of coverage were needed. These goals were defined as

  1. An infrastructure for safety and security is established and maintained.
  2. Safety and Security risks are identified and managed.
  3. Safety and Security requirements are satisfied.
  4. Activities and products are managed to achieve safety and security requirements and objectives.

Microsoft

Microsoft has defined one of the best set of Patterns and Practices and they align to 12 stages.

Stage 0: Education and Awareness
Stage 1: Project Inception
Stage 2: Define and Follow Design Best Practices
Stage 3: Product Risk Assessment
Stage 4: Risk Analysis
Stage 5: Creating Security Documents, Tools, and Best Practices for Customers
Stage 6: Secure Coding Policies
Stage 7: Secure Testing Policies
Stage 8: The Security Push
Stage 9: The Final Security Review
Stage 10: Security Response Planning
Stage 11: Product Release
Stage 12: Security Response Execution

These 12 stages when followed and constructed within the DevOps framework make for the best overall security posture I have seen in practice. We will dive deeply into the Microsoft framework in future articles.

Software Engineering Institute’s Team Software Process

The Software Engineering Institute’s (SEI) Team Software Process (TSP) provides a framework, a set of processes, and disciplined methods for applying software engineering principles at the team and individual level.

TSP for Secure Software Development (TSP-Secure) extends the TSP to focus more directly on the security of software applications. TSP-Secure addresses secure software development in three ways. First, since secure software is not built by accident, TSP-Secure addresses planning for security. Also, since schedule pressures and people issues get in the way of implementing best practices, TSP-Secure helps to build self directed development teams and then put these teams in charge of their own work. Second, since security and quality are closely related, TSP-Secure helps manage quality throughout the product development life cycle. Finally, since people building secure software must have an awareness of software security issues, TSP-Secure includes security awareness training for developers.

SEI

Another key area is vulnerability filters to remove defects from escaping into the final product.

Final Thoughts

With the idea of these models we can begin defining processes and build our secure software development lifecycle. These articles will focus heavily on the development portions of these processes.