Software development methodologies have been in existence for decades, with new versions being developed to capitalize on advances in teamwork and group functionality. While security is not itself a development methodology, it has been shown by many groups and firms that security functionality can be added to a development lifecycle, creating a secure development lifecycle. While this does not guarantee a secure output, including security in the process used to develop software has been shown to dramatically reduce the defects that cause security bugs.

Secure Development Lifecycle

The term “secure development lifecycle” (SDL) comes from adding security to a software development lifecycle to reduce the number of security bugs in the software being produced. There are a wide range of different software development lifecycle models in use today across software development firms. To create a secure development lifecycle model, all one has to do is add a series of process checks to enable the development process to include the necessary security elements in the development process. The elements that are added are the same, although the location and methodology of adding the new elements to the process are dependent upon the original process.

Principles

In Chapter 1, we examined the specifics of a number of security principles that form the foundation of security. The objective of a secure development lifecycle model is to provide a foundation where the principles of security can be used and instantiated in the software being developed. Ensuring that both the security tenets and design principles are considered and addressed throughout the development process is one of the main goals of the SDL. Details of the tenets and principles are covered in Chapter 1.

One of the principles that applies to both the specifications for the software development process and the software itself is the acronym SMART. SMART stands for Specific, Measurable, Attainable, Realistic, and Time bound. These are all important and valid considerations, both with respect to the software development process and the software being developed. Failures in development can typically be traced back to one of these elements.

Security vs. Quality

Quality has a long history in manufacturing and can be defined as fitness for use. Quality can also be seen as absence of defects. Although this may seem to be the same thing as security, it is not, but they are related. Software can be of high quality and free of defects and still not be secure. The converse is the important issue; if software is not of high quality and has defects, then it is not going to be secure. Because a significant percentage of software security issues in practice are due to basic mistakes where the designer or developer should have known better, software quality does play a role in the security of the final product. Ross Anderson, a renowned expert in security, has stated that investments in software quality will result in a reduction of security issues, whether the quality program targets security issues or not.

Figure 4-1 illustrates some of the common issues associated with software quality versus security issues. If the product has quality but lacks security, then the result is a set of vulnerabilities. If the software is secure but is lacking in quality, then undocumented features may exist that can result in improper or undesired behaviors. The objective is to have both quality and security in the final output of the SDL process.

FIGURE 4-1 Software security vs. quality

Security Features != Secure Software

A common misconception is when someone confuses security features with secure software. Security features are elements of a program specifically designed to provide some aspect of security. Adding encryption, authentication, or other security features can improve the usability of software and thus are commonly sought after elements to a program. This is not what secure development is about. Secure software development is about ensuring that all elements of a software package are constructed in a fashion where they operate securely. Another way of looking at this is the idea that secure software does what it is designed to do and only what it is designed to do. Adding security features may make software more marketable from a features perspective, but this is not developing secure software. If the software is not developed to be secure, then even the security features cannot be relied upon to function as desired. An example of this was the case of the Debian Linux random-number bug, where a design flaw resulted in a flawed random-number function which, in turn, resulted in cryptographic failures.

Secure Development Lifecycle Components

SDLs contain a set of common components that enable operationalization of security design principles. The first of these components is a current team-awareness and education program. Having a team that is qualified to do the task in an SDL environment includes security knowledge. The next component is the use of security gates as a point to check compliance with security requirements and objectives. These gates offer a chance to ensure that the security elements of the process are indeed being used and are functioning to achieve desired outcomes. Three sets of tools—bug tracking, threat modeling, and fuzzing—are used to perform security-specific tasks as part of the development process. The final element is a security review, where the results of the SDL process are reviewed to ensure that all of the required activities have been performed and completed to an appropriate level.

Software Team Awareness and Education

All team members should have appropriate training and refresher training throughout their careers. This training should be focused on the roles and responsibilities associated with each team member. As the issues and trends associated with both development and security are ever changing, it is important for team members to stay current in their specific knowledge so that they can appropriately apply it in their work.

Security training can come in two forms: basic knowledge and advanced topics. Basic security knowledge, including how it is specifically employed and supported as part of the SDL effort, is an all-hands issue and all team members need to have a functioning knowledge of this material. Advanced topics can range from new threats to tools, techniques, etc., and are typically aimed at a specific type of team member (i.e., designer, developer, tester, project manager). The key element of team awareness and education is to ensure that all members are properly equipped with the correct knowledge before they begin to engage in the development process.

Gates and Security Requirements

As part of the development process, periodic reviews are conducted. In an SDL, these are referred to as gates. The term “gate” is used, as it signifies a condition that one must pass through. To pass the security gate, a review of the appropriate security requirements is conducted. Missing or incomplete elements can prevent the project from advancing to the next development phase until these elements or issues are addressed. This form of discipline, if conducted in a firm and uniform manner, results in eventual behavior by the development team where the gates are successfully negotiated as a part of normal business. This is the ultimate objective; the inclusion of security is a part of the business process.

Bug Tracking

Bug tracking is a basic part of software development. As code is developed, bugs are discovered. Bugs are elements of code that have issues that result in undesired behaviors. Sometimes, the behavior results in something that can be exploited, and this makes it a potential security bug. Bugs need to be fixed, and hence, they are tracked to determine their status. Some bugs may be obscure, impossible to exploit, and expensive to fix; thus, the best economic decision may be to leave them until the next major rewrite, saving cost now on something that is not a problem. Tracking all of the bugs and keeping a log so that things can be fixed at appropriate times are part of managing code development.

Security bug tracking is similar to regular bug tracking. Just because something is deemed a security bug does not mean that it will always be fixed right away. Just as other bugs have levels of severity and exploitability, so do security bugs. A security bug that is next to impossible to exploit and has a mitigating factor covering it may not get immediate attention, especially if it would necessitate a redesign. Under these circumstances, the security bug could be left until the next update of the code base.

There are many ways to score security bugs; a common method is based on the risk principle of impact (damage) times probability of occurrence. The DREAD model addresses this in a simple form:

Risk = Impact * Probability

Impact = (DREAD)

»   Damage

   Note that Damage needs to be assessed in terms of Confidentiality, Integrity, and Availability

»   Affected Users (How large is the user base affected?)

Probability = (DREAD)

»   Reproducibility (How difficult to reproduce? Is it scriptable?)

»   Exploitability (How difficult to use the vulnerability to effect the attack?)

»   Discoverability (How difficult to find?)

Measuring each of the DREAD items on a 1 to 10 scale, with 1 being the least damage or least likely to occur and 10 being the most damaging or likely to occur, provides a final measure that can be used to compare the risk associated with different bugs.

One of the problems with scoring bugs has to do with point of view. A developer may see a particular bug as hard to exploit, whereas a tester viewing the same bug from a different context may score it as easy to exploit. Damage potential is also a highly context-sensitive issue. This makes detailed scoring of bugs subjective and unreliable. A simple triage method based on a defined set of severities—critical, important, moderate, and low—will facilitate a better response rate on clearing the important issues. A simple structure such as this is easy to implement, difficult for team members to game or bypass, and provides a means to address the more important issues first.

This brings us to the topic of bug bars. A bug bar is a measurement level that, when exceeded, indicates that the bug must be fixed prior to delivering the product to customers. Bugs that come in below the bar can wait until a later date for fixing. Bug bars are an important tool for prioritizing fixes while maintaining a level of code security. Any bug that exceeds the bar must be addressed in the current release, thus making bug fixes an issue based on risk, not ease of closure.

Threat Modeling

Threat modeling is a design technique used to communicate information associated with a threat throughout the development team. The threat modeling effort begins at the start of the project and continues throughout the development effort. The purpose of threat modeling is to completely define and describe threats to the system under development. In addition, information as to how the threat will be mitigated can be recorded. Communicating this material among all members of the development team enables everyone to be on the same page with respect to understanding and responding to threats to the system.

Threat modeling begins as a team effort, where multiple team members with differing levels of experience and expertise examine a design with respect to where it can be attacked. Threat modeling is best performed during the application design phase, as it is easier to make application changes before coding. It is also less costly than adding mitigations and testing them after code has been implemented and onwards.

The threat modeling process is designed around the activities performed as part of the software development process. Beginning with examining how the data flows through the system provides insight into where threats can exist. Beginning at the highest level, and typically using data flow diagrams, the threat model effort is focused on how data moves through an application. The elements that require attention include

•   The application as a whole

•   Security and privacy features

•   Features whose failures have security or privacy implications

•   Features that cross trust boundaries

Close attention can be paid to the point where data crosses trust boundaries. At each location, a series of threats is examined. Microsoft uses the mnemonic STRIDE to denote the types of threats.

As the threat model is constructed, the information about threats, their source, the risk, and mitigation methods are documented. This information can be used throughout the development process. Keeping the concept of threats, vulnerabilities, and risk up front in the developers’ minds as they work results in software where the number and severity of vulnerabilities are reduced.

Fuzzing

Fuzzing is a test technique where the tester applies a series of inputs to an interface in an automated fashion and examines the outputs for undesired behaviors. This technique is commonly used by hackers to discover unhandled input exceptions. The concept is fairly simple: For each and every input to a system, a test framework presents a variety of inputs and monitors the results of the system response. System crashes and unexpected behaviors are then examined for potential exploitation. Two different kinds of inputs can be presented: random and structured. Random inputs can find buffer overflows and other types of input vulnerabilities. Structured inputs can be used to test for injection vulnerabilities, cross-site scripting, and input-specific vulnerabilities such as arithmetic overflow conditions. The two can be used together to manipulate payloads via buffer overflows.

Fuzzing frameworks can present two different forms of inputs: mutation or generation based. Mutation-based input streams use samples of existing data, mutating them into different forms. Generation-based input streams create input streams based on models of the system. Fuzzing is frequently connected to other forms of testing, as in white box and black box testing. Fuzzing has also been responsible for finding a large number of vulnerabilities in software. The reasons for this are twofold: First, it is relatively easy to set up a large number of tests, and second, it attacks the data input function, one of the more vulnerable points in software.

Security Reviews

Adding a series of security-related steps to the SDL can improve the software security. But as the old management axiom goes, you get what you measure, so it is important to have an audit function that verifies that the process is functioning as desired. Security reviews operate in this fashion. Sprinkled at key places, such as between stages in the SDL, the purpose of these reviews is not to test for security, but rather to examine the process and ensure that the security-related steps are being carried out and not being short-circuited in order to expedite the process. Security reviews act as moments where the process can be checked to ensure that the security-related elements of the process are functioning as designed. It may seem to be a paperwork drill, but it is more than that. Security reviews are mini-audit type events where the efficacy of the security elements of the SDL process is being checked.

Mitigations

Not all risks are created equal. Some bugs pose a higher risk to the software and need fixing more than lesser risk-related bugs. Use of a system such as DREAD in the gating process of bug tracking informs us of the risk level (Risk = Impact * Probability) associated with which bugs pose the greatest risk and therefore should be fixed first. The mitigation process itself defines how these bugs can be addressed.

When bugs are discovered, there is a natural tendency to want to just fix the problem. But as in most things in life, the devil is in the details, and most bugs are not easily fixed with a simple change of the code. Why? Well, these errors are caught much earlier and rooted out before they become a “security bug.” When a security bug is determined to be present, four standard mitigation techniques are available to the development team:

1.   Do nothing

2.   Warn the user

3.   Remove the problem

4.   Fix the problem

The first, do nothing, is a tacit acknowledgment that not all bugs can be removed if the software is to ship. This is where the bug bar comes into play; if the bug poses no significant threat (i.e., is below the critical level of the bug bar), then it can be noted and fixed in a later release. Warning the user is in effect a cop-out. This pushes the problem on to the user and forces them to place a compensating control to protect the software. This may be all that is available until a patch can be deployed for serious bugs or until the next release for minor bugs. This does indicate a communication with the user base, which has been shown to be good business, for most users hate surprises, as in when they find out about bugs that they feel the software manufacturer should have warned them of in advance.

Removing the problem is a business decision, for it typically involves disabling or removing a feature from a software release. This mitigation has been used a lot by software firms when the feature was determined not to be so important as to risk an entire release of the product. If a fix will take too long or involve too many resources, then this may be the best business recourse. The final mitigation, fixing the problem, is the most desired method and should be done whenever it is feasible given time and resource constraints. If possible, all security bugs should be fixed as soon as possible, for the cascading effect of multiple bugs cannot be ignored.

Software Development Models

Professional software development is a methodical and managed process. It is a team effort that begins with requirements, and then through a process of orchestrated steps, designs, implements, and tests the software solution to the requirements. Many different methodologies are employed to achieve these objectives. The most common methodologies are variants of the following basic models:

•   Waterfall model

•   Spiral model

•   Prototype model

•   Agile model

In today’s environment, most firms have adopted a variant of one or more of these models that are used to guide the development process. Each model has its strengths and weaknesses, as described in the following sections.

Waterfall

The waterfall model is a development model based on simple manufacturing design. The work process begins and progresses through a series of steps, with each step being completed before progressing to the next step. This is a linear, sequential process, without any backing up and repeating of earlier stages. Depicted in Figure 4-2, this is a simple model where the stages of requirements precede design and design precedes coding, etc. Should a new requirement “be discovered” after the requirement phase is ended, it can be added, but the work does not go back to that stage. This makes the model very nonadaptive and difficult to use unless there is a method to make certain that each phase is truly completed before advancing the work. This can add to development time and cost. For these and other reasons, the waterfall model, although conceptually simple, is considered by most experts as nonworkable in practice.

FIGURE 4-2 Waterfall development model

The waterfall methodology is particularly poorly suited for complex processes and systems where many of the requirements and design elements will be unclear until later stages of development. It is useful for small, bite-sized pieces, and in this manner is incorporated within other models such as the spiral and agile methods.

Spiral

The spiral model is an iterative model for software development. As shown in Figure 4-3, the process operates in a spiral fashion, where specific process steps can be repeated in an iterative fashion. This model stems from a prototyping mentality, where things are built in increments, adding functionality with each trip through the process steps. The spiral model can include many different elements in each cycle, and the level of detail is associated with the aspect and context of application. Documentation is created as the process occurs, but only the documentation for the current work. Risk analysis can be applied at each cycle, both to the current and future iterations, thus assisting in planning.

FIGURE 4-3 Spiral development model

The spiral model is suited for larger projects, although a large project may consist of several interconnected spirals, mainly to keep scope manageable in each group. A smaller-scale version of the spiral model can be seen in some of the agile methods, which will be presented in a later section.

Prototype

Just as the waterfall model can trace its roots to manufacturing, so can prototyping. A prototype is a representative model designed to demonstrate some set of functionality. In the software realm, this could be mockups of user input screens or output functions. Prototyping comes in two flavors: throwaway and evolutionary. In throwaway prototyping, a simulation is constructed to gain information on some subset of requirements. Mocking up user input screens is a form of prototyping, one that can gain valuable user feedback into the design process.

In evolutionary prototyping, a mockup that provides some form of functionality is created, allowing testing of the designed functionality. Should the design pass, then other elements can be added, building the system in a form of accretion. Prototyping can also be either horizontal or vertical in nature. A vertical prototype is a stovepipe-type element, such as a data access function to a database. This allows exploration of requirements and design elements in a limited working environment.

A horizontal prototype is more of a framework or infrastructure. This is also commonly used in software development, as most major software is modular in nature and can work well in a defined framework, one that can be tested and explored early in the development process via a prototype.

Prototyping can work well in conjunction with other incremental development methodologies. It can work inside the spiral model and as part of an agile development process. One of the primary reasons for prototyping is to reduce risk. By limiting early resource expenditure while obtaining a model that allows testing of major design elements and ideas, prototyping enables better risk management of complex development processes.

Agile Methods

Agile methods are not a single development methodology, but a whole group of related methods. Designed to increase innovation and efficiency of small programming teams, agile methods rely on quick turns involving small increases in functionality. The use of repetitive, small development cycles can enable different developer behaviors that can result in more efficient development. There are many different methods and variations, but some of the major forms of agile development are

•   Scrum

•   XP (extreme programming)

XP is built around the people side of the process, while scrum is centered on the process perspective.

Additional agile methods include methods such as Lean and Kanban software development, Crystal methodologies (aka lightweight methodologies), dynamic systems development method (DSDM), and feature-driven development (FDD). The key to securing agile methods is the same as any other methodology. By incorporating security steps into the methodology, even agile can be a secure method. Conversely, any methodology that ignores security issues will not produce secure code.

Scrum

The scrum programming methodology is built around a 30-day release cycle. Highly dependent upon a prioritized list of high-level requirements, program changes are managed on a 24-hour and 30-day basis. The concept is to keep the software virtually always ready for release. The master list of all tasks is called the product backlog. The 30-day work list is referred to as a sprint, and the daily accomplishment is called the burn-down chart.

From a security perspective, there is nothing in the scrum model that prevents the application of secure programming practices. To include security requirements into the development process, they must appear on the product and sprint backlogs. This can be accomplished during the design phase of the project. As additions to the backlogs can occur at any time, the security team can make a set of commonly used user stories that support required security elements. The second method of incorporating security functionality is through developer training. Developers should be trained on security-related elements of programming, such as validating user input, using only approved libraries, etc.

The advantage of scrum is quick turns of incremental changes to a software base. This makes change management easier. There is nothing about the scrum model that says developers do not have the same level of coding responsibility that is present in other models. There are limitations in the amount of planning, but in a mature agile environment, the security user stories can be already built and understood. The only challenge is ensuring that the security elements on the product and sprint backlogs get processed in a timely manner, but this is a simple management task. Security tasks tend to be less exciting than features, so keeping them in the process stack takes management effort.

XP

Extreme programming is a structured process that is built around user stories. These stories are used to architect requirements in an iterative process that uses acceptance testing to create incremental advances. The XP model is built around the people side of the software development process and works best in smaller development efforts. Like other agile methods, the idea is to have many incremental small changes on a regular time schedule. XP stresses team-level communication, and as such, is highly amenable to the inclusion of security methods.

One of the hallmarks of XP methods is the use of feedback in a team environment to manage the three-step process of release planning/iteration/acceptance testing. New user stories can (and are) introduced through this feedback mechanism, as well as reports of bugs. Security can be included in the programming model in several ways. First, it can be done through a series of security requirements, proposed as user stories and run along with all of the other requirements. Second, programmers can use appropriate programming practices, such as the use of approved functions and libraries, approved design criteria, validate all inputs and outputs, etc. In this respect, XP programmers have the same level of responsibilities as do all other programmers in other development methodologies. Last, the concept of abuser stories has been proposed and is used by some teams to examine security-specific elements and ensure their inclusion in the development process. Abuser stories are similar to user stories, but rather than listing functionalities desired in the software, they represent situations that need to be avoided.

Open Source

Open source is less of a development model and more of a philosophy. The concept behind open source is the idea of sharing applied to software development. If a parser that provides the needed functionality for your project already exists and has open-source licensing, then it makes more sense to adopt that methodology than to reinvent the wheel on one’s own limited resource base.

Microsoft Security Development Lifecycle

Microsoft’s Security Development Lifecycle (SDL) is a software development process that is designed to enable development teams to build more secure software and address security compliance requirements. It has an added benefit of reducing development costs when total lifecycle costs are measured and improves customer experience with the software. The SDL is built using a series of specific proven security factors that can be used in virtually any development effort, regardless of methodology or size. The SDL is designed to focus effort on producing software that is secure, not software that performs security or has specific security features. Security features such as BitLocker, Kerberos authentication, or Address Space Layout Randomization (ASLR) are not what the SDL is about. SDL is designed to achieve two objectives:

•   Reduce the number of security vulnerabilities in a product

•   Reduce the severity of security vulnerabilities that remain in a product

History

In 2002, Microsoft initiated security pushes on several different development teams, which led to the formation of the Trustworthy Computing (TwC) team. The TwC team formed the concepts and processes that became mandatory across Microsoft in 2004. One of the first major elements of the Microsoft security effort was the definition of the Secure by Design, Secure by Default, Secure in Deployment and Communications (SD3+C) program. This initiative helped everyone become familiar with determining where security and privacy efforts are needed and working together as a team to achieve this.

The SDL is reviewed and revised as necessary on a semiannual basis. Viewed as a strategic business investment, the SDL has matured into a way of life throughout the organization. As the effort matured, Microsoft has released guidance and tools associated with the SDL to the public via the Web to assist others in improving their own development efforts.

SDL Foundation

The foundation of the SDL is built around the elements of the SD3+C program, expanded to include privacy in addition to security. Using both security and privacy as a lens at the critical points of design, default settings, deployments, and communications can provide clarity as to a team’s direction.

By Design

By design refers to the incorporation of security thinking as part of the design process. This includes working to design a secure architecture and structure for the software. It is important that designers consider security issues part of the basic architectural design of software development. Reviewing detailed designs for security issues and developing mitigations for all identified threats as part of the design process can greatly improve security. These elements are communicated to the rest of the team via the threat model document. For known security vulnerability types, such as SQL injection, architecture and design can mitigate much of the potential vulnerability associated with these issues. Paying attention to legacy code, protocols, and deprecating elements that are no longer secure is an important function of the design process. Designing in defense in depth so that single mitigating elements are not relied upon to protect important information improves the resilience of the software.

Privacy can be enabled through designing in elements of end-user control, enabling end users to make informed decisions about the data that is collected, stored, or shared so they can make informed decisions about their personal information. Minimizing both data collection and retention to what is required protects both from privacy issues and limits exposure if data is disclosed at a later time. Designing in controls to allow parents and/or enterprises to manage settings associated with privacy enables better control over privacy-related elements.

Ensuring that any sensitive data that is collected and retained is properly encrypted whenever it is in storage or in transit mitigates potential data loss issues. Designing in proper cryptographic libraries and functions can protect the system from cryptographic failures. It is important to design the use of cryptographic functions in a modular fashion so that if a particular method or algorithm needs to be changed, it can be done without redesigning the entire program. Designing in proper key protection mechanisms prevents strong cryptographic systems from failing due to lost or stolen keys.

The bottom line on design is simple. Designing in as many security principles as possible, defense in depth, least privilege, minimizing attack surface, etc., is the best method of ensuring the best security levels in the final software. Design forms the foundation for implementation and testing, and success or failure is many times determined at this early stage.

By Default

By default refers to ensuring that the default configuration of the software is, by design, as secure as possible. In the past, the “turn it all on” design idea made it easier for software to be used, but it also revealed numerous vulnerabilities that could be exploited. As software has become more complex, especially with regard to functions and options, limiting what is on by default has become an important security feature. Users can enable only the desired functions and services, integrating them into their overall security plan. Privilege level is another issue that needs to be addressed. Software should operate at elevated privilege levels only when specifically required. Excess permissions or excessive levels of permissions are contributing factors to increased severity of bugs.

The attack surface of the software is a measure of the potential points where an attacker can attack a piece of software. Minimizing the attack surface is a design principle, and the default configuration should represent this minimum. Changes to this minimum should include user notification so that the user can make appropriate security decisions concerning the environment of the deployed software to ensure the desired level of security. When system changes are made, it is important to inform the user. Opening a bunch of firewall ports may be necessary for the operation of the software; however, doing so without informing the user so they can make appropriate plans may create situations where users are out of compliance on issues they could have resolved had they been informed.

Many software programs use services or daemons to accomplish functions. The default state for these elements should also be considered, with seldom-used elements not being activated. Activation upon use is one solution, and forcing manual activation for others should be considered. Deciding what elements are running by default should be a conscious decision, one made with security as one of the consideration factors.

Elements that impact privacy should also be considered when determining default settings. Including privacy as part of the default configuration discussion will lead to software that has fewer issues once deployed. Consideration of security and privacy settings when creating default configurations is not designed to limit the end-user ability, but rather to protect security and privacy, and when changes are required, enable the end user to understand the implications of the decisions.

In Deployment

Deployment is one of the last major touchpoints where software configurations and settings are routinely modified before use. Ensuring that security and privacy elements are properly understood and managed through the deployment process is essential. Developing prescriptive deployment guides that detail how to deploy each feature, the implications of deploying it, and the options available to the user provides the users with the necessary information where they can make an informed choice. This will enable them to integrate the software within an existing security framework, helping them help themselves when it comes to securing an entire enterprise.

All software eventually requires patching or upgrades. Embracing this and building it into the deployment configuration will help users maintain their software environment. Providing patching and upgrade solutions that give users total control over their software operations and maintenance processes improves the usability of security- and privacy-related elements.

Communications

In any team environment, communications are critical to teams working in a cohesive and effective manner. Creating efficient communication channels between the security response function and the development team is essential if security issues are to be corrected through patches and future releases. Creating a communication channel where all elements of the development team are connected to information sources, such as through end-user issues and reports, provides for a more effective development environment.

Communicating with end users is also critical. Whenever the security configuration of the software or system is going to change, it is critical to communicate with the user the nature of the change and provide the necessary information so that the user can make appropriate security decisions. This results in two specific results. First, the user base can become actively engaged in the security solution, avoiding preventable security incidents. Second, this improves usability and creates greater long-term value through reduced administrative costs.

Communication via media and trade outlets to both customers and prospective customers can create value, as it can help others to understand strategies and tactics associated with the software and security. White papers and other communications can provide transparency in the design process and improve the effectiveness of the security effort, reducing concerns and issues from customers and potential customers. Open communications have been shown to not increase risk, but rather to lower it through increased cooperative and coordinated efforts.

SDL Components

Begun in 2002, the Microsoft journey to enterprise use of an SDL has been a journey marked by change, improvement, and adaptation. As illustrated in Figure 4-4, the SDL operationally consists of seven phases: training, requirements, design, implementation, verification, release, and response. Regularly updated, the individual elements associated with the major phases are kept fresh, current, and effective. The objective is not to just increase the security process, but also to focus its efforts on the key elements under each phase.

FIGURE 4-4 Microsoft SDL

Training

The Microsoft SDL has a strong dependence on training. There is security training for all personnel, targeted to their responsibility associated with the development effort. From designers to architects, project managers to executives, everyone receives regular security training to equip them with the knowledge associated with their responsibilities. This is not a small effort, but it is one of the strengths of the SDL, in that all of the players are specifically trained to incorporate security-related thinking in their daily tasks.

Microsoft security training consists of several types of training. Core security training is a prerequisite for all team members and provides basic knowledge of the foundational concepts for secure development, including secure design, threat modeling, secure coding, security testing, and best practices associated with protecting privacy. On top of the core training are specialized modules that focus in depth on issues associated with specific job tasks and responsibilities. The final set of training is associated with new developments and practices. Just as the IT world is constantly shifting, so is security, and elements may begin as special topics and eventually become part of the core if the implementation aspect becomes mainstream. Microsoft continually updates its training offerings and has training-hour requirements associated with different jobs.

Requirements

The requirements process is the best time to plan and consider the fundamental security and privacy aspects of software. It is during this planning and requirement-gathering activity that the development team establishes several key elements to be used through the remainder of the development process. These elements are

•   The establishment of the security and privacy requirements for the software

•   The creation of quality gates and bug bars

•   The development of security and privacy risk assessments for the software

These tasks are not done in isolation, but rather are built upon an existing set of criteria that has been used in previous projects. The continual adaptation and improvement of these elements have led to stronger security and privacy in an achievable production setting.

Design

The design phase is where best practices associated with design and functional requirements are used to create a secure design. Risk and privacy analyses are performed to ensure that security and privacy issues are thoroughly mitigated by design. The use of attack surface reduction techniques and threat modeling is used to improve design coverage against known and potential threats.

Implementation

The implementation, or coding, phase is the straightforward application of secure coding practices in a programming language to achieve design objectives. The use of approved languages, functions, and libraries is paramount, with the removal of deprecated functions and recoding of legacy code as required. The use of static program checkers to find common errors is intended to ensure coding standards are maintained.

Verification

The verification, or testing, phase is where dynamic testing enters, testing the code for known and potential sources of vulnerabilities. A review of the attack surface is performed, verifying the as-built model matches the design goals. The use of fuzz testing against all inputs is performed to cycle through large numbers of input conditions to ensure resilience.

Release

The release phase is where the software is prepared for and ultimately released to end users and customers. This phase must prepare the organization for potential issues coming in from the field, and includes the preparation of the incident response plan to be used in the response phase. A final check to ensure that all security-related activity was performed and done so properly occurs prior to release. This is not a product testing effort, but rather a process check to ensure that all of the security elements associated with the SDL were properly completed and documented. With these steps complete, the code can be archived and released.

Response

The response phase is marked by the collection of error reports and handling per the release-based incident response plan. This may include the passing of information back to the development team for bug fixes or the documentation of elements for future releases. The response phase acts as a conduit between reported issues and the development team, both for the current release through patches and for future releases through mitigation efforts.

Chapter Review

This chapter began with an examination of the concepts behind creating a secure development lifecycle. An examination of how the security principles presented in Chapter 1 can be incorporated into the software development process was presented, as well as an examination of the relationship between security and quality in software. The issue of not confusing security features with the objectives of secure development were covered. An examination of the common elements of a secure development lifecycle process—training and education, security gates, bug tracking, threat modeling, fuzz testing, and security reviews—was presented.

An examination of the common software development models and how security can be incorporated into them was presented. The chapter ended with a discussion of the elements associated with the mature Microsoft SDL model.

Quick Tips

•   A secure development lifecycle is one where security tenets and design principles are built into the process of the development model.

•   Adding security features to software is not secure development.

•   All development team members should have appropriate security training.

•   The inclusion of security processes in the development process occurs at security gates.

•   Bugs should be measured and tracked as part of the secure development process.

•   Threat modeling is a major tool for understanding threats and mitigation actions in the development process.

•   Fuzz testing should be used against all inputs in the software.

•   Security tenets can be included in all development models, including agile methods.

•   Microsoft has a well-documented and mature SDL that it freely shares to assist others in pursuit of secure development practices.

Questions

To further help you prepare for the CSSLP exam, and to provide you with a feel for your level of preparedness, answer the following questions and then check your answers against the list of correct answers found at the end of the chapter.

1.   Creating a secure development lifecycle involves:

A.   Adding security features to the software

B.   Including threat modeling

C.   Training coders to find and remove security errors

D.   Modifying the development process, not the software product

2.   A software product that has security but lacks quality can result in:

A.   Exploitable vulnerabilities

B.   Undocumented features that result in undesired behaviors

C.   Poor maintainability

D.   Missing security elements

3.   Which of the following is not an attribute of an SDL process?

A.   Fuzz testing

B.   Bug bars

C.   Authentication

D.   Developer security awareness

4.   Periodic reviews to ensure that security issues are addressed as part of the development process are called:

A.   Security gates

B.   Security checklist

C.   Threat model

D.   Attack surface area analysis

5.   The term DREAD stands for:

A.   Damage potential, Recoverability, Exploitability, Asset affected, and Discoverability

B.   Damage potential, Reproducibility, Exploitability, Affected user base, and Discoverability

C.   Damage potential, Reproducibility, External vulnerability, asset Affected, and Discoverability

D.   Design issue, Reproducibility, Exploitability, Asset affected, and Discoverability

6.   The term STRIDE stands for:

A.   Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege

B.   Spoofing, Tampering, Reproducibility, Information disclosure, Denial of service, and Elevation of privilege

C.   Spoofing, Tampering, Reproducibility, Information disclosure, Discoverability, and Elevation of privilege

D.   Spoofing, Tampering, Repudiation, Information disclosure, Discoverability, and Elevation of privilege

7.   Which of the following describes the purpose of threat modeling?

A.   Enumerate threats to the software

B.   Define the correct and secure data flows in a program

C.   Communicate testing requirements to the test team

D.   Communicate threat and mitigation information across the development team

8.   A tool to examine the vulnerability of input interfaces is:

A.   Threat model

B.   Bug bar

C.   Attack surface analysis

D.   Fuzz testing framework

9.   A linear model for software development is the:

A.   Scrum model

B.   Spiral model

C.   Waterfall model

D.   Agile model

10.   User stories convey high-level user requirements in the:

A.   XP model

B.   Prototyping model

C.   Spiral model

D.   Waterfall model

11.   Bug bars are used to:

A.   Track bugs

B.   Score bugs

C.   Manage bugs

D.   Attribute bugs to developers

12.   SMART is an acronym for:

A.   Security, Measurable, Attainable, Realistic, and Threats

B.   Security, Measurable, Attributable, Realistic, and Training

C.   Specific, Measurable, Attainable, Realistic, and Time bound

D.   Specific, Measurable, Attributable, Realistic, and Training

13.   What is used to ensure that all security activities are being correctly carried out as part of the development process?

A.   Project manager judgment

B.   Security leads

C.   Security engineers

D.   Security reviews

14.   The objectives of an SDL are to achieve all of the following except:

A.   Reduce the number of security vulnerabilities in software

B.   Reduce the severity of security vulnerabilities in software

C.   Eliminate threats to the software

D.   Document a complete understanding of the vulnerabilities in software

15.   Which is the most common security vulnerability mitigation methodology used in design?

A.   Defense in depth

B.   Separation of duties

C.   Least privilege

D.   Auditability

Answers

1.   D. The creation of a secure development lifecycle process involves multiple changes to the development process itself, not the software.

2.   B. Poor quality can result in undocumented features that result in exploitable output conditions.

3.   C. Authentication is a security feature, not an attribute of secure development.

4.   A. Security gates are the points in the development cycle where proper security processes are checked for completion.

5.   B. The term DREAD refers to a manner of classifying bugs: Damage potential, Reproducibility, Exploitability, Affected user base, and Discoverability.

6.   A. The term STRIDE refers to sources of threats: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege.

7.   D. Threat modeling is a tool used to communicate information about threats and the mitigation procedures to all members of the development team.

8.   D. Fuzz testing is the application of a series of random inputs to an input interface to test for exploitable failures.

9.   C. The waterfall model for software development consists of linear steps progressing in just one way.

10.   A. User stories are associated with agile methods, typically XP.

11.   B. A bug bar is a measurement level that, when exceeded, indicates that the bug must be fixed prior to delivering the product to customers.

12.   C. SMART stands for Specific, Measurable, Attainable, Realistic, and Time bound.

13.   D. Security reviews act as moments where the process can be checked to ensure that the security-related elements of the process are functioning as designed.

14.   C. Elimination of threats is not possible from the development perspective.

15.   A. The use of multiple lines of defense, or defense in depth, is the most common mitigation technique and should be a design standard traced back to the results from the threat model.