The Hidden Security Risks of Legacy Software

Consider this: Last year, Microsoft launched a website dedicated to the eradication of Internet Explorer 6 – a product that was released in 2001, more than a decade ago. Featuring the tagline “Friends don’t let friends use Internet Explorer 6,” the IE6 Countdown website aims to persuade users to upgrade to a more modern and secure browser.

That effort has met with limited success: Today, more than 6 percent of Internet users worldwide (22 percent in China) continue to browse the web with this program that was once derided as “the least secure software on the planet” (and those words were written six years ago).

In the enterprise, the picture looks even worse. As recently as 2009, a Forrester Research study found that 60 percent of businesses were still using Internet Explorer 6.

The mere fact that a major software company would find it necessary to launch a PR campaign to discourage the continued use of one of its own products speaks to the sticky and often risky nature of legacy software.

The story of Internet Explorer 6 is really a parable for legacy software in general. Why do users and organizations persist in using legacy software for so long? Why do the risks of using legacy software increase over time? And what can be done to mitigate these risks? (But before we answer those questions, please take a moment to make sure you are not reading this article with Internet Explorer 6!)

A Sticky Legacy

Although the technology marketplace is one of rapid turnover, some products do seem to become very sticky, living on for many years beyond their expiration date. Legacy software persists for a few powerful reasons:

Investment in deployment. You’ve already paid for the product, and so the natural incentive is to keep using it as long as possible.

Investment in training. You or your employees have already invested the time (and potentially additional capital) in learning the product, and so again there is a built-in incentive to leverage established skills into the future.

Dependencies on supportive technology. Your legacy software might only run on a legacy system, which would be burdensome to upgrade. For example, the current Adobe Premiere Pro CS6 requires a 64-bit version of Windows. An organization using a 32-bit version of Windows and unwilling to upgrade the whole platform will have to stick with a legacy version of Premiere Pro.

Dependencies built on the legacy product. Your organization may have built custom products using the legacy software, creating a huge disincentive to abandon it and risk having to rebuild in-house software. Internet Explorer 6 is a classic example: Many businesses attribute its longevity to having built custom intranet apps which do not work with more recent versions of IE.

Of course, just because there are incentives to stick with legacy software does not negate the disincentives. One of the most powerful disincentives is (or should be) the security vulnerabilities left unguarded with legacy products in place.

Risk Over Reward

Saving time and money by continuing to use legacy software might seem like a reward, but it is often illusory. A security breach can easily result in a disaster which is far more time-consuming and potentially costly than maintaining up-to-date software. For example, the cost of a breach that leaks social security or credit card information now averages over $7 Million.

No software product is perfect, and even brand-new technologies possess security risks. In fact, sometimes this is an argument used in favor of legacy products – that new products may contain unknown and still-undiscovered threats, so why not stick with the tried and true. But in fact, the risks inherent in legacy software actually compound with time.

Let’s consider several reasons why legacy products can be especially risky:

Lack of vendor support. It costs money for a vendor to continue updating a product. Eventually, support may end and new vulnerabilities may either not be caught or remain unpatched. Understandably, vendors tend to concentrate more of their resources on developing, updating, and promoting new products rather than maintaining old ones.

Old threatscape. Legacy software was, by definition, developed at a time when the understanding of the security threatscape was less advanced than the present. Many of the techniques developed by hackers to compromise systems, as well as strategies created by security professionals to protect them, were less mature in the past. It stands to reason that older products possess less sophisticated security mechanisms. Just as this will be true ten years from now relative to software produced today, it is true of software produced today relative to that from ten years ago.

Code re-use. Many software products incorporate some amount of code from a predecessor or other products. This can introduce security vulnerabilities that predate even the legacy product itself.

Weaknesses widely published. When security flaws are discovered in software, they are published in security circles so that they can be understood and acted upon, either through development of patches or other defenses. But this also educates the hackers, and for a legacy product the known vulnerabilities have been exposed for years, providing ample time for hackers to learn, understand, and develop tools to exploit them.

Patch lag. Compounding the above point, many organizations are slow to install security patches even when they are released by vendors. This allows legacy products to remain exposed for a potentially long period of time—during which the information about those very flaws is increasingly disseminated.

Evolving hacker tools. When a new security flaw is discovered in a contemporary product, many times it can only be exploited by the most sophisticated hackers with a high degree of tech savvy. Over time, the hacker toolkit evolves, and compromises which once required the most advanced knowledge can be executed by more rudimentary hackers using simplified tools, sometimes even with user-friendly interfaces and guided by online tutorials.

Dependency on insecure platform. In some cases, a legacy product may only run in a legacy environment. For example, Quickbooks Pro 2006 is not supported under Windows Vista or newer. Even if the legacy product in question does not itself pose a security risk, the fact that it forces us you continue using a highly exploited platform (Windows XP) still puts your organization in a vulnerable position.

Of course, not all legacy software is created equal—nor equally vulnerable. Network-facing applications—those that can be accessed off-site or controlled remotely typically carry the most risk.

Defensive Strategies

Let’s be clear: Upgrading is your best defense against the security risks of legacy software. While no product can be guaranteed free of security flaws, newer products have been built with the knowledge of past vulnerabilities in mind. It will take time for new vulnerabilities to be discovered and exploited.

But sometimes the upgrade path is blocked. The budget might not be there. A newer version might not even exist. When a legacy product must be used in a networked environment, consider one of these strategies to mitigate risk:

Isolation through virtualization. One of the many great uses of virtualization is to sandbox a risky platform to keep it isolated from your important systems. Using free software such as Oracle VirtualBox, you can, for example, run a legacy copy of Windows 95 or XP with your legacy apps within a self-contained window on a modern, secure system. Better yet, the virtual system can be cutoff from network access to the outside world.

Virtual patches. Sometimes there is no security patch available to directly modify and harden a legacy product. But a so-called “virtual patch” can address a known vulnerability upstream of the insecure application itself. For example, legacy database products can be vulnerable to SQL injection attacks – when a query sent to the database sneaks in syntax which tricks the database into modifying or revealing otherwise protected data. A virtual patch could consist of rules in a firewall packet inspector or web server which look for and detect SQL injection syntax and block the request before it ever reaches the vulnerable legacy product.

Aaron Weiss is a technology writer and frequent contributor to eSecurity Planet and Wi-Fi Planet.

Aaron Weiss
Aaron Weiss
Aaron Weiss is a technology writer, comedy writer, and web developer.

Latest articles

Top Cybersecurity Companies

Related articles


Please enter your comment!
Please enter your name here