Want Real App Security? Ditch Your Legacy Code

First, thanks to PreEmptive for inviting me to do a guest post.

Since you’re reading this on preemptive.com, you are already aware of and probably concerned with the importance of planning for security in application development. In this guest blog post, I want to address the security vulnerabilities legacy applications present to your entire organization.

If the Equifax hack wasn’t a wake-up call for your entire appsec team, you’re probably headed for an earlier retirement than you might have planned.

Equifax wasn’t hacked solely because they ran an old version of Apache Struts, but it didn’t hurt. They were hacked because they didn’t update the software with a patch they had until after the vulnerability had been exploited. Waiting was fatal.

I’m pretty sure the “unnamed individual” doesn’t work there anymore, nor do the CEO, CIO, or CSO. Equifax will be in court for years, but more importantly, people like you and me now have our PII scattered all over the interwebs to be sold like chattel to whoever wants to ruin our lives.

It’s all a big bowl of wrong.

One of the more common threads running through cyber horror news is that an attack vector was old, as in legacy. Legacy OS, legacy platform, legacy apps, and even legacy languages. Legacy is old, old is dangerous, and thus legacy is dangerous. Let me restate that:

Legacy. Is. Dangerous.

But why, you ask? After all, my legacy app has been running fine for all these years. I’m still here—there is no hack that I can see.

“If it ain’t broke, don’t fix it.”

Well, the Equifax app had been running fine for years, too. Although they had experienced earlier hacks, they were on other applications. And I’m pretty sure (just guessing) that on the morning of the discovery, no one got up, yawned, and thought, “Today’s the day my career goes down in flames.” Everyone thinks they’re okay until they aren’t.

The following isn’t new, but it’s even more relevant today:

• Old stuff is vulnerable not only because it’s old, which means when it was created, people hadn’t seen (and thus armed themselves against) all the exploits that have surfaced in the intervening years.
• Old stuff is vulnerable because the code is crap, and no one knows if it’s buttoned up nice and tight.
• Old stuff is vulnerable because it relies on the full stack of other old stuff, some of which can be used against you.
• Old stuff is vulnerable because, being old, the bad guys have had more time to play with it and find weaknesses.
• Finally, old stuff is vulnerable when it uses COM objects about which you really don’t know much—maybe they are connecting to servers in Moscow warehouses, but it looks like perfectly innocent traffic if you bothered to run Fiddler all the time, but you don’t, so you can’t tell.

How to get rid of legacy

Old stuff sticks around because there frequently isn’t a reasonable way to make it newer or replace it. Looking at legacy code, you have some clear choices about disposition:

1. Kill it: if the code is crap, and it doesn’t do anything Excel (or Salesforce, Dynamics, or even Access) can’t do, ditch it. Replace it with a commercial off-the-shelf software package or subscription.
2. Improve it: If the code is good and provides business value, give it some love. Wipe out the accumulated technical debt. Refactor it to implement modern practices and patterns like DRY and KISS. Don’t let it get moldy.
3. Rewrite it: If the code is garbage but it’s a mission-critical system, you may have to rewrite it from scratch. Be warned, though: Studies show that 70% of software projects either fail outright or are “challenged.” And just like no one expected the Spanish Inquisition, no one expected their project to turn into a series of ugly meetings full of finger-pointing and recrimination.
4. Migrate/modernize it: Legacy code is often still around because it still has real business value, from thoroughly debugged algorithms to business processes and rules and staff familiarity. Those kinds of apps can benefit from modernization via AI-assisted automation.

Why migration is a better answer

The Visual Basic Upgrade Companion (VBUC) has existed since the dawn of .NET. It’s the most trusted and popular method for migrating VB6 apps to .NET, targeting either C# or VB.NET. Over 80% of the Global 1000 have used the VBUC to migrate billions of lines of legacy VB6 code.

Why? Why not rewrite? Because using the VBUC, you don’t introduce errors in existing, proven business logic code. You don’t change namespaces, comments, or structure. You don’t have a plug-in or runtime, which depends on a third-party company. The VBUC generates native .NET, readable, understandable, familiar, and correct. That cuts time and risk out of the equation, letting you get off legacy quickly.

Further, the VBUC is your on-ramp to web, mobile, and cloud. The .NET apps generated by VBUC can be fed into WebMAP and migrated to a well-formed web application as a second step. They are ready for Azure or AWS, are less complex, and are expensive to deploy.