Zulfikar Ramzan mentions in his blog post from last month, “Next year, CISOs will have to grapple with the consequences of the decisions they made (or were forced to make) in 2020. One of their first orders of business will be to ‘un-cut’ the corners they took in the spring to stand up remote work.” Nowhere is this more the case than with dealing with their technical infosec debt, a term coined by Ward Cunningham decades ago.

This is a term that has taken on a greater sense of urgency thanks to the continued pandemic. (See this cartoon for a more humorous illustration.) It is basically a fancy term for taking the easy route, for cutting corners and saving time by not really looking at the longer-term consequences of certain decisions that make your IT infrastructure inherently insecure. It reflects the implied costs of reworking the code in your program due to taking these shortcuts, shortcuts that eventually will catch up with you and have major security implications in the future.

Security trainer and consultant Tanya Janca puts it this way: “Technical debt is a decision. It is a decision to put upgrading, fixing, and improving last. Technical debt is security debt, and you need to make it a personal priority to prevent it.” By choosing the most expedient route, she says IT managers accumulate lots of debt. Examples abound, including “not patching or upgrading endpoints and servers as soon as these are available, using outdated programming and development frameworks or code sources, or being slow to react to specific changes that are needed in your home-grown apps,” she says in her latest book, Alice and Bob Learn Application Security. The focus of the book is on building more secure apps, and technical debt just gets a small mention – but the book (and an accompanying series of online classes available on her website) are an excellent resource for those new to app security.

Technical debt thrives in massive bureaucracies, where buying paper clips require five signatures, or so it seems. If your enterprise makes it difficult for your developers to get the right tools and software frameworks to do their jobs, they will take the easier (and less secure) path. Debt will accumulate if the normal software development cycle is measured in months rather than minutes. Look at the major breaches of the past few years – if the technical debt at Equifax, Uber and Target had “been better understood, then perhaps it could have been appropriately managed and brand reputation could have been maintained and financial losses avoided,” said Jane Frankland, a security executive writing in 2019.

Granted, the pandemic has forced the hand of many IT organizations that can barely keep the wheels turning, let alone have more longer-term plans to keep things as secure as possible. Which comes back to Ramzan’s post.

If you want to pay down your technical debt, here are some suggestions to get started. First, examine your collaboration between your development and security teams. The more they can share best practices, the more secure your apps will become. Second, try to avoid making lots of last-minute changes to your apps, but try to consider security before a single line of code is written. One way to be more deliberate is to have a set of test suites to root out any bugs or missteps. Look at your security issues holistically, not sequentially, as Frankland suggests. (She has lots of other suggestions on her blog too at the link above.)  Create a solid code documentation culture, which avoids making quick and dirty development decisions without considering the security implications. Finally, Cunningham himself had these words of wisdom: “Don’t let the debt build up. Everyone knows the list will never be addressed. Remove cruft as you go. Build simplicity and clarity in from the beginning.”

Janca writes in her book, “When organizations spend most of their time just trying to keep the lights on, constantly fighting fires, technical debt will most certainly result in security problems as well.”