Security Debt

You spend time paying down your credit card and mortgage debt at home, but are you up to date on your security debt?

Security debt is an offshoot of another term, known as technical debt. The latter isn’t itself a common term in an industry always chasing shiny new features. First coined by agile development guru Ward Cunningham, it describes decisions taken early on in a software project that make it easier to ship but that cost time and money later.

Think of software like a house. You have $1500. You can buy a snazzy new couch for your basement den, or you can replace that old, outdated water heater. One has clearly visible benefits right now. The other is boring. On the other hand, it will stop a nasty flood sometime in the future that would have wrecked that couch and cost three times the money to clean up.

Security debt has similar characteristics. The things you don’t spend time fixing now could come back to bite you – and your customers – later. Remember when Bill Gates sent his Trustworthy Computing memo to try and shore up security in Microsoft products? He was trying to redress security debt that was starting to have a tangible effect on the bottom line. He knew that unless the company took care of its security issues, it would stymie its ability to sell new features.

Some companies might take efforts to clear up security debt, but Charl van der Walt, chief security strategy officer at SecureData, worries that many are not. He frets about the potential impact of security debt if left unchecked, likening it to the global financial crisis.

Debt, debt, everywhere

In the mid-2000s, banks were busily abstracting debt into derivatives called Collateralized Debt Obligations (CDOs). They black-boxed that debt, masked the nature and source of the original liability. It’s how banks were able to trade billions of dollars in junk mortgages at triple-A prices. It’s what sunk the housing market and almost destroyed the economy.

We are inadvertently cloaking security debt in similar ways, says van der Walt. As millions of lines of code and the companies that use it are broken up, recombined and layered on top of each other, we obfuscate security debt that was difficult enough to spot in the first place.

We’ve been doing this since the early days of the web, he warns. Consequently, debt is now inherent not only in our legacy code but also in the third party libraries and products that we use. It’s entrenched in the dependencies that we rely on and which can break the Internet with a single rage-quit. It even arguably shows up in the business models that have developed to exploit the web.

What business models might those be? Think of Facebook’s recent privacy problems, born from what Jaron Lanier has criticized as flawed early decision making about how the commercial Internet developed. You could argue that this is a form of security (or perhaps privacy) debt borne of specific business decisions about free content and customer monetization, made not long after Zuckerberg was still in college insulting his users. Put it this way; the business model helped cause the problem. Changing that model now would take a monumental effort.

What does all this stored security debt mean for us? Van der Walt is grim, almost apocalyptic, about it. “This has the potential to be truly catastrophic, in the way that the global financial crisis was. The software is homogenous, and it keeps stacking and accruing,” warns van der Walt. “You just need a trigger of some kind to end up with forced repayment. I think it could have serious global consequences.”

What kind of trigger? Take your pick. Heartbleed, EternalBlue (which spawned WannaCry) and now Spectre and Meltdown are all examples of events that exploited latent technical debt and sent vendors and customers alike scurrying for cover. There will be more, of course, and they will be terrifying.

Responsible folks pay off their credit card debt early and avoid interest payments. By the time the collection agency’s letters begin arriving, it’s too late; their credit score will be toast. Similarly, you want to pay off security debt before someone makes you.

Paying it down

How do we make those payments? We make them steadily, and with intent.

First, we must find the debt. Security debt can surface in several ways. User bug reports in our own software, alongside publicly disclosed flaws in products that it depends on, are a good source of information. Static analysis tools and fuzz-testing can help to expose hidden debt. Auditing the products on which ours relies and scanning our code for open source dependencies are all part of this puzzle.

Then, we must quantify it, so that we can prioritize it and decide which security debt to pay down earliest. There haven’t been many standard methodologies or frameworks for this, but things are changing. Carnegie Mellon University’s Consortium for IT Software Quality (CISQ) and the Object Management Group (OMG) recently created an Automated Technical Debt Measure, based largely on static analysis, which includes security debt in its framework.

Using the quantified debt measure to prioritize which debt we address first is a more complex task. It involves a risk analysis that will weigh the financial and time cost of mitigating the debt against the potential impact on business processes, user privacy, safety and earnings. That risk matrix will constantly shift thanks to new regulatory considerations like GDPR.

Having found it and measured it, we must have the development chops to pay it down. If you’re shipping monolithic code four times a year consisting mainly of new features and the occasional bug fix, then it is time to rethink things. An agile continuous integration process will help to make the collection and remediation of security debt a more frequent and systematic process.

Is any of this going to be easy? No, but this conversation about security debt may be more urgent than general discussions about its broader superset, technical debt.

Technical debt can eventually railroad product development along a single track, limit new feature options, and cripple product revenue. At some point, even small elements of technical debt become so great that the product ceases to be viable.

That’s bad, but security debt can be worse. It can embody a range of flaws that could put a company and its customers at significant risk of a breach. The more that this debt builds up, the more susceptible data and potentially control systems are to attack.

Faced with that risk, it’s never too soon to begin holding our software owners and development teams accountable.