Eric Bidstrup here.
This year at Blackhat in Las Vegas, there is an interesting title for a session that caught my eye: “Iron Chef: Blackhat”. The presenters will be running static and dynamic analysis tools on code to find vulnerabilities. While this will likely be entertaining theater (I’ll likely attend) and an Iron Chef may be able to cook interesting culinary delicacies in an hour on TV, expecting to secure code in an hour is half baked at best. I realize that this event is not being positioned as a 100% solution to secure code in an hour – and I’m sure that those presenting do too – but the Iron Chef analogy does seem to imply that something useful will be done in an hour. I want to be clear I'm not picking on this presentation specifically. Instead I wanted to consider the approach and the mindset, which I think is far too common in the industry.
This cooking/coding analogy is similar to many discussions I’ve had with various people with responsibilities for managing software development efforts. Those discussions usually boil down to “Trying to do everything described in SDL is too costly and/or hard, can’t you just let me know the highest yield activities/tools”. My response is always that any effort to deliver secure software is more effective than no effort, but the primary reason SDL has been successful is that no single method, tool, or process is perfect. The sum is greater than the parts. (By the way, I’ll even include SDL in the scope of that last statement – it is not perfect either, but it does include self correcting processes to examine where it fails so we can learn to accomplish better results and continually innovate to address gaps.)
In the early days of the Trustworthy Computing Initiative here at Microsoft, the SDL started from the security “push”(es) that were done for the .NET Framework and Windows Server 2003. Many people with many eyeballs spent many days reviewing many lines of code and running the analysis tools we had available, and this certainly had an appreciable impact on improving the security of that those releases. However, the single most important lesson from that experience for the development and evolution of SDL was that secure development practices have to be an ongoing activity. A “push” (or an Iron Chef cook-off) is somewhat like cramming for a final examination. It can certainly help, but the student who applies effort consistently will be better able to accomplish their goals without having to rely upon such concentrated efforts. There have been many studies of software engineering that have shown that it’s far more efficient and cost effective to address deficiencies as early as possible, preferably never allowing them to get into code in the first place. Security is no different; the most effective means of eliminating vulnerabilities in software is to never allow them to occur in the first place. And to the software managers I mentioned earlier who are concerned over the costs of SDL – it’s not only more effective, it’s also cheaper to do it this way!
Security vulnerabilities can result from a variety of different causes. The size and complexity of software continues to increase, and isn’t likely to decrease any time soon. When considering all possible sources of vulnerabilities in complex systems, a methodical approach is the ONLY strategy that has a chance of delivering the desired results. Careful analysis of possible design vulnerabilities early in the development process, understanding attack surface and giving it high levels of scrutiny, informed use of code analysis tools (and understanding their limitations) and other code quality techniques, executing thoughtfully designed test plans, and (last but not least) leveraging defense in depth mitigations are ALL vitally important in attempting to deliver the most “iron clad” code possible.
An Iron Chef will get you four or five good dishes in an hour. Iron Chef Blackhat might give you four or five good bugs. Secure software takes more time. I certainly wish those presenting good luck in the presentation, like I said earlier - it's one of the ones I will try to be at.
Bon Appetite.
As James wrote up the previous posting on “Why the SDL works”, it generated some interesting discussion. It was fascinating for me to see the perspective from James’ point of view as an experienced security professional that semi-recently joined Microsoft, and compare it to mine as an “old time” Microsoft person who has been driving SDL policy for the last several years. I have to concede that James is correct in that there has been a culture shift and it’s a lot harder for those of us who lived through it to fully appreciate how much change has indeed occurred. However, I have a different perspective and hence the reason for this posting. I’d summarize “why the SDL works” in four key reasons:
1) Management support and commitment in allocating resources
Regardless of what you build (software or otherwise); deciding what to build, how to build it, actually building it, testing it, delivering it, and supporting it all takes time, energy, and resources. The longer the list of requirements “it” is expected to satisfy – the larger the amount of time, energy, and resources that will be needed. So, you also want it to be secure? Better make time, energy, and resources available for that. It helps to have the boss “sign the check” and support how you spend money. Not very technical to be sure, but also critically important to be successful. There are no free lunches…
2) Provide explicit directions and as much automation as you can If you want people to do something, it’s a good idea to tell them what you want them to do… …and telling them how they can best do it doesn’t hurt either. Tools help too!
Most people with a given job to do are pretty receptive to receiving instructions on how they can most successfully do it. Getting the benefit of previous learning experiences on good and not so good ways of meeting a need never hurt anyone. If you give them tools that can help optimize their efforts even more… You get the idea. Related points: Unless the problem you are solving is extremely well understood and there is a widely accepted solution that addresses the problem (security isn’t quite there yet) – remain receptive to feedback and be willing to continue to invest in innovation, improvements, and opportunities for greater efficiency. Similarly, continue to critically evaluate how effective the tools and processes are in actually solving the problem you care about. Measuring the “effectiveness” of a given tool in identifying vulnerabilities is actually an extremely hard problem in optimizing for a minimum number of false positives (that engineers have to spend time on to verify as false positives) vs. avoiding “false negatives” (failing to identify actual vulnerabilities). Perhaps I’ll discuss this more in a subsequent blog post…
3) Use measurements and metrics to communicate about successes and issues
SDL covers a variety of development activities spanning all aspects of the software development process. Measuring some of those activities is harder than others. Validating some elements of SDL is relatively straightforward (ex: ensuring that C/C++ code was compiled with a specific version of a compiler, and validating that the /GS option was used). Validating other elements of SDL can be very challenging and/or labor intensive to verify (ex: ensuring that threat models reflect software as built, have considered all known/meaningful risks, and appropriate mitigations exist). It’s important to both consider how the development team validates that they are doing what is expected of them as well as considering how validation can be done outside of the development team. Measuring the security of software and the effectiveness of development practices intended to deliver more secure software are both really, really hard. Don’t expect perfection anytime soon, but it’s important to think about how each tool or process can be monitored to ensure that it is being successfully applied. If you can’t measure it, how do you tell if you’ve done it?
4) Stay current with changes in security. Attacks and methods change, so should you.
It’s interesting to consider that when Michael Howard and David LeBlanc wrote the first edition of “Writing Secure Code”, it didn’t contain references to either SQL injection attacks or integer overflows. The reason for that is no oversight on their part, but rather is a reflection on the fact that such attacks were unknown when the first version was written (and those familiar with WSC will see that both were added for the second edition). Time passes and stuff happens. Count on it. There is a lot of very impressive research and development done by an ever increasing number of security researchers, so the security landscape will always be changing. It’s important to stay current and pay attention; this is a dynamic and rapidly evolving field. You snooze, you lose (or more importantly, your customers could lose…).
In late 2005 I gave a talk on SDL at a university symposium in Germany. When I was walking out of the auditorium, I was walking behind a few students who were discussing my talk. (I’m pretty certain they didn’t notice me in the crowd behind them). One student said “I was really expecting to hear about new innovation Microsoft is doing in security, but his talk just described a lot of focus on engineering fundamentals and learning from security researchers”. While there are some interesting innovations in the specifics of SDL tools and processes, at the conceptual level that summary is not an unfair characterization. There is an amazing community of talented security researchers who are constantly advancing the state of the art in security, and it’s important to pay attention to research and think about how to apply that knowledge in order to protect our customers who purchase our products. Those who do not learn from the past (and present!) are doomed to repeat it.
…and keep patching.
James Whittaker here.
One of the first things I did as a new Microsoft employee was tour the company and meet with, literally, dozens of groups that are implementing the SDL. Before joining Microsoft, I had heard many firms claim their passion and commitment to security, and I‘ve always been a little skeptical about big players saying they’re doing something because it is the right thing to do, particularly when the right thing to do requires very serious and long-term dedication. For my part, I was determined to find out the real story behind the claimed turnaround in Microsoft development practices that occurred under the SDL banner. As an employee I would be granted full access to the data and hear the story as it really exists. No official messaging, just the facts.
The question I sought the answer to is: “does this stuff really work and, if so, why?” What place does security really hold in the software development process?
I admit I went into this endeavor with specific expectations. I expected that the mandate from BillG (in his famous Trustworthy Computing memo of 2002) would play a major role in the attitudes of our engineers. After all, having no choice in the matter is a strong behavioral change agent. Also, I was actually hoping to find that the process provided a structure to their work that developers actually welcomed.
But I could find no evidence of either. There were no managers transcribing the mandate on a stone tablet and using it as a license for the wholesale slaughter of sacred coding cows. There were no program managers with clipboards telling developers and testers how to do their job. In fact, the mandate was never mentioned. The process was never worshipped. What really seemed to have caused the change was a real concern for customers and a determination to do everything possible to prevent the kinds of issues they’d been facing over the years because of insecure software. (It’s a constant battle too given that the majority of universities ignore security in their curricula and that education is left up to us. As a former professor, this aspect of my new industry career really hurts.)
It was that attitude that caused a cultural shift across the company. And I believe that more than any other factor, it was this cultural shift that helped the SDL take such a firm hold throughout our developer, tester and program manager ranks. The mandate helped, the process enabled, but it was the sheer determination of the program managers, developers and testers to address customer demand for better security that caused many of our products to improve so dramatically. That fighting spirit is embedded in the SDL as technical mechanisms to make our software more difficult to break. Our engineers are determined to build software that causes adversaries to work inordinately hard to compromise and that sets a high bar for our competitors to match.
Security is not just a word, it’s an attribute that our customers care deeply about and that will make our products more competitive. The SDL is about satisfied customers and increasingly it’s about competitive advantage. Our engineers understand that and they’ve internalized it.
The SDL works because a cultural change has happened at Microsoft. Innovation, security, customer experience are all so tightly intertwined that we don’t think about them as separate entities. We don’t do the SDL because we have to; we do it because we do it. Word is getting around, the cultural change is spreading. The clipboards have been thrown out and the natural resistance to change has morphed into a development culture centered around a secure customer experience.
The answer I sought had nothing to do with mandates or subservience to process. Security has assumed its proper place in the software development process: a natural consequence of designing, writing and testing code. The next step in this evolution will be when we stop talking about the SDL and simply call it software development.