Everyone hates dealing with legacy code and monolith systems. However, the longer you leave your legacy systems "frozen" in time, the greater your risk of breach becomes. With attacks occurring in greater frequency & severity and vulnerabilities piling up, it's time to do something (anything) with your legacy systems.
By: Stephen Graham @ AnonTech
The dreaded legacy system. No owner. No new features. Increasingly fewer people who can support it. Yet somehow, it lives on. For whatever reason, you can't replace it, and you can't shut it off. Maybe it performs some critical business function that isn't very well understood. Or it's an internal app and you just can't get the resources to replace it. No matter what the reason for its continued, undying existence, the longer your legacy systems endure, the greater your risk to breach & exposure becomes.
Software developers & IT professionals are constantly updating systems to protect against security breaches. However, once a piece of software becomes legacy, it may no longer be supported and will stop receiving security updates. This leaves your entire system vulnerable to an attack. Additionally, legacy systems’ lack of vendor support makes them particularly vulnerable to cyberattacks as well. The famous Equifax breach of 2017, which resulted in the exposure of 146 million Americans' personal information, was caused by a failure to patch a critical vulnerability in a legacy system developed in the 1970s. According to WHOA, the #1 cause of a data breach is old, unpatched security vulnerabilities. Additionally, according to MSSP Alert, enterprises with outdated technology lose 47% more money on average when they suffer a data breach compared to those who update their IT systems in a timely manner.
The unfortunate and uncomfortable truth is the longer your legacy systems are left frozen in time, the greater the risk those systems pose to your business. So what do you do? If you are able to sunset a legacy system, either by replacing it with a new system or handling capabilities with alternatives, fantastic! Don't delay any longer, get your people together, put together a sunset plan, and get rid of that risk.
But what if you cannot sunset a legacy system? What if the function it provides is too valuable or there are simply no alternatives? In that case, you need to take some basic steps to make some updates to the legacy system and reduce the risk that system introduces. If you take it piece-by-piece, you can eventually get to the point where the legacy system can be fully replaced.
Step 1: Get Backing from Management
Let's face it, not only will no volunteers emerge to update a legacy system, but IT and engineers will actively fight to not get involved. You need to educate business management on the risks and associated potential costs this system poses to your business. The IBM Cost of a Data Breach Report 2021 is a great place to start gathering some of this intelligence and there are plenty of other resources out there to help build your case. Present your case to management and get them to formally sponsor & back this effort once they fully understand the risks.
Step 2: Get Technical Ownership
Most legacy systems no longer have someone that "owns" it anymore. Getting ownership on a project like this is paramount to its success. Work with your business & technical leadership to identify the right person or team to own the system and the efforts to modernize it.
Step 3: Limit the Scope
Because engineers hate taking over legacy code & systems, their first response is almost always to rewrite the system in its entirety all in one shot. Sometimes, that may be the right approach, but in general, if your goal is simply to reduce risk in a timely fashion and not fully reinvent the wheel, this may not be an option (there is an entertaining story here about what happens when you try this approach). Keep the scope down to just reducing the risk that the legacy system is imposing on the business.
Step 4: Find & Fix Known Vulnerabilities
Have your IT team patch the system's associated infrastructure up to modern standards. Ask your engineers to use code scanning software like SonarQube to identify & fix known security issues in the code. If nothing else, taking these basic steps will greatly reduce your risk of exposure and put you in a much better spot. Suggest a regular cadence on this step, maybe quarterly so that you stay current with newly identified attack vectors. Work the scans into your release process so that any newly introduced code or dependencies get scanned before getting released to the wild.
Step 5: Remove Personal Information
Even though the system is now patched & updated, the technologies being used are still likely old & outdated and therefore still pose a significant risk of breach. If nothing else is done to the application, at the very least update it to remove direct access to personal information (PI). Have any PI removed from directly attached databases, moved to a secure & modern service behind an API, replace the PI in the database with pointers, and update the code to push & pull PI from the new, secure API as-a-service when needed. At AnonTech, we offer technology to help with this effort with our personal information management platform, ViziVault. Regardless of what you decide to use, get the PI out of the system directly to eliminate your exposure of the riskiest and costliest form of data when it comes to data breaches.
Step 6: Iterate
By removing PI from the system and moving that into a microservice which specifically manages that data, you've taken the first basic step in modernizing your legacy system and drastically reduced your risk. However, maintaining the rest of the legacy system is still going to be a major source of frustration for the organization. Have your engineering teams keep going with the modernization effort. Identify pieces of the monolith that can be ripped out into smaller microservices and managed independently on a modern tech stack. Take it one piece at a time until there's not much left of the original system.
Step 7: Cut-Over
Eventually, you'll get to the point where the original legacy system is no longer doing all that much. Most of the functionality is being supplied by smaller, more manageable microservices. Now is the right time to take the significantly smaller effort to replace the remainder of the system and replace it with a new, modern system. Keep doing the regular patches & code scanning and let your microservices handle their respective functions so that you don't end up back where you started. Congratulations, you have now fully replaced your legacy system!
Even if you don't make it all the way to cut-over, each step incrementally reduces your risk of breach & exposure and makes your legacy system easier for your organization to maintain. Remember, every day that your legacy systems sits frozen in time, your risks are growing and compounding. New attack vectors are discovered every day and it is a constant battle to stay ahead of the bad actors. Don't let your company be in the next data breach report, take action today and get those legacy systems updated.