How to Get Out of Technical Debt

When it comes to technology—including security—it often costs more to fix something later rather than sooner. Putting off the inevitable improvements necessary to fix buggy software or out-of-date technology is like “borrowing money thinking you never had to pay it back,” says programmer Ward Cunningham, who developed the first wiki.

Cunningham invented the term “technical debt” more than a decade ago to describe how rushing buggy technology out the door functions in a similar way to accumulating interest on a debt. If you don’t pay down the principal, the interest builds to a point where it consumes all your budget and becomes impossible to pay off.

Ask a dozen technology professionals to define technical debt and you’ll get a dozen answers. To software developers, technical debt probably means something along the lines of cutting corners to ship code. A CIO, on the other hand, may view technical debt as the accumulating impact of older tools that hinders the ability of an organization to deliver modern digital capabilities and innovations to its employees, partners, and customers.

Take a proactive, data-driven, and continuous approach to managing your exposure with a real-time view of risk.

In either case, the buildup of unaddressed technical work needed for future success leads to magnifying costs and complexity down the road. The end result: IT staff develop more and more work-arounds to fix what they should have fixed earlier.

“I view technical debt as something that comes about from having to make decisions that meet short-term objectives but create long-term liabilities,” says Fernando Montenegro, a principal security analyst at 451 Research, a part of S&P Global Market Intelligence.

Regardless of the definition, tech debt is piling up. When McKinsey surveyed 50 CIOs in 2020, the management consulting firm found that 10% to 20% of the tech budget earmarked for new products was instead used to pay down tech debt. In fact, tech debt made up 20% to 40% of an organization’s current technology investment before depreciation. At the time of the survey, 60% of CIOs said their technical debt had increased considerably over the past three years.

Making technical security debt a priority

Jonathan Feldman isn’t interested in accumulating too much interest on technical debt. As the CIO of the city of Asheville, N.C., Feldman has been working hard to ensure that his city’s technology systems remain up-to-date. For example, he’s steadily transitioned Asheville’s information systems away from on-premises software and onto the cloud.

Technical debt comes about from having to make decisions that meet short-term objectives but create long-term liabilities.

While modernizing the IT environment often means adopting cloud software, it also means building a technology stack of programming languages, frameworks, and development tools that is able to quickly adopt new features and adapt to changing business requirements. As an example, Feldman points to how cloud- and SaaS-based software systems helped the city of Asheville to quickly pivot to remote work during the pandemic.

“We didn’t have to mess around with VPNs and getting software on people’s endpoints,” says Feldman.“I know municipalities that had to spend hundreds of thousands of dollars to expand their VPN concentrator to accommodate all of their remote workers. Who in security thinks that client-side VPN is the way to do security nowadays? Exactly nobody.”

Many reasons explain why companies accumulate technical debt, including managing too many development platforms and too much aging and legacy infrastructure. Hiring and retaining skilled technical staff adds to the burden, as does the shortsightedness of failing to budget for the maintenance of systems and software for their duration.

How technical debt becomes technical security debt

A significant reason for security related technical debt is the dichotomy between how security professionals and other tech professionals view technology. “Information security people tend to come at problems from the point of view of how they can break something,” says Nick Selby, CSO at Paxos, a blockchain infrastructure platform, and co-host of the Tech Debt Burndown podcast. “We look at what an attacker sees from the outside in and try to find the open areas that need to be shut down.”

[Read also: Lateral movement: how cybercriminals move across your network and how to stop them]

In contrast, modern developers want to prioritize efforts “from the inside out,” Selby says. They ask about what they are trying to build, what they cannot build, how to push code more quickly, and what’s standing in their way.

Feldman notes that a decade-old technology is likely to have outdated encryption standards, ancient APIs, and a greater level of rigidity compared with today’s more flexible applications. “It’s just going to be ugly to secure most of the time,” he says.

Technical security debt magnifies latent flaws in security that make it more difficult to safeguard out-of-date applications, infrastructure, and endpoints. “I cannot think of an example of technical debt that doesn’t affect security, in that technical debt almost always affects throughput, scalability, resilience, and uptime,” says Selby.

The costs of tech debt are often tricky to uncover. Perhaps they show up in legacy systems that are difficult to maintain, or in old code that doesn’t meet current needs but is too costly to replace, or in data stored in silos that cannot be analyzed and put to good use. Security teams may discover they are limited in their ability to securely provide for the confidentiality, integrity, and availability of systems and information.

Given that every enterprise has tech debt, and tech debt has a substantial impact on security, what can a leader do? Security practitioners recommend cutting technical security debt to a manageable level:

Bring in security teams early

Being brought in early might mean being involved with a new system or application during the design phase, or when the addition of new features or changes could change a company’s risk level.

“For security professionals, the earlier we get the design doc, the better,” says Selby of Paxos. He recommends embedding security engineers into engineering squads so they’re working together from day one. “There [was] no call to security way down the line to check things over and make sure they’re all good,” he says. “The security team was already there making it good all along.”

Prioritize debt paydown

The tech debt in every company will be different, along with the optimal ways to pare it down. Sometimes technical security debt may appear as outmoded business platforms that require a lot of additional effort to secure. Other times, a company could have deployed too many security tools without enough skilled professionals to run them.

[Read also: Federal cybersecurity: Too many tools spoil the broth]

“Many things that have a high impact on security may not appear directly related to security,” says Selby. “It’s often the foundational work that comprises technical debt, such as refreshing equipment or getting the right tools for the job. Many of these things tend to have a higher overall impact on security.”

Make steady debt payments

It doesn’t matter how big or mature an organization is. All organizations accrue tech debt over time. The important thing is to set a dedicated time period for paying down the existing debt. “If you’re a company with any kind of technology base, that’s just the way it is,” says Selby.

Modernize the environment

Modernization isn’t just about having the latest and greatest technology just for the sake of having it. It’s about having an enterprise technology stack that is agile enough to grow and change as your business demands change.

Who in security thinks that client-side VPN is the way to do security nowadays? Exactly nobody.

When organizations don’t modernize, the CIO might have to tell a business unit that the company can’t make a large investment to turn on a new feature, says Asheville’s Feldman. “Whereas with a modern platform, it would likely be possible just to flip a switch.”

Structure technology investments over time

Many budget requests only look at initial system and deployment costs without looking at how tech debt is incurred over time. “It’s not that we need $5 million and then this application is done in terms of capital investment,” says Feldman. “What is needed is a commitment from the organization to spend a certain amount every quarter for the life cycle of the application.”

Adds Montenegro of 451 Research: “You are forever responsible for what you’ve deployed. Organizations need to have the resources to make sure they are planning to not only address debt but also avoid incurring too much debt by failing to properly manage systems over their life cycle.”

[Read also: How DevOps and security can work together]

Ultimately, organizations may decide to pay down technical debt, but that decision may not be something security teams and leaders control. Montenegro advises senior security leaders to let the company’s overall IT leadership know that when organizations take on certain kinds of technical debt, it can have big consequences on their risk profile.

“You’re not going to be getting any Christmas cards from a team that is forced to delay product releases because of security flaws,” he says. “But the organization has to make an important choice.”