Imagine a company that took two years to build its modern customer-facing services on top of a completely overhauled backend with containers, automatic patches, well-managed secrets, and all the functionality. Then imagine attackers breaking into the system using a completely unregulated and untouched payment server since 2014.
This is more common than we like to admit. The security gap between a newly built backend and the legacy systems it relies on grows larger over time.
In this post, we will talk about the reasons for the formation of this grade, where it often manifests itself, and what can be done about it with small changes in the stack.
Two systems built for two different worlds
Modern backends were developed with security in mind. Small updates are posted regularly; all dependencies are analyzed automatically, and risks found in the morning are crushed in the afternoon. There is improved identity management through tokenization, automatic encryption of any communication, and code-defined infrastructure.
Legacy systems, however, were built at a time when protecting the network circuit was sufficient. The logic behind it was simple: keep the attacker outside the network perimeter and trust everything inside it. It may have worked in the days when your servers lived in a special locked house, and the Internet was a friendly place. That's not the case anymore.
It's not the same as inheritance plans themselves are not protected. On the contrary, many of them work stably and well, but the concept of security behind them is strengthened at a time when everything continues to change. It's not just different versions – it's a completely different worldview about security.
Where cracks appear
The distance does not make itself known. It comes from the gut, from the connection between the old and the new.
One common example is a modern microservice that needs to pull some data from a legacy database. For convenience, it establishes a connection to this database using a shared service account with broad permissions and a permanent password.
Everything is logged and managed correctly on the modern side; no logging at all on the legacy side. What you have is a successfully secured entry door with a straight line to the open window.
Here are some of the weaknesses that can cause a widening gap between the legacy and modern side of the stack:
- Differences in authentication systems. The modern side, with its advanced token-based identity management system, should connect to the legacy component that only works with empty usernames and passwords.
- Unattached software that has stopped receiving updates from the vendor, thus exposing itself to known risks for years.
- Lack of visibility. A legacy system usually does not produce logging, and any intrusion into it may remain undetected for months.
Each problem can be handled individually. The danger lies in their combination. Once an attacker gains control of a seemingly useless legacy system, they can move to the actual target components via an unsecured internal network.
Why getting rid of everything is the wrong first step
The obvious solution is to simply rewrite the legacy programs. But in reality, this recommendation seems to be obsolete soon.
Legacy systems are responsible for your company's core processes: payroll, basic banking, ordering, etc. Rewriting them requires a lot of time and money; the original developers are long gone; there may be bugs during rewriting. This is a worst case scenario where you are replacing a known vulnerability with an undiscovered one.
Also, there is the reality of the budget. Budgets are constantly flowing towards tangible and innovative things, such as customer-facing applications. A fifteen-year-old integration server will be ignored until such time as it fails and causes inactivity. And carelessness is the direct reason for the widening of the gap between the old and the young.
That is why the idea is not to get a complete modern stack immediately, but to reduce the differences to a point where the vulnerability of one component does not destroy the whole stack.
Effective ways to close the gap
The good news is that you don't need a major rewrite to reduce the distance. What you need is isolation, visibility, and skepticism about internal communication.
Start by mapping your current infrastructure. What surprised us the most was that most of the violations came from an old server that no one knew about. You can't protect what you don't know is there, so create a list of all your systems and the connections between them, including who is responsible for each of them. Part of the effort will be found in just finding out which servers are still active and have been doing so for years, regardless.
Once you have built the inventory, start segmenting the network. Network partitioning it allows you to place the problematic part of the inheritance in a special isolated area so that the violation in it cannot spread freely. It's like isolating a problem server from all other systems by putting it in a special room with a door, rather than leaving it free in an open office.
Then reduce the connection between old and new systems. Get rid of shared accounts and create accounts for specific purposes. Add a modern authentication gateway in front of the legacy service to provide authentication, logging, and throttling capabilities to the interface, while the legacy service itself will remain unchanged.
This is a safe way to wrap a vulnerable part in a safe shell without touching its internals, which may not be possible to replace for fear of breaking something important.
Visibility also needs special attention. In case the old system cannot generate enough logs, it is possible to monitor the traffic to and from the system.
And finally, rethink the location of your sensitive data. Storing important data in an unattended legacy system is always risky.
Moving it to a well-protected, regularly patched area business cloud storage it will allow us to remove an entire class of risks, while allowing the legacy application to run against a safe copy of the data. The idea is that internal storage shouldn't be automatically considered safe just because it's inside a firewall.
This is a mindset shift, from relying on network security to verifying everything. The system, where every application must prove its identity, regardless of where it comes from, closes many of the doors opened by the legacy era. There is no need to accept this plan completely; just some partial steps will do the trick.
The cost of waiting
The distance keeps getting wider. Each month, the legacy system spends without updates, and many risks accumulate in it. At the same time, today's side is getting safer, thus increasing the difference between them. The attackers are aware of this fact and look for soft spots behind the fort walls. An unattended inheritance box is this type of soft spot.
The regulations also no longer accept age as an excuse. Modern data protection requirements require that everything that has access to personal data be protected, regardless of the age of the system. Violations from the corner of your infrastructure still bring fines, loss of reputation, and public cleanup that will cost more than the repair.
There is also another cost. If teams ignore this issue, they start to fear for their infrastructure. People are afraid to touch legacy systems because something can break, thus nothing improves, and the risk increases. Troubleshooting is partly about increased security and partly about giving your team the confidence to work with the systems under their responsibility.
The conclusion
The gap between modern backends and legacy systems is one of the most underrated risks of the technology industry, mainly because the dangerous part is also the boring part. No one cares about the integration server that set it up ten years ago, and this is the main reason why it is an entry point for attacks.
You don't have to have a perfect place to be very safe. Start with one practical measure, such as doing an inventory of your systems. Find the oldest still connected to anything important and ask one question about it: if an attacker gains control of this server, where will he go next?
This is how to get the first point of improvement. Break it down, monitor it, and move on from there. The gap can be narrowed through a series of deliberate actions. The best time to make the first move is before others discover it for you.
Image Source
