Legacy applications are essential components of almost every organization yet are fraught with vulnerabilities and security challenges. Effective protection of legacy applications is a rich and complex topic that we will detail in a series of blog posts over the next several months.
Be sure to stay tuned to our blog for future installments.
Legacy Applications – Not Going Anywhere
Almost any real-world organization has a mix of applications and platforms, from legacy applications that can’t be easily retired, to cutting edge tools in cloud, hybrid, container, or serverless environments. Many organizations – from the enterprise to the industrial control space – can have software, hardware, and other technology that is designed to last a long time, sometimes even decades. There are many applications both in the enterprise and industrial control space that fulfill a strong business need.
An organization may have an “always-up” or “continuous uptime” type of policy, and these applications are mission-critical to the company. The applications may be tied to specific versions of an operating system. Both software and hardware solutions can be considered legacy technology, which means they both need constant updating.
The trouble arises when the application has been ingrained in an infrastructure for a long time but fails to keep up with patching and updates because it is tied to a particular service or function. The older the application, typically is the harder it is to upgrade or replace, and it is often part of complex custom deployments.
Legacy applications that are composed of off-the-shelf code are even more challenging because organizations cannot directly control them. When legacy applications are ingrained in an organization and has core business functions that rely on it. Once it has been implemented – the default stance – in popular parlance – is, “If it ain't broke, don't fix it.”
Ongoing Challenge of Protecting Legacy Applications
Applications are often overlooked by legacy security vendors because it can be a challenge to support them. They believe that it is far easier to get rid of the old and replace with new technology that they are better suited to defend. But the reality is that legacy applications remain an important and integral part of many organizations’ IT infrastructure. It is equally important to protect legacy applications in the same way that you protect any other kind of application.
If you have a legacy application that has been around for five or ten years, there could be hundreds, if not thousands, of different types of vulnerabilities that put that application at risk. Add to that equation the many bad actors who are always looking for new ways to exploit those types of vulnerabilities that can bypass your security and cause significant damage.
Common Legacy Application Characteristics:
May be years to decades old and no longer supported
Have vulnerabilities that grow over time and can be un-patchable
May not have original source code and developers are long gone
Security-by-patching, especially for legacy applications, will never be able to fully keep up and ultimately may interrupt business operations altogether. Patching is always difficult and with legacy applications it can be almost impossible. Patching requires testing, validation, and downtime that often has unintended or unexpected consequences that can interrupt business if these components are not executed within the time frame allotted.
An organization with an “always-up” model may not have the capacity or ability to turn a system off and patch at a scheduled time. Even if that was possible, and an organization could schedule in two or three periods a year to do patching on these systems, can you afford to wait until those patching periods have been completed? These patching periods can put your data and the organization security at risk during that timeframe.
Many legacy applications are third-party composite packages, and organizations do not own the source code. As the number of vulnerabilities have increased, an organization cannot change the code, and possibly cannot even patch to address these threats.
True Legacy Application Protection
Complete security in the real-world requires protection of all applications, from old to new, regardless of their platforms or patch status. At Virsec, our philosophy is that it is critical that an organization can protect any application – be it legacy, COTS, off-the-shelf, custom, ERP, ICS/SCADA – without requiring the source code.
In the real-world, you will never have perfect code. The rule of thumb is that the older the code, the more vulnerabilities, so we must be able to protect applications against all vulnerabilities. Virsec Security Platform® (VSP) provides application-aware workload protection at runtime without requiring prior knowledge. VSP protects the full stack, which includes the host, memory, and web level. VSP not only provides visibility at runtime, but strict application controls to ensure the integrity of the code itself.
In contrast, conventional security tools focus outside of the execution process and on the perimeter of the application, therefore creating a more limited scope of protection. They may identify anomalies during the pre/post-execution process, but they do not have the context, awareness, or visibility at runtime.
VSP Application-Aware Workload Protection
Protection for any hosted application – without source code
Runtime protection – without prior threat knowledge
Prevent vulnerabilities from being exploited
Deterministic – not probabilistic – security
Virsec’s AppMap® Technology
Virsec’s patented AppMap® technology is uniquely suited to protect legacy applications because it provides automated, continuous, and comprehensive awareness of the entire application package and its expected execution. This includes the applications’ dependencies, understanding the scripts used to control the application behavior and drive unique actions, providing visibility into the assigned memory layout, including the directory file structure, accessibility assignments, file paths, and so on.
Preventing Advanced Attacks on Legacy Applications
Advanced attacks will often use trusted files and packages and processes, and even memory of the legacy application, to build out and execute attacks. VSP’s application-aware workload protection ensures the integrity of the application at runtime. Any deviation from normal is identified within milliseconds, before the code executes, treated as a threat, and blocked through a zero-dwell time defense approach.
Key Considerations for Legacy Application Protection
Commercial Off-the-Shelf (COTS) Applications: comprise a large part of any enterprise, and they have frequent vulnerabilities. The only solution for COTS is to patch.
VSP protects COTS in runtime at the memory and host layers without prior knowledge, learning, or access to source code.
Legacy Applications: Present similar issues to COTS but tend to be older and even more difficult to patch because often patches are no longer even available. They are commonly found in the industrial control space and government, where legacy hardware and software may be more than twenty years old.
VSP protects legacy applications during runtime without access to source code.
3rd Party Binaries: Almost every application has some components developed by 3rd-parties where organizations do not have access to source code. For example, Apache and NGINX web servers run many custom web applications, but the underlying frameworks run 3rd-party compiled code that can have vulnerabilities.
VSP does not require access to source code to protect applications.
Patching: painful for almost all organizations, especially with legacy systems or industrial controls systems that can’t afford downtime.
VSP detects new or unpatched vulnerabilities during runtime and prevents them from being exploited, which can also be referred to as Patch Bridging and Compensating Controls.
Cloud, Hybrid, and Container Deployments: legacy applications are often deployed in hybrid environments or ported to containers.
VSP unique protection travels with the application itself, wherever it is deployed.
Stay tuned to our blog for our next installment in this series.