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 and probably concerned with the importance of planning for security in application development. And in this guest blog post, I want to address specifically the security vulnerabilities that legacy applications present to your entire organization.

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

Equifax wasn’t hacked solely because they were running 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 whomever wants to ruin our lives.

It’s all a big bowl of wrong.

One of the more common threads I see running through cyberhorror news is that an attack vector was something old, as in legacy. Legacy OS, legacy platform, legacy apps, 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–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. And although they had experienced earlier hacks, they were on other applications. And I’m pretty sure (just guessing) that the morning of the discovery no one got up, yawned, and thought, “Today’s the day my career goes down in flames.” Because everyone thinks they’re ok until they aren’t.

I wrote this a little while ago, but it’s even more relevant today:

Old stuff is vulnerable not only because well, it’s old, and that 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 really knows if it’s buttoned up nice and tight.
Old stuff is vulnerablebecause 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 around with it and find weaknesses.
And 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 doesn’t seem to be a reasonable way to make it newer or just replace it. Looking at legacy code, you have some clear choices about disposition:

Kill it: if the code is crap, and it really 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.
Improve it: if the code is good and it provides business value, throw some love at it. Wipe out the accumulated technical debt. Refactor it to implement modern practices and patterns like DRY and KISS. Don’t let it get moldy.
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 expects the Spanish Inquisition, no one expects their project will turn into a series of ugly meetings full or finger pointing and recrimination.
Migrate/modernize it: A lot the reason legacy code is still around is that it still has real business value–from thoroughly debugged algorithms, business processes and rules, and familiarity by staff. 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 been around since the dawn of .NET. It’s the most trusted and popular method to move VB6 apps to .NET–targeting either C# or VB.NET. The VBUC has been used by over 80% of the Global 1000 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 with its commensurate dependency 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 and efficiently.

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 a second step to a well-formed web application, using popular building blocks like ASP.NET MVC, JSON, JavaScript, HTML5, and more. Ready for Azure or AWS. Ready to run on mobilize. Less complex and expensive to deploy.

Learn how you can get off legacy today.