Thursday, December 13, 2007

Where is the security debt?


In development there is a term technical debt, which basically means that there are bits and pieces left over from the development that need to be finished. It could be some refactoring on a messy class, a hacky implementation, missing functionality, etc... I think we also need to use this same idea in security. I know when we boil it all down it could be put under technical debit, however, I think security should be in its own category as that has a different impact than a poorly written class...well most of the time :).

Just like in development when securing a product the cost of doing the work vs. the risk of an incident occurring has to be weighed to come up with a business case for doing the work. On top of that there is a schedule that needs to be adhered to. What this means is not all of the security work and/or testing gets done. I have seen this for many products and I still do see it on applications I use throughout the day (just monitor any vulnerability web site and you will see what I am talking about). However, I hardly see a list of things that still need to be done or as I like to think about it a debt sheet. When the next iteration of the software or when maintenance is going to be done on an area that also has some security work, the security work should be bundled into it to whittle down the debt.

I would think in a perfect world the following scenario would happen:
1) A product is built and security is done and a list of things done and things that still need to be done is kept in a central location.
2) Once the product is finished security personnel goes through the list of things not done and removes items that are no longer valid (threat landscape has changed, it has been fixed by something else, etc...)
3) When the next version / iteration is being built this list is shown and it is gone through again and any cruft is removed. After that the remaining debt is put into things that need to be planned for.
4) Repeat steps 2 and 3 for each product iteration until no security stuff needs to be done (yea right!).

0 Comments:

Post a Comment

<< Home