Thursday, November 14, 2019

The SDLC vs. An SDLC


Understanding how to implement the SDLC in your SDLC

In the 1960s, we developed a process called the System Development Life Cycle. In the 1990s and early 2000s, we began creating a process called the Security Development Life Cycle. Sometimes we shorten that to SDL (as in Lifecycle) but the intent is the same. In other instances, we emphasize only the development of secure software, incorrectly implementing a Secure Development Life Cycle.

In this post, I'm exploring the System Development and the Security Development life cycles. These process phases are not written in stone, but they do represent the general flow of development for a given information system. Your experience may vary.

The System Development Life Cycle

A product or system development life cycle generally consists of the following phases.

Initiation

In the initiation phase, product stakeholders develop concepts, business requirements and perform analysis. A requirements specification is developed. Executive approvals are generally obtained in this phase. 

Planning


In the planning phase, product stakeholders develop fundamental and architectural design constraints based on requirements. Primary use cases are developed.

Design


Information System designs are developed, less important implementation decisions are made using requirements documentation. Data classification and data dictionaries are developed. Use cases are refined and expanded.

Implementation


Coding begins and quality assurance designs (bug bars, quality gates) are specified and implemented. Minor design considerations are explored, tested and implemented. Components of the application are submitted for verification. 

Verification


Functional and non-functional testing is performed. The application may be pushed back into the implementation phase as components are tested. The product is moved towards production using one or more stages involving smoke testing, readiness testing, and a variety of reviews and approvals.

Release


The product is moved into production. The Product Team receives reports from consumers and concerned 3rd parties pertaining to features, bugs, and vulnerabilities. Based upon this information, the product lifecycle will restart in the Planning phase, ultimately resulting in major, minor, or patch releases.

Disposal


The product is decommissioned and potentially replaced with a different solution.

The Security Development Life Cycle & Alignment


The security development life cycle injects the system development life cycle with security best practices at each phase.


Initiation


Concepts and business requirements are reviewed for the application of customary security controls. General architectural security requirements are expressed and proposed.

Planning 


Architectural security requirements are reviewed, revised and established. Data flow diagrams are produced and threat modeling (e.g., STRIDE by element & interaction) is performed. Abuse cases are developed. General product security requirements are reviewed, revised and established.

Design 


Abuse cases are refined and developed. Product security requirements are reviewed and updated. Core components are reviewed for security requirements in alignment with architectural security requirements and industry best practice standards.

Implementation 


Product security requirements are implemented and built into the product; secure architecture design, abuse cases, and threat models instruct implementation. A variety of security testing is performed in conjunction with known attack vectors and threat actors. Test-driven development may be utilized; unit tests and security tools are developed and procured to exercise and expose the security qualities of the application.

Verification 


Additional security testing is performed for those things that cannot be easily confirmed with unit tests or test-driven development. Testing results are confirmed against abuse cases and product security requirements.

Release 


The information system is monitored for vulnerabilities in the applications, the operating systems, and the infrastructure. Observations are communicated to the product team. The PSIRT is engaged as necessary.

Disposal


Design documentation, data classification, and data dictionaries are reviewed. Plans are developed to retain or dispose of data in a secure manner.

Summary

The idea is to understand where key activities are taking place within the Development Life Cycle, so that we may insert the appropriate Security Development activities.  

Remember this key idea: just as Software Engineers develop applications using software and engineering best practices, Security Architects enable the development of Secure Qualities that can be traced to Security Standards and well-designed Product Security Requirements.

No comments:

Post a Comment