Developers rely on languages like Python, Node.js, and Java to write and release complex web applications, but their rapid development cycles make securing these applications a challenge. Enter RASP (run-time application self-protection), which incorporates vulnerability protection directly into the application to block threats as they appear.
Applications use RASP to self-protect against internal and external attacks by including the security controls into the application runtime engine, such as the JVM. Since the controls are part of the runtime engine, RASP has a comprehensive view of the application's logic flow, data flow, and configuration.
At the basic level, RASP protects the application by blocking unauthorized attempts to execute shell commands. All of this is done without requiring any changes to the application code.
"RASP moves protection inside the application itself," said Mike Milner, CTO of Immunio, which offers a platform to protect Java and other dynamic languages, including Python, Node.js, and Ruby on Rails.
Immunio's platform isn't limited to just detecting and protecting against code-level vulnerabilities and application issues like cross-site scripting and SQL injection. It can also detect and block account takeovers. Immunio recently added Node.js support to the platform to reflect the growth in Node.js within enterprises.
Many enterprises have focused their development efforts on a single language, such as Java or .Net, and used static analysis tools to look for vulnerabilities in those applications. The growth in adoption for dynamic languages makes it harder to rely on static code analysis to find vulnerabilities. Dynamic languages are increasingly powering large swathes of the internet, and enterprises need faster methods to mitigate vulnerabilities in production environments.
Enterprises typically have to wait for the vendor to release a patch for commercial applications, which leaves open a window of opportunity for attackers. The situation is even murkier with open source applications. With RASP, though, organizations can protect the applications while waiting for the official patch, regardless of when it actually arrives.
Consider the Java deserialization flaw publicized earlier this year. The vulnerability has been patched in applications like JBoss and Websphere, but it likely remains unpatched in older Rails applications, and Milner noted that many custom Java applications likely still have the flaw. This is where RASP comes in handy, as it can protect the application against exploits attempting to trigger that flaw.
Make no mistake -- RASP is not the cure-all for addressing software vulnerabilities in web applications. It should not be considered a replacement for the Web application firewall, or even an excuse for dumping application security testing and static code analysis. A WAF excels at detecting and blocking network-level attacks against the application, such as detecting malicious IPs and automated bots, and blocking denial of service attacks. RASP, on the other hand, is better suited for monitoring code-level vulnerabilities and mitigating cross-site scripting and SQL injection threats.
Applications are under attack, so instead of looking for one silver bullet to protect them, enterprises need to use a combination of detection and protection techniques which span development and operations. Developers still need to run code through static code analysis scanners to find vulnerabilities during the development phase. Application security testing helps find security issues before the software goes live.
For the devops devotees, security testing and code scanning address the "dev" part of the equation, and RASP covers the "ops," as it lets teams be "proactive about vulnerabilities in their applications, instead of being reactive," Milner said.