Why Is Runtime API and Application Protection Important?

We recently unveiled our latest advancement in the evolution of API and application protection – ThreatX Runtime API and Application Protection (RAAP). Why did we go in this direction and focus our engineering resources on runtime protection? Because in the aftermath of the Log4j vulnerability announcement in December 2021, we realized that runtime protection is critical for stopping malware and other malicious runtime threats from impacting APIs and applications. 

Lessons From Log4j  

Thanks to the dedicated team of experts that runs our managed services, we were early in identifying attacks related to the Log4j vulnerability. Beyond addressing the initial wave of Log4j-related attacks, our experts were also able to work with our customers to roll out virtual patches as all the attack variants emerged in subsequent months. As we were doing this work, the limitations of only observing HTTP request and response pairs became clear. Many Log4j attacks were runtime-related, and while the HTTP requests were giving us a lot of information, it took us a lot longer than we wanted to understand what attackers were targeting, what techniques they were using, and how they were going about it. 

We’d been looking at some new technologies and other ways to gather more threat information, and dealing with Log4j moved runtime protection up the priority list and incited us to make that investment. 

Introducing ThreatX Runtime API and Application Protection (RAAP) 

And this led to the development of ThreatX RAAP, powered by eBPF. Extended Berkeley Packet Filter (eBPF) is a framework that extends the ability to attach at the kernel level within a Linux environment, and, more importantly, it allows you to safely peer into that data, without modifying the kernel, and stop malicious processes and infected containers without any performance degradation. Ultimately, RAAP gives us a lot more data beyond typical HTTP, from monitoring at the kernel level, seeing all the way down to network flows, the process tables, arguments, environment variables, etc. And we can do this do in a really efficient, low-impact way.  

RAAP vs. RASP 

There have been other runtime protection technologies available for a while, like runtime application self protection (RASP)-based products, which were deployed as agents. The big challenge with RASP was that teams had to deploy agents in numerous places, and the agent maintenance made it untenable. With RAAP, we deploy a single sidecar container, and yet it gives us even more visibility than some of the traditional RASP-based solutions, all without managing agents. 

What’s Possible With RAAP 

ThreatX’s runtime protection goes beyond basic observability to extend threat detection, tracking, and blocking to customers’ runtime environments, without slowing developers or requiring expertise in cloud-native applications.  

Some API security solutions claim runtime protection, but actually simply highlight potential vulnerabilities, leaving security teams to investigate and recommend code changes or to try to model the complex behavior in a third-party WAF. ThreatX offers true real-time blocking for runtime threats.  

As organizations transition apps and workloads to the cloud, often across multi-cloud environments, attackers seek new ways to access sensitive data. While the Log4j vulnerability served as a wake-up call to runtime threats, shoring up these gaps is easier said than done. With ThreatX RAAP, organizations can greatly extend protections beyond the edge and address a myriad of risks to runtime environments, including insider threats, malware, web shells, remote access software, code injections and modifications, and malicious rootkits.