Hi, this week is a post from Michael Howard and Laura Machado de Wright, who both attended and presented at TechEd 2008 in Orlando the week of June 2nd.
First up is Laura.
I have been a Security Program Manager for the last 3 years, working as a security advisor for a variety of products across Microsoft and the last seven months as a member of the SDL policy team.
It’s been a few years since I’ve been to TechEd, and this was my first time attending as a member of the security team. TechEd is now a two week conference, with one week dedicated to developers and the other to IT professionals. I think that breaking down the conference into a Developer week and an ITPro week was a good idea, and it allowed us to have good conversations with people who wanted more information about the SDL. I did two main things at TechEd:, I presented on threat modeling, and I spent a lot of time talking to customers at the SDL booth. At the SDL booth, we heard questions ranging from “What does the SDL stand for?” to “Our Web site was hacked; how do I stop it from happening again?” It was encouraging hearing people interested to hear more specifics about how we implement the SDL at Microsoft, and thinking through how they can apply it in their own companies. My understanding from other TechEd veterans in our booth is that interest in the SDL seemed higher, which is great.
During my Threat Modeling session, , most of the feedback and follow-up questions were similar to the ones in the booth: how to expand the threat modeling processes to their own companies, and how to get started.
My typical response to both questions is to start small and do what makes sense for your organization. At Microsoft, for example, when we introduce new SDL requirements, we usually start with a few teams so we can refine the requirement and supporting tools before expanding the requirements to a broader group. Similarly, while we have a core set of requirements that all teams have to meet, there are other requirements that are specific to a platform, scenario, or functionality. For example, there are some requirements that make sense for desktop-oriented products, but do not make sense for mobile devices. You may very likely have to make changes to our policies to make them relevant to your organization, your scenarios, and functionality.
Now over to Michael.
Hi, Michael here.
One of the joys of presenting at TechEd each year is hearing from real people about the issues they face using our products in the real world; rarely are the issues pure philosophical security geekness. This year I gave two talks and one “chalk talk.” The talks were “Top Ten Strategies
To Secure Your Code” and “How To Review Your Code
and Test For Security Bugs”, and the chalk talk, which was a lot of fun, was simply answering numerous developer questions.
It’s interesting to gauge overall security awareness from our customers, and there is no doubt that over the years, the level of security knowledge and maturity has risen. I think it’s possible to evaluate overall security maturity by the questions posed. Some years ago, security was never really a topic of discussion other than those that relate to security technologies, such as how to use and manage X.509 certificates. About four years ago the tide really changed and people started asking more questions about “secure” application deployment and management, and developers wanted to learn more about securing their code; especially C and C++ code. Even then there was still a reliance on exterior defenses like firewalls. All too often I would hear people claim that they don’t need to focus on securing their apps because a firewall was in the way. Heck, David and I documented this excuse in the original version of Writing Secure Code (Appendix D, “Lame Excuses We’ve Heard, #6, ‘We’re Secure-we use a Firewall'”) way back in 2002.
Fast forward to 2008.
Things have obviously changed. I don’t know if finally the security message is getting through because many people asked me highly specific questions about securing their apps and how best to use the defenses we offer in Windows Vista and Windows Server 2008.
I still hear the firewall excuse a little, but not too much!
Perhaps the most telling trend I saw this year was a great deal of interest in the SDL. Not cursory, “that looks interesting” interest, but, “how can I implement this in my company” interest. After answering specific questions, I pointed most folks to Jeremy’s “Crawling Toward SDL” post on the subject.
In my opinion, getting to a point where you want to change your development process shows you really understand there’s an issue that needs fixing.
And that’s goodness.