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?
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?
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?
Hi all, Dave here…
I’m pleased to announce the availability of new resources for the Microsoft Security Development Lifecycle (SDL).
We have recently launched a dedicated SDL website at www.microsoft.com/sdl. This website will serve as the main online presence for all SDL related communications and resources from Microsoft.
For several years now the SDL has been at the heart of Microsoft’s strategy for making security and privacy an integral part of the software development culture at Microsoft. As a result of the SDL, we have seen significant security improvements across many flagship Microsoft products including Windows, SQL Server and others. These security improvements have been widely recognized by security analysts, researchers and other experts. However, despite the significant improvements and recognition, we believe that our connections to our broad technical audiences (developers and IT Pros) are not equating the SDL to the progress we have made with our technologies and services.
Given that, our goal is to help illustrate SDL processes and tooling in a structured and consistent manner – by providing actionable guidance for the different job roles within a development organization.
We welcome your feedback – on the site, and on other information you’d find useful in evaluating the SDL.
Hi, this week is a post from Michael Howard and Laura Machado de Wright, who both attended and presented at TechEd 2008 in Orlando the week of June 2nd.
First up is Laura.
I have been a Security Program Manager for the last 3 years, working as a security advisor for a variety of products across Microsoft and the last seven months as a member of the SDL policy team.
It's been a few years since I've been to TechEd, and this was my first time attending as a member of the security team. TechEd is now a two week conference, with one week dedicated to developers and the other to IT professionals. I think that breaking down the conference into a Developer week and an ITPro week was a good idea, and it allowed us to have good conversations with people who wanted more information about the SDL. I did two main things at TechEd:, I presented on threat modeling, and I spent a lot of time talking to customers at the SDL booth. At the SDL booth, we heard questions ranging from "What does the SDL stand for?" to "Our Web site was hacked; how do I stop it from happening again?" It was encouraging hearing people interested to hear more specifics about how we implement the SDL at Microsoft, and thinking through how they can apply it in their own companies. My understanding from other TechEd veterans in our booth is that interest in the SDL seemed higher, which is great.
During my Threat Modeling session, , most of the feedback and follow-up questions were similar to the ones in the booth: how to expand the threat modeling processes to their own companies, and how to get started.
My typical response to both questions is to start small and do what makes sense for your organization. At Microsoft, for example, when we introduce new SDL requirements, we usually start with a few teams so we can refine the requirement and supporting tools before expanding the requirements to a broader group. Similarly, while we have a core set of requirements that all teams have to meet, there are other requirements that are specific to a platform, scenario, or functionality. For example, there are some requirements that make sense for desktop-oriented products, but do not make sense for mobile devices. You may very likely have to make changes to our policies to make them relevant to your organization, your scenarios, and functionality.
Now over to Michael.
Hi, Michael here.
One of the joys of presenting at TechEd each year is hearing from real people about the issues they face using our products in the real world; rarely are the issues pure philosophical security geekness. This year I gave two talks and one "chalk talk." The talks were "Top Ten Strategies
To Secure Your Code" and "How To Review Your Code
and Test For Security Bugs", and the chalk talk, which was a lot of fun, was simply answering numerous developer questions.
It's interesting to gauge overall security awareness from our customers, and there is no doubt that over the years, the level of security knowledge and maturity has risen. I think it's possible to evaluate overall security maturity by the questions posed. Some years ago, security was never really a topic of discussion other than those that relate to security technologies, such as how to use and manage X.509 certificates. About four years ago the tide really changed and people started asking more questions about "secure" application deployment and management, and developers wanted to learn more about securing their code; especially C and C++ code. Even then there was still a reliance on exterior defenses like firewalls. All too often I would hear people claim that they don't need to focus on securing their apps because a firewall was in the way. Heck, David and I documented this excuse in the original version of Writing Secure Code (Appendix D, "Lame Excuses We've Heard, #6, ‘We're Secure-we use a Firewall'") way back in 2002.
Fast forward to 2008.
Things have obviously changed. I don't know if finally the security message is getting through because many people asked me highly specific questions about securing their apps and how best to use the defenses we offer in Windows Vista and Windows Server 2008.
I still hear the firewall excuse a little, but not too much!
Perhaps the most telling trend I saw this year was a great deal of interest in the SDL. Not cursory, "that looks interesting" interest, but, "how can I implement this in my company" interest. After answering specific questions, I pointed most folks to Jeremy's "Crawling Toward SDL" post on the subject.
In my opinion, getting to a point where you want to change your development process shows you really understand there's an issue that needs fixing.
And that's goodness.
Bryan here. A couple of weeks ago, I posted a blog entry with links to SQL injection defense guidelines. The SDL requires guidance and education for end-users, and tools to verify security settings are highly recommended, as defined in "Stage 5: Implementation Phase: Creating Documentation and Tools for Users that Address Security and Privacy". Today, Microsoft is releasing two new SQL injection defense and detection tools, URLScan 3.0 and Microsoft Source Code Analyzer for SQL Injection (MSCASI). We are also excited to announce the release of HP Scrawlr, a SQL injection detection tool developed by HP Web Security Research Group in conjunction with Microsoft.
Each of these tools works differently and each attacks the SQL injection problem from a different angle, and in combination they complement each other well. MSCASI analyzes classic ASP source code to find potential SQL injection vulnerabilities. It can detect both first- and second-order SQL injection bugs and will point you to the exact line of source code where the error occurs.
However, sometimes you don’t have access to the complete source code of your application; for example, you might use third-party libraries or services in your code. This is where Scrawlr comes in. Scrawlr is a black-box analysis tool that doesn’t require access to source code. You just give Scrawlr the URL of your web application and it crawls and analyzes that application for SQL injection vulnerabilities. One downside is that Scrawlr can’t point you to the exact line of vulnerable code the way that Microsoft Source Code Analyzer for SQL Injection can, but this is why the two tools work so well together. In general, source-code analysis tools and black-box analysis tools often work better in conjunction with each other, but this is definitely a larger topic for another blog post.
Finally, URLScan 3.0 is an update to the existing URLScan IIS request filter tool. URLScan 3.0 blocks HTTP requests that contain suspicious text like SQL keywords. URLScan 3.0 is a good defense-in-depth measure, but it’s important to find and fix vulnerabilities at the source. Never rely solely on URLScan or any type of application firewall as your only defense. (I’ve talked on my blog about some potential dangers of substituting firewalls for secure development practices.)
If you’d like more information, the Security Vulnerability Research and Defense blog has posted a more in-depth analysis of each of these tools. I recommend that you download both of the detection tools and test your applications against them. If either tool reports a vulnerability, I also recommend that you use URLScan 3.0 to block attacks while you fix the problems in the source code.
One last note: none of these tools are required by the SDL yet – they just came out today! – but we will definitely be exploring ways to incorporate them into the SDL in the near future. I’ll keep this blog updated with our results.
Adam Shostack here.
I wanted to share my slides from the recent Layer One conference [link], where I talked about "SDL Threat Modeling: Past, Present and Future."
There are a few points that I wanted to emphasize. The first is that I'm talking about threat modeling from the perspective of the SDL. We have other threat modeling processes here at Microsoft, and we're working to bring you more clarity in how we speak about them. For my part, I'll try to clearly say "SDL threat modeling," or be explicit when I'm talking about threat modeling in broad terms.
Which brings me to my second point, and a slide I wanted to emphasize. (Shown here)
I no longer think of threat modeling as one thing. I see it as a label for a set of ways to address the question of "what could go wrong" with a design or set of requirements. The SDL has one process. The folks in ACE and Patterns and Practices each have another. All are customized to meet various needs. Much like we have lots of programming languages which address different problems, we're going to have lots of threat modeling processes.
Anyway, I hope you enjoy the slides.
Hi, Michael here.
In a previous post I explained how to use HeapSetInformation correctly. In short there's an option when calling this function that will terminate your application if the heap manager detects some form of heap corruption, or the potential to cause heap corruption.
I would recommend you read the previous post before continuing.
You guessed it, the number one email I got after this post was, "So, what sort of corruption will terminate my app?"
So for all those who emailed me, here's a list:
- Corruption of an uncommitted range (region inside heap segments which are reserved but not committed)
- Heap header corruption, for example the heap header checksum is invalid. This can be a single header, or multiple headers.
- Walk of the large virtual blocks shows corruption (all blocks above about 512Kb on x86 and 1Mb on 64 bit are not allocated from segments; they are direct virtual allocations, the heap just holds a list of them along with some metadata to assure consistency with the rest of the heap. They are chained in a double linked list so corruption can be detected by walking the list.)
- Buffer overrun: the next block header size does not match the expected current block size.
- Buffer underrun: same as above, but the previous block header size does not match the expected current block size.
- Attempting to free a free'd block (double-free bug)
- Attempting to free a non 8-byte aligned block.
- Passing a bogus heap handle, it could simply be an invalid heap or a handle to a different heap.
- Corruption of free block list. A bit of a catch-all, including: writing after free, overrunning a previous and managing to step over the list entry.
But there is one huge and critically important caveat to using the defense: it only works if you use the Windows heap manager. You might be surprised to learn that many applications actually implement their own heap functionality for various reasons, often legacy reasons based on historically poor performance of operating system heap managers. A great deal of performance work was performed on the Windows Vista and Windows Server 2008 heap managers, but the work performed is way beyond the scope of this document. Another common scenario is to allocate a huge block of memory from the operating system and then perform custom allocation within that heap block. Again, if you do this, you will not get benefit from using the heap corruption termination capability and you will still be subject to repeatable heap based attacks.
Another down side of not using the native Windows heap manager (or if you use your own sub-allocation mechanism) is you cannot take advantage of Windows leak-detection tools because you are not using the Windows heap in the way it's meant to be used, or you're not using the Windows heap at all.
With all this said, I realize that moving off a custom heap to another heap is never an easy task, but if you want to take advantage of this defense, you should add "Move off our custom heap" to the list of development tasks.
Hi everyone, Bryan here. Michael wrote a great post here on SDL-required SQL injection defense techniques in the wake of the recent mass SQL injection attacks against ASP sites. Additionally, the Security Vulnerability Research & Defense blog has just posted an analysis of the attack along with guidance recommendations for IT/database admins, web developers, and end users. Finally, if you are looking for classic ASP-specific (not ASP.NET) guidance, Bala Neerumalla has posted a detailed document on preventing SQL injection in ASP on MSDN.
Hi everyone, Shawn Hernan here. Being a security guy is incredibly rewarding because you get to look at virtually any part of a product, from kernel drivers to web services to user education to sales and servicing. You have to do that because a failure in one of those areas can endanger the security of our customers. Microsoft’s SDL process reflects that reality. The process is structured so that you really do have to look at each piece before you can sign off. But sometimes when others want to emulate the success of the SDL, they want to skip steps. They try to boil the SDL down into its component parts, like training, or tooling, or security response. Maybe the most common form of that mistake is training, but you see that same thinking applied to code scanning, security response, and just about every phase of the SDL. “Let’s just train everyone, and all our security problems will go away.” If only it were so easy. I’d like to take a few minutes to try to explain why it’s not really that easy from my own experience.
Have you ever sat in a corporate training? Some are good, some are bad, but did you ever say, “man I can’t wait for training today.” What about mandatory training? What about mandatory training in a subject that you really don’t think is your area? What if you had to do it every year, and got harassed if you didn’t do it? What if you were, say, an audio engineer and were dragged into a security class?
I ran the SDL training program at Microsoft for a long time, and developed and taught a big chunk of the training. I spent hundreds of hours in front of thousands of developers, testers, and program managers. I got some really good reviews (and a few bad ones) on the classes I offered. And I tried to do a lot of things to try to make the trainings interesting. I handed out dozens of fresh peaches in an early class on fuzz testing, for example. The room smelled really nice after that, and there are probably still a few people around Microsoft who think of fuzz testing when they see a peach.
But even on my best day, I was under no illusion that the majority of the audience was excited to be there, and I was certain that they weren’t going to go back to their offices and spend weeks applying the lessons from the class, setting aside other things that are causing present and immediate problems in favor of something that is far off into the future.
You have to work at getting people’s attention – especially as it relates to security and privacy. From time to time, I would see people reading their mail in class, and I would point to them and ask them a question. That did not endear me to the audience as much as the peaches, but embarrassment is always fresh and in season. J
One student wrote of one of my classes, “the basics for secure design - could be replaced by non-anonymous site-wide exam with open material.” He was not alone, I assure you.
Is that an indication that our training, or any training, is pointless? Hardly, but training alone is not a change agent.
Richard Derwent Cooke wrote, “It is a first principle of Change Management that people will act in what they perceive as being their best interests.”
At best, training can provide people with insight into what they need to do to solve a security problem if they believe that solving that security problem is in their best interests.
To be effective, training needs to happen in an environment:
· Where expectations are clearly set (the SDL sets specific minimum requirements).
· People have appropriate incentives and consequences (security is a great career path at Microsoft, and nobody wants to be the one holding up a ship schedule for failure to meet a security requirement).
· Where tools and resources to accomplish the goals are available (we build a whole variety of tools that map to the SDL requirements).
· Where management models the behavior (recall the original BillG TWC memo).
· Where the environment reflects and supports the values presented in the training (apparent in everything Microsoft does).
Don’t make the mistake of thinking that a bunch of training, even really high quality training done periodically, will result in actual behavior change. It won’t. You have to build an environment where people perceive solving security problems as being in their best interests. You have to make security their problem – not in the sense of passing the buck, but in the sense of changing their behavior so they will bring security problems to you.
To illustrate further, I’ll cite two examples. First, fuzz testing. Fuzz testing has been a success story here at Microsoft. Tools arise spontaneously to solve new fuzzing challenges, written by people who believe the challenges are their challenges. There are people who feel ownership for our fuzzing strategy and on-going research and science, there are specific goals and requirements, we have training (remember the peaches?), and internally developed fuzzers have won prestigious awards within the company, handed out by members of the executive staff, and all of this gets revisited periodically as part of the SDL.
By contrast, I’ll choose a less successful area – defect estimation. On my own volition, I created (based mostly on some excellent material from Microsoft Research) and taught a class called “Defect Estimation and Management” and added it to the SDL curriculum. Microsoft is a great place to work in that regard. It was pretty close to the best-reviewed class I taught. But, we have not yet been able to establish a set of tools to estimate security defect density effectively, and establish a fair set of expectations, incentives, and consequences, or even decide what we should do if we had the data. We discovered some things, though. For example, based on what I observed (which should not be construed as rigorous research), it does not appear as if the density of general defects correlates closely with the density of security defects. And Microsoft Research found higher code coverage in testing correlates with higher bug rates in the field.
And so even though people like the idea of defect estimation, and we’ve got some interesting and surprising data, we’ve not yet been successful in changing people’s behavior. Generally speaking, an individual test manager does not feel that establishing a high quality estimate of their defect density is in his or her best interests, as compared to, say, improving the time in which an established series of tests can be performed .
We need to build an environment that has the tools, training, rewards and incentives, and expectations and consequences to change people’s behavior. Not that we’re not trying. But training won’t solve it alone, nor would tools, trophies, rants, testing, code review, or some edict from on high. The SDL is as much about changing the culture and influencing the behavior of individual engineers as it is anything else.
I’m convinced that Microsoft’s SDL process works because it addresses the end-to-end problem - from training through servicing, and provides a complete environment where people feel ownership of their part of the security problem and have the resources to solve it.
So the next time you find yourself sitting in some mandatory training, remember the lessons of the SDL (and most of the research on human performance management): training alone won’t cut it. If you want real behavior change, there have to be things outside the lecture room to influence people to change their behavior.
Hello, Michael here...
You may have read recently about a large number of Web servers that were compromised through a SQL injection attack. The malicious SQL payload is very well designed, somewhat database schema agnostic and generic so it could compromise as many database servers as possible. While the attack was a SQL injection attack that attacked and compromised back-end databases courtesy of vulnerable Web pages, from a user's perspective the real attack was compromised Web pages that serve up malware to attack user's through their browsers. In essence, there were two sets of victims: the Web site operators and the users who visited the affected Web sites. In this post, I want to focus on what the first set of users, the Web site operators, can do to protect themselves.
The fact that the malicious payload was so generic shows that the science of SQL injection has not taken a back seat to research in other vulnerability types, such as buffer overflows or cross-site scripting issues.
I think the first lesson from this attack is this:
If you have a Web server (doesn't matter what type), and it's hooked up to a database (doesn't matter what type) you need to go in and review your code that performs the database work.
So now that you've determined the database access code, now what? The SDL is very specific about what do here, there are three requirements - they are requirements not recommendations, which means you must do the following coding requirements and defenses
- Use SQL Parameterized Queries
- Use Stored Procedures
- Use SQL Execute-only Permission
Use SQL Parameterized Queries
From the SDL documentation:
"Applications accessing a database must do so only using parameterized queries.
Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application. This vulnerability allows for unauthorized, interactive, logon to a SQL server which may result in the execution of malicious commands leading to the possible modification (or deletion) of Operating System or user data.
Combining the use of parameterized queries and stored procedures helps to mitigate the risk of successful exploitation of user input which is not correctly verified."
This defense has been known about forever; heck, David and I discussed this in detail in the first edition of Writing Secure Code in 2002:
From page 320, "Another way to perform this kind of processing is to use placeholders which are often referred to as parameterized commands."
Just about every database access technology supports parameterized queries; work out what they are for your DB technology and use them: the defense for a PHP/MySQL combo will not be the same as a C#/SQL Server combo.
The most likely cause of these recent compromises is using string concatenation to build SQL statements. Just don't do it, even if you think you're safe, just don't use string concatenation to build SQL statements! There are some very specialized cases where string concatenation is valid, but they are rare, especially for Web apps. In my opinion, any use of string concatenation in a Web application is a high-priority bug.
Use Stored Procedures
From the SDL documentation:
"Applications accessing databases should do so only using stored procedures. "
-and-
"Do not use "exec @sql" construct in your stored procedures.
Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints the stored procedures will throw an exception. In the vast majority of the cases, this should be properly handled within the application.
However, if the stored procedures perform string manipulation in their code and then execute that query using the "exec @sql" construct incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer."
Note the words "help mitigate," by themselves stored procedures do not remove SQL injection vulnerabilities; they just raise the bar on the attacker by hiding much of the underlying database schema from the attacker.
Use SQL Execute-only Permission
This next defense is interesting in that it is a defense in depth method; in this case it assumes the attacker has successfully found a SQL injection bug in your code. Now what? Thankfully, this defense will stop most every attack dead in its tracks.
From the SDL documentation:
"Only grant ‘execute' permission on all stored procedures, and grant that permission only for the application domain group.
Ensure that this group is granted execute permissions only on your stored procedures. Do not grant any other permission on your database to any other user or group."
This is a great defense, because if the attacker attempts to access any other database object other than through a stored procedure (you can use views also), the underlying database permissions model prevents the attack by denying access to the attacker.
It's interesting that the SDL offers three SQL injection requirements; only one actually remedies the problem (secure by design) and the other two offer mores defenses assuming failure (secure by default.)
Of course, a simple set of rules is not a substitute for careful design, implementation, and test. The SDL is a holistic process that covers the software lifecycle end-to-end, so don't mistake these simple rules as a guarantee that you will avoid SQL injection problems. You need to understand the situations in which the rules apply. You may find, for example, that string concatenation is the best - or perhaps only - solution to a particular problem and these rules may not guard against SQL injection in those situations. Follow secure development practice throughout the lifecycle of your project - including things we left out of this blog, like testing and security response, for best results.
Hi folks, Eric Bidstrup here.
As I touched on in my December posting on Common Criteria, and as Michael Howard discussed in his post on security metrics, trying to objectively quantify and measure “How secure is secure” is far more difficult than one might think. I’d like to share my perspective that there are two “dimensions” useful to consider when characterizing software security metrics: security functional requirements and security engineering quality requirements. While the SDL is focused primarily (but not exclusively) on the latter, both are ultimately important when assessing the security of a given bit of software. However, for reasons I’ll elaborate on below, the SDL does focus on trying to prevent the most common causes of vulnerabilities today and hence looking at the ways in which Microsoft tracks and measures individual products teams’ compliance with SDL requirements offers some interesting fodder for the security metrics debate. I’m not offering a complete solution, but am sharing our experience at Microsoft with measuring how development teams actually follow the SDL. It’s helped us deliver more secure software, and sharing this will hopefully help others as well as putting more data on the table for consideration when discussing security metrics.
Putting aside computer security for just a moment, it’s interesting to look at other ways in which we attempt to measure security in our society. Padlocks offer security protections, and organizations such as the American Standard for Testing and Materials (ASTM) provide standards like F883-04 Standard Performance Specification for Padlocks that characterize padlock security ratings. Prisons provide security protections as well. Prisoners reside in different facilities that vary by security level. The US Bureau of Prisons uses a numbered scale from one to six to represent the security level. Both of these examples are similar in that the threats and risks each of them must protect against are reasonably well understood and relatively static (meaning the threats don’t change much over time). Computer security is still evolving with new classes of attacks still being discovered, and while hackers understand how to exploit known types of vulnerabilities – software developers are still catching up in learning how to modify engineering practices to be resilient against both new and old types of attacks. Hence, metrics are more challenging for computer security.
Several attempts have been made by governments to come up with a security rating system similar to the examples listed above. In the 1980’s, the US Department of Defense created the “Trusted Computer System Evaluation Criteria (TCSEC)” that tried to establish a standard for measure operating system security. The “Orange Book” offered a relatively simple system for assigning “score” summarized below:
D (Minimal Protection)
C (Discretionary Protection)
C1: Discretionary Security Protection
C2: Controlled Access Protection
B (Mandatory Protection)
B1: Labeled Security Protection
B2: Structured Protection
B3: Security Domains
A (Verified Protection)
A1: Verified Design
In the 1990’s, the US and other nations combined their efforts to create an international security standard for software known as the Common Criteria (ISO 15408). Common Criteria also has a rating system that scores products with “evaluation assurance levels” (EALs):
EAL 1: Functionally Tested
EAL 2: Structurally Tested
EAL 3: Methodically Tested and Checked
EAL 4: Methodically Designed, Tested, and Reviewed
EAL 5: Semi-formally Designed and Tested
EAL 6: Semi-formally Verified Design and Tested
EAL 7: Formally Verified Design and Tested
Both TCSEC and Common Criteria (CC) are primarily focused on “security functional requirements” (as called out earlier, distinct from “security engineering quality requirements”). The EALs reflect the amount of rigor and attention to claimed security functional requirements a developer applied while creating a product. Furthermore, the EALs also reflect increasing levels of effort and resources necessary by anyone reviewing a product in order to evaluate the product’s claimed security functional requirements. However, EAL ratings for commercial products have historically not correlated with the number of vulnerabilities found in commercial products after release. As I discussed in my December posting on Common Criteria, this is because CC is primarily focused on “security functional requirements” and fails to adequately address “security engineering quality requirements”. This leads a question on how to measure those aspects of software security that earlier efforts have been unable to successfully address.
Microsoft has been releasing security bulletins since 1999. Based on some informal analysis that members of our organization have done, we believe well over 50% of *all* security bulletins have resulted from implementation vulnerabilities and by some estimates as high as 70-80%. (Some cases are questionable and we debate if they are truly “implementation issues” vs. “design issues” – hence this metric isn’t precise, but still useful). I have also heard similar ratios described in casual discussions with other software developers. In other words, most vulnerabilities can be addressed by the “security engineering quality requirements” described via SDL. This is not to say that “security functional requirements” are unimportant or that SDL ignores secure design (as Adam has described in his threat modeling series), but rather that it is not where vulnerabilities are being most frequently encountered. With SDL, we adopt a pragmatic approach in looking at identifying the root causes of security vulnerabilities, and trying to prevent those root causes from reoccurring. The challenge lies in how we actually validate that development teams are indeed adopting and executing whatever changes SDL requires in engineering (either in terms of process or tools). Process changes are often difficult to quantify, as we must rely upon development teams truthfully attesting they have followed the process. As long as development teams believe the process results in better code, they generally will adopt and follow such practices. Tool usage becomes more interesting and valuable in that using tools becomes a vehicle for objectively and independently verifying if code satisfies requirements or not. But that is just the tip of the iceberg…
As I said above in my comments on EALs, the amount of time required by anyone reviewing a product to assess “security” is relevant since security review can be a very time and resource intensive activity. However, running static code analysis tools, verifying build tools and switches, searching for banned APIs, and recording the output of other tools that inspect code and/or binaries for potential implementation vulnerabilities is a key element in how we approach the challenge of trying to measure compliance with SDL requirements from product groups at Microsoft today. While not every technique required by SDL has a corresponding tool, we try to provide both tools and automation if and wherever possible. There is still much work to be done in terms of standardizing tool output formats and creating automation to assess tool output. However, these “grass roots” metrics derive from practical experience of changing engineering requirements based on actual vulnerabilities. We look objectively at what is causing vulnerabilities, and target solutions to address the root causes of those issues. As the saying goes, “If it hurts when you do that, stop doing that”. If what we have done in the past has hurt our customers by creating vulnerabilities requiring security bulletins, we want to stop doing that. J
The challenge in using a plethora of individual detailed metrics such as I describe above (that we do internally at Microsoft for measuring SDL compliance), is that they don’t roll up into a nice aggregate score that customers can easily understand. However, they have translated into reduced numbers of vulnerabilities as Michael Howard wrote a few weeks ago. Coupling these types of scores with assessment of compliance with “security functional requirements” might be the basis for coming up with a metric that is useful to customers, both in the government and private sector.
What do you think?
Hi everyone, Bryan here. I’m speaking at BlueHat today and tomorrow about some of my experiences as a new Security PM here at Microsoft. I’d like to take this week’s blog entry to share some of my presentation with those of you that can’t make it in person. For those of you who are planning to attend, be sure to find me and say hi, and stop reading this blog entry! You’ll ruin the surprise. J
Today, the single biggest threat to Web application security is the Cross-Site Scripting (XSS) vulnerability. In fact, I’ll go so far as to say that XSS is the new buffer overflow, the Public Enemy #1 for Web applications. With a successful XSS exploit, an attacker may be able to accomplish all of the following:
· Hijack the victim’s application session and impersonate him/her
· Phish the victim’s username and password
· Log the victim’s keystrokes and send them back to the attacker
· Forge malicious requests with the victim’s authentication credentials
· Create a worm that will attack not only the victim but all of the victim’s email contacts, and all of their contacts, and so on
As bad as XSS is, it’s just the tip of the Web vuln iceberg. Let’s look at what OWASP considers to be the Top Ten list of the most important web application security issues:
1. Cross-Site Scripting
2. Injection Flaws
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross Site Request Forgery
6. Information Leakage and Improper Error Handling
7. Broken Authentication and Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure to Restrict URL Access
Looking at this list, we address Cross-Site Scripting issues in the SDL very thoroughly today: we have several XSS detection and prevention tools our development teams use to defend against XSS attacks. (As I’ve written here before, some of these tools are Microsoft-internal, but some are publicly available; I highly recommend that you use the ones you can.)
We also have guidance for preventing SQL Injection attacks, the most common form of injection flaws (#2 on the list). In a nutshell, our recommendations here are to: use parameterized queries/commands when possible; deny access to underlying database objects and use views or stored procedures to perform the data access; avoid using EXEC in stored procedures; and avoid using ad-hoc concatenated SQL statements at all times.
Next, we also have requirements concerning the use of cryptography, and a list of mandated cryptographic algorithms and key sizes (currently: AES >= 128 bits for secret-key ciphers; RSA or Diffie-Hellman >= 2048 bits or ECC >= 256 bits for public-key ciphers; SHA2 for hashing; and >= 128 bit key lengths for HMACs) for new code. This pretty much covers #8 on OWASP’s list, “Insecure Cryptographic Storage”.
As for the rest of the OWASP Top Ten list, we still have some work to do to more fully incorporate it into the SDL. Why is this? The nature of the Web application security space is that it changes very rapidly. Three of the top ten items (#3: malicious file execution, #5: cross-site request forgery, and #9: insecure communications) are new items that didn’t appear on the previous list. And items that were on the previous list were removed from this list – in fact, even the previous #1 most important issue (unvalidated input) does not appear in the current top ten (perhaps because it was deemed to be too generic). It’s possible that some security researcher will drop an 0-day at Black Hat, or Toorcon, or some other security conference that will completely change the vulnerability landscape and be next year’s new #1 top vuln.
Furthermore, it’s not just that Web vulnerabilities are churned out in record time, but Web applications are too. Web apps don’t have two- or three-year long release cycles like box products. They have two- or three-week long release cycles. This presents something of a dilemma from a security standpoint. We can’t and won’t allow our software to be releas