S-SDLC: Secure Software Development Life Cycle

This article introduces the Secure Software Development Life Cycle (will now on be referenced to as S-SDLC). There are multiple reasons why programs like these have gained popularity. We can say to a certain extent that they have become mandated in organizations concerned about security. This article provides a brief explanation about S-SDLC but does not explain it in detail. We will first touch upon SDLC to understand its various phases. Then we will look into why S-SDLC is needed in the first place to develop secure software and give a brief overview of it.

Intended Audience

This article is written keeping in mind Project Managers, Program Managers, Developers, Architects and every individual interested in improving the security of product(s) developed by their organization(s). This article is written as a starter document for people who want to integrate security into their existing software development process.

Brief overview of Software Development Life cycle

Software Development Life Cycle (or SDLC) is the process which is followed to develop a software product. It is a structured way of building software applications. Most organizations have a process in place for developing software; this process may, at times, be customized based on the organizations requirement and framework followed by organization.

Knowledge about SDLC is very important for anyone who wants to understand S-SDLC. The Following are some of the major steps which are common throughout the SDLC process, regardless of the organization. Here is a photo representation of a Sample Software Development Life Cycle:

S-SDLC: The Secure Software Development Life Cycle

  • Requirements Gathering

    A Software Requirement Specification or SRS is a document which records expected behavior of the system or software which needs to be developed.

  • Design

    Software design is the blueprint of the system, which once completed can be provided to developers for code development. Based on the components in design, they are translated into software modules/functions/libraries, etc… and these pieces together form a software system.

  • Coding

    During this phase, the blueprint of the software is turned to reality by developing the source code of the entire application. Time taken to complete the development depends on the size of the application and number of programmers involved.

  • Testing

    Once the application development is completed, it is tested for various issues like functionality, performance, and so on. This is to ensure that the application is performing as expected. If there are any issues, these issues are fixed before/after going to production depending on the nature of issue and the urgency to go live for the application.

  • Deployment

    Once the application is ready to go live, it is deployed on a production server in this phase. If it is developed for a client, the deployment happens in a client premise or datacenter where there client wants to get the application installed.

What is S-SDLC?

S-SDLC stresses on incorporating security into the Software Development Life Cycle. Every phase of SDLC will stress security – over and above the existing set of activities. Incorporating S-SDLC into an organization’s framework has many benefits to ensure a secure product.

Current Trend

Current trend is to identify issues by performing a security assessment of applications after they are developed and then fix these issues. Patching software in this way can help, but it is a costlier approach to address the issues.

This cycle of Testing – Patching – Re-testing runs into multiple iterations and can be avoided to a great extent by addressing issues earlier in the Life Cycle. This next section covers a very important aspect – the need for programs like S-SDLC.

Why S-SDLC?

As an old saying goes – “Need is the mother of invention” – This is applicable for S-SDLC as well. There were days when organizations were just interested in developing an application and selling it to the client and forget about rest of the complexities. Those days are gone.

A very simple answer to the question is – “The threat landscape has changed drastically.”

There are people out there whose only intention is to break into computer systems and networks to damage them, whether it is for fun or profit. These could be novice hackers who are looking for a shortcut to fame by doing so and bragging about it on the internet. These could also be a group of organized criminals who work silently on the wire. They don’t make noise but when their job is done, it reflects into a huge loss for the organization in question – not to mention a huge profit for such criminals.

The criminals or novice hackers can break into an organizations network through various routes and one such route is the application host. If applications are hosted by organization are vulnerable, it can lead to serious consequences.

There’s bad press and stock crashes resulting due to such incidents. Especially these are financial organizations/institutions such as banks and brokers – that’s where the money is! However, this does not eliminate the risk for non-financial organizations, as pretty much every avenue to generate money is targeted.

These organized gang of cyber criminals can siphon off money directly, they do so, however if it is not possible straight away, they even go to extent of threatening and extortion. Every organization is afraid of bad press as it can have direct impact on the stock price and sometimes extortion techniques by threatening to go public can have an impact on organizations and they may even end up coughing up money to save themselves from issues that may crop up if these cyber criminals go public with private information.

Some organizations may file lawsuits against such extortionists. There can be various things that can be done, but one thing which undeniably happens is that it costs organization money.

This is where S-SDLC comes into the picture. While employing a team of ethical hackers helps, having processes like S-SDLC can help organizations in addressing the above discussed issues in a much more cost-efficient manner as identifying security issues earlier in the development life cycle reduces the cost.

Brief Explanation of S-SDLC

Now that we know what exactly SDLC is, let’s explore S-SDLC. The above sections have touched up on what it is and why it is required, however they do not explain what things are covered in each phase.

It should be noted that the following sections will very briefly touch upon activities covered in each phase of SDLC. This is by no means a full list of activities that can be performed. The idea here is to familiarize the reader with the concept of S-SDLC. Also, it should be noted that each organization calibrates SDLC and S-SDLC according to their needs; hence there is no silver bullet solution here. Having understood this, now let’s get into the details.

The following is a Pictorial Representation of Sample S-SDLC Process:

S-SDLC: The Secure Software Development Life Cycle

Each phase of the Sample SDLC is mapped with security activities, as demonstrated in the figure and as explained below:

  • Requirements Gathering
    • Security Requirements
    • Setting up Phase Gates
    • Risk Assessment
  • Design
    • Identify Design Requirements from security perspective
    • Architecture & Design Reviews
    • Threat Modeling
  • Coding
    • Coding Best Practices
    • Perform Static Analysis
  • Testing
    • Vulnerability Assessment
    • Fuzzing
  • Deployment
    • Server Configuration Review
    • Network Configuration Review

As I highlighted earlier, the above mentioned S-SDLC is not complete. You may find certain activities like Training, Incident Response, etc… missing. It all depends on the scope of the program and the aim with which it is implemented. If it’s being rolled out for entire organization, having all the activities makes sense, however if only one department of the company is proactively interested in improving the security stature of their applications, many of these activities may not be relevant or needed; hence activities like Incident response can be dropped in such cases.

Stakeholders

Programs like S-SDLC can have multiple Stakeholders – some of them can be in Senior Management while some of them can even be at root level (e.g. Software Developers). It is imperative to communicate with these stake holders for the success of the program. Stakeholders will differ from organization to organization based on the software development approach that it follows.

Developing Supporting Policies & Procedures

To implement S-SDLC, we may also have to update some of the existing policies and procedures and in certain cases we might also have to create new policies and procedures – if they are missing.

Measuring the success

It is necessary to understand the current stature of the S-SDLC Program, re-evaluate and calibrate it on a need to need basis; however this is not possible unless we can measure our success. Measuring our program’s success helps us in comparing the current posture of our program with a benchmarked posture and thus evaluates our future course of action.

References

www.microsoft.com/security/sdl/default.aspx

https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet