Security Curve Weblog

Microsoft SDL: Serve the community, brilliant marketing

If you follow the same blogs that I do, you're probably already aware of the fact that Microsoft is hosting a series of discussions with their OEM partners about the SDL (Security Development Lifecycle.)  First of all, let me say that I'm seriously jealous of these OEM people, since it would be awesome to participate in this training.  However, references to the green beast aside, I think it's an interesting exercise to stop for a moment to consider where Microsoft is going with this whole SDL thing.  Why are they doing this, what are they doing, and what does it mean to security as a whole?

So, for some background...  If you're a developer, you're probably somewhat familiar with the "software development lifecycle" (SDLC.)  For the sake of folks who haven't spent much time in development shops, there are a variety of approaches and techniques for how software development gets done.  All software development shops operate within a spectrum of what CMM calls "maturity", what some might call "formality", and what I call "discipline."  In other words, the process that developers adhere to vary from "undisciplined" shops (usually startups) that try to rush to market without any kind of structure whatsoever.  At the other end of the spectrum, you have shops that use a formalized process that defines how requirements are developed, that ensures that users are invested, and that accountability is assigned.  Of course, there are all sorts of processes along the spectrum:   RUP (Rational Unified Process,) XP (Extreme Programming), SPICE, and so on.  Microsoft even developed their own called the "Microsoft Solutions Framework" (MSF).  I'm not going to go into a bunch of detail here on why it's a good idea to be disciplined - the most I'll say is that (though most developers feel too much process is a pain in the ass) the process really is there to make the developer's life easier.  Although I don't have direct evidence for this, I've informally noticed that the "getting woken up in the middle of the night for some issue" factor is inversely proportional to the maturity of the development shop.  Really, it's true. 

Anyway, the overall goal of maturity (read: "discipline") is to increase the quality and reliability of development.  And it works.  In point of fact, I find that the dynamics are such that there is additional up-front investment in development time for a disciplined approach, but that the long-term gains are quality, alacrity, and reliability.  Now, Microsoft has picked up on something else that I've argued as well - which is that a disciplined approach (if designed intelligently) can also lead to increases in security as well; check out this text from the MSFT overview of SDL:

...there are three facets to building more secure software: repeatable process, engineer education, and metrics and accountability.... If Microsoft's experience is a guide, adoption of the SDL by other organizations should not add unreasonable costs to software development. In Microsoft's experience, the benefits of providing more secure software (e.g., fewer patches, more satisfied customers) outweigh the costs. The SDL involves modifying a software development organization's processes by integrating measures that lead to improved software security.

Now, for anyone who hasn't familiarized themselves with the SDL, I highly recommend that they do so.  It's a great read.  Unlike some folks, I haven't swallowed all the KoolAid...  The Microsoft approach is heavy on the documentation (documentation of attack surface, documentation of threats, etc.) and heavy on the education of developers.  I disagree that this is the most effective approach over the long term; the point I've made in the past is that some activities (such as developer education) require continued investment over time; by contrast, standardization of the development process through the use of a framework is self-enforcing and therefore costs less over time.  To make it really simple, you can educate developers about why they shouldn't do this:

void doNothing(char * somefoolishness) {
    char a[5];
    strcpy (a, somefoolishness);
}

or you can do this once and make everybody use it:

class SafeString {
    SafeString(const char * somefoolishness) {
        myVal = (char*)malloc(strlen(somefoolishness));
    }
    const char * getValue() const {
        return myVal;
    }
//and blah blah blah

or whatever.  (Please don't try to compile that and complain about it, bust my nads about the strlen(), complain about the malloc, or the lack of error checking...  this is a blog for Chris'sakes so cut me some slack and just let me make the point.)  Now, one could argue (and they'd be right) that most of the "secure framework" concepts that I'm talking about are implemented in the .NET System classes (aha!).  If you ask me, MSFT has some master plan over there that accounts for both .NET and SDL.  Or maybe not...  

But anyway, small differences in philosophy aside, I think the fact that MSFT is even going here is impressive.  After all, application security is a topic that most of mainstream security (unfortunately) doesn't care about all that much.  They should, mind you, since I think it's where the majority of the issues are - but the fact that they don't is clear.  Example: do a search for "+application +security +sdlc" in your search engine of choice and compare the results with a search for "+mobile +malware +phone" - notice how the phone-malware stuff eclipses application security by an order of magnitude?  That's my point. 

So why is MSFT going there?  All told, I think it's twofold - internally to them, I think it's motivated by reducing their long-term security-related costs - which it probably will.  So, they're probably investing in their internal processes to realize some efficiency and maintainability gains (and therefore lower costs.)  Smart move.  Externally, though, is where I think the strategy gets brilliant.  Brilliant?  For sure.  Think about the marketing potential here...  can you think of a better way to displace their (unearned in my opinion) reputation for being insecure?  How much marketing would it take for them to give them an image as being a "secure" solution?  Millions?  More, probably.  Not to mention that people would be loathe to take that marketing seriously.  But by becoming the de-facto thought leader in application security - a space that is directly applicable to their product and that is underrepresented in the field?  That's the path right there. And the cost?  a few whitepapers, a book or two, a few pro-bono education sessions with partners.  I'll make a pilgrimage to bow at the feet of whoever's idea that was. 

Posted by Ed at November 9, 2006 01:06 PM | TrackBack