If you have read Michael Howard’s blog for a while, you may recall that our team held a two-and-a-half day SDL training session back in November for fifty senior engineers from a number of the hardware OEMs and some of their component suppliers. At that time, we heard strong feedback from the group that they wanted us to work with other sectors of the IT community, (particularly with ISVs) to get more people attuned to the importance of security development practices. Since that time we have been doing mostly individual engagements – informally briefing and working with customers, partners and others usually on a one-to-one basis.
Yesterday, we held a somewhat shorter version of the November session for an interesting mix of security-focused groups as part of the Microsoft Security Response and Safety Summit (MSRSS). MSRSS is an event focused on sharing information with a number of different security groups that comprise the Microsoft Security Response Alliance and the Secure IT Alliance. Our track was one of two running concurrently – we had forty or so in attendance from government, ISPs, AV vendors, CERTs, security ISVs and the like.
Scott Charney opened the event with a discussion about the evolving threat environment – he emphasized the need for cooperation and information sharing from all the players in the IT security space. After Scott’s call to action, we moved into the training portion of the day. Most of the SDL blog gang presented – Eric Bidstrup provided an overview of the SDL; Adam Shostack discussed the threat modeling process and how it is evolving; Michael Howard did a variant of his “Writing Secure Code” talk; James Whittaker talked about security testing and the final session focused on privacy, with Tina Knutson and Sue Glueck. In November, I gave a talk on the intersection of security policy and development practice – given the time constraint, this time I gracefully accepted the role of emcee and checked hats and coats for the attendees. : ^ )
At first I was a little concerned about the potential for “impedance mismatch” – after all, we were talking about the various facets of security development methodology and this was an event traditionally focused on how to collaborate effectively in a time of security crisis. It occurred to me about half way through the opening talk that it was okay if this wasn’t a developer to developer talk – everyone in the room had “a dog in the security fight” and as a result, it’s incumbent upon us to have as many conversations with folks in the community (regardless of discipline) as we can.
Exposure to these partner groups provided us with interesting perspectives – the attendees asked good questions (a few of them pointy) and many of us were corralled during the breaks for robust discussions on a variety of subjects.
Some of you may be thinking “So what? Microsoft had another security event – whoopee!!” Fair enough. However, in our defense, I’d like to make two points. First, I think it’s mildly amusing that the notion of Microsoft hosting a security collaboration event has become so commonplace – it wasn’t so long ago that Microsoft and security couldn’t be uttered in the same sentence without fits of laughter – it’s interesting how times change. Second, (and of far greater importance) we strongly believe that it’s in the best interest of protecting our mutual customers to work with these groups and share our knowledge. Conversely, it’s an opportunity for us to learn about emerging issues and concerns that we typically aren’t exposed to on a day-to-day basis.
Bottom Line: It was a great opportunity and a practice that we will no doubt carry forward.