Not all technical debt is created equal. Many legacy business systems—whether architected in-house or purchased from software vendors—contain inherent security vulnerabilities that may be growing worse over time. In a recent Accenture study of government agencies, 85% of IT leaders believe not updating legacy technology will threaten their agency’s future. The Workplace Agility report from Capita and Citrix found more than half of CIOs surveyed think legacy applications are delaying digital transformation.

Here are five security vulnerabilities associated with legacy business systems:

1. Outdated Security Functionality Doesn’t Adapt to Evolving Threat Landscape

Today’s hackers enjoy a target rich environment—in 2018, there were more than 15,000 known Common Vulnerabilities and Exposures (CVEs). When legacy systems were developed, these applications may have been on top of then-current cybersecurity practices. But with the passage of even a short time, the threat landscape evolves while many legacy systems get left behind.

Legacy systems may be incompatible with security features surrounding access, such as multi-factor authentication, single-sign on and role-based access, or lack sufficient audit trails or encryption methods. Whatever the reason, these systems are unable to accommodate today’s security best practices.

When security flaws are discovered in legacy software, they are widely published on security blogs and in industry journals. While it is important to update security professionals on vulnerabilities, hackers are also receiving a free education. In the case of legacy systems, cyber criminals have had years to perfect tools for exploiting well-known vulnerabilities.

2. Older Hardware, Software or Databases Create Legacy Dependencies

Sometimes it isn’t just that a legacy application lacks security features, but rather that the ability to continue using that legacy application is contingent upon a variety of legacy dependencies that introduce additional security vulnerabilities. These legacy dependencies can include hardware (such as old mainframe computers), database structures, operating systems, or other legacy software.

A classic example of legacy dependencies can be found within many enterprise ERP systems. Suppose you added a third-party reporting tool or created a customized barcode scanning application five years ago that integrated with an older version of your ERP. You should have upgraded your ERP system twice by now in order to benefit from security enhancements, but you have put it off because moving to the latest version of the environment would break the integrations between your custom apps or third-party solutions.

Over decades many organizations built a web of proprietary, interconnected, mission-critical business systems that still feed into legacy databases. A recent strategic technology plan for Grand Traverse County, Michigan gives an all too familiar description:

“The AS400 based applications that are running on the IBM Platform are in-house programmed over decades. This results in many application revisions by multiple programmers with little or no oversight into best practices for security and usability. This lack of oversight creates what is referred to as spaghetti code, or code that is difficult to untangle and secure.”

Grand Traverse County had built 57 custom applications on its outdated IBM mainframe environment, and the IT department requested over $6 million just to migrate to modern platforms and applications—about 1/10th of the county’s entire annual budget. Modernizing and securing spaghetti code can be complicated, causing many businesses to delay until after a security incident occurs.

Legacy dependencies can also create a drag on business that extends far beyond the IT department. Here are two ways they slow down or prevent the achievement of critical enterprise objectives:

1. In-house systems can hold back the development of a better customer experience. Are you unable to provide customers with self-service? Do you lack the ability to launch subscription products because a legacy billing system cannot provision and invoice for them correctly?

2. Legacy dependencies can stall a strategic move to the cloud and digital transformation. A recent survey conducted by market research firm Vanson Bourne found that 85% of enterprise digital transformation architects said legacy databases limit their ability to transform. During transformation projects, 60% of architects observed that managing legacy system involvement took too much of the IT team’s time.

3. Legacy Systems Lack Full-Stack Security Visibility

Legacy systems with spaghetti code also tend to leave discarded bits of code and tools hanging around—quite possibly in your production environment. Small apps may still be used by a few employees, but may not show up in IT inventories, even though they contain old open source code. Because these tools aren’t under active development anymore, there should be a plan to sunset them or modernize them, but if they slip off the IT radar, security lapses may ensue.

Java development magazine Jax cautions IT security professionals to

“Remember, any application – no matter how big, small, old, or new – is fair game for cybercriminals so businesses can shrink their threat surface by removing any potential footholds into their infrastructure. IT and security teams need to implement a plan and process for regularly reviewing their technology stack and sunsetting applications that no longer serve a business function.”

When business systems run on a modern platform, the IT department can utilize full-stack security solution suites to gain better visibility into enterprise-wide security.

4. Internal Applications More Likely to Become Externally Exposed Over Time

Even businesses with good security procedures and the best of intentions about solving technical debt incur increased vulnerability over time with legacy systems. That’s because as years (or decades) pass, mergers, acquisitions and corporate restructuring may leave orphaned hardware and software that no one “owns” anymore. With nobody using these assets and no decommissioning plan in place for them, the legacy hardware or software bumbles along in the background, until one day an IT change inadvertently results in its exposure to the external world. An unguarded, unintended door open without anyone keeping an eye out for intrusions.

An example of this occurred when FedEx acquired a company called Bongo. Bongo’s legacy storage server went unnoticed as its IT assets were incorporated into FedEx’s environment. The result was an Amazon S3 server left unsecured online, sitting on FedEx’s network.

5. Legacy Platforms Lack the Ability to Implement Additional Layers of Security Quickly

Many security packages weren’t designed for legacy mainframe environments and operating systems. And the legacy applications themselves often lack the kind of real-time security monitoring needed to pin down and resolve security intrusions. Legacy systems might monitor performance, for example, but lack the details and contextual information that create the true visibility needed by security professionals. Audit trails and log functionality might be missing altogether or could be in a proprietary format that proves difficult to access and analyze.

The lack of adequate monitoring and logging can get enterprise businesses into trouble quickly if legacy applications are connected to both the internet and an internal corporate network. Once a legacy application has been exploited without triggering any alerts or logs, cybercriminals have free rein to run through the internal network cracking into other systems—potentially undetected—while the IT team lacks visibility into where the original intrusion occurred. By contrast, when you’re operating applications that are part of a modern cloud or hybrid tech stack, you can quickly and easily add plug-and-play security and network monitoring solutions that are interoperable with your platform.

Conclusion

The solution to legacy security vulnerabilities is tech stack modernization, followed by Continuous Modernization to keep future technical debt from accruing new security risks. Gain greater visibility into technical debt that might cause security concerns by creating an application catalog that notes legacy dependencies and assigns a measurement of risk. Then create a decommissioning plan to eliminate technical debt from the riskiest legacy systems first.

Synchrony’s Modernization Lifecycle Platform (MLP) brings an automated upgrade process, a collaborative work environment, and transparent and traceable perspectives to software upgrades. Continuous Modernization, or CM, is a complementary approach to the DevOps practices of Continuous Delivery (CD) and Continuous Integration (CI). CM gives enterprises the ability to systematically and incrementally apply new software updates to in-house applications, APIs, or any other software components, regardless of the underlying technology being upgraded.