In “Managing risky business,” I mentioned that when advice on secure development turns out to be flawed or incomplete, smart organizations learn from their mistakes and update the guidance they issue. In other words, root cause analysis.  Root cause analysis is such an important point that it’s worth coming back to.

In Michael Howard’s and my book The Security Development Lifecycle, free to download from Microsoft Press, we included a couple of chapters on security response process. We did that in part because having a good response process is an important part of a software security program. But we also wanted to highlight that the security response process is a natural source of feedback for the software security program.

It wasn’t always so. In the 1970s, when computer security research was beginning, most developers responded to vulnerability reports by fixing the problem reported. There was no assumption that the problem was an instance of a recurring issue and no attempt to research or define that issue and then resolve it. We used to call the approach of finding and fixing one instance at a time “penetrate and patch.”

The “penetrate and patch” approach survived into this century (and probably survives today in some development organizations) until organizations started to create secure development processes. Those processes define specific measures that developers must take to eliminate all instances of a specific class of vulnerability. To the extent that the measures are effective and can be applied wherever appropriate, they can make a class of vulnerability extinct, eliminating “penetrate and patch.” Of course, for some classes of vulnerabilities, we don’t have fully effective measures, and it’s hard to find all the places where vulnerabilities might occur. And we also don’t have a complete list of the classes of vulnerabilities that we need to worry about – new ones keep coming up.

Root cause analysis and the secure development process

That’s where root cause analysis comes in. If a new vulnerability report arrives, the development organization should not only fix the problem reported, but also try to identify the issue that it’s an example of. Next, the organization should conduct a review:

  • Is this an example that we missed of an issue we already knew about? If so, can we update our process requirements, training, or tools to do a better job going forward?
  • Is this an example of a new issue? If so, should we (and can we) add process requirements or training or build new tools to keep the issue from recurring?

While some issues are just hard to detect – the best process, tools, and training aren’t sufficient to eliminate all examples – the feedback from vulnerability reports helps identify new issues that need attention and also helps us prioritize hard to detect issues that need more attention. A mature secure development process will incorporate root cause analysis to keep driving vulnerabilities out and making software more secure.

There are a couple of other points that are worth considering. First vulnerability researchers – and vulnerability reports – often follow trends. If you get a vulnerability report that’s an example of an issue, once that report is made public other vulnerability researchers will start to look for similar examples. So it’s a really good idea to get ahead of the vulnerability researchers by reviewing your code (manually or with code analysis or testing tools) to look for those examples and eliminate them all. That’s a lot better than having to issue what looks like the same security update week after week for months. I’ve been there and I know.

The second point has to do with bug bounties. A lot of development organizations have bug bounty programs under which they pay vulnerability researchers who report security problems in their code. Those programs are a great idea, but if a development organization implements one without having a secure development process and root cause analysis, they can look an awful lot like “penetrate and patch.” You not only pay the vulnerability researcher to find each bug, you also pay your developers to fix the bugs one at a time in shipping software, and your customers suffer the pain of update after update.

The smart approach is to use the bug bounty program to feed your root cause analysis and secure development process. (Katie Moussouris, a pioneer in creating and managing bug bounty programs, and Chris Wysopal, CTO of Veracode, elaborate on this point.)