Our Previous Secure Development Lifecycle Design and Methodology

We start this section by introducing the concept of overcoming the challenges of making software secure through the use of an SDL, as described in Core Software Security. Software security has evolved at a rapid pace since that book was published.

We will move quickly from a review of our previous design in this section to an approach better aligned with Agile methods and a design that is more appropriate for a DevOps environment throughout the remainder of the book.

Further discussions of the models, methodologies, tools, human talent, and metrics for managing and overcoming the challenges to make software secure can be found later in this book.

It should be noted that there is still a need for better static and dynamic testing tools and a formalized security methodology integrated into SDLCs that is within the reach of a majority of software development organizations. In the past decade or so, the predominant SDL models have been out of reach for all but the most resource-rich companies. Our goal in this book is similar to our previous book: to create an SDL based on leveraging resources and best practices rather than requiring resources that are out of reach for a majority of software security teams.

Overcoming Challenges in Making Software Secure

SDLs are the key step in the evolution of software security and have helped to bring attention to the need to build security into the SDLC. In the past, software product stakeholders did not view software security as a high priority. It was believed that a secure network infrastructure would provide the level of protection needed against malicious attacks. In recent history, network security alone has proved inadequate against such attacks. Users have been successful in penetrating valid authenticated channels through techniques such as cross-site scripting (XSS), Structured Query Language (SQL) injection, and buffer overflow exploitation. In such cases, system assets were compromised, and both data and organizational integrity were damaged. The security industry has tried to solve software security problems through stopgap measures. First came platform security (OS security), then network/perimeter security, and, now, application security. We need to defense-in-depth to protect our assets, but, fundamentally, it is a software security flaw and needs to be remediated through a software security approach (SDL) that tightly integrates and is organic to the SDLC developers’ use.

We might call this integration software security’s “SDLC approach,” or something like “developercentric security.” Whatever we term it, the critical concept is that an easily implementable SDL must support the development methods (SDLC) in use by developers. Ours constitutes an about-face from software security approaches that force developers to also learn and accommodate security approaches that conflict with their SDLC.

The SDL has, as its base, components that all of the activities and security controls needed to develop industry and government compliant as well as best practices hardened software. A knowledgeable staff, along with secure software policies and controls, is required in order to truly prevent, identify, and mitigate exploitable vulnerabilities within developed systems.

Not meeting the least of these activities found within the secure SDLC provides an opportunity for the misuse of system assets from both insider and outsider threats. Security is not simply a network requirement, it is now an information technology (IT) requirement, which includes the development of all software for the intent to distribute, store, and manipulate information. Organizations must implement the highest standards of development in order to ensure the highest quality of products for its customers and the lives that they protect.

Implementation of an SDLC program ensures that security is inherent in good enterprise software design and development, not an afterthought later in production. Taking an SDLC approach yields tangible benefits such as ensuring that all software releases meet minimum security criteria, and that all stakeholders support and enforce security guidelines. The elimination of software risk early in the development cycle, when vulnerabilities are easier and less expensive to fix, provides a systematic approach for information security teams to collaborate with during the development process.

Mapping the Security Development Lifecycle (SDL) to the Software Development Life Cycle (SDLC)

Whatever form of SDL you use, whether it is one that already exists, one you developed yourself, or a combination of both, you must map it to your current SDLC to be effective. Figure 1.4 (formerly Figure 2.4) is an SDL activity and best practices model that the authors have developed and mapped to the typical SDLC phases. Each SDL activity and best practice is based on real-world experience, and examples from the authors show the reader that security can be built into each of the SDLC phases—a mapping of security to the SDLC, if you will. If security is built [as a core part of development tasks], then the software has a higher probability of being secure by default, and later software changes are less likely to compromise overall security. Another benefit of this mapping is that you will have presumably worked with the owner(s) and stakeholders of the SDL, which will serve to build buy-in, efficiency, and achievable security in both the operational and business processes of the SDLC and will include the developers, product and program managers, business managers, and executives. (As stated previously, the model in Figure 1.4 is based on the years of experience, research, and stakeholder/customer interaction shared between the authors in the field of software and information security.)

Each phase of the SDL in Figure 1.4 was described in great detail in Core Software Security and was broken up as shown in Figures 1.5-1.10 below.

 
Source
< Prev   CONTENTS   Source   Next >