Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Five Most Important Things to Know About RASP

DZone's Guide to

The Five Most Important Things to Know About RASP

Mike Milner shares his five most important things to know about runtime application self-protection and how it can help secure your data in production.

· Performance Zone
Free Resource

As developers turn to agile languages like Python and Node.js to build complex web applications, it has become more difficult than ever to secure these apps. Development cycles continue to shorten, which makes it more challenging to ensure app security during runtime. Web applications are prime targets for attackers, because they are externally-facing, so they present a larger attack surface.

RASP (runtime application self-protection) technology brings security directly into the application, so threats can be blocked as they emerge — even in production. RASP is a relatively new approach to web application security, and it’s often compared to WAFs (web application firewalls). But there are significant differences in the two approaches.

WAFs protect apps after they’re developed and deployed, by observing incoming requests and comparing the request input data against known attack signatures. By contrast, RASP works inside the runtime engine, so it has a more comprehensive view of the application’s logic, data flows, and configuration. Armed with this information, RASP helps organizations address vulnerabilities in all their apps, even after they’ve been released.

If your organization is seeking new solutions for web application security, it’s important to understand these differences so you can determine which type of solution is right for you. With this in mind, here are the five most important things to know about RASP.

RASP protects your apps even if the network perimeter has been breached. With RASP, attacks that take advantage of vulnerabilities missed by the development team can be blocked in real time.

With RASP, you don’t have to rely on static signatures to detect malicious behavior inside your apps. Instead of signatures, a RASP adjusts to application changes automatically without requiring code changes because they can access application internals. This approach allows active protections to be defined and implemented so they do not interfere with legitimate traffic.

With RASP, you can protect your apps without making changes to application code. Using an agent library that’s installed alongside the application, making it accessible to developers, RASPs work by automatically hooking functions and methods in the web application, rather than by changing the code itself.

RASPs protect against more than just coding errors. The most advanced RASPs protect against many different attack types including account takeover attacks, scanning and scraping, and zero day bugs in third party libraries and frameworks.

A RASP won’t replace all the other tools in your web app security arsenal, but it’s a critical addition to that toolset. RASP technology picks up where static and dynamic analysis tools and WAFs leave off. Malicious traffic is identified, along with the vulnerable code it is trying to exploit. Developers get full details on exactly what they need to fix. What’s more, because the RASP operates at runtime, it can fence off the vulnerable segment until remediation has taken place, providing real time protection against potential exploits leveraging that vulnerability.

The bottom line is that developers should still test for and fix as many vulnerabilities as possible before deployment. Firewalls and other perimeter defenses should still monitor network access, along with identity or access management systems. But by adding RASP to your organization’s web app security toolset, you can enable applications to secure themselves in real time, in the production environment — keeping your customers, their data, and your organization safe.

Topics:
performance ,security ,runtime application

Published at DZone with permission of Mike Milner, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}