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.