How to Approach Security Development Lifecycle (SDL)

Introduction to the Security Development Lifecycle (SDL)

Security Development Lifecycle is one of the four Secure Software Pillars. By pillars, I mean the essential activities that ensure secure software.

SDL can be defined as the process for embedding security artifacts in the entire software cycle.

SDL activities should be mapped to a typical Software Development LifeCycle (SDLC) either using a waterfall or agile method. The benefits from the following SDL activities are endless, but two of the most important benefits are:

• Security-by-default
• Build buy-in, efficiency in both operations, and business processes

Software Development LifeCycle (SDLC) defines the different phases that a software product goes through from beginning to end of its life. Different SDLCs exist and companies are free to define their own. SDLC not only applies to the software directly shipped to customers, but it also applies to IT and to Software as a Service (SaaS) projects.

A typical SDLC has the following seven phases, though these can be modified according to your team’s methodology:

1. Concept
2. Planning
3. Design and development
4. Testing
5. Release
6. Sustain
7. Disposal

New development methodologies like Agile, Lean, CD, and others require rethinking existing SDLCs and making adaptions. For example, a team with an agile environment may have the following flow:

Once we determine the methodology, each phase in the SDLC should be mapped to the corresponding activities in the SDL, as follows:

A good implementation of SDL in the software development cycle may look like the following:

Now, let’s dive into the preparation for SDL implementation.

SDL Discovery/Preparation

When? During the concept phase.
Who? Usually initiated by a sponsor but can be anyone in the team.

Goals
SDL Discovery should address the following questions:

1. What are the security objectives required by the software?
Think in CIA terms (Confidentiality, Integrity, Availability).
2. What are the regulations and policies that we need to follow?
3. What are the possible threats in our environment?

When working on SDL Discovery, focus on the following deliverables:

• Security milestones throughout the SDLC
• Security requirements gathered from customers, regulations, and standards
• Required certifications
• Risk assessments
• Required trainings
• Required third-party software
• Key security resources (security team, SDL champions, etc.)
• SDL resources (e.g. coding guidelines, testing tools, compliance checks, etc.)
• Security metrics
• Privacy Impact Assessment (PIA)

After the discovery and preparation have been done, we can start mapping SDL artifacts to our own SDLC.

SDL Artifacts

1. Security Baselines (Requirements)

When? Early in the cycle (e.g. planning)
Who? Senior engineers and project managers

A security baseline is a list of requirements that every product must comply with. Examples of security requirements might include:

• Only approved cryptography
• Sanitize your inputs
• Don’t use backdoors
• Only use approved libraries
• Use multifactor authentication, etc.

Evaluating the product against the Security Baseline is vital. This is called “Gap Analysis.” This is when you compare and contrast the features in your product and the initial features of the baseline. An initial gap analysis at the beginning of the project and a final prior to product shipment are necessary.

The goal of an initial gap analysis is to identify areas that are not compliant with the Security Baseline, missing features, and other requirements. Gaps are analyzed. If any decisions need to be made, they can be addressed in the current release, the next release, or you can make an exception. The gaps that need to be addressed in the current release are documented and reported as work items such as Agile user stories, work items, tickets, etc.

The Final Gap Analysis is performed before products are released. This is done after work items in the initial gap analysis are finished. Companies can release the product based on the compliance level to the baseline. Some companies may only release a product if it is 100 percent, 90 percent, or 80 percent compliant. The level of compliance required is determined by the project managers or by the company standards.

2. Security Training and Awareness

When? Anytime, but preferably during the early stages
Who? Everyone

Security trainings aim to raise the security knowledge of developers, designers, architects, and quality assurance. On the other hand, security awareness sessions are targeted at everyone involved in the project. The goal is to encourage a security mindset in all stakeholders.

Security trainings target developers, designers, architects, and QA. These can cover aspects like SDL, secure design principles, and common security issues, and also address some coding pitfalls such as Java coding, avoiding buffer overflows, etc. They can also focus on specific security areas like web security or encryption.

Security awareness sessions target everyone involved in the project because software security is everyone’s responsibility. Sessions should not require a technical background and they may include topics like CIA (Confidentiality, Integrity, and Availability), understanding threats, risk impact and management, understanding SDL, and lessons learned from previous release experiences followed with examples.

These trainings and awareness programs can also help to fill the gap in education, as most security courses teach how security technologies work, but not how to develop secure software or applications.

3. Threat Modeling

When? During planning
Who? Senior engineers and project managers

Threat modeling aims to identify and manage threats early in the secure development lifecycle and plan for proper mitigations because the cost of remediating issues early on is much lower than later during the cycle. It also helps to validate the architecture with the development team and forces the team to look at the architecture from a security and privacy perspective.

Threat modeling consists of modeling the software components, data stores, trust boundaries, data flows, and external dependencies because the chances of identifying threats are greater if the software is modeled accurately.

There are four steps to threat modeling:

1. Prepare
What are we building?
Create architecture diagrams

2. Analyze
What can go wrong?
e.g. Map a STRIDE Model

3. Determine mitigations
What can we do about it?
Describe mitigations

4. Validate
Did we do it right?
Execute a retrospective activity

Threat modeling can also have different approaches, for example:

Asset-centric = Protect specific things
Attacker centric = Exploit weaknesses
Design-centric = Focus on system design

Threat modeling should be done early during the planning phase and updated later during development.

4. Third-Party Software Tracking

When? As early as possible
Who? Senior technical member/ technical lead

Leveraging third-party software can also introduce additional risks that need to be mitigated. Third-party software can be both open source and commercial use. The project team needs to keep an inventory of all third-party tools used in the project, as this will help ensure that all the tools used in the project have the latest security patches.

The inventory should be done as early as possible in the development cycle. Monitoring vulnerabilities have to be done by a senior technical member who can understand the vulnerabilities and a technical lead who will coordinate the deployment of security patches.

Third-party components can be tracked in a spreadsheet or database with application capabilities such as versioning, patched level, vulnerability fixes, project dependencies, etc. There are some tools that will give you an alert if any of your tools need an upgrade. Some companies are required to keep track of third-party software for financial and legal licensing reasons as well.

5. Secure Build

a) Security Design Review

When? During design and implementation
Who? Development team
Goal: Make sure the software is built with the most secure flags

Security design applies to individual features created by the development team. These features can correspond to respective user stories. The security design review can be done at the same time as the functional feature design, for example:

Functional feature design review: Will this feature work as expected?
Security design review: How can this feature be abused? “Think like a hacker.”

A common strategy for Agile teams is to define an “Evil user story,” which corresponds to each user story for certain features.

b) Peer Code Review

When? During implementation
Who? Development team
Goal: Make sure the software is built with the most secure flags

Security checks should be part of the code review. These can be done by training developers on common coding security pitfalls and providing a secure coding checklist.

Examples of security code review checks may include the following:

• Are important security events logged?
• If authentication is required, can it be bypassed?
• Does the software dump user passwords in logs?
• Is user input properly validated?
• Does the software properly release sources like memory, system handles, and ports that aren’t needed anymore?

Functional code review can also help to discover security issues, for example, improper logging and memory and process synchronization.

6. Security Testing and QA

In the software development cycle, code review and QA mostly focus on being functional to make sure that the software is doing what it is supposed to do. However, security testing means testing with a hacker’s perspective.

Security testing can be done manually or automatically through the use of tools, or a combination of both. Before security testing, threat modeling, design reviews, and user stories must be done.

Security testing includes static and dynamic analysis, vulnerability scanning, fuzzing, third-party penetration testing, fault injections, and others.

In this article, we’ll focus on the following:

a) Static Analysis

When? During development and testing
Who? Developers, QA, or security expert

Static application security testing or SA is the analysis of software that is performed without executing programs. It can be performed on source code and on object code. SA is a white-box testing technique that has full access to the possible behaviors of the software.

Some of the advantages include:

• Can identify exact locations of weaknesses
• Allows quick fixes
• Reduces overall project cost by finding weaknesses earlier
• Can be done by a QA engineer who understands the code.

Static analysis tools can help to look at the possible program flows to detect potential error conditions at runtime. It also helps to check if the code performs as designed and checks for coding best practices. Modern static analysis tools are getting better at finding security vulnerabilities in the source code.

Examples of security issues found by static analysis may include:

• Potential buffer overflow
• SQL injections
• Cross-site scripting (XSS)
• Use of unsafe functions

b) Dynamic Analysis

When? During development and testing
Who? Developers, QA, or security expert

Dynamic application security testing or DA is the analysis of software. This is done by executing programs on a real or virtual processor in real time. The goal is to find security errors in the program while it’s running. It can also help to ensure that the functionality of the program works as designed.

Some of the advantages of DA testing are:

• Can find infrastructure, configurations, and patch errors that SA tools might miss
• Identifies vulnerabilities in a runtime environment
• Validates the findings from SA tests
• Can be done on any application written in any language

c) Vulnerability Scanning

When? During development and testing
Who? Developers, QA, or security expert

Vulnerability scanning tools are used against running software. These tools usually work by injecting “malicious” inputs and observing how the software handles them. These types of tools are mostly used to scan applications with a web interface including REST and SOAP APIs. Vulnerabilities like XSS, SQL injections, and poor session management can be found during these scans. Some tools allow you to modify payloads in other to get a more accurate result.

d) Fuzzing

When? Towards the end of development and during the testing phase
Who? Developers, QA, or security expert

Fuzzing is a black-box testing technique that involves providing invalid, random unexpected data into a program. The goal is to test how well protocols and file formats are handled. In simpler terms, fuzzing finds security flaws or bugs by using malformed data injection.

Whenever a protocol or file format is involved in an application, there’s a chance of injecting harmful data. It’s very important to execute these tests because the incorrect handling of unexpected protocols and file formats can lead to Denial of Service attacks or even remote code execution.

Fuzzing can be done manually or by a tool. When it is done manually, the tester must tweak the protocol and file format, and observe the outcome. When fuzzing is done by a tool, the protocol or format definition needs to be provided to the tool in advance. Some strategies for fuzzing through the help of a tool include:

• Let the fuzzing tool generate random input
• Have the tester define the fuzzing space
• Have the tool try all possible tweaking

One of the biggest advantages of fuzzing is that the test design is very simple; its random approach allows you to find bugs that would often be missed by humans. Bugs found during fuzzing are usually severe and exploitable by an attacker.

e) Third-Party Penetration Testing (Optional)

When? At the end of the development and testing phase

Who? Third-party certified pen tester

Penetration testing is a security analysis in which the tester simulates the actions of a hacker. The goal is to discover coding errors, system configuration faults, and to uncover exploitable vulnerabilities and validate security features.

This test is performed by a skilled security professional. Being an individual who is independent of the team is a requirement for pen testing. This is why it is recommended to have a third-party external tester, as this will provide an “outside” perspective. This is very critical, especially for high-risk projects.

The key to a successful pen test is to always test the system from a hacker’s perspective!

7. Data Disposal and Retention

When? At the end of a product’s or feature’s life
Who? Developers and security expert/data expert

There are many motives for data disposal. They can vary from an old product that is no longer needed, to no further use of the data, a defective product, or no legal right to retain the data. One of the most used practices is “crypto-shredding,” which is the act of deleting or overwriting encryption keys. Getting rid of data is a huge challenge when there is concern about the confidentiality of the information. Making sure that the data has been properly deleted or overwritten is a very important part of the SDLC.

Some recent laws, regulations, and policies like GDPR have very specific requirements for data retention and disposal. Companies need to create their own data destruction policies with the help of an attorney to make sure they are compliant to the state laws and the regulations applicable according to their type of data and national/international data protection laws.

Conclusion

SDL is a process that standardizes security best practices and will help you to integrate security checkups throughout your development cycle, which will naturally result in building security by default.

If you are a developer, designer, or architect, I encourage you to read more about the other three essential pillars to secure software:

1. QA
2. Secure design principles
3. Security technologies

If you are a project manager thinking to establish an SDL in your team, I suggest starting by following the “Discovery” part mentioned earlier, and definitely start to create a security mindset in your team through security training and security awareness programs.

Happy software building!