Dante Alighieri said it best, "Abandon all hope, ye who enter here." Many believe he was referring to entering hell, but he was actually referring to securing legacy applications.
Legacy applications tend not to get a lot of TLC. The codebases are usually large and not well documented. Basically, there aren’t many people chomping at the bit to sign up to support legacy anything. This blog post assumes that legacy applications are not being maintained, except when something breaks.
TL;DR
There is really nothing you can do besides fixing your crappy code. Everything below are decent suggestions, but in reality, it is like putting a band-aid on a bullet wound. Best solution is to retire the application.
RECON
First, find all the documentation, diagrams, or really anything that can help (I mean, if you can find any). Really, you don’t have time to read all of this, but it is an excellent CYA technique ;). You should go through the application and understand what it does, know where the codebases used are located, and find the DNS entries that point to it.
Use all the Tools
The bosses love it when you use all the tools. Plus you are already paying for them so you should just use them right?
Web Application Firewalls (WAF)
I hate WAFs with a passion. I think, for the most part, they are pretty useless. That being said, you should use one. There are some things that I find useful about WAFs; for example, they let you know when people are scanning your site with off-the-shelf tools. I mean, if a nation-state wanted to hack you, then this blog isn’t going to help you anyways. Also, some WAFs have built-in DoS protection. If your site can’t handle more than 20 requests a second (I mean, you have much bigger problems), then this is definitely a helpful feature.
Runtime Application Self-Protection (RASP)
I have never used any RASP technology before in production (only POCs). I usually unfairly throw them into the same usefulness category as WAFs. I know nothing about the performance impacts of RASPs either, so do your own testing before you decide to use one. Since RASPs could have deeper integrations with your code or the runtime, they could help prevent injection attacks like SQL, Command, etc. If you want them to secure your shitty business logic, then this probably isn’t the right tool for you.
Dynamic Application Security Testing (DAST)
DAST scanning can be a pain to set up depending on your website/API/whatever. Running your own out-of-the-box scanning tools will let you see what the “attackers” will see when scanning your application with their out-of-the-box tools. You can use this information to tune your WAF, if you want.
Static Application Security Testing/Software Composition Analysis (SAST/SCA)
I like SAST, but I am totally biased because I worked on a SAST scanner long ago. But since this is a legacy app, it kinda falls into the “more you know” category. SCA is cool too but let’s be real. You are never going to get your devs to upgrade their Struts2 framework that is 10 years old. At least you will have some useful information to give to the people in your organization that care about open source licenses.
Locking down sections
Does your admin panel really need to be accessible to the entire internet?
Remove unused/unsupported functionality
Like the admin panel, if there are pages that are broken or no longer in use, why is your website serving them?
Politics
What do we do with all of these results that we aren’t going to fix? Well, this is where you make a top 5 or top 10 list of vulnerabilities that has to be fixed. So this list would include things like a “world-ending-the-sky-is-falling-if-something-did-this-we-would-be-ruined-because-of-a-breach-level” vulnerabilities. Once you get this list, get it in front of all the stakeholders of that application. Make sure everyone knows about these vulnerabilities and the suggestions to fix them. Seriously, look at the code and guestimate how long it would take to fix it. If it is an easy fix, just write the code and give it to the devs as a suggestion to improve.
The only real way to secure legacy apps is to actually fix the vulnerabilities. Point out the ones they absolutely have to fix and stop caring about the other ones, even if they are high or critical, because those will probably never get fixed, and the business owners will just have to eat the risk on those ones. Legacy apps are hard, no one wants to maintain them, and no one wants to spend money to support them.
Retirement
Try to agree on an end of life or sunset date for the legacy application. This is the best way to “fix” your legacy app. This will inevitably get pushed back forever, but at least there will be a light at the end of the tunnel that can give you hope.
Remember that maintenance is the cost you pay to be in production. Or you can just ignore it and hope it goes away. It is really up to you and the business.
About the Author
Ray is a Life Coach and Conspiracy Theorist. He does AppSec in his non-spare time for money. Twitter