After reading the Theories paper by the badsoftware.com folks... I wanted to focus on the "Technological Risk Management" piece of puzzle. Let's assume for a minute that the "Fault" model of software liability won't work and evaluate then what constitutes effective "Technological Risk Management."
If we take the risk management approach we still need to determine what constitutes effective risk management in the software development lifecycle. We need some metrics to judge what SDLC models work for improving security, and which don't.
Reading through Howard and Lipner's SDL Book they make the categorical claim that though the SDL isn't necessarily the only way to improve software security, it is proven to work.
It gets me thinking about how we can create effective ways of measuring software development processes for their security oriented results. If we can, then we can start to baseline SDLC methodologies according to their security-risk-reduction potential to class them into good/bad/ugly and start to make decisions about what software we buy based on software development methodology alone.
That said, in all processes there is a lot of wiggle room. It is possible to write horrible software at the CMM-level-5 because the specifications aren't useful or the underlying idea is flawed. CMM-5 doesn't guarantee good software, it just guarantees we understand the process that created it.
There are several software specific SDLC's, I think I need to do a comparison of them to fully appreciate the differences between them before I can make a valid comparison.
Gary McGraw of Cigital has a nice blog entry giving an analysis of how their process differs from Microsoft's. I think one of these days I'm going to have to meet with the Cigital folks in person to get their take on appropriate approaches for a proper security development model for large online applications. Seems like in Gary's piece he doesn't believe that Microsoft's SDL is necessarily well-suited to the website environment.
I'm inclined to believe that all three of these approaches will yield good results if applied with some discipline and flexibility regardless of the underlying application. The problem is I can't try all three throughout my organization - so again I'm stuck making a non-empirical choice.
No comments:
Post a Comment