Don’t pay the price - technical debt and security planning

In enterprise IT, the phrase ‘if it is not broken, don’t try to fix it’ is common. However, sometimes you don’t have a choice around when to make a change. When software reaches its end of support (EoS) or end of life (EoL) status, it is no longer supported and no additional changes or fixes will be released.

For IT security teams, keeping software up to date is a no brainer - it should be obvious that software is patched, so that potential issues are removed. Yet EoL software continues to be a massive risk. The Cybersecurity and Infrastructure Security Agency (CISA) estimates that 48 percent of all the issues in its Known Exploited Vulnerabilities (KEV) catalogue are in out of date software and operating systems. 

This kind of issue can have widespread implications. When the Apache Log4J issue was first discovered, more than 50 percent of the applications that used this open source software component ran an out of date version that was EoS and therefore vulnerable to the Log4Shell vulnerability. According to the Qualys Threat Research Unit, around 20 percent of critical assets - that is, devices, applications and servers that power the business and are responsible for revenue - have issues due to EoL software vulnerabilities rated as “high” or “critical” severity. This is not a small problem.

Even for organisations that you would expect to be fully cognisant of the risks, their operations can be affected by EoL assets. For example, CISA released details on how a US government agency was breached in late 2023 through a recently discovered security flaw in Adobe ColdFusion. While the issue was newly reported, it affected multiple previous versions of ColdFusion including EoL versions.

So, when we know the risk exists, why is EoL software still such an issue? When these issues exist in one in five of our mission-critical applications, why are these problems not addressed immediately? As CISOs and security leaders, how can we understand and fix these gaps before they lead to attacks?

Understanding technical debt

The EoL software problem arises because IT teams are stretched. There are not enough hours in the day to deal with all the updates, changes and additions that have to be made, so that mantra of not making unnecessary changes gets followed. When a change could lead to huge amounts of downtime and cost the company revenue, business leaders are reluctant to support these projects. IT leaders may also be risk-averse, resistant to carrying out change projects that don’t deliver additional business value but could represent ‘career-limiting decisions’ if things go wrong.

Over time, these issues fester. A single update on its own may not represent a significant amount of work, but multiple updates and patches put off for months or even years will mount up and become a drag on the team. This work is covered by the term ‘technical debt.’ Paying off technical debt can be hard, because it represents a big outlay for not much business value. This traditional way of thinking about updates makes it harder for security teams to get support for their work.

However, this means that many organisations do not consider cyber risk when they consider their technical debt and where they make upgrades, and any changes they do make will be in response to issues that have been released. This means that all the teams involved are working reactively and are already behind. These outdated assets can fail at the worst times as well, leading to higher costs on fixing problems.

To solve this, IT and Security teams have to deliver more insight into cyber risk and technical debt proactively. At the same time, this can’t be a finger waving approach that simply points out where things are going wrong. Instead, IT security has to take a collaborative approach and work with infrastructure and software development teams to get ahead of the problems before they can have a material impact.

Cybersecurity teams already hold a lot of the data to improve tech debt management within organisations, but they need help on how to engage around that data. Using the existing data that you have on asset criticality, potential vulnerabilities, and risk factors around exploitation gets you so far, but adding in cyber risk data specifically on EoL software can flag where those risks exist and how critical the assets are. This can then be put into more business risk terms so leadership teams can see the impact that not making changes will have.

In practice, this involves communicating effectively by sharing that risk and business impact data with multiple teams, then using this data to plan ahead around EoL dates six to twelve months in advance. Where existing critical assets have high-risk vulnerabilities associated with tech debt, this business risk data can put a pound or dollar sign next to that risk and provide clear information on why it should be prioritised. In the background, this data should synchronise with the other systems that companies have on their assets, such as configuration management databases (CMDBs) so that everyone involved can get that same proactive view of what is in place, what risk exists, and how to plan ahead. 

This information can be used to prioritise fixes and reduce risk. Over time, IT leaders can take a more proactive approach and reduce technical debt to minimise risk around unpatched and obsolete technology. Rather than waiting for breakages, CISOs can plan ahead and demonstrate why those changes are needed based on business needs.