A few things struck me, given what I know about the differences between what Microsoft documents and what people familiar with SDL (inside and outside of Redmond) do in practice:

1) Developers often see true modeling tools, like Prefix, as too hard to set up and use; “Don’t bother???, some think. I perceive a rift between those who shepherd these tools and the developer-masses on this tool’s value. I, personally, think tools like Prefix rock.

Your organization needs to decide whether or not they want quick(er) adoption of a parser-based tool, or to spend the time setting up and tuning a modeling tool when it chooses to do code analysis with a tool.

2) Microsoft goes beyond fuzzing (or more complex tool-based integration testing approaches, such as fault injection). Specifically, their data flow diagrams (D.F.D.s) written as part of Threat Modeling techniques drive security testing I’ve witnessed: still at the API-level though.

Your organization needs to decide how it’s going to bolster QA staff, tools, and approach to incorporate security. Microsoft has taken a very design-by-contract approach, it seems, and the addition of Whittaker and his tool-horsepower helps. What strengths can your org. leverage?

3) Microsoft’s code review seems reminiscent of Fagan. They seem to implement it based on a growing checklist of previously found testing bugs, security standards, and that’s it. Our code review (in practice) seems much heavier-weight, incorporating understanding of software’s design and aspects of dynamic testing.

I firmly believe your organization needs to go well-beyond code print outs and walkthroughs when it does code reviews. Any more on this subject would be its own entry.

4) Microsoft, I believe, spends much time writing security requirements. I’m largely shocked they haven’t adopted something closer to our misuse/abuse cases formally—as it would fill a gap in their Threat Modeling exercise and seems to fit with their developer-driven software development culture well.

Microsoft has, in general, tackled Security within the development lifecycle like a subset of Quality in terms of methodological approach. They think about things from a perspective deeply steeped within their own product suites, OS, and language platform–as they should. No where else (not even in some embedded device shops) will you see so integrated a technology stack. There’s a lot of contextual baggage that comes with that.

Everyone lauds Microsoft’s security efforts, I’l join in: Good job. The fact that they’ve published books on how and what they’re doing also helps. For those of you trying to absorb SDL, think about what Microsoft was trying to accomplish in each step and figure out how to apply the ‘spirit’ of that guidance to your organization in a culturally compatible way rather than copying SDL wholesale.
-jOHN