ClearNet Security

edit

Agile vs. Security

Posted by Ian S. Nelson Wed, 25 Oct 2006 18:11:00 GMT

I read this article and was reminded of my own post a couple months back. I generally try to avoid the religion disputes within the community but this is one I'm feeling more inclined to chime in on. I'm going to make an assertion to clarify the debate: basically, the "successful" agile projects seem to pretty much build interfaces. I think a lot of developers may be sensitive to that description but that's pretty much what web programming is.

There are some great concepts in agility, there is an overwhelmingly strong tendency for companies to talk about stuff a lot more than actually doing things and at some point the talking always outweighs the effort of just "getting it done." Most teams need a shot of "agile" somewhere. You know, just a kick in the ass to start doing more and talking about doing less. At the same time, I know of no teams that are building things like compilers or operating systems agilely. I know of no widely used protocols that were constructed with agile. I doubt you'll ever see any agile embedded projects in the near future. Basically anything that is actually hard or where mistakes are costly due to limited debugging that might be available or where the customers are so far detached from the actual technologies that they cannot contribute much to the development beyond the interface ( a lot more people use compilers than have anything to add to conversation when it turns to intermediate representations.) Interface security is much different what is meant by security in a protocol. To be fair, I think the discussion should be scoped around this. Agile seems to be at its best in the interface. Maybe it will eventually move beyond that but I don't see any reason to think that will happen soon.

So agile and security... There are a couple things here. First off, security isn't a requirement from customers until it's too late. This is changing but unless they are coached or somehow lead, I doubt most customers would list it high on the list as a fundamental requirement of a new product. It's both implicit and not and when schedules are tight and there are other features that have been sold already it becomes a lot more like a "nice to have."

There aren't a lot of easy ways to automatically test security, I wish there were. More and more software is getting back to the point where there is an automated test suite that will verify functionality, the best projects are still under 100% coverage. I know of no projects that have test suites that verify security after various refactorings. In fact once you trust that something is secure, it's a huge anchor, it's hard to change it and maintain that level of trust. If something some how is perfectly secure, all you can really do is decrease or maintain that by refactoring it.

I also think that the notion that "working software" is the measured deliverable is faulty when you factor security in. Most software works fairly well and accomplishes the goals of the user to some degree, a lot of it also has known insecurities and vulnerabilities. Security is a benchmark above and beyond "working code." In fact most vulnerabilities go unnoticed by the user. Just today we found a hole in our blog software, Typo, that we haven't known about for quite a while and it was being abused. Everything seemed to work just fine though. When security matters, it's a requirement above and beyond "just working."

So are they contradictory like the article on The Server Side asks? I think so if you take agile in a literal sense. If you look at agile as more of a cultural thing rather than a software engineering methodology (and there are a lot of good reasons to do that) then they start to work together more closely, it's a very agile thing to respond to a vulnerability quickly with code, you have to be "agile" to do that. The other change is that security is becoming less and less of a boutique feature, pure security companies are dying and security is becoming just another expectation when you purchase software.