Technical debt is a very important topic. Brian Snow mentioned it prominently in a number of recent speeches; Chris Wysopal has a post on this issue and one of the important persistent problems it creates - interest rates.
Technical debt is a good way to communicate the Problem, but its hard to get people to act on it. Think of the real world financial debt crisis, we are sitting on $54 trillion in debt over the next few decades, but is anyone acting on it?
And really infosec is no position to preach to other technical disciplines about technical debt. If you consult the Infosec technical debt clock you find that SSL plus Firewalls architecture is almost ready for college age (15 + years old, ain't he cute, all growed up now!) with nary an improvement. Maybe SAML and/oauth will step in and make a real improvement I hope so but no guarantee
So while I like the technical debt metaphor infosec as a whole cannot point to major enhancements towards closing out this debt. Development groups are the ones making real progress in dealing with technical debt, and its development groups that are closing important gaps - like taking username and password behind the barn and finishing it off. Why isn't infosec the group doing this important security-focused work? I have no idea, but I am just glad someone is doing it. If anything, infosec pros should ask development peers for ideas on how they dealt with technical debt in the past for availability, distribution and others where development has excelled on precisely this problem.
The technical debt concept communicates the problem but does not really act as a call to action, but I quite liked Martin Fowler's quadrant approach. Let's assume we are going to ship something with some amount of debt we can do this in a Reckless way or a Prudent way. To give a concrete example of this let me go back the Web Services security strength scale. We could ship a Web services ensure that its routed through a Gateway that supports multiple security token types. Let's assume that the deployment realities do not support a strong security token. Does that mean version 1.0 should have no security at all? No.
Its much better to plan ahead, building in a security token in the message header, say a password digest and then look to upgrade to SAML or other in the future. This puts in basic authentication, establishes the token/header structure, sets up the message routing correctly, and implicitly establishes the Policy Enforcement Points (Gateway) that you will want going forward. Its not everything your security architect wants for their birthday and a pony too! But its a whole lot better than the nothing that often gets shipped in message security.
The Prudent way of dealing with Technical debt is about identifying tradeoffs, making hard decisions and putting in stubs to improve over time.
Not all debt is bad. Think about borrowing money for going to medical school, you incur debt for a specific reason and there are nice outcomes (likely) on the other side. Now compare this to taking on debt for consumer spending and buying a humongous TV. So it helps to keep the debt front of mind and have an idea how you are going to act on it. Otherwise the interest payment Chris Wysopal mentions will swamp your future.
The debt concept is easy to convey and people get it, they nod their heads and say "oh yes, I see! Technical Debt is bad!" but that does not make them change their behavior. We had a very short period during the financial crisis where Americans actually saved more than they spent (amazing!), but one the recovery started it was back to same old same old. We need to not just express the Technical Debt concept in an engaging way; in addition we need to hack through the complacent mentality towards behavioral changes.
The key thing that Fowler's quadrant does is to take an unpleasant concept that people don't want to think about and extends that by making the decision tradeoffs and outcomes more actionable. He has continued to work to develop these ideas and the Tradeable Quality Hypothesis is the most recent example.
Comments