19-07-21 | Blog
Maintaining a legacy system architecture is increasingly regarded as an expensive luxury by some organisations and especially those severely financially impacted by Covid-19. It can be a costly practice, due the high system availability requirements and high original number of concurrent users when application was live. When they become legacy, these systems may be addressed by a lot of users, but usually only for brief periods and with a low number of concurrent users. Given that cost reduction is such a common target for organisations running large legacy applications such as SAP systems, finding work arounds is always a priority.
One work around that has often been regarded as a safe bet is to move legacy systems onto Virtual Machines (VMs). It is seen as a cost-effective way to maintain legacy system access and also sustains access required to eventually shut down the machine when it is no longer used, further reducing cloud computing costs.
Yet in their haste to find cheap solutions, many organisations have failed to appreciate some of the drawbacks with Virtual Machine (VM) usage, for instance, not taking into account data privacy deletion requirements (such as GDPR), or the lack of monitoring. There is another frequently overlooked issue too - security. This article explains why security can be compromised when using a VM for maintaining legacy application access and why data archiving and using specialist solutions is a safer and cheaper alternative.
As their name suggests, legacy systems rely on old architecture. The server firmware, operating systems, applications and databases are all old and have often missed out on the usual maintenance fixes and upgrades issued by vendors during last phase of their deployment lifecycle. They are vulnerable. Even if an organisation wanted to, maintaining legacy systems indefinitely may not even be possible and upgrading them is rarely part of the IT strategy.
Moving them into the cloud on VMs sounds good in principle but there are inherent risks with this approach. This is because cloud computing relies on the ability to run multiple virtual machines on a single hardware platform, so whether you are using on premise VM or cloud VM, it can lead to same potential malicious activities. Attackers will always try to penetrate virtualization technologies regardless of where the applications are hosted.
This practice is evident in the data shared by CVE (https://cve.mitre.org) The CVE website identifies, defines and then catalogues publicly disclosed cybersecurity vulnerabilities – their reports identify dozens of cases or hypervisors.
However the situation is actually more complex than this, as this November 2020 paper by Dina Mohsen Zoughbi and Nitul Dutta highlights (https://www.ijitee.org/wp-content/uploads/papers/v10i2/B82621210220.pdf). It classifies cyberattacks on cloud applications in three different ways – a hypervizor-based attack, a VM based attack, and VM image attacks. Therefore, the assumption that the only vulnerability is the hypervisor is incorrect, because two other means to attack a legacy application on a virtual machine exist. There’s more to consider.
Some attacks inject rootkits based on virtual machines that can attack and then take control of the hypervisor, giving them full control of the entire environment. Hyperjacking is a good example (https://en.wikipedia.org/wiki/Hyperjacking). In an attack like this, it’s not only the legacy system VM that is vulnerable, all virtual machines under supervision may also be completely controlled by the attackers.
This means an outdated legacy system VM, for example, a Windows 2003 machine, may not just be a security vulnerability but an open door. And not only to legacy system information, but to current systems! The last thing any IT department wants to encounter is a virtual machine escape, when an application breaks away from the VM and interacts with the host. This would open up an organisation’s whole cloud architecture or VM environment.
Shifting legacy systems onto a VM may seem like a good idea on the surface, but taking all the security risks into consideration, it could represent a high price to pay when there are better cost efficient options.
For instance, by either decommissioning a legacy system completely, or using specialist applications that make it easy to securely decommission legacy systems, but retain access where needed, e.g. for auditors. ELSA by TJC (Enterprise Legacy System Application) is one such solution.