By Ajay Singh, Author of CyberStrong! A Primer on Cyber Risk Management for Business Managers
Whenever a significant cyber-attack happens (which is more frequent now than ever before), several issues relating to vulnerabilities, technology, and processes are back on the discussion table for those responsible for cybersecurity. One issue that often gets bypassed or does not get the attention it deserves is the cybersecurity debt that an organization accumulates over time.
What is Cybersecurity Debt?
Cybersecurity debt is a subset of what is known as ‘technical debt. Simply put, it is an accumulation of vulnerabilities that exist on account of shortcuts taken during the development, deployment, and operation of applications, systems, and networks which at any time can potentially become a source of risk to organization systems. Security debt arises from many factors such as insufficient upfront investment of time, money, resources to address security concerns, inadequate testing, security preparedness procedures, and a tendency to address security issues at a later date. Like the pressures of monetary debt, security debt imposes a long-term burden in terms of unaddressed security issues.
Not updating systems in time from known vulnerabilities is another form of security debt. Equifax notoriously failed to update a known vulnerability in Apache Struts even though a patch was available, which led to a data breach that compromised the personal data of more than 147 million US citizens. While Equifax is an oft-cited example, delayed patching is more prevalent than we can imagine. A survey by security company Tripwire found that unpatched vulnerabilities cause one in three data breaches.
Even though organizations are aware of the risk involved due to delays in patching, sometimes the sheer scale of the exercise across thousands of systems, locations and devices may be a daunting one. What is more challenging is finding the vulnerabilities that need to be patched.
Regardless, not patching in time raises security debt and according to Ponemon Institute, the average time to patch is 102 days. They further discovered that 57% of organizations that faced a cyberattack felt that applying a patch would have prevented the attack. What was worse was that 34% said they were aware of the vulnerability before the attack. Today, there are many hackers equipped with various tools which are constantly looking for unpatched vulnerabilities. Living with this kind of cybersecurity debt can be flirting with danger and is avoidable!
Not all vulnerabilities are equally dangerous. MITRE maintained the Common Vulnerabilities and Exposures (CVE) list is a valuable reference for publicly known vulnerabilities. Vendors also provide information to their user organizations that can be useful. Prioritization based on impact and likelihood of risk materializing from vulnerabilities can help ensure that risks are mitigated.
There is also the issue of dealing with cybersecurity debt from legacy business systems that are still in use but do not have their original development teams (inhouse or vendor teams) providing fixes and patches for security vulnerabilities. This type of cybersecurity debt is difficult to address and may involve the costly upgradation of legacy systems. In this context, Accenture, which conducted a study of government agencies, found that 85% of IT leaders believe not updating legacy technology could threaten their agency’s future.
For a software development team, the temptation to use open-source software is hard to resist in the face of hard deadlines. Development timelines and budgets are invariably tight. There is a tendency to focus on a limited set of security concerns without fully understanding the security challenges that may emerge later in the deployment life cycle. Often analysts who define business and functional requirements are focused on aspects of business value and importance and less on security matters. This leaves room for vulnerabilities that attackers can exploit and results in the building up of security debt. Organizations have used multi-functional development teams, including people from development, security, and operations (called ‘devsecops’ teams) to focus on security throughout the development cycle.
Testing methodologies like Static application security testing, interactive application security testing, dynamic application security testing, along with pen testing are today an integral part of a software development cycle. Despite this, the lack of attention to security needs during the development cycle results in vulnerabilities that are not found until after deployment and sometimes discovered only after being exploited.
Eventually, security measures must be commensurate with risks, and this is often a changing equation in a fast-moving cyber threat landscape. In this context, existing security debt puts your organization at a much greater risk of malicious cyber exploits. To address the issue of security debt, organizations must first recognize it as an essential cybersecurity concern. At an actionable level, the following five steps could help in the reduction of cybersecurity debt:
- Maintain an Enterprise-wide Software Bill of Materials (SBOM)
- Use a software composition analysis (SCA) tool to help discover the open-source components you are using and develop a risk mitigation plan.
- Ensure timely patching and updates
- Build-in security as far as possible during the design and development phases
- Eliminate legacy Hardware, Software, or Databases dependencies as soon as possible
Becoming security debt-free is perhaps being idealistic, and neither is it entirely necessary unless it represents a source of risk. The more significant challenge is to be in control and not keep raising your levels of security debt across applications, networks, and systems, as this could lead to unwanted consequences such as data breaches, fines, loss of customer and investor trust, and possibly litigation. Without a plan to address it, cybersecurity debt could well be a ticking time bomb!
