Good EOL Management is Good Vulnerability Management
In this bog post, we discuss why managing EOL or deprecated software is an inherent part of managing vulnerabilities but usually has a longer resolution time thus needing a proactive management process.
tldr
Resolving EOL takes a lot more time since there is no security patch to just apply. Upgrading, replacing, or de-risking an EOL software requires planning ahead of time with engineering teams and leadership.
A proactive EOL management process cuts down on cross team friction and actively contributes to vulnerability management by reducing the exploitation of vulnerabilities in EOL software.
Why care about EOL software?
EOL software and dependencies are potent attack vectors. The 2023 government agencies breach was caused by an EOL version of Adobe ColdFusion. The 2017 Equifax data breach was caused by an EOL version of Apache Struts (still an issue to this day!). One of the most famous ransomware attack, WannaCry, exploited EOL Windows systems. In each of these case, the attackers exploited vulnerabilities in EOL software.
EOL risks are fundamentally about the unknown unknown. Once EOL, a software no longer receives any attention from the publishers or security researchers until an (in)famous exploit surfaces. In a weird way, you almost don’t want to hear that your EOL software is being patched because that means something has really gone afoul. The only thing for certain is that if a vulnerability does exist, there will not be the resources to identify it as a CVE nor the will to address it in a security patch.
This means that even though not all EOL software have vulnerabilities that are exploitable, the ones that do have no quick fix increasing the risks to your organization when they surface. Remediating an exploit of your EOL software could take weeks absent an out of band security patch from the publishers because remediating EOL is rarely just a minor version bump or patch.
Why can’t you quickly fix EOL software?
By definition almost, EOL software will not have a security patch waiting to be applied. This leaves fewer choices for remediation. There are 3 most likely paths to remediation; upgrade, replace, and de-risk.
Upgrade
If luck will have it, there will be a new major version of a software can be upgraded to that is not EOL. For example Vue 2 became EOL on December 31st, 2023, we can upgrade it to Vue 3 which has active support. However, this is much easier said than done. A major version upgrade of this level requires not only the identification of it as a priority by AppSec teams but also the active collaboration of the engineering team.
The engineering team needs to evaluate whether Vue 3 supports all Vue 2 features that are in use. The engineering team also needs to evaluate potential breaking changes in relation to other dependencies of Vue. The actual upgrade and post upgrade monitoring can be heavy lifts as well and this is not to account for micro-services architecture where this effort will have to be duplicated across all services. All of a sudden this went from an AppSec priority to an engineering nightmare. If the upgrade was not identified ahead of time (quarters ahead), then this is not only an engineering nightmare but one on a ticking clock. Hardly the stuff that builds healthy security and engineering relationships.
The fortunate part is with careful planning ahead of time in collaboration with engineering, an major version upgrade can eliminate a massive attack vector in your software supply chain.
Replace
Fortunately many commercial EOL software have a major version that can be upgraded to. However, this is rarely the case for open source projects and dependencies. Open source projects are more decentralized in nature. There isn’t a single person or entity in charge, they rely on the community for technical support. This is a fantastic way to build software but they end up lacking an official EOL date. An open source project could naturally fall into an EOL state due to low community involvement. This means less security research on it and a slim chance that a security patch can be issued promptly.
Replacing a poorly maintained open source project due to a lack of newer version can be challenging and time consuming. It is challenging because a one-to-one valid replacement might not exist. It is time consuming because just like a upgrade, the rip and replace process followed with validation can be involved.
De-Risk
When neither upgrading nor replacing are viable then adding compensating controls can help reduce the risks. This does not solve the underlying issue of vulnerabilities being exploited in EOL software but it controls the risk in the event of an exploitation.
There are many possible compensating controls from isolating the service running EOL software to stricter access controls. De-risking services running EOL software is most effective when implemented ahead of time, before potential vulnerabilities in EOL software are exploited. As with both paths above, the process needs to be deliberate and proactive.
What are the best practices for managing EOL software?
- Know about all your EOL software from operating systems to open source projects and which will become EOL.
- Create plans to upgrade, replace, or de-risk EOL software in conjunction with your engineering team.
- Be proactive with your EOL remediation plans! Do not wait until the last minute or react to an exploit!
Ultimately you should treat your EOL management process as part of your vulnerability management process. There are vulnerabilities in EOL software but there are much fewer remediation options. As with a good vulnerability management program, EOL management programs should also be proactive and deliberate.