The SD3 security framework

Using this approach allows developers to consider security throughout the software development lifecycle.

The initial phase is Secure by Design, and relates to the actual design and initial development of the software taking into account security controls.

Secure by Default relates to designing the software to have the minimum possible exposure to generic threats that may already exist. This means that security measures will be set as default and allow users to make decisions to then remove these controls. This means you can run the software without have administrator's privileges.

Secure in Deployment shows that the responsibility for security does not end once the software has been issued for wider use. Users need to be given appropriate training in using the software securely, and documentation is needed to describe how the software works.

Secure by Design

Ensure that the design team are given the correct training and have the correct attitude towards security. Security awareness should be second nature for them, and security should never be an afterthought or put into the ‘too difficult’ pile.

Software should always aim to achieve its security goals, with these being regarded as a key feature rather than an unnecessary add-on. Define these security goals right at the start of the process to ensure you are always working towards them.

Understanding the possible threats that could affect the software will help to steer the required security goals, ensuring that the development team can concentrate on the necessary security issues rather than working on mitigating irrelevant threats.

Secure product development timeline

A basic timeline for the secure development process, showing the stages where milestones and activities fit in. 

Many of the activities are not one-time efforts: Training, assessment, analysis, testing, verification, and refinement are all on-going activities and will carry on even if the project has moved into the next phase. 

System Development Lifecycle Models (SDLC)

The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation, and maintenance, and ultimately its disposal that instigates another system initiation.

Figure 1: System development lifecycle models

WATERFALL GFX

The traditional model for the SDLC is the Waterfall, or its v-shaped variant. This approach to systems development is very hierarchical, with clearly delineated phases. The results from each phase cascade down to the next. In the v-shaped model, the testing of each phase is also included in the SDLC, with the results from each phase of testing feeding back up through the development phases until the final testing proves acceptance that the software matches the original requirements.

AGILE GFX

The current fashion in systems development is to be Agile. In Agile, development phases are broken down into small blocks of work called Sprints. The results of these Sprints are discussed at Scrum meetings, where a Scrum Master will pull together the disparate work streams and keep the project on track.

Agile is very flexible and allows for rapid prototyping of systems without having to go through all the hierarchical steps associated with Waterfall. This approach does have the benefit of producing systems in shorter timescales, but it can be easy to lose sight of security objectives when the system is undergoing rapid change.

INCREMENTAL GFX

The Incremental SDLC works in similar ways to Agile, but is far more structured. The development process is broken up into small chunks, but each is actioned in order, and tested prior to moving on.

SPIRAL GFX

The Spiral SDLC looks to combine the best of the Incremental and Agile approaches, with a high emphasis on risk analysis throughout.

What's next?

Next you will look at DevOps vs DevSec.