Of losing design battles and winning wars

In my Enterprise Security To Do list for 2009 my first to do item suggested the following:

1. Educate yourself on state of the practice in software development

Spend as much time (or more) reading about software and data as reading Bruce Schneier and security. Specifically, security people should pick some good topics in software and data and follow up on them - some good places to start Martin Fowler, Pat Helland, and Kent Beck. if you want to be taken seriously by developers, you need to master this stuff before lecturing developers on how you think the so-called SDLC should work. Plus understanding the software development rabbit holes in your organization will help you craft more successful implementations.

And now here is a perfect example why this is the case. Martin Fowler's Bliki from today on Technical Debt

To my mind, the question of whether a design flaw is or isn't debt is the wrong question. Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking. A particular benefit of the debt metaphor is that it's very handy for communicating to non-technical people.

I think that the debt metaphor works well in both cases - the difference is in nature of the debt. A mess is a reckless debt which results in crippling interest payments or a long period of paying down the principal. We have a few projects where we've taken over a code base with a high debt and found the metaphor very useful in discussing with client management how to deal with it.

The debt metaphor reminds us about the choices we can make with design flaws. The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small - such as if it were in a rarely touched part of the code-base.

So the useful distinction isn't between debt or non-debt, but between prudent and reckless debt.

Almost every single Information Security design meeting I have ever been in involves a variant of this theme. Unfortunately, as readers of this blog know that in 2009 the Information Security Technical Debt Clock rolled over 14 years, because there is too much focus on the hype of security and not enough on design and integration. 

To make this actionable, Fowler includes a helpful quadrant to discern the difference approaches and outcomes.

This quadrant is a good way to look back on implicit assumptions that lead to any number of security surprises. To that end I made a security version of this quadrant that contextualizes the framework into scenarios that security people will find familiar

In InfoSec we're used to not winning all the battles, but its very useful to understand what decisions are being made for time to market expediency and if in the design its at all feasible to revisit them. A PEP is a good concrete example here, building an interceptor pattern in front of your web service a la Axis2/Rampart could allow you to get to market with say Basic Username/Password token and later on change to a SAML token. If the interceptor was there your revision is causing not only behavioral changes but also structural changes and will likely be much more difficult to get through dev/QA later on. Sometimes the most important thing is getting the boundary right on release 1 even if that means the boundary is not optimally protected til later.