Published on
This post was written by Chris Romeo during his tenure at Security Journey.
Customers demand secure products out of the box, so security should be a top priority that should be top of mind for everyone. But without a standard approach to security, it is almost impossible to deliver on the customers' expectations.
That's where the Secure Development Lifecycle (SDL) comes in.
SDL is a process. If you look at the many SDLs that exist across industries, you'll find that most include the same basic security phases and activities. They may have different names for the pieces, but everyone follows roughly the same process.Here's an essential guide to placing security front and center.
Defining the Secure Development Lifecycle
In its simplest form, the SDL is a process that standardizes security best practices across a range of products and/or applications. It captures industry-standard security activities, packaging them so they may be easily implemented. The software development lifecycle consists of several phases, which I will explain in more detail below.
The SDL was unleashed from within the walls of Microsoft, as a response to the famous Bill Gates memo of January 2002. In it Gates laid out the requirement to build security into Microsoft's products. He admitted that due to various virus and malware outbreaks, Microsoft had to embed security if it was to be taken seriously in the marketplace.
This resulted in the Microsoft Trustworthy Computing endeavor, out of which the idea of SDL was born. Microsoft made the SDL mandatory in 2004, and a cottage industry was unleashed. Many other companies, including Cisco, Adobe, and Aetna, have since adopted Microsoft's SDL processes or created their own. And Microsoft has been gracious over the years in sharing its SDL successes with other companies and releasing many of its materials and tools as open source.
The problems the SDL solves
The lack of a standard approach to securing products causes problems. For one thing, vulnerabilities run rampant in shipped products. The triage and response needed to deal with this are major resource sinks. As a result, developers spend too much time fixing code they wrote in the past and not enough focusing on the future.
The second problem is that developers tend to repeat the same security mistakes, each time expecting a different response (which is the definition of insanity). The third issue is that problems are found at release or after deployment, beyond the reasonable time when the problems could be mitigated in an inexpensive manner.
Finally, without a security standard customers have no assurance that a given product is secure. A single product considered for purchase may be one of the good ones, or it might be terrible from a security perspective. Without an SDL, there is no product security parity across the company. And without a standard process, some product teams ignore security altogether.
People, process, and technology
The SDL is a process with different phases that contain security activities that sits inside of the classic people-process-technology triangle. The SDL forms the process portion.
It includes both the central security team that governs the process and updates it and the product or development teams that perform security activities. The technology portion consists of tools that assist in finding vulnerabilities in source code or discovering vulnerabilities in a running instance of the product or application.
The SDL is methodology-neutral. Security activities fit within any product development methodology, whether waterfall, agile, or DevOps. Methodology differences show up in the cadence of security activities.
The SDL was developed during the time of waterfall, so it is usually portrayed as a linear process that begins with requirements and ends with the release. When the SDL is extended to agile, some security activities get integrated into the normal sprint schedule, while others are pursued out-of-band. With DevOps, activities are embedded into the build pipeline using automation, while additional activities happen outside the pipeline.
An SDL is divided into phases that tie closely into the waterfall approach. The standard approach to SDL includes requirements, design, implementation, test, and release/response.
The requirements phase
In the requirements phase, best practices for security are integrated into a product. These practices may come from industry standards or be based on responses to problems that have occurred in the past.
Requirements exist to define the functional security requirements implemented in the product, and include all the activities of the SDL. They are used as an enforcement point to ensure that all pieces are properly considered.
Requirements may take the classic form, stating that the product or application must, may, or should, do something. One example might be that the product must enforce a minimum password length of eight characters.
In the agile world, requirements are expressed as user stories. These stories contain the same information as do the requirements, but security functionality is written from the user's perspective.
The design phase
The design phase of the SDL consists of activities that occur (hopefully) prior to writing code. Secure design is about quantifying an architecture (for a single feature or the entire product) and then searching for problems. Secure design could occur in a formal document or on a napkin.
With many systems, the plane is in the air as the wings are being designed, but the SDL can survive even this craziness. The key is to use threat modeling.
Threat modeling is the process of thinking through how a feature or system will be attacked, and then mitigating those future attacks in the design before writing the code. Threat modeling is akin to perceiving crimes prior to their occurrence, as in the 2002 movie Minority Report.
A solid threat model understands a feature's or product's attack surface, then defines the most likely attacks that will occur across those interfaces. A threat model is only as good as the mitigations it contains to fix the problems. But it is crucial to identifying security issues early in the process.
Implementation or coding
The next phase is implementation, or writing secure code. The SDL contains a few things programmers must do to ensure that their code has the best chance of being secure. The process involves a mixture of standards and automated tools.
On the standards front, a solid SDL defines a secure coding guide (such as those published by SEI CERT for C, C++, and Java), that defines what is expected and provides guidance for when developers hit a specific issue and need insight.
Implementation tools include static application security testing (SAST) and dynamic application security testing (DAST) software. SAST is like a spell-checker for code, identifying potential vulnerabilities in the source code. SAST runs against a nightly build or may be integrated into your IDE. It may find and open new bugs in the bug management system nightly or prompt the developer to pause while coding to fix a problem in real time.
DAST checks the application's runtime instantiation. It spiders through an application to find all possible interfaces and then attempts to exploit common vulnerabilities in the application. These tools are primarily used on web interfaces.
The test phase
Formal test activities include security functional test plans, vulnerability scanning, and penetration testing. Vulnerability scanning uses industry-standard tools to determine if any system-level vulnerabilities exist with the application or product.
Penetration testing involves testers attempting to work around the security protections in a given application and exploit them. Pen testing stretches the product and exposes it to testing scenarios that automated tools cannot replicate. Pen testing is resource-intensive, so it's usually not performed for every release.
The final phase: Release/response
Release occurs when all the security activities are confirmed against the final build and the software is sent to customers (or made available for download). Response is the interface for external customers and security researchers to report security problems in products.
Part of the response should include a product security-incident response team that focuses on triaging and communicating product vulnerabilities, both individual bugs and those that will require industry-wide collaboration (e.g., Heartbleed, Bashbug, etc.).
Other security activities are also crucial for the success of an SDL. These include security champions, bug bounties, and education and training.
Think differently, think secure
The Secure Development Lifecycle is a different way to build products; it places security front and center during the product or application development process.
From requirements to design, coding to test, the SDL strives to build security into a product or application at every step in the development process. A modern application company cannot survive without getting serious about security, and the way to get serious is to integrate an SDL into your everyday work.
Read more from:
Research