Imagine a company that took two years to build its modern customer-facing services on top of a completely updated backend with containers, automated patches, properly managed secrets, and all the works. Then imagine attackers walking into the system through the completely unmanaged and untouched by anybody since 2014 billing server.
This is much more common than we like to admit. The security distance between the newly built backend and the legacy systems it relies on grows bigger and bigger with time.
In this post, we will talk about the reasons behind the formation of this distance, where it usually manifests itself, and what can be done about it with minimal changes to the stack.
Two systems built for two different worlds
Modern backends were developed with security in mind. Small updates are shipped regularly; all dependencies are analyzed automatically, and the vulnerability found in the morning is patched in the afternoon. There is an advanced identity management via tokenization, default encryption of any communication, and infrastructure described in code.
The legacy systems, however, were built in the era when securing the network perimeter was enough. The logic behind it was simple: keep the attacker outside the network perimeter and trust everything that is within it. It may have worked back in the days when your servers were living in a special locked-up room, and the internet was a friendly place. Not anymore.
It's not like the legacy systems themselves are insecure. On the contrary, many of them work pretty stably and well, but the security mindset behind them froze in time when everything else kept changing. It's not just different versions – it's a completely different worldview about security.
Where the cracks actually appear
The distance never makes itself known. It emerges in the seams, in the connections 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 wide permissions and an eternal password.
Everything is logged and properly managed on the modern side; there is no logging at all on the legacy side. What you've got is an effectively reinforced entrance door wired directly to an unlocked window.
Here are some of the weaknesses that can cause the widening of the gap between the legacy and the modern side of the stack:
- Mismatch in authentication schemes. The modern side, with its advanced token-based identity management scheme, has to connect to a legacy component that works only with plain usernames and passwords.
- Unpatched software that has stopped receiving updates from the vendor, thus exposing itself to known vulnerabilities for years.
- Lack of visibility. The legacy system often produces no logging whatsoever, and any intrusion into it can remain undetected for months.
Each of the problems can be handled individually. The danger lies in their combination. Once the attacker gains control of a seemingly useless legacy system, he can easily move to the actual target components through the unprotected internal network.
Why ripping everything out is the wrong first move
The obvious solution is to simply rewrite the legacy systems. But in reality, the recommendation turns out to be impractical very soon.
The legacy systems are responsible for the critical processes of your company: payroll, core banking, ordering, etc. Rewriting them requires a huge amount of time and money; the original developers are long gone; there might be bugs introduced during rewriting. This is the worst scenario where you exchange known vulnerabilities for the ones yet undiscovered.
Also, there is a budget reality. Budgets always flow toward the visible and new things, such as the customer-facing applications. The fifteen-year-old integration server will be ignored until the moment when it fails and causes downtime. And the neglect is the exact reason for the widening of the distance between the old and the new.
That's why the idea is not to immediately get the perfect modern stack, but to reduce the difference to a level where a vulnerability of one component doesn't destroy the entire stack.
Practical ways to close the gap
The good news is that you don't need a massive rewrite to reduce the distance. All you need is some isolation, visibility, and skepticism about the internal connections.
Start by building a map of your current infrastructure. Much to our surprise, many of the breaches originate from an old server that nobody knew about. You can't protect what you don't know exists, so create an inventory of all your systems and the connections between them, including who is responsible for each of them. Half of the effort will lie in just figuring out which servers are still functioning and have been doing so for years, unnoticed.
Once you've built the inventory, start segmenting the network. Network segmentation allows you to put a problematic legacy component in a special isolated zone so that a breach in it will not be able to spread freely. It is similar to isolating the problematic server from the rest of the systems by placing it in a special room with a door, rather than leaving it loose in the open office.
Then narrow the connection between the old and the new systems. Get rid of the all-powerful shared accounts and establish narrow purpose-specific accounts. Add a modern authentication gateway in front of the legacy service in order to provide authentication, logging, and rate-limiting capabilities at the connection point, while the legacy service itself will remain unchanged.
This is a safe way of wrapping the vulnerable component in a safer shell without having to touch its internals, which might be impossible to change due to the fear of breaking something important.
Visibility also needs special attention. In case an old system is unable to produce adequate logs, it is possible to monitor the traffic going to and from the system.
And finally, reconsider the location of your sensitive data. Storing critical data on the unmaintained legacy system is always a risk factor.
Moving it to a properly secured, regularly patched business cloud storage will allow us to remove the whole class of risks, while letting the legacy application work against a safer copy of the data. The idea is that internal storage should not be considered automatically safe just because it is inside the firewall.
This is the shift of the mentality, from relying on the security of the network to validating everything. The scheme, where every request has to prove its identity, regardless of origin, closes most of the doors opened by the legacy era. There is no need to adopt this scheme completely; just some partial measures will do the trick.
The cost of waiting
The distance keeps widening. Each month, the legacy system spends without updates, and more vulnerabilities accumulate around it. At the same time, the modern side is becoming increasingly safe, thus widening the contrast between them. Attackers are aware of this fact and are actively searching for the soft spots behind the fortress walls. An unmaintained legacy box is exactly this kind of soft spot.
The regulations also no longer accept age as an excuse. Modern data protection requirements demand that everything that has access to the personal data be protected, regardless of the age of the system. A breach originating from the corner of your infrastructure still brings the fines, loss of reputation, and very public cleanup that will cost much more than the maintenance did.
There is also another cost. When teams neglect the issue, they begin to develop fear about their infrastructure. People are afraid of touching the legacy systems because something can break, thus nothing improves, and the risk accumulates. Solving the problem is partially about the increased security and partially about giving your team the confidence to work with the systems under its responsibility.
Conclusion
The distance between modern backends and legacy systems is one of the most underestimated risks of the technology industry, mainly because the risky part is also the boring part. Nobody cares about the integration server that you set up ten years ago, and this is the main reason why it becomes the entry point for attacks.
It's not necessary to have a perfect environment to become significantly safer. Begin with a single practical measure, such as creating the inventory of your systems. Find the oldest one of them that is still connected to anything important and ask a single question about it: if an attacker gains control of this server, where will he go next?
This is the way of figuring out the first point of improvement. Isolate it, monitor it, and proceed from there. The gap can be narrowed by a series of deliberate actions. The best time to make the first action is before the others find it for you.
