Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
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.
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 vulnerabilit