Legacy Data is Valuable, but Legacy Applications Are a Risk. What’s a Finserv IT Department to Do?
In January 2022, infosec and tech news sources blew up with stories about “Elephant Beetle,” a criminal organization that was siphoning millions of dollars from financial institutions and likely had been doing so for over four years.
This group is sophisticated. It is patient. But the truly frightening part of the story was that the group was not using genius-level hacking techniques on modern technology. On the contrary: Their MO is to exploit known flaws in legacy Java applications running on Linux-based machines and web servers. Doing this carefully, the group has been able to create fraudulent transactions, thereby stealing small amounts of money over long periods. Taken altogether, the group managed to siphon millions unnoticed.
What this story reveals is that legacy applications are a huge liability to financial institutions. They have known vulnerabilities that, too often, go unpatched, and they can be exploited without raising an alarm.
Even if they are not breached by bad actors, such systems can be a drag on institutional resources. According to research done by Ripple back in 2016, it was estimated that maintaining legacy systems accounted for some 78% of the IT spending of banks and similar financial institutions.
The question is: Why are financial institutions holding onto these legacy applications? And what can be done to minimize the risk they pose?
The Need to Retain Legacy Data
Most companies have at least one legacy application they still support simply because they need its data. In some cases, that data has to be held to fulfill retention requirements for
operational or compliance purposes. In other cases, that data holds important business insights that can be unearthed and used profitably. And in some cases, it’s a mix of both.
But with the march of technological progress, it’s easy to see how this situation can get out of hand. Some organizations have hundreds of legacy applications they’ve accumulated over time just to keep easy access to the data stored within them. The vast majority of those applications are no longer being fed live data, having been replaced by next-generation solutions. But they sit on the organization’s network just the same, taking up resources and allowing bad actors to have a back door to other more mission-critical applications.
Because these applications are no longer in use or are being updated with new data, it does not make sense to patch and maintain them continually. (And in most cases, patching is not even an option as no one is supporting the legacy application anymore.) To really make them safe, they should instead be retired. Application retirement, done correctly, can render an application inert while still providing select users access to its data.
Application Retirement is Now a Part of Finserv IT Best Practices
Application retirement is the process used to decommission applications (and any supporting hardware or software) while securely keeping their data accessible to maintain business continuity. As applications grow, develop, and change, the number of legacy applications that need to be carefully retired grows exponentially.
An application retirement program is simply a strategy, including a schedule and a set of rules, for ensuring that application retirement happens correctly. Any application retirement program must ensure that the right data is retained and in the correct business context so that the data remains meaningful to business users (or auditors) long after the legacy application is decommissioned.
More and more businesses are looking for increased sophistication when it comes to such programs because they provide:
- Direct savings by eliminating legacy support and maintenance costs (which, again, can account for 78% of financial institutions’ IT budget).
- Efficiency gains by delivering effortless access to historical business data.
- Regulatory compliance through application retention rules that manage data securely throughout its lifecycle.
That said, the most challenging part of a retirement program often is getting it off the ground. Getting leadership buy-in, determining retirement criteria, and classifying all of the applications in the ecosystem can produce hurdles to effective execution.
And even when those hurdles are cleared, the process itself takes a great degree of technical expertise to execute. System analysis; data extraction, processing, and storage; user access design—all of these need to happen seamlessly before the application itself can be successfully retired.
Getting the Expertise on Board for a Successful Application Retirement Program
We’ve only scratched the surface here regarding best practices around application retirement. Those interested in learning more about the application retirement process and the best practices around a robust application retirement program are encouraged to download our white paper: Application Retirement: The Practical Guide for Legacy Application Maintenance.
But even with this quick glimpse, two things are already clear. One is that it takes a good deal of technical know-how, as well as best-in-class tools and technology, to successfully retire applications while still making the critical data within them accessible.
The other is that relying on the status quo is simply not a viable option. While the organizational and technical hurdles to proper application retirement are substantial, their cost is far outweighed by the cost of doing nothing—which includes not only wasting valuable IT department time and budget but also leaving the back door open to bad actors.
Interested in tools that make application retirement easier? Ask us about Infobelt’s Application Retirement Workbench, available with Omni Archive Manager.