ADR: Taking threat detection and response ‘below the waterline’

If you’re a naval commander, you worry about attacks coming from all directions. There could be missiles from the air, or guns could be aimed at you. Luckily, you’ve got radar to defend against those kinds of threats. What you’re probably nervous about, though, are attacks that come from below the waterline. A submarine firing a torpedo at your ship is hard to detect.

The IT estate has its own “waterline,” so to speak. It’s the application layer. Murky and opaque like the high seas, this collection of application code, servers, and application programming interfaces (APIs) can shield a variety of serious cyberthreats from your view. Then, like a torpedo coming out of the launch tube, a stealth cyberthreat like a zero-day can burst out of the application layer and move laterally in your environment, wreaking havoc in the process.

For the first time, this is a problem that can be solved. By planting agents inside code running in production, a new generation of application security tools make it possible to get better at detecting hidden threats that lurk in the application layer. This article describes how application detection and response (ADR) works and how it mitigates the risk of vulnerabilities in the application layer.

The Application Layer: Today’s Cybersecurity “Waterline”

The application layer sits between the data layer and the layer that contains endpoints, servers, and containers. It’s made up of production code, language platforms (e.g., Java), and APIs. It connects software to databases, file repositories, caches, large language models (LLMs), and more. In some cases, the layer even extends outside the corporate entity, such as when APIs integrate sources of data to mobile apps run by other companies.

This is a dynamic and complex environment, often comprising dozens of repositories, hundreds of libraries, numerous APIs and microservices, serverless functions, and containers—deployed across multi-cloud environments. When assembled, the layer embodies many vulnerabilities.

The application layer has become increasingly critical for businesses. As companies undergo digital transformation and leverage APIs and mobility, among many other technologies, to redefine customer relationships and internal processes, they rely more and more on the application layer. For this reason, the application layer is a major source of risk exposure.

Like the sea beneath the waterline in the naval context, however, the application layer tends to be difficult to see and secure. Security tools don’t have much visibility into it, if any. Attackers who can breach it gain access to valuable data. They can use the application layer as a jumping off point for attacks on other parts of the IT estate. And, they can disrupt business operations if they can impair the application layer significantly enough.

How Attacks in the Application Layer Remain Below the Waterline

This has been the year of the zero-day. These novel threats lack any kind of known signature. Google threat research noted that there has been a 53% increase in zero days released in the wild. This ominous reality is compounded by the Verizon DBIR report revealing that there has been a 300% increase in the exploitation of vulnerabilities as the initial attack vector. 

Why are zero days like Log4Shell, which take root at the application layer, so difficult to spot? The simple answer is that there aren’t any security tools located in this layer. The assumption has long been that application vulnerabilities will be addressed at the software development stage. This traditional view of application security (AppSec) holds that developers, engineers and dedicated AppSec teams will remediate vulnerabilities before code is released into production. This is not a healthy assumption.

For one thing, the AppSec process is invariably backlogged. It can take months to get to the most serious vulnerabilities. And, perhaps more troubling, traditional AppSec is inadequate when dealing with zero-days. It’s extremely difficult  to remediate a vulnerability that is unknown. Malicious actors can also embed malware in open-source libraries, which can result in a stealth threat being replicated across thousands of applications. Code scanning can manage this risk, but it’s not bullet proof, and it, too, requires remediation by developers. As a result, code often enters production containing unknown vulnerabilities and malware.

Log4Shell, a zero-day that caused untold damage worldwide, offers a good example of how an application layer attack might unfold. The attack involves a hacker sending a malicious request to a vulnerable application using the popular Java Naming and Directory Interface (JNDI). The compromised application, in turn logs the request using the vulnerable Log4J framework. Log4J then forwards the request to the attacker’s LDAP server, which a malicious payload using Express Language (EL). The EL is then injected into the application and executed.

Attacks against the Log4Shell vulnerability involve remote code execution. The attack can be obfuscated. It’s extremely difficult to detect through simple, established security practices like the pattern matching of network-level protections. The JNDI request looks normal, so few security tools will flag it. There are typically no security sensors working inside the targeted application itself.

The exploitation of a zero-day should be viewed as a behavioral anomaly in an application. A Log4Shell attack, for instance, can only be detected when it manifests in a place where existing security tools are operating. If the attack results in suspicious network traffic, it might trigger an alert from a network detection and response (NDR) or extended detection and response (XDR) solution.

However, XDR has yet to fully encompass the application layer. This omission is critical, as the application layer is a frequent target for attackers as well as a mechanism for adversary lateral movement and persistence. A security incident and event management (SIEM) solution could detect evidence of a Log4J attack in device logs, but that may occur sufficiently late for the attacker to have done extensive damage.

Web application firewalls (WAFs) offer a measure of protection, but they, to are typically configured to identify known threat signatures. They operate at the perimeter and inspect incoming and outgoing traffic to identify malicious patterns in applications. They are not effective for mitigating zero days, as WAFS are notorious for either under- or over-blocking, as well as for generating an excessive number of false positives for security operations center (SOC) analysis to handle.

Getting Better Visibility Below the Waterline

The risks from attacks at the application layer make it imperative that we find ways to enhance the visibility and capability of our XDR platforms and security operations (SECOPs) teams. ADR offers a distinctive, novel solution. By taking an “inside out” approach and embedding agents in production code, they can detect anomalous behavior through continuous monitoring while the code is running.

ADR’s internal positioning and ability to monitor the entire application stack on a continuous basis enable it to see anomalies that reveal zero day attacks. For example, consider how such a tool could detect an unsafe deserialization vulnerability as it is being exploited. The tool could generate a report that gives SOC analysts the complete HTTP request details, including the payload, a stack trace of the deserialization operation, captured directly from the running code, and a contextual diagram providing the security context of the route being attacked.

The tool might augment its context aware monitoring with automatic response features. It could block the attack without a person sending the command. This response might sandbox the deserialization process and preventing it from making any operating system calls. Alternatively, it could send the report to a security orchestration, automation, and response (SOAR) solution, which then executes an automated incident response workflow. In this case, the tool provides enriched data about the threat and vulnerability that helps the SOAR run its “playbook.” And, of course, the tool can send alerts to human SOC analysts for evaluation and response.

Conclusion

The application layer masks serious threats. The enterprise is exposed, much like the hull of a ship below the waterline. Existing security tools lack visibility into the application layer, so attackers can lurk there and expand laterally without warning. ADR changes this high-risk dynamic. By working from the inside out using in-app agents, it can detect application layer attacks that are otherwise invisible to the SOC. Allowing for automatic response, and  sending enriched data to SOAR platforms or SOC analysts. ADR protects the enterprise below the waterline.