How to close SIEM visibility gaps created by legacy apps

As companies get better at analyzing log data to spot potential security threats, legacy applications create blindspots that can be hard to tackle. “Modern SIEMs [security information and event management] have evolved beyond their own legacy feature sets, and have become advanced threat detection and response platforms,” says Gabriel Gumbs, chief innovation officer at Spirion, a data security company.

The log data available from legacy applications doesn’t always translate well to these platforms, he says. For example, a legacy application might be able to report who has access to the system, he says, but not what they have access to inside those systems. “That’s a visibility gap that requires closing,” he says.

The problem is exacerbated when legacy applications must be monitored for threats. For example, they may have been built when security requirements were vastly different than what we have today, or before best practices were in widespread use.

They may also include known vulnerabilities, require outdated and insecure infrastructure, or have access to sensitive data or critical systems. “Take, for example, the energy sector,” says David Mound, principal cybersecurity engineer at Furnace Ignite, a UK-based startup that makes it easier to collect data from legacy applications and feed it into SIEMs. “They’ve got SCADA infrastructure, things that have been around for years.”

A recipe for unwanted surprises 

Companies sometimes don’t want to touch applications that are running, he says. It’s not just the energy sector. “Generally, when I’m doing consulting, most companies seem to have some legacy applications kicking around,” he says. “Payroll, or something like that, that’s been left untouched for years.”

Too frequently, legacy applications don’t offer the kind of monitoring that companies need. They might produce performance data, for example, but not fine-grained details about which users accessed which data, or they are missing context that security researchers would need to discover what happened. If they do produce logs, they might be in some proprietary, difficult-to-use format.

“Especially for internally developed legacy applications, there are going to be definite visibility gaps,” says Jeremy Batterman, global director of threat intel and detection at Trustwave, a cybersecurity firm.

That’s a major concern when cybersecurity security events occur and need to be investigated, he says. “In the incident response cases that I’ve worked, it’s oftentimes a one-off application that caused the issue,” he says.

In addition, the lack of logging can exacerbate other security problems with a legacy application. For example, in one case, a company had a legacy application that was connected both to the internet and also to its internal network, instead of being placed inside a DMZ. “They also didn’t realize that they were using an old version of JBoss and Apache that were trivial for the attacker to compromise,” he says. “Once it was compromised, there was no visibility there, and the attackers are easily able to move through the network.”

During his incident investigations, Batterman says that he often asks companies why they kept the legacy application around. “Oftentimes, it’s money,” he says. “More often, it works for them, so why change it.” According to an Accenture survey of federal IT leaders, 37% says that legacy applications hinder their ability to protect against cyber threats and 85% says that their agency future is threatened unless they update their technology.

To discover how many legacy applications are in their environment, companies should look for them as part of their threat and vulnerability assessment, says Ron Schlecht, managing partner at BTB Security, a cybersecurity consulting firm. Sometimes, companies are well aware of their insecure legacy applications because they’re trying to get rid of them, he says.

Legacy applications sometimes fly under the radar. “In most of those cases, the applications are used very infrequently, or by smaller departments,” Schlect says. “Since there haven’t been any problems, people just continue to use them.”

Sometimes, an application has already been replaced, but the legacy version continues to run. “That tends to be a surprise,” he says. “Sometimes it’s just that they forgot to turn it off. Other times, they still want to be able to access old historical data in the application.”

Either way, these applications and servers are hanging around, Schlect says. “Anytime you have that in the environment, there’s a possibility that someone might misuse that.” It’s particularly dangerous if an application is running with administrative privileges or has functions that could be used to escalate access. If the application is sitting on an old server, there might be vulnerabilities in its environment, as well.

Modernizing legacy apps

The first step, according to Schlecht, is to check if the original vendor can help get log data from the legacy system to your SIEM. “Maybe the vendor could provide an API or at least some documentation,” he says. “If not, there could be custom development efforts to try to get logs out of that application.”

Another strategy is to modernize the entire application, not just the logging functionality. That way, the company can address not only its cybersecurity needs, but also compliance, scalability and other business requirements. According to a Gartner report, for every dollar invested in digital business innovation through 2020, at least three times as much is spent on modernizing legacy applications. The investment is worth it. In addition to security risks, legacy applications may not meet today’s business needs and can’t keep up with the pace of technological change, are hard to scale, can create compliance risks, and may be too expensive to maintain.

According to another Gartner report, there are seven major ways to modernize a legacy application:

1. Encapsulate it and make it available as a service
2. Rehost it
3. Move it to a new runtime platform
4. Refactor the code
5. Rearchitect the application
6. Completely rebuild or rewrite it from scratch
7. Replace the application, taking new requirements and needs into account.

Mitigation strategies

When a legacy app can’t be modernized or replaced, companies can adopt mitigation strategies to help address some of the visibility problems. For example, if an application has a back-end database, it might be possible to grab access and usage information from the database itself, says Trustwave’s Batterman. If there’s traffic going in and out of an application, a network sensor could be used to capture data packets, he adds.

Whatever the mitigation strategy, enterprises should also put extra protections around their legacy applications, Batterman says. “Perhaps we’d be able to build a more locked-down system or have just a small portion available as a service,” he says. “And there are architectural things they can do to keep it from being on the front lines.”

For example, many companies, faced with the problem of having to maintain an old, insecure application, will sandbox it and put it in a virtual environment or the cloud, says BTB’s Schlecht. That way, if it is compromised, there will be minimal impact on the rest of the organization.