Security Debt. What about it?

The technology industry is always abuzz with jargon, terms, anagrams, and what not to push for new technologies. A term (not very new) but currently gaining currency in the market is “Security Debt”.

So, what exactly is Security Debt?

To understand this, we need to go back a little and understand the term “Technical Debt”.

Technical debt is a phrase coined by Ward Cunningham, a software developer who is one of the 17 authors of the Agile Manifesto and is also credited with inventing the wiki. He first used the metaphor at WyCash to explain to his non-technical stakeholders why?he needed resources to be budgeted for refactoring.

As per Wikipedia, in?software development,?Technical Debt?(also known as?Design Debt?or?Code Debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. ?

Now let us understand Security Debt in the context of Technical Debt.

Security debt is a subset of technical debt. ?In my opinion, a Technical Debt can introduce a security vulnerability in the system/application. An accumulation of these vulnerabilities in the system is termed a Security Debt. If not addressed in time, this can become a serious problem.

As with any Monetary Debt, Technical Debt needs to be repaid. If not repaid it can accumulate “interest”, making it harder to repay.

Why do developers take on Technical Debt? Is it Bad?

Like Monetary Debt, a Technical Debt may not always be a bad thing as it may help in expediting the development and go-to-market readiness. But developers need to be cognizant of the fact that the debt needs to be repaid, meaning whatever short-cut (debt) they have employed needs to be fixed at the earliest a.k.a Debt Servicing.

Let us understand a few reasons why developers take on Technical Debt.

§?Speed to Market: Organizations are under pressure to release applications to ensure that they are ahead of the competition, to meet customer expectations, to capitalize on new market opportunities, or for any other reasons. This forces them to release applications that do not have all features ready or are not tested for security bugs or efficiency as much as may be needed. Of late, you see new versions of applications released every year or so. This begs a question if they have gone through a detailed quality process, probably not, when you see the list of vulnerabilities that keep piling up year on year.

§?Outdated technology:?A modern application consists of several modules, front ends, back ends, and databases, each of which may be built using different coding languages or frameworks. There is a challenge in ensuring the currency of each of these modules and the risk of these may be becoming obsolete.

§?Backward Compatibility: While technology is developing at a rapid pace, organizations must be cognizant of the marketplace and the value for money for their customers. This drives a need to ensure that all current releases are compatible or sufficiently compatible with old hardware and versions. This might force them to reengineer things in a particular way that may not be the most efficient way of incurring a Technical Debt.

How to reduce Security Debt?

The only way to reduce a Security Debt is to Service it. If the code has vulnerabilities, the only way to make the code secure is to refactor (redo) it to correct the vulnerabilities. Otherwise, security issues will persist. Tacking something onto the top as a “fix” is like putting up makeup. The makeup may make you look good for some time, but it doesn’t make you beautiful forever.

In the long run, if you need to ensure an Acceptable Security Debt (read Minimal Security Debt) you will have to put in place a system that will help you achieve this.

This includes amongst other things:

1.??????Management Commitment: As in any security program, there should be buy-in from the CXO range about the need for security and the implications of a security problem.

2.??????Governance: A strong governance needs to be in place to ensure that the Technical Debt does not become a huge security problem. The CISO needs to be empowered to ensure that the software developers understand and are aware of security, are trained to build secure codes, and have controls in place to monitor the quality of software developed.

3.??????Business: The business needs to manage a balance between quality and speed while developing the code.

4.??????Operations: Using the right tools. A?software composition analysis?(SCA) tool will help you discover the software components that are used in your system, it will help you create a software inventory that you can use to identify and mitigate any vulnerabilities they contain and also address potential licensing problems. There are several software security testing tools and services available that can help you ensure the quality of your developed code. Following is a list of some of the tools that you could use:

a.??????ARA?(architecture risk analysis) flags possible structural flaws in a program during the design stage.

b.??????SAST?(static application security testing) uncovers security and quality defects in code during the development and build stages.

c.??????IAST?(interactive application security testing) detects vulnerabilities as a program is interacting with external input during the testing and QA stages.

d.??????DAST?(dynamic application security testing) finds vulnerabilities in running web applications during the testing and release stages.

e.??????Fuzz testing?“attacks” systems, apps, and services with random, malformed inputs to test their robustness, safety, and security.

f.???????Penetration testing?generally occurs at the end of the SDLC, where white hat hackers see if they can exploit any remaining weaknesses in a program.