Hey all - Dave here...
In the interest of giving Adam a break on the threat modeling series, I thought I'd take this week and give him a breather. As much as I like him blogging about threat modeling, I like him driving our tool development efforts even more...
As we have alluded to many times in the past, our success with the SDL has been predicated on a number of factors - however I'd like to focus on one very important factor - namely executive support for the work that we do.
One could argue that the support we receive from executive management is borne out of necessity - if we truly mean what we say when we talk about our commitment to protecting customers, we damned well better have the people and processes in place to deliver on that commitment. There's more than a grain of truth to that notion - however, for us to grow the SDL (and by proxy, our other security and privacy initiatives) we need to deliver value to the executive suite beyond simply maintaining the status quo.
Our success has been borne out by a lot of hard work by folks all across our organization - providing timely, accurate information to our customers, continuing our outreach to the security researcher community, helping product groups secure their products, improvement of our tool suite, and of course, continuous improvement of the SDL. At the end of the day, the work being done by the various teams in Microsoft's Trustworthy Computing group provides value (IMHO) well beyond the primary goal of protecting customers - the whole is truly greater than the sum of the parts.
The people in our group have a lot of ideas about how to make our security efforts more effective - "smart," "practical," "wild," or "extraordinary" are all reasonable adjectives to apply to the discussions that take place on a daily basis here - which leads to my next point. Since we have done an excellent job earning the trust of our management, we find ourselves happy victims of the old adage: "Be careful of what you ask for, you may get it..."
Our group - Security Engineering and Community (SEC), the home of the Microsoft Security Response Center (MSRC), Secure Windows Initiative (SWI) and the Security Development Lifecycle (SDL) - is expanding; despite the increased societal awareness of security and privacy, our commitment (and desire) to protect customers has not waned one bit. As a result, we have some great opportunities for talented Program Managers, Developers and Testers who are passionate about security and want to make Microsoft products and the ecosystem as a whole as secure as possible.
If you're a motivated type with strong security chops and looking to make a difference, you can find the list of open positions on the Microsoft Career Website. Here's your chance to contribute your own smarts, practicality or wildness (!) to the experience that is SEC.
As I mentioned above, our parent organization is the Trustworthy Computing group - so if none of these opportunities suit your fancy, you might consider expanding your search to see the other open positions in our org.
Job Title
Job Code / Search Link
Program Manager - Microsoft Security Response Center
185585
Program Manager - Security Tool Development
203157
204145
Software Development Engineer in Test - Security Tool Development
207441
Software Development Engineer - Penetration Testing Team
207643
Software Development Engineer - Security Science Team
207816
Program Manager - Security Development Lifecycle, Agile Development Practices
208141
Program Manager - Security Development Lifecycle, Security Tools
208143
Program Manager - Security Development Lifecycle
208144
Software Development Engineer - Windows Security Assurance
208899
Director - TwC Excellence
208661
On a final note, Adam plans to write at least a couple more posts on threat modeling - so stay tuned. We are winding down for the Thanksgiving holiday so we will not be posting next week. Enjoy your Turkey Day!
No, it’s not a post on why Adam should never volunteer to do a 12 part series on threat modeling, but rather, why inventing your own mitigations is hard, and why we suggest treading carefully if you need to go there.
Let me first explain what I mean by mitigations because apparently there’s some confusion. We have folks here at Microsoft who call things like the /GS compiler flags "mitigations." When I talk about mitigations in a threat modeling context, I mean things that prevent an attack from working. For example, encryption mitigates information disclosure threats. If you use a strong cryptosystem, and you keep your keys secret, attackers can’t read your data.
Next, why would you need to go there? Often times you don’t. The problems that we face in building software projects are often similar to the problems that other software projects have faced, and we can learn from their successes and mistakes. There’s been a fair amount of good work done in patterns in software, and we even have design principles that we can use. Sometimes, the work being done is really new and different, and there’s a need to create innovative mitigations.
The security experts in the audience are cringing at the very idea. They know that this often ends in pain. I’d like to explain why.
Designing security mitigations is a skill. If I’m trying to design a database, my personal lack of database skills will be obvious: it will be slow, it might lose data, and we’ll discover there’s a problem very quickly. In contrast, if I’m designing a cryptosystem, I might not be able to break my own design. This is a common situation for amateur cryptographers. They build a system which they can’t break, but when an expert looks at it, it’s no more reliable than a fish in a blender.