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.

While attending the SANS event in Orlando this week I had a chance to meet a fellow who works at a company that is a StillSecure customer.  I had never met this particular guy before, so I asked him how long he had been working in security at the company.  The answer I got reminded me of an old quote from the move "The Producers" -

-Who d'ya want? -I beg your pardon? -Who d'ya want? Nobody gets in the building unless I know who they want. I'm the concierge. My husband used to be the concierge, but he's dead. Now I'm the concierge.

This guy had worked at the company for a number of years in the network department. They had a "guy who did the security".  He is the one that bought the StillSecure product.  Evidently a while back the security guy left the company.  It is not clear whether he quit or was asked to leave, but the bottom line is they had no security guy. Instead of hiring another security guy, they made this poor SOB the security guy.  He inherited a bunch of security products including our own and a bunch of "open source stuff".  This guy didn't even know where to begin.

After floundering around for a while, he made a smart move and signed up for some security training from SANS and is just beginning to realize how much he doesn't know.  But it will still be some time before he is in a position to handle the security at his company, that by the way has SOX issues to deal with.  I suggested that perhaps he look into some MSSP service to help him out.  I am going to try and help this fellow out as much as I can, but he has a tall order.

How many others are out there in the same boat?  How many people have had the security role thrust on them, without the training or expertise to make it happen.  The greatest tools in the world, won't make up for this lack of skills and experience.  Is it any wonder that we have a breach a day announced and our security seems to be in such disarray? We should let security be handled by security professionals or else we deserve what we get!