Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi everyone, Bryan Sullivan here.
I’m having something of a dilemma today. An important part of my job is keeping current with security issues so that we can provide appropriate guidance for dealing with those risks in the SDL. A great way to keep current with security issues is to hang out at hacker cons. Now on one hand, I really love hacker cons. I always find sessions that are relevant, I always meet interesting new people and catch up with old friends, the liquor flows freely at the after-parties…there are lots of great reasons. And it’s fun to speak at these shows too. But I have to honestly ask myself, how much good am I doing? If I stand in front of a group of netadmins and pentesters and describe a new method of hacking Ajax apps, what have I really accomplished? I suppose that a few of those people might use my ideas to find vulnerabilities in the field, which is good. But security shouldn’t start with the pentester – after all, you can’t test security into a product. Security should start with the developer, and then continue on with the tester, the pentester, the netadmin, and everyone else in the product lifecycle.
Instead of teaching pentesters how to find vulnerabilities, I’d rather be teaching developers how to write their code correctly in the first place so that the pentesters don’t have any vulnerabilities to find. But, as a general rule, developers don’t really attend hacker cons. They attend developer cons. There are of course exceptions to this rule, but ask yourself honestly: How many people do you suppose really go to DEFCON to learn how to write secure code versus those who go to learn how to break things? Now, I love developer cons too. I always find sessions that are relevant, I always meet interesting new people and catch up with old friends, and while the liquor may not flow quite as freely I still always manage to have a great time. But here’s the dilemma: developers don’t go to developer cons to hear about security. They go to hear about sexy new OS or language or compiler features. There’s nothing sexy about developer security. Nobody wakes up on Monday morning and says, “Wow! I get to go work on developer security issues today! Awesome!” OK, I have to admit that I actually do this – really – but I’m probably an atypical example. For most people, following the SDL is a lot like flossing their teeth. They know they’ll regret it later if they skip it, but that doesn’t make it any more fun right now.
So what can we do to make security a little more fun? What’s the adult equivalent of a Hello Kitty or Power Rangers toothbrush? For better or worse, I haven’t been able to think of one. But maybe we can take a different approach to the problem. What if, instead of trying to make the SDL fun, we tried to make it as painless and unobtrusive as possible? To put it another way: What if, instead of having to floss your teeth yourself, little gnomes came in and flossed your teeth for you while you slept? (OK, that’s a little creepy, but you get the point.) Think about the /GS compiler option in Visual C++, or the ValidateRequest page directive in ASP.NET. These security features provide excellent defenses against stack overruns and cross-site scripting attacks (respectively), and the best part is that developers get them essentially for free. If we can automate enough SDL requirements this way, developers could spend more time implementing new features and less time worrying about security. And that would be truly sexy.
PingBack from http://msdnrss.thecoderblogs.com/2008/01/29/sexy-development-lifecycle/
The SDL blog has some good comments - http://blogs.msdn.com/sdl/archive/2008/01/29/sexy-development-lifecycle.aspx
The SDL blog has some good comments - http://blogs.msdn.com/sdl/archive/2008/01/29/sexy-development-lifecycle
The more of these "automations" that can be integrated into the FxCop/VS2008 "Code Analysis" engine, the better off we'll be.
This complements the /GS flag, and helps reduce the need for "band-aids" around vulnerable code such as ValidateRequest(), by helping the developer flag potential issues in their code the first time they check it in (or whenever their build process automatically runs their chosen FxCop ruleset).
So, it comes down to one core facet of the SDL - tools.
Microsoft is in a unique position (as usual) to supply those tools - I would expect SDL aspects to be rolled right into Visual Studio, Foundation Server, maybe even Project... (and btw, I would expect better integration between the last two...)
I hope that the next version of these products will include this?
Hi Douglen, (Eric Bidstrup here)
Let me jump in to respond. Short answer is: Yes, tools are very important to enable automation and scaling SDL. Actually several tool with origins in SDL have already been released publicly, and you can expect to see more over time. /GS and /SAFESEH support are present in Visual 2005 and later for stack protection and safe exception handling respectively. Leveraging Address Space Layout Randomization is Vista can be enabled using the /DYNAMICBASE flag in Visual Studio 2005 SP1 (or later) linker. For code analysis, FxCop (for managed code) and /analyze (aka "PREfast") are available in Visual Studio 2005 as well.
As we continue to refine and improve tools that do prove effective, we plan to get those into the pipeline for external release in order to enable the development community to create more secure code to help better secure the broader ecosystem...
So why not start a secure development con? Get hackers and developers in the same room. I for one had a blast when you guys had a bunch of your OEMs up for training about the SDL. And then you can have the best of the hacker con and the developer con under one roof.
Bryan here. Last January, I wrote a post on this blog bemoaning the difficulty of making security interesting
A little late because of travel. Secure database authentication in  ADO.NET applications -- This