Adam Shostack here. We think of the SDL as a cradle-to-grave process, where we build security into the product from conception until the end of support. One part of that process that doesn't get much attention on this blog is how we engage with vulnerability reports. We work very closely with the Microsoft Security Response Center (MSRC) and the Microsoft team in charge of relationships with security researchers to better understand what issues are turning up in our products and what researchers are doing with them. The relationships aren't always perfect, but we work very hard to ensure open channels for dialogue. We do this because at the end of the day, we would like to improve computer security, and researchers share that goal.
Even when researchers such as Ed Felten send us potential vulnerability notices a week before releasing them to the public http://blogs.msdn.com/si_team/archive/2008/02/25/protecting-bitLocker-from-cold-attacks-and-other-threats.aspx, we like to talk to them on two important levels. The first is technical: what did they find, and can they help us reproduce it? The second is logistical: what's their timeline for disclosing a vulnerability, and how can we all work together to release guidance or protection for customers? Ideally, we do that in concert with the researchers and thank them for their responsible disclosure. For this issue, it didn't work out that way, mainly because the story broke as we were analyzing the report.
While these conversations aren't always comfortable, we've learned it's much better to have them on a technical level than on a legal level. They're also better on a person-to-person level, rather than being mediated by attorneys. http://feeds.freedom-to-tinker.com/~r/freedom-to-tinker/~3/253302555/. Research into security issues helps us improve our products. Collaborating around that research, and doing so in a civil and mutually respectful way, is even better. That's why we invite folks like H.D. Moore to our BlueHat conference. We recognize that MetaSploit is both valuable and also worry about how it might be used, but we're all better off when we talk to each other. We create the foundations for trust.
One of the things I found fascinating in reading the California and Ohio voting system reviews was the lack of mention of this tension. (I didn't read all the reports-did I miss this somewhere?) I think a key recommendation to the states should include a more transparent process for review, better reporting of issues and better vendor responses to issues when they're reported. What's better? That's for the community to figure out. We can't dictate it, it has to involve give and take over a series of conversations about what's important and why.
When we look at voting systems http://blogs.msdn.com/sdl/archive/2008/02/04/more-trustworthy-election-systems-via-sdl.aspx , we think about trustworthiness not only in terms of the technology, but in terms of the cradle-to-grave processes. As citizens, we would feel more trust in our voting systems if we knew the people creating them took that same approach.
Hello everyone, Shawn Hernan here. I used to work on the SDL team, and I might have been a regular contributor to this space, but instead I joined the SQL Server security team. Ralph Hood, Microsoft SDL guru, asked me if I would contribute a post about “Life on the other side,” talking to what I’ve learned about the SDL from this new perspective -- sort of the reverse of his recent post. I couldn’t turn down the opportunity.
First, let me say what I knew about the SDL going in: no policy can anticipate every situation; you have to make tradeoffs; the details matter; the big picture matters; you need tools; you need human insight; you need management support; and we’re never going to be perfect. All of the things you’ve read in this blog are true, and they really shouldn’t be controversial. Since joining SQL, I’ve learned a lot about SQL Server too, and what it means to ship a product - but that’s outside the scope of this blog. So instead, I’ll try to describe three real experiences that illustrate things that shouldn’t be controversial either, but aren’t usually covered under the rubric of security. They are crucial nonetheless.
Security is not the point, it’s the needs of the customer. It’s easy to believe that security is the point of producing a product. It’s not. We won’t produce an insecure product, but the primary driver for a product team is to produce a valuable, useful product. Yes, security is a big part of that, but security is not a goal in and of itself. For example, one of the areas of fierce competition in enterprise database products is performance, and we have to balance security with performance. One of the ways we do that is by verifying data we receive really well, but only when necessary. We define clear trust boundaries, and check the data thoroughly once on the way in, and then work very hard to enforce those trust boundaries.
I first encountered this in SQL when I helped review threat models for the database engine. The engine trusts that the data on the disk was written correctly by a trusted entity (with checksums to guard against random errors), and enforce that. Instead of a slavish adherence to the principle of total mediation or defense in depth, which, when taken to its extreme would say to “check everything, every time,” we are hard core about making the right checks, but only the right checks.
I will note that it is not an either/or choice between security and performance – it is possible to do both. Indeed, I would say that doing one without the other is pointless, but to get both 1) world class performance, and 2) world class security, you have to understand your data flows really well, and make detailed decisions.
Be polite, but don’t be afraid: Job interviews at Microsoft can be challenging. When I interviewed for this job, my final interview was with a very senior architect. The subject of integer overflows came up, and he asked me to describe the problems and solutions. So I started writing some code on the whiteboard. After about 10 minutes of describing my approach to integer overflows, he said to me, “What if I were to tell you that’s a really bad solution, and the interview is over?”
My heart sank.
But instead of rolling over, I said, “well, that’s a bad outcome, tell me why.” He proceeded to attack my solution on several grounds, including being unreadable and unmaintainable, and he proceeded to describe his solution to the problem. Now, this was a very serious, very senior technical architect, and I was in a high pressure, asymmetric situation. So, not willing to be intimidated, but unable to attack back, I pointed out several shortcomings of his solution, politely, but firmly. And we spent the next 40 minutes talking about various aspects of the problem, and me defending my solution, which I think was credible. I don’t know if he agreed with my solution or not, really, but I suspect it might have been a test to see if I would cave. Or maybe he thought it really was a bad solution, I don’t know. But I got the job.
As a security professional, you’re always going to be at a technical disadvantage when you’re reviewing another team’s components. They designed and implemented the system. You are an outsider, and it is absolutely impossible to understand the system to the degree as the people who built it. Nonetheless, you’ve got to find a way to ask hard, probing, impolite and sometimes even uninformed questions without being threatening or insulting, or undermining your own credibility.
Be polite, be firm, put your ego in a box, and ask questions until you understand.
“It should work” is not a good answer: We take the giblets problem very seriously, and managing giblets can be quite difficult at times. And in SQL, we have lots of giblets. We consume things from Windows, and Office, and Visual Studio, and others, and we provide giblets to other teams as well. In fact, we provide components that other teams use to build the giblets they provide to us – we consume our own giblets!
And as it happens, one of the components we use was updated recently. Even though it would get serviced through Microsoft Update, we want to ensure we have the latest and greatest version of any component we ship. But to consume the latest and greatest version of this particular component would require some small updates to either our installer or theirs. So we met with the team that owns the giblet in question to try to divvy up the work, and to avoid schedule disruptions on either side.
There was a lot of back and forth about various things to try, and we continued to refine a solution until we had reduced the problem to a single issue.
At this point, there was an air of hope in the room. If the idea actually worked, we had a solution at relatively low cost. But would it work? When the question of “will this work” comes up, all eyes turn towards test managers.
Our general manager was looking right at our test manager and she asked, “Will that work?” The test manager looked across the table at the development manager from the other group, and said, “I don’t know. That depends on their level of confidence in the behavior of their component under these conditions.”
Now, all eyes were starting at the dev manager, and the room got quiet. A somewhat sheepish look came over his face, because he knew the answer he was about to give would be unsatisfactory. He said, “Well, I’m not a tester, I’m just a developer, but it should work.”
At which point the room erupted into hysterical laughter.
“It should work” means “I think so, but we have to test it.” And that means the whole battery of tests for each of the affected components, across all of the supported platforms. And that has to be scheduled in test labs. To be clear, this wasn’t a lack of confidence in the developer, quite the contrary, he was laughing along with everyone else. We just know that writing software to satisfy all the scenarios in which our software is deployed requires far more testing than can reasonably be performed on a single desktop system.
So the tests were scheduled, the developer was proven correct, and we’re picking up the latest version. Even seemingly simple changes require a lot of testing.
So, that’s what I’ve learned: security isn’t the be-all-end-all,, things are really complex and hard to understand, and you don’t really know if anything works until you test it. None of which should be controversial, but none of the central ideas in the SDL are controversial either. The hard part is putting theory into practice, and recognizing that no venture is risk free, despite the natural inclination of security engineers to avoid any risk whatsoever. In this, I am reminded of one of my favorite books, “To Engineer is Human: The Role of Failure in Successful Design,” by Henry Petroski. He writes, “No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts [and are] constantly striving to do more with less. [] The engineer always believes he is trying something without error, but the truth of the matter is the each new structure can be a new trial. [] Such is the nature not only of science and engineering, but of all human endeavors.”
Adam Shostack here. Blogger Ian Grigg has an interesting response to my threat modeling blog series, and I wanted to respond to it. In particular, Ian says “I then would prefer to see the threat - property matrix this way:”
I wanted to share an additional table from our training, and talk about repudiation a bit more.
Actually, I’d like to repudiate the term “repudiation.” It’s an awful name that most people never run into in day-to-day life. It doesn’t hit the simplification bar the way say, “denial,” would. Unfortunately, STDIDE (Spoofing, Tampering, Denial, Information Disclosure, Denial of Service, Elevation of Privilege) doesn’t make a very memorable acronym. Memorable is important when training people. Our reviewers have raised this as an issue, and ’d love to get feedback from our readers. How can we ensure that the software we build has the right level of logging and audit-ability? What evocative words can we use, and can you help us come up with a word or phrase that starts with R? Let us know!
And then, here’s the chart:
(Ian’s post is here https://financialcryptography.com/mt/archives/001013.html . IE users will see a warning about certificate authorities when visiting this site. As I wrote this, Gunnar Peterson added commentary at "Threats, Mechanisms and Standards.")
Hi, Ralph Hood here. I should probably take a minute to introduce myself since this is my first official SDL blog post. I’ve been a program manager at Microsoft for almost nine years. In past roles at Microsoft I was the lead program manager for security response in the Windows Sustained Engineering group, and in my last role I was a project manager in the Microsoft Auto group that partnered with Ford Motor Company to create the SYNC device. I joined the Security Engineering and Communications group in early November of last year as a program manager on the SDL team. My primary responsibility on the SDL team is coordinating the internal update and change process for the SDL inside of Microsoft to ensure we are always looking at new processes and technologies to further enhance the benefits of the SDL.
In the Microsoft Auto group we spent a lot of time trying to figure out what the SDL meant to our product. We knew we needed to do threat modeling, primarily because threat modeling is probably the most commonly known requirement of the SDL. Beyond threat modeling though, members of the various disciplines in our product team didn’t know what parts of the SDL applied to our product and what parts applied to technologies, platforms, or programming languages we didn’t use and thus could safely ignore. One of our program managers set out to sift through the SDL requirements and associated tools to try and determine what was applicable to our environment. While we eventually made the right decisions on what SDL requirements we needed to focus upon, we spent more time than we would have liked trying to figure it all out.
With our most recent update to the SDL at Microsoft we’ve made one significant change to try and help in this scenario. That change is to take all of the SDL requirements and plug them into a filterable framework that allows a person or a team to match requirements with specific technologies. Now, instead of being presented with a large document that covers all SDL requirements, a team is presented with a dynamic Web site that allows them to selectively filter requirements based on their product type (Client, Server, Hardware, Online Service etc), code type (Native, Managed, JavaScript etc), platform type (Win32, Win64, WinCE, Mac etc), or applies to their specific role (Program Manager, Developer, Test Engineer, Operations, etc).
This means if I’m a program manager for a Win64 Client product, I can view just the SDL requirements that apply to that criteria and the result is a clearer starting point for what you need to do to begin adopting the SDL for your project. This applicability filtering also allows product groups to more easily divide up the responsibility for ramping up on the SDL instead of overloading a single person in their group with figuring out what needs to be done. For instance, a product group could assign a person from each discipline in their team to identify which SDL requirements need to be met and at what point in the product cycle. A program manager can now more easily identify the SDL requirements that need to be thought about and met during the Requirements phase of a product, and likewise a test engineer can identify and begin working on the test collateral for SDL requirements that will be needed later in the schedule during the verification phase.
As the SDL continues to grow to address evolving security concerns and new technologies, it’s necessary for the SDL to be able to scale and have this type of filtering in place. Enhancing the functionality and depth of our tools that we use in the SDL is an ongoing process. These tools don’t always apply to every code type or product type. We have test tools that only run on native code while other tools run only against managed code, and that’s just one example. It’s important that we leverage a filterable framework like we have to address these differences and help teams understand where they need to focus their resources and what just doesn’t apply to their product or technology.
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:
· 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.