Cigital’s Touchpoints versus Microsoft’s SDL

by gem on Thursday, March 8, 2007

Recently, someone at Cigital asked me to characterize the difference between our approach to software security and Microsoft’s. Before I get to comparing things I want to note that we’re big fans of Microsoft when it comes to software security. Under the leadership of Michael Howard and Steve Lipner, Microsoft has made great progress in software security over the last few years. There are many lessons that we can all learn from what they’re doing.

That said, Microsoft’s approach to software security does differ from ours in a few fundamental ways that are worth discussing.

The biggest difference to highlight is that their approach has a static threat model that is great for operating system vendors. People in other sectors such as finance or hospitality will not have the same kind of threats that Microsoft does. In this case, what I mean by threat is an actor or agent who causes risk. That is, your possible attacker(s). Building a threat model that is tailored for a customer is a key aspect of our approach at Cigital. Microsoft has already done this for their business, but chances are you are not an operating system vendor.

At the heart of Cigital’s approach to software security are a number of best practices that we call the touchpoints. You can read about the touchpoints in my book Software Security. The top two touchpoints are “Architectural Risk Analysis??? which helps uncover and mitigate flaws at the design and architecture level, and “Code Review with a Static Analysis Tool??? which helps ferret out bugs in code at the implementation level.

Our approach to Architectural Risk Analysis is much better suited to finding new risks not yet ever seen before than Microsoft’s list-based approach. Undiscovered new risks are the kinds of things that lead to 0days and help you to wind up on the front page of the Wall Street Journal. Our three-phase analysis goes way past Microsoft’s STRIDE model with regard to dependencies and ambiguities. Our approach to risk is much more sophisticated and grounded in business as well. The reasons for this probably have to do with having to demonstrate to our customers the importance of the things we’re finding. By contrast, Microsoft doesn’t need to be convinced to fix security problems, Bill Gates already said that they have to.

When it comes to code review, Microsoft and Cigital approaches are similar, but Microsoft leverages proprietary unreleased tools that are not available outside of Microsoft. (Many of you will have heard of Prefix…Prefast, now available with some Microsoft compilers, is not the same thing.) The Cigital approach leverages customizable commercial tools and a best of breed approach. We often use Fortify’s supremely good static analysis tool, but we have been known to wield Coverity’s tool and Klokwork’s tool as well, depending on the situation. In both cases, however, the use of a static analysis tool to find bugs is absolutely critical.

Our approach to security testing is much more white box than Microsoft’s is, and involves using the risks uncovered during Architectural Risk Analysis to drive inside-out test planning. Microsoft’s approach is grammar driven and focused on APIs. The fact that James Whittaker now works for Microsoft is likely to help to evolve Microsoft’s approach to security testing, but James has a tendency to start with API fault injection as well (see his great book How to Break Software Security).

As far as I know, Microsoft does next to nothing at the requirements level. At Cigital, we have a decent approach to security requirements that covers both functional security mechanisms and abuse cases.

There are many other differences between our approaches, but those are the highlights. The most interesting thing is just how closely aligned the two approaches are.

[tags]software security,microsoft,stride,sdl[/tags]

  • jOHN

    Gary, excellent post. Some of our larger customers make a pilgrimage out to Microsoft, look around, and then come back and ask me, “How much of SDL should _my_ org. be using today?” Like a previous entry indicated, most people obsess about the Joneses; Microsoft plays the Joneses part well.

    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.