Applications are vulnerable. Eighty-six percent of web apps have access control and authentication issues, while 80 percent of mobile apps may unwittingly expose critical vulnerabilities. As noted by Dark Reading, even traditionally “safe” digital environments such as industrial control systems (ICS) are now at risk — more than 50 percent of ICS/SCADA applications available through reputable app stores contain serious authorization flaws.
The result? Companies are looking for new ways to defend web and mobile apps that go beyond standard testing practices and empower real-time response. Enter Runtime Application Self-Protection (RASP) which is designed to detect app attacks as they happen. Over the last few years, the market for this technology has diversified and evolved; recent data puts the RASP market on track for 50 percent CAGR over the next four years.
The problem? Just like cloud computing and big data analytics before it, the expanding RASP market has generated significant hype. Now, research firm Gartner puts RASP firmly in its “Trough of Disillusionment” — businesses aren’t sure exactly how RASP works, what it can really deliver and if it can live up to expectations.
So let’s take a deep dive, dig into RASP and separate hype from reality.
The core of RASP is the first letter: Runtime. Instead of protecting apps after the fact, RASP solutions look for malicious behavior or resource calls when the application is running. RASP technologies can analyze both objective behavior and the context of that behavior to determine if specific activity is indicative of an attack or falls in the spectrum of normal behavior.
Consider the example of SQL injection, which sees hackers inserting their own SQL statements into active query fields. If applications don’t have limiter controls on these fields, it’s possible for malicious actors to compromise databases or take control of applications. RASP tools analyze these queries in real time to determine if users are inputting common requests, making run-of-the-mill mistakes or actively trying to bypass security.
If potential attacks are detected, RASP solutions can send out alerts to IT staff, terminate user sessions or stop the app in question from running. Along with thorough app testing and ongoing IT oversight, RASP is now a critical facet of application defense.
Despite a strong use case for RASP, rapid market growth has led to confusion for companies as providers attempt to brand their solutions as RASP even if they don’t quite hit the mark. As a result, there’s now uncertainty about exactly what runtime application self-protection does for organizations day-to-day.
As noted above, Gartner now places this technology in the “disillusionment” stage of their hype cycle thanks to muddied waters about its impact — many companies don’t see the benefit of yet another layer of complexity on top of their existing infrastructure, especially one that’s ill-defined by vendors.
The other problem? Remnants from the peak of the Hype Cycle which had some providers pushing RASP as the be-all, end-all of application security, capable of turning ordinary apps into fully-equipped hacker fighting machines. This simply isn’t feasible. In fact, RASP presents its own unique challenges, such as the potential to be used as a DDoS threat by hackers; if cybercriminals can force RASP-protected apps to consistently shut down sessions and terminate active processes they could effectively cut off companies from their own applications.
It’s also worth noting that the expanding RASP market now offers a choice to organizations — and not all “RASP” is exactly as advertised.
As noted by DZone, for example, some solutions marketed as runtime applications self-protection are actually just blacklist- or signature-based tools which are effectively sub-par WAFs. Other variations include delivery method; some RASP solutions are server-based while others are delivered via third-party clients. Some only provide per-platform coverage (such as Java or .NET) while others cover apps on any platform. Some vendors handle all maintenance and upgrading automatically, while others are less responsive.
Bottom line? While typical of a hype-driven market, it means companies must be diligent when looking for reliable, robust RASP.
The best way to think of RASP? As one piece of the security puzzle instead of the whole picture. Consider RASP a kind of “shield” around your applications that both registers the presence of incoming attacks and can help keep systems safe. Given the widespread use of open-source code and the necessity of interacting with public web services, no mobile app developer has complete control over their application and its component parts — injecting RASP is a way to go beyond device- or server-based controls to actively monitor the runtime environment.
The caveat? It’s not enough in isolation. Effective protection of apps starts with rigorous, reliable testing to discover and correct any in-production vulnerabilities. And once you go live, it’s important to protect apps from attacker debugging and tamper attempts and ensure that rooted devices aren’t able to run system-critical apps. But RASP tools may not see debug efforts or rooted technology as a threat to your network and won’t throw up the red flag. If you’re expecting total defense from RASP, you may not see app issues coming until it’s too late.
Here’s the takeaway: The right RASP solution helps shield applications from potential misuse or compromise. But don’t believe the hype — this isn’t fire-and-forget. Instead, combine Runtime Application Self-Protection and app hardening/obfuscation to frustrate hacker efforts by making it more difficult to tamper or remove the RASP technologies. And don’t forget, RASP and app obfuscation & encryption are part of a layered approach to protecting software. They should be used in combination with security code reviews, application penetration testing, static and dynamic security testing and other techniques.