Bryan here. Last January, I wrote a post on this blog bemoaning the difficulty of making security interesting and “sexy” to developers. Applied research conferences generally place a much greater emphasis on revealing new vulnerabilities and new attack techniques, and much less emphasis on educating people on how to actually fix those vulnerabilities. I was at RSA Conference last April, and I attended a session by a very well-regarded, high-profile security researcher. He gave an eloquent and educational presentation on the dangers of a significant new attack vector, but all the prescriptive guidance he gave for dealing with the threat amounted to something like, “If you’re worried about this kind of thing, talk to your browser manufacturer.” No offense to this presenter, but if I’m going to listen to 70 minutes of discussion of a dangerous threat, I want to leave the room with a clear understanding of what I can do to solve the problem! It’s not enough just to know that the problem exists.
So, in conjunction with the BlueHat team, I am pleased to announce that the SDL team will be organizing the sessions for the second day of the fall BlueHat conference. The BlueHat SDL sessions will be laser-focused on not just describing vulnerabilities but also solving them. Every attendee should leave every presentation with a clear idea of exactly what he or she needs to do to protect themselves from the threat that was discussed during the session.
The sessions will begin, appropriately, with the topic of secure design. Danny Dhillon of EMC and the SDL team’s own Adam Shostack will each present their organization’s approach to threat modeling. As a bonus, Adam will also be demonstrating the new SDL Threat Modeling tool that you might have heard about last week.
Next up is Matt Miller, a recent and very welcome addition to the Microsoft Security Science team. Matt has a fantastic presentation on the evolution of buffer overflow attacks and on the corresponding development of overflow mitigations. From there we will switch gears to look at some managed code implementation issues: iSEC Partners’ Scott Stender and Alex Vidergar will demonstrate coding techniques to mitigate elusive concurrency vulnerabilities in web applications.
At this point we will have covered the Design and Implementation phases of the SDL; where better to go from here than Verification? One of the most important activities in the Verification phase is fuzzing, and we have a trio of security experts from the Microsoft Security Science team to talk about it. Jason Shirk, Lars Opstad, and Dave Weinstein will answer three of the most common fuzzing questions: How should I fuzz? When have I fuzzed enough? And what do I do now that I’ve fuzzed?
Finally, we will wrap up the Verification phase talks with a return appearance to BlueHat by Stach & Liu’s Vinnie Liu. Vinnie will compare different approaches to security verification – static code analysis, blackbox analysis, and manual code review – and make recommendations as to when each approach is best used.
Even if you can’t make it in to BlueHat in person, you can still watch the sessions via streaming media on TechNet. Additionally, webcast interviews with the speakers – condensed “Cliff’s Notes” versions of their full presentations – will be posted on Channel 9. And we’ll be continuing the BlueHat tradition of inviting speakers and other industry notables to guest blog about their topics and the latest security trends. More information on all of these resources will be posted here when it becomes available.
I expect that a number of you have seen the announcement and various press articles or Steve Lipner's Tuesday post about our launch of the SDL Threat Modeling Tool 3.0, the SDL Optimization Model and the SDL Pro Network. Since I was intimately involved with the creation of the SDL Pro Network, I thought I'd write a few words about our objectives and chat a bit about the thinking behind our partner choices for the pilot phase.
So, what are we hoping to gain by creating a network of security consulting and training experts to work with customers who want to implement the SDL? Generally speaking, this question has a two-part answer: First, Microsoft is, and always will be a partner-driven company - we rely on the skills and capabilities of our partners to provide specialized services and broad geographic coverage for Microsoft products and services. Second, even though there are talented folks in the Microsoft Services organization, it's clear that we will need help from our partners to scale to meet the demand. I can't tell you how many times the folks on the SDL team have been approached by people - after an executive briefing, or a session at TechEd - asking for guidance in implementing SDL in their own organizations. When we look at the demand and pair it with the geographic diversity of our customer base, it's clear that a partner approach is the right answer.
Now a few words about the partners who will be participating in the pilot phase...
After the decision was made to work with partners on SDL delivery, we had two primary criteria that we had to address; partner quality, and manageability of the SDL Pro Network pilot. We have all seen instances where individuals or consulting organizations have represented themselves to the IT community as having security expertise when in reality the "experts for hire" were simply reading a page or two ahead of the customer in whatever security tome was "in vogue" at the time.
Based on those observations, it was clear that partner "quality" was a critical criterion. Fortunately for us, we didn't have to look far to satisfy our quality bar - many of the companies in the SDL Pro Network pilot have direct experience with executing portions of the SDL on our products, or have delivered services to Microsoft in a security context. Design reviews, code reviews, penetration testing, training and other tasks critical to SDL implementation were (and are) common fare for these folks.
Despite the customer demand for SDL that I alluded to above, starting with a small pilot was the right thing to do; a small group of trusted consultancies supports our imperative for quality and it allows us to pragmatically grow the SDL Pro Network as the market matures. As we continue to evolve and innovate with the SDL, we'll have a strong core of partners to help drive the software security message.
Will we grow the SDL Pro Network? The qualified answer is: "When the market demands it..." - there are a number of talented potential partners who meet the quality bar - and clearly, the need for security in software development will grow to demand additional talented specialists. However, it's our plan to begin with a small set of partners of known expertise, and then respond to growing demand as it materializes.
So there you have it - the nuanced beginning and bright future of the SDL Pro Network... I invite your comments, and encourage you to check in at the SDL Portal as we continue to build out the program
Steve Lipner here.
Last week I participated in a “press tour” talking to press and analysts about the evolution of the SDL. Most of our past discussions with press and analysts have centered on folks who follow security, but this time we also spoke with publications and analysts who write for software development organizations. I was struck by the extent to which the folks who focus on development have been grappling with many of the issues about developing secure software that we’ve focused on here at Microsoft.
Security beat reporters, whom we have been working with for years, have been exposed to a regular stream of news on the latest bugs, worms and viruses, and Microsoft’s ability to react quickly to customers affected by those attacks with patches has been the industry story for many years. Last week, I had an opportunity to get out and tell the other side of the story – what we are doing proactively as a major software vendor and platform provider to help eliminate vulnerabilities during the development process. Based on feedback from reporters and analysts who know this space, our work to take Microsoft’s SDL best practices and share them externally has clearly been a need in the industry for a long time.
The specific occasion that motivated me to spend a week in conference rooms, airplanes and hotel rooms was today’s announcement of new initiatives in sharing aspects of the SDL with the development community. These initiatives don’t make secure development a “cut and dried” process, but I believe they will take things one step further toward enabling developers to build more secure software. I’d encourage you to look at our announcements. I’m really excited that we’re taking these new steps to share more of our secure development practices and tools with developers who need them.
As always, we’d welcome your feedback about these new programs and what we should do next.
Hey all – Dave here…
Wanted to drop a quick note to introduce the latest member of the SDL team - Katie Moussouris!
Many of you may already know Katie from her past work on the MSRC Ecosystem Strategy Team or her tenure at Symantec and @Stake.
Katie has joined the SDL team to help drive crucial elements of our SDL outreach effort; her primary responsibility will be managing our relationships with security consulting and training partners. She’ll additionally be tasked with ongoing analysis of the SDL – with a goal of assisting industry verticals that are looking to apply the SDL in critical computing scenarios.
It goes without saying that she will be a regular contributor on the SDL Blog – but given her expertise, it’s likely she’ll continue to blog on an occasional basis over on Ecostrat...
Anyway – here’s Katie in her own words!
Katie Moussouris is a Senior Security Program Manager in the Security Development Lifecycle (SDL) Outreach Team, working to bring Microsoft’s SDL to partners, vendors and customers in order to improve the security of the Internet as a whole. Katie began her nerdy life programming her C64 in grade school, writing her own Zork-like text-based adventure – which was of limited use, since she had no friends and she knew all the puzzles in her own game. Good thing she eventually left her room and found some like-minded people at a local 2600 meeting.
Katie’s professional background is application security, having come from Symantec by way of the @stake acquisition. Katie founded the Microsoft Vulnerability Research Program (MSVR), extending the focus of Microsoft’s security vulnerability research to third party software. Katie also founded and ran the Symantec Vulnerability Research Program, the first program of its kind in Symantec's history to allow the publication through Responsible Disclosure of original vulnerability advisories discovered by Symantec researchers. In addition to performing security research, Katie has been an application penetration tester for Fortune 500 companies across numerous industries. She has uncovered serious vulnerabilities during the course of her work before they could be widely exploited by hooligans and criminals for either fun or profit, respectively.
Bryan here. Since Steve called me out in his post on the XSS Filter last week, I feel obligated to clarify my position. ☺ I believe that the SDL blog is mainly for development teams; after all, development is the D in SDL. Now, development teams are made up of more than just developers. Development teams include everyone involved in the development process from management on down. But development teams don’t include end users. While XSS Filter is a great, innovative XSS defense technology, there’s really nothing that development teams can do to take advantage of it. Users alone make the decision as to whether they’re going to take advantage of XSS Filter: they either use IE8 and get it, or they use another browser and don’t get it.
That being said, there are some interesting implications that XSS Filter and other user-specified defenses have for the SDL. Given that XSS Filter is effective in stopping many types of reflected XSS attacks, should we relax the SDL coding and testing requirements around server-side XSS defense? Of course not. For one reason, the SDL requirements are effective in preventing forms of XSS that XSS Filter does not address, like persistent XSS. For another, not everyone uses IE 8. If we were to relax server-side requirements now, we would jeopardize IE 7 users, as well as Firefox, Safari, Opera, Chrome, and all the other browsers’ users.
But what if these conditions change? What if David and others on the security science team develop a new version of XSS Filter that’s effective against all forms of XSS? And what if all the browser manufacturers develop similar technology and implement it in their browsers? (Or alternatively, what if every user on the planet switches to IE 8? ☺) Then would we relax the server-side XSS defense requirements? Yes, we probably would.
I’ve always been more of a security pragmatist than a security purist. While the security purist in me would want to keep the requirements around to prevent developers from falling back into bad habits, the security pragmatist in me would recognize that development teams have a limited amount of bandwidth, and making them defend against rare, obscure vulnerabilities is a poor use of their time. Unfortunately, we’re not likely to face this scenario any time in the near future, so the SDL will continue to require server-side input validation and output encoding to prevent XSS attacks.
We now return you to your regularly scheduled development-focused blog.