The Security Development Lifecycle : Crawl Walk Run

Wrapping up "Walking" with the SDL

sdl — Wed, 30 Jul 2008 22:16:00 GMT

Jeremy Dallman here. Before we move on with our regularly-scheduled programming here at the SDL blog, I wanted to pull all of the “Walking with the SDL” blog posts into a single document to put it all together in another format. You can find that document here.

Hopefully the “Walking with the SDL” series provided some valuable guidance that will help you formalize your own Security Development Lifecycle. As always, we welcome your thoughts or questions in the COMMENT section of this blog. If you have specific questions that you would like to discuss with our team, you can use the EMAIL link at the top of the blog and we’ll be sure to reply.

"Walking" with the SDL - Part 4

sdl — Fri, 25 Jul 2008 23:49:00 GMT

Jeremy Dallman here with the final piece of my multi-part series on “Walking” with the Security Development Lifecycle (SDL) [Part 1, Part 2, Part 3]. So far I have discussed getting management approval, expanding security training, formalizing security requirements and effective ways to reuse your threat model or attack surface review data. In this post, I will wrap up with a look into setting up final security reviews and managing post-release documentation.

Formalize your Final Security Review (FSR) Process

A Final Security Review is your final security audit to ensure your software is secure enough to deliver to your customers. I will assume the idea of an FSR is a new concept and try to provide some FAQ-style detail on this topic.

Who is the FSR team? An FSR Team usually consists of a non-product-team security expert (for impartial perspective), a security representative from the product team, and individual representatives from the separate disciplines. However, that size team may not scale to your company. If that is the case, at a minimum, you should have an impartial “outsider” separate from the product team who understands the security requirements as well as the measurements used to validate them. This person along with a project manager can probably perform the bulk of the FSR with development or test leadership providing input as needed.

What is needed to do an FSR? All threat models should be revised to reflect the final product, the code should be complete, and all security-related testing should be completed and documented. In addition, everyone involved in the FSR should have full access to the bug database to review status or exceptions to security bugs.

What does an FSR team do?

Re-review threat models to verify all mitigations identified in those exercises were fixed or went through an exception process.
Verify that all security issues uncovered during the development process were fixed or granted exceptions by the appropriate people. This is where you verify whether the state of your security bugs meets the “bug bar” requirements you have defined for your products.
If there is any output from security tools that you have used to define requirements, the FSR team would verify that the results of the tools meet the security requirements.
Review all exceptions to verify that they approve these decisions in the context of the final product. If they identify risks associated with the exceptions, they should communicate those to the business ownership for a final decision before signoff. Any decisions related to known risks should also be reflected in the response plan for future reference.
Finally, there should be a final signoff exercise where all security people and project leadership jointly approve the decision of the Final Security Review.

How long does an FSR take? If done correctly, the FSR will likely take some time. You should schedule this review well in advance of your release date to give your FSR team some time to complete the review, push issues back to the product team, and respond to any serious issues that may be discovered.

Final security reviews are a crucial piece to your Security Development Lifecycle. It would be easy to encourage secure development in your team, but as you expand your process to include formal security requirements and begin enforcing those requirements, it is necessary to perform a final audit of your product before it is released. Your customers will thank you for taking the time to add this layer of quality control to your operations and you will likely save yourself some security embarrassment down the road by adding a FSR to the end of your product cycle.

Document security work for reference

After the FSR is complete, there is still work for the security team. The final FSR documentation should be archived along with the symbols and code that represents the finished project. This becomes the time-stamped “snapshot” of your product. Your post-release process should include archiving the following documents in an easily accessible location:

· All final threat models for future reference.

· Bug bars, tool settings, and test results related to your project and the supporting tools used to validate. These will be referenced and reused in the next product cycle.

· All documented security bug exceptions. These need to be rolled into your next product cycle to ensure they are addressed.

· The final symbols that reflect the product shipped should be archived.

· The Final Security Report and project signoffs to validate your security audit activity

· Your Incident Response Plan (discussed in the Crawl post). This must be accessible for quick reference if security incidents occur.

Archiving this evidence serves a few critical purposes: it shows historic evidence of the work you did to ensure a secure product, allows you to postmortem the results and improves your process each time, and reduces the amount of time your team will have to spend next time around by making the existing resources reusable.

In closing…

I hope this long series has provided some practical steps you can take to move your Security Development Lifecycle practices to the next level. At Microsoft, creating a lifecycle to match security development practices has faced a fair share of challenges. However, the investment and time has resulted in more secure products. We’ll continue refining how we execute the Security Development Lifecycle and hope to share those ideas with you along the way. We welcome your thoughts and questions as you start “Walking” with the SDL in your own company and look forward to seeing more secure products and customers as a result.

I’ve created a unique tag on the SDL Blog to cover this series. To get a full list of the related posts, click the “Crawl Walk Run” tag on the left column. I’ll post a Word document version of the full “Walk” series sometime in the next week.

"Walking" with the SDL - Part 3

sdl — Wed, 23 Jul 2008 19:43:00 GMT

Jeremy Dallman here. This is Part Three in my multi-part series on “Walking” with the Security Development Lifecycle (SDL) [Part 1, Part 2]. So far I have discussed getting management approval and expanding security training. In this post I will discuss formalizing requirements and effective ways to reuse your threat model and attack surface review data. I’ll wrap up with a look into final security reviews and managing post-release documentation.

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies. Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version. Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

· Think about component-level architecture

· List common pitfalls in writing code, or begin defining and building test cases.

· Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

· Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

· Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

? How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

? What challenges have you faced in enforcing requirements across your teams?

? How have you implemented threat models or attack surface reviews?

“Walking” with the SDL – Part 2

sdl — Mon, 21 Jul 2008 19:56:00 GMT

Jeremy Dallman here with Part Two in my series on “Walking” with the SDL. In Part One, I provided a snapshot of “Crawling” and discussed getting management approval. In Part Two, I will cover a couple more “Walk” components: expanding security training and formalizing requirements.

This blog gives us a place to talk about our experiences from using the SDL here at Microsoft and hopefully provide useful information that will help you implement it more effectively at your company. So, I would encourage you to use the Comments section at the bottom of each post to ask questions, give us feedback, or request other topics for us to cover.

Some quick definitions before we dive in. I’ve been using the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing the Security Development Lifecycle (SDL). “Walking” is the point where your security development practices become a lifecycle – a repeatable, reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll continue to talk about walking – or adding the “L” in SDL.

Let’s jump into another component for adopting the Microsoft SDL to expand your own Security Development Lifecycle.

Expand Security Training

Once you have management approval, it is necessary to gain grassroots acceptance of the changes – at the developer, QA/test, and PM levels. If you have been “crawling”, you have probably already implemented some sort of discipline-specific training around things like threat modeling, using compiler defenses, and fuzz testing. Now that you are building a lifecycle, your goal for security training should expand. Security training should be about creating an environment where writing secure software is everyone’s mission. While security training should be undertaken with the goal of understanding security issues and how to address them, good training (and instructors) will also explain why solving security problems is in their best interests and create an environment where they know voicing security concerns is encouraged.

Training has been one of the earliest and most important elements of the SDL at Microsoft. From our experience, we learned that the most effective approach is to divide your training into two tracks: general security principles and role-specific security practices. Before I jump into the details, I want to encourage you to also read Shawn Hernan’s very good post about SDL training that highlights some of the ways to make security training effective.

The general security principles should explain why security is important, how you define security requirements, the process you will use for writing and validating secure code, and how security relates to each phase of the lifecycle or unique roles contributing to the development process. A key factor for building a development lifecycle is educating your individual contributors on the value of investing in security. Of course changing culture takes time, but using the opportunity of structured training to explain your principles will be one of your most effective platforms for influencing change.

At this point in your organizational maturity, you are also beginning to expand your security thinking by focusing on each role in the development process. Discipline-specific security training is where you dig into the details of implementing a Security Development Lifecycle.

· The developer needs to understand the practical details of how to write code securely, how to set compiler flags, what a security code review means, how to avoid using banned APIs, and what tools are available for them to perform security analysis before checking in their code.

· The QA/tester needs to know how to set security rules in test tools, how to perform penetration testing, and what the security quality criteria is for your product, or how to file a security bug.

· The PM needs to understand how to define measurable goals or how security policies can be factored into feature design.

· The business decision maker of your organization should understand how to track security metrics alongside other product measurements or how security policy plays a critical role in the overall quality and value of your product.

· Finally, it is critical for the employees occupying all job roles to understand the value of threat modeling – both as a tool for understanding threats early in the design phase and throughout the development process as a key barometer to the security pulse of your product.

Discipline-specific training will be the place to address these issues for your organization. In case you were wondering, all job roles should be required to attend both types of security training before working on your product.

Our new SDL website [http://www.microsoft.com/sdl] will be a very good place to watch for future training materials. The SDL Training and Resources page has some useful material up now and more will be coming in the future.

That’s Part Two. In Part Three, I will discuss the important “walk” components of formalizing security requirements and reusing threat models and attack surface reviews. Then we will close with the discussions on conducting final security reviews, and managing post-release documentation.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

? Do you provide security training to your employees today?

? Do these additional training topics make sense in your organization?

? What would you add to this that is unique to your application or company?

"Walking" with the SDL - Part 1

sdl — Fri, 18 Jul 2008 19:55:00 GMT

Jeremy Dallman here. Back in March I wrote a post about “Crawling” Toward SDL. I used the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing a version of Microsoft’s Security Development Lifecycle (SDL).

In this series I am going to talk about “Walking” with the SDL. Walking is the point where your security development practices become a lifecycle – a repeatable, mostly reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll talk about walking – or adding the “L” in SDL.

I will be covering quite a bit on this topic, so I intend to split it up in to a multi-part series over a few days. I’ll condense it all into one big doc at the end. In Part One, I will review “crawling” and the foundation you need to have in place as well as discuss getting management approval. In Part Two we’ll cover the topic of expanding your security training. In the additional posts, we’ll discuss formalizing requirements, reusing threat modeling and attack surface review data, the importance of final security reviews, and managing post-release documentation. All of these are components to “walking” with the SDL.

Before I jump into detailing what you can do to “walk” with the SDL, let’s look back at a snapshot of what you should already have in place from learning to “crawl.” At a high level, crawling involved three components. Each of these components requires specific activities or tools that your team must implement to begin developing secure code:

1. Detailed awareness of your architecture and its attack surface.

a. Threat Modeling

2. Tools that will perform security analysis on your application.

a. Strengthen compiler defenses

b. Use code analysis or static analysis tools such as PREfast, FxCop, AppVerif

c. Build a strong fuzz testing capability

3. Results that show how the analysis resulted in improved security

a. Response planning and response process in place

b. Use bugs to gather evidence and show that your work improved security

Think of these pieces as the “gross motor skills” you need to start walking. You should already be using these components and have reached a conscious decision to start building a lifecycle around your secure development practices. As you start figuring out how to “walk”, I want to point out that each of the concepts I discuss in this post is a critical component of the Microsoft Security Development Lifecycle. Adopting the SDL in your company involves a combination of integrating the existing SDL principles and the creating of unique requirements and components specific to your environment to build your own Security Development Lifecycle.

With that in place, let’s start talking about what it means to “Walk with SDL.”

Obtain Management Approval/Endorsement

Creating a Security Development Lifecycle will cost time and money. In addition, it will likely require some process changes. In most organizations, this change will not happen unless you obtain the management approval and endorsement necessary to compel the organization to act.

The key to successfully pitching SDL to your management can be found in the data you have been accumulating during the “crawl” phase. As you may recall from my crawling post, the simplest way to create evidence that clearly illustrates improved application security is to “mine” the data from your bug database. Connecting those bugs to known security vulnerabilities or to what would have been bad security issues that were avoided by fixing them in development is a powerful story. Of course your pitch should include other necessary components like anticipated costs, new software acquisition, possible vendor and consulting contracts and anticipated return on investment.

However, the heart of your argument will be the story you tell. The story is quite simply “If we hadn’t done this basic work in security, here is what we would have missed and how much it would have hurt…” followed by “if we continue to expand our security practices and make them a part of our process, we can better predict measurable security improvements that reduce the likelihood of future risks.”

The new SDL website [http://www.microsoft.com/sdl] provides some valuable reference material on the Business Case for SDL. I would recommend that looking through that information for some good supporting material. In Part Two, I will discuss expanding your security training as another component of “walking” with SDL.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

? What unique challenges are you facing as you try to push for SDL adoption?

? What have you used to successfully communicate the importance of security to your management?

"Crawling" Toward SDL

sdl — Fri, 07 Mar 2008 01:13:00 GMT

Hey everyone, Jeremy Dallman here.

One of the phrases I often hear during vision and strategy planning meetings at Microsoft is "What is the crawl, walk, run?" We use this phrase to differentiate the initial activities that will get us quickly moving toward our larger goals and then supplement them with other activities that may require longer preparation or planning. As I help non-Microsoft companies implement SDL into their development lifecycles, this "crawl" phase toward full adoption of SDL is very important. Usually some person in an organization picks up on the principles of SDL and is ready to roll them out immediately. However, that person usually is faced with competing interests that complicate full adoption: the team is mid-stream in development, short on budget, or management wants to see clear evidence before investing in the changes to support full SDL adoption.

Since we usually focus on how to roll out the full Lifecycle, I want to take a shot at defining what it means to start “crawling” toward SDL. One very important note before I start. What I describe below is not Microsoft’s SDL process. It matches some of the tools and principles, but does not encompass the holistic application security solution provided by SDL.

In my mind, to start crawling toward SDL, you need to execute on some of the core principles. They obviously need to be low-cost and effective. So, I want to summarize these into three components.

1. Detailed awareness of your architecture and its attack surface.

2. Tools that will perform security analysis on your application.

3. Results that show how the analysis resulted in improved security.

The good news is that you can attain these components with tools that are already available. The one consistent minimum requirement is that your code compiles/builds within Visual Studio 2005 SP1. The SP1 piece of this is important because some of the important defenses I discuss below were first made available in that version. Let’s look at some of the tools you can use to get “crawling” toward SDL today:

Detailed awareness of your architecture and its attack surface

Threat Modeling

Even if you are past the design phase, assign someone to do a retrospective model (perhaps as part of a pre-release review). This will likely give you a better understanding of your overall architecture and uncover holes in places you may have inadvertently overlooked.

Tools that will perform security analysis on your application

This is probably one of the most often discussed topics around SDL, so I’ll spend some time providing more detail. Let’s break this down into how it impacts differing parts of your team or organization: developers, testers, and operation.

Developers

You should start by strengthening your compiler defenses. Depending on whether you are writing native or managed code, these will differ.

For C and C++ code:

Strengthen your compiler defenses

· Use the latest compiler and linker because important defenses are added by the tools

· If using Visual C++, use Visual Studio 2005 SP1 or later

· Compile with appropriate compiler flags

· Compile clean at the highest possible warning level

· Compile with –GS to detect stack-based buffer overruns

· Link with appropriate linker flags: /NXCompat to get NX defenses, /DynamicBase to get ASLR, and /SafeSEH to get exception handler protections

Do not use banned APIs in new code

· Use #include “banned.h” header file to find banned C/C++ functions in your code quickly. This header file is included in the companion disk in the Security Development Lifecycle book.

· Compile regularly with /W4 and fix all C4996 (banned C Runtime function) warnings

For all Languages:

Strengthen your compiler defenses

· Use the latest compiler, linker and libraries because defenses are added by the tools and code

o If using C#, use C# v2.0 or later and if using VB.Net use 8.0 or later

· Use .NET Framework 2.0 or later

· Do not use weak crypto in new code

o Use only AES, RSA and SHA-256 (or better)

· Prevent XSS vulnerabilities by using filtering and escaping libraries around all Web output

· Secure your SQL script by only using prepared SQL statements - no string concatenation or string replacement

Run these tools habitually

· PREfast (in Visual Studio 2005, use the /analyze compiler option) – a static analysis tool that identifies defects in C/C++ programs and enables you to perform quick desktop error detection on small code bases

· FxCop – an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies

· Application Verifier (AppVerif) – detect and help debug memory corruptions, critical security vulnerabilities, and limited user account privilege issues.

Testers

James Whittaker has covered testing in the SDL on this blog in the past. In a “crawl” scenario, you need to keep it simple while maximizing the value of output. I would recommend focusing on fuzz testing. This is likely something you will need to invest some time creating. Scott Lambert’s article on Fuzz Testing at Microsoft and the Triage Process provides some good guidance on how to think through what type(s) of fuzzing to exercise against your application.

If you choose to expand beyond fuzz testing, I would point you back to James’ article on the broader topic of Testing in SDL. You may come to the conclusion that expanded security testing may come later in your “walk” or “run” phases, but I would take some time to think through testing even while “crawling” to ensure you are getting broad enough coverage for your application. James’ article highlights the three-pronged approach to security testing we use at Microsoft. You should use these three approaches to ensure your own fuzz testing is comprehensive.

1. Attacks against the application’s environment.

2. Direct attacks against the application itself.

3. Indirect attacks against the application’s functionality.

Results that show how the analysis resulted in improved security

Response planning

Protecting your customers is the entire reason for focusing energy on application security. If there are holes in your code that you don’t uncover, someone else will. It is absolutely critical that you are prepared to respond rapidly and protect your customers. It is equally important that you construct your response plan to serve as a front-line barometer for detecting the resilience of your security design and what pieces of your applications security should be proactively bolstered to address externally reported vulnerabilities. The knowledge you harvest from these security incidents (typically through root cause analysis) is the primary way to improve your code and security tooling for the future. Do everything you can to learn lessons from the vulnerabilities others find. If you don’t have a response plan in place, you need to get one in place as soon as possible. If you don’t know where to start, take a look at how our own Microsoft Security Response Center does it and fit to your scale or pick up the Security Development Lifecycle book and dig into the four-step process outlined.

The four steps of the emergency response process:

1. Watch

2. Alert and Mobilize

3. Assess and Stabilize

4. Resolve

Bugs, Bugs, Bugs

Gathering evidence that clearly shows your work has improved the security of your application is always a challenge. Trying to keep it lightweight adds to that challenge. The most effective way to create traceable and practical evidence without a lot of overhead is detailed management of security issues in your bug database. The key here is that your bug database is configurable and able to be queried in a variety of ways to pull out this data. From the time you set out to implement this plan, be strict in tracking every discovery from threat modeling, the mitigations to those threats, and every bug you expose in tool analysis. This library of security bugs will give you an easy way to go back and gather evidence that shows the quantity of issues you discovered, the mitigations you used, and the impact the changes had on your application.

I have provided a fairly detailed view of these components. As I indicated, many of these defenses are available for you in Visual Studio 2005 SP1 or various linked resources above. If you are unsure whether you are taking advantage of all available defenses in your development tools, take the time to check.

It is my hope that some of you can use this scaled back entry into the principles of SDL to get moving toward improved security assurance. In the non-Microsoft SDL engagements I have been involved in, we have seen these steps effectively establish a baseline architectural understanding of your application security and identify critical weaknesses while providing solid evidence to support the decision to “run” forward into full SDL adoption.

[I want to thank Michael Howard for providing some of the key data for the Developer pieces in this article.]

edit - 7/28/08: adding tag for Crawl Walk Run series.