In his cybersecurity predictions for 2021, RSA Chief Digital Officer Dr. Zulfikar Ramzan writes that “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.
Technical infosec debt is a term that has taken on a greater sense of urgency thanks to the continuing pandemic. 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 could 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. (See this cartoon for a more humorous illustration.)
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 that 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 requires 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. 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 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 brings us back to Dr. 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.”