End-of-life software is just a fact of our fast-paced technology life. Tech teams know that they need to manage the software lifecycle. Teams also know they must avoid running out-of-support software at all costs.

Nonetheless, organizations sometimes end up in hot water over end-of-life software, and sometimes through no fault of their own.

In this article, we’ll discuss strategies for dealing with end-of-life software with a focus on operating systems – though our advice also holds true for any end-of-life technology, whether hardware or software.

What Does End Of Life Mean?

To keep up with technological change, most software solutions undergo a big refresh every couple of years. Users are expected to migrate to newer releases of software versions, but also need time to complete such a migration – particularly when it comes to something like an operating system.

That’s why a software release that’s been superseded by a newer version enjoys ongoing support: it allows time for testing and migration.

Yet at some point in time, the software vendor must call it a day on older releases of their software. It’s not realistic to continue supporting a 30-year-old operating system, for example.

End of life (EOL) is how we describe this type of software, which is no longer supported or maintained by the vendor. It means that the manufacturer will no longer provide updates, bug fixes, or technical support and – in most instances – there would be no critical security updates either.

So don’t expect a vendor patch if a serious security flaw is found in an end-of-life operating system. Instead, the vendor expects that, by now, users like you have moved on to a supported version of the OS.

As a consequence, anyone relying on end-of-life software without vendor support will be exposed to security breaches because they won’t be able to apply a vendor-provided patch to protect against newly discovered vulnerabilities.

Why Is EOL Software Even a Problem?

The phrase “end of life” says it all, and sysadmins shouldn’t need much more motivation to upgrade to the latest version of an operating system before it’s too late. Besides, in practice, tech teams have plenty of notice because software vendors publish support schedules long in advance.

So, what is it that goes wrong? Why is end-of-life software so commonly in use, despite the risks?

There are a few reasons. End-of-life software is deceptively stable because, after all, everything still works. Why kick out a solution that serves its purpose flawlessly just because of some spurious security concerns?

Updating a server to the next-generation operating system is a hassle, to say the least, which is why many administrators delay the process. Sometimes there’s just too little staff resources to migrate anyway.

There’s a concern about risk: just because the current version runs smoothly doesn’t mean the latest version will run without issues. Currently installed software might not work with newer versions and configuration changes may cause outages.

Nonetheless, migrating to a supported, patched release of an OS is a prime responsibility for tech teams, and in most cases it can and should happen on time.

CentOS as a Cautionary Tale

We said “in most cases” because getting into trouble with EOL software isn’t necessarily the fault of overworked or negligent sysadmins. There could be a variety of reasons behind the practical implications of running end-of-life software, including decisions by the vendor.

That’s what happened with CentOS. CentOS is a widely-used Linux distribution that is based on Red Hat Enterprise Linux (RHEL). CentOS was celebrated for being a free, open-source alternative to RHEL that was a good fit for data centers and other enterprise-level applications.

In December 2021, Red Hat abruptly announced that it would be ending support for CentOS, creating an end-of-life cliff edge for some CentOS distributions.

The sudden end-of-life announcement around CentOS left many organizations without a stable and reliable operating system, because regaining vendor support meant shelling out significant sums for RHEL or testing and switching to an alternative such as AlmaLinux or RockyLinux.

The net result is that a significant number of organizations are running end-of-life CentOS 6 or CentOS 8 machines with no vendor support. And it really matters because organizations that had poor strategies around end-of-life software ended up in a very tough spot.

Why It Matters: Security

OK, so let’s take a deeper look into why running an end-of-life OS is such a big deal. By far the biggest threat from using an EOL operating system is the vulnerabilities found after the support expiration date. Why? Because the vendor won’t release patches for them.

For example, Linux kernel 2.6.32 has long been retired, but there have been many vulnerabilities discovered since it reached end of life, even as recently as 2019. Any Linux servers running distributions based on the older kernel would be vulnerable to denial-of-service attacks.

Leaving an EOL operating system installed means you won’t get any more security patches, so every public vulnerability announcement makes your server an open target. No patches means administrators can’t protect infrastructure.

The likelihood of attack is also higher than you’d think: because many servers are publicly available and because attackers use automated scanning tools, there’s a real risk that attackers will eventually pick up that servers are vulnerable.

Attackers are essentially fingerprinting your architecture 24/7 and will pounce on an unsupported, vulnerable operating system. The consequences can be dire.

Why It Matters: Compliance Risk

Regulatory standards surrounding financial and healthcare information mandate specific cybersecurity procedures that protect customer data. Running unsupported, unpatched software goes squarely against the mandates of several of these compliance standards.

This includes patching critical vulnerabilities within a set timeframe. But what if you’re unable to obtain a patch? Similarly, compliance regulation stipulates that covered organizations are barred from using software that is not covered by vendor or third-party support.

For example, PCI DSS requirements cover companies that handle payment card data and include a specific demand that critical vulnerabilities are patched within 30 days. Any organizations that fail to meet that deadline would be found non-compliant with PCI DSS.

Out-of-date software could lead to hefty fines and residual lawsuits that could go on for years after a data breach. For example, a $40 million lawsuit for the Target data breach in 2013 was not settled until 2016.

Why It Matters: The Best of the Rest

If the cybersecurity and compliance concerns around running end-of-life software is not alarming enough, then we’d suggest you also consider the following reasons:

• Incompatible software: When an operating system is no longer supported, developers of third-party applications will also cease support for the older system. It’s possible that updates to current applications could cause issues with the older OS, or that the software will simply no longer work with the EOL operating system.
• Poor performance: It’s not uncommon for older software to run on older hardware. This means that bottlenecks could stem from older infrastructure on the network. By relying on an outdated OS you also forfeit the performance improvements inherent to the latest versions of the OS.
• Reliability: Because older applications are no longer supported, crashes and bugs aren’t patched either. If the software fails, your server could potentially no longer boot, which affects SLAs and uptime.
• High costs: Constantly applying band-aids in order to fix and keep up software that’s no longer supported by the vendor quickly becomes costly, and you never know when an unexpected glitch will hit your pocket. EOL software developers charge a premium for support per device, which can get expensive for a large organization.

So yes, it may look as if your EOL operating systems are ticking over just fine, but the truth is far more sinister, and chances are that you’ll run into a wall sooner rather than later. Establishing where you’re exposed in terms of end-of-life software is a start.

Start by Establishing the Status Quo

If you don’t already have an inventory strategy, it’s time to get one. It’s not just about software; hardware can also hit a point where it’s time to retire it. Inventory management will help identify what infrastructure and software should be upgraded and which infrastructure should be retired.

An inventory process highlights which software has reached end of life and allows IT departments to quickly and easily identify which software is no longer supported by the vendor, if any, and to make plans to either upgrade or replace it ASAP.

Based on your inventory, you’ll identify which machines or nodes run an OS that’s close to end of life – and where you have plenty of time to address EOL. Your inventory process should also identify which end-of-life (or near end-of-life) OS instances are the most critical, so you can prioritize the actions around removing, retiring, or replacing the instances.

With an inventory process in place, organizations can plan for the efficient replacement or upgrade of end-of-life software, reducing the risk of unexpected downtime or security breaches.

Migrate as Fast as You Can – If You Can

Updating software and operating systems to the latest versions can quickly snowball. Migration should be completed as fast as possible to avoid a chain reaction of delayed updates – and to avoid migrating in a rush, which can end up breaking things.

Planning is therefore critical. With a thorough inventory in hand and working with the EOL schedules from vendors, tech teams should be able to roster migration in a way that reduces pressure but that also gets the job done in time.

Mission-critical infrastructure needs to be updated, but a new operating system must always be tested first. A mirror of production in a staging environment can help eliminate any unforeseen issues during migration.

Retiring it is also an option. Eventually, if you don’t upgrade a server, it might be time to retire it. An alternative is to move retired equipment to the cloud and migrate to a virtualized environment.

Consider Buying Extended Support

Migrating in time isn’t always an option. It can happen that all you need is just a few extra months to thoroughly test your migration plan. Thankfully, in many instances, extended vendor support or third-party support is available.

This price is usually per device and can be expensive. For instance, Windows 7’s EOL was January 2020 and the first year of support is $25/device and $100/device. Thinking about Linux distributions, vendors including Ubuntu and Red Hat Enterprise Linux offer extended support but only to customers who subscribe to comprehensive enterprise plans (at a significant cost).

Third-party vendors are another option. Provided you find a reliable vendor, you can purchase extended support at very sensible rates. For example, TuxCare’s Extended Lifecycle Support for end-of-life versions of CentOS and Ubuntu starts from just USD 4.25/server/month.

Extended support services like these will eventually also run out as vendors and third-party providers limit the extended support to e.g. 4 or 5 years. That said, Extended Lifecycle Support buys an awful lot of time for instances where the planning just didn’t work out.

Last Resort Options

So yes, sometimes it just doesn’t work out. You can’t migrate fast enough, there’s no extended support available, or – for some reason – your workload simply requires you to run an end-of-life operating system in its current state, whether you like it or not.

If you absolutely have to run an unsupported, unpatched, and potentially vulnerable OS, you need to think from an isolation and risk management perspective:

•  Network isolation: use a separate network to prevent systems running an unsupported OS from interacting with any external machines. By blocking access to other devices on your network and the internet, network segmentation can sometimes protect EOL devices from potential threats – though it is not an airtight solution and it comes with an efficiency price.
•  Virtualization for isolation: hosting end-of-life operating systems in virtualized environments improves control over these assets – making it easier to re-image if there’s a security incident while also limiting the EOL system’s exposure to the outside environment. Targeted assets can also quickly be isolated and reinitialized.
•  Application control and whitelisting: similar to the previous suggestions, this strategy isolates the vulnerable OS by allowing only known “good” applications to run on it – and interact with it. It’s a model that denies access by default, only allowing pre-approved connections.

Nonetheless, trying to get away with running an unsupported OS by segregating it is without doubt a risky strategy – there are countless attack vectors and there’s a chance that a bit of lateral movement by a crafty attacker could thwart your isolation efforts.

Conclusion

With sufficient planning, it really shouldn’t come down to desperate measures, such as isolating machines that run unsupported operating systems. Ideally, a team should migrate in time and always run a supported OS that’s kept safe thanks to easily accessible vendor patches.

But technology life can get in the way – including rash decisions by vendors, as we illustrated with the CentOS example.

Where that happens, obtaining third-party support can buy a lot of time. A support plan from the original vendor could do the job (at a high cost). If you’re running end-of-life CentOS, Oracle Linux, or Ubuntu, however, then you should consider buying extended support from an expert such as TuxCare — which delivers ongoing security updates for a much more affordable cost than distribution vendors.

Summary

Article Name

Strategies for Managing End-of-Life Operating System

Description

We’ll discuss strategies for dealing with end-of-life software with a focus on operating systems, whether hardware or software.

Author

Stephan Venter

Publisher Name

TuxCare

Publisher Logo