The Artima Developer Community
Sponsored Link

Weblogs Forum
Security Debt

5 replies on 1 page. Most recent reply: Mar 10, 2011 10:32 PM by Johan Peeters

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Johan Peeters

Posts: 30
Nickname: yo
Registered: Nov, 2003

Security Debt (View in Weblogs)
Posted: Mar 6, 2011 9:41 AM
Reply to this message Reply
Summary
Chris Wysopal likens application security debt to technical debt in a couple of recent blog posts. It turns out that the debt metaphor is particularly apt as, like financial debt, application security debt is susceptible to interest rate fluctuations.
Advertisement

Chris Wysopal likens application security debt to technical debt in a couple of recent blog posts. It turns out that the debt metaphor is particularly apt as, like financial debt, application security debt is susceptible to interest rate fluctuations.

The threat landscape changes in the application's life time. Unfortunately, security interest rates are much more likely to go up than down as new vulnerabilities are disclosed and the application gains mind share. The former makes it easier for attackers to compromise the application, the latter provides them with a greater incentive. An effect that Chris missed is the tendency for an application to increase its attack surface as it is extended with new functionality.

Leverage through financial debt can help a company grow and, similarly, so can technical debt. However, as interest rates become punitive, clearly the time to de-leverage has come. Chris presents a model to quantify the dollar cost of the debt, but, frankly, the calculations are tenuous, as he admits himself. I would feel happier with qualitative guidelines. What do you think the tell-tale signs are for the need to de-leverage?


John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: Security Debt Posted: Mar 7, 2011 3:51 PM
Reply to this message Reply
Jaw drop.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Security Debt Posted: Mar 9, 2011 2:24 AM
Reply to this message Reply
This kind of pseudo BA or capitalist-realist reasoning is totally insane and it is a shame that it is produced by "software engineers".

Security needs certifications. Those won't guarantee that programs ( or hardware ) can't be cracked either but it ensures at least that they are not completely sub-par. Security certificates have to be renewed periodically. This way more recent attacks are already reflected in the certification process. Optimistically speaking standards/certifications can drive technological progress towards platforms/techniques/languages that reduce costs for gathering a certificate.

Johan Peeters

Posts: 30
Nickname: yo
Registered: Nov, 2003

Re: Security Debt Posted: Mar 9, 2011 3:35 AM
Reply to this message Reply
I am not sure whether you are agreeing with me that expressing security debt in dollar terms is over-ambitious or whether you think that even the very concept of technical debt is silly.
Personally, I think that, as software engineers, it is important that we think about the business drivers of our work.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Security Debt Posted: Mar 10, 2011 1:36 PM
Reply to this message Reply
I thought it was decided that "technical debt" was a bad metaphor given that finance types really really like having debt.

Johan Peeters

Posts: 30
Nickname: yo
Registered: Nov, 2003

Re: Security Debt Posted: Mar 10, 2011 10:32 PM
Reply to this message Reply
Just like in finance, technical debt can be a useful tool, but, used in excess, turns toxic.

Flat View: This topic has 5 replies on 1 page
Topic: Hybridizing Java Previous Topic   Next Topic Topic: Roundup 2011 Summary and Upcoming Summer Event

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use