Considering RASP and Modern Application Security Defense

Are you considering RASP? Certainly many enterprises large and small are so you aren’t alone. Having runtime application self-protection (RASP) sounds great conceptually, and if implemented right, it actually will be a very important component in your application security program. Rather than attempting to author an eloquent award winning blog post on RASP, I think this will be a more useful post by just sharing some thoughts and real world experiences on RASP from an application security practitioner’s perspective. Or to phrase it more eloquently, a brain dump!

In the end, my goal here is to outline things for you to consider as you look into purchasing RASP. I expect some of these points will resonate with you, and some you may even disagree with. That is all good. The worlds of application development cycles, operations, and deployment platforms continue to evolve so an open dialogue on where approaches in application security is headed is important.

Agile Development and the Need for RASP

Why is runtime application self protection (RASP) important? There needs to be a fundamental shift in how we think about protecting our applications. Traditional application security programs strive to find all the vulnerabilities before code is deployed to production, e.g. SAST, DAST, and manual testing. But, the speed of business is pushing for quicker, and more frequent, development cycles, e.g. agile. To not get in the way of business, slowing it down, we need the ability to defend our applications in production at runtime. This doesn’t mean we do away with SAST, DAST, or manual testing — but we do need to continue optimizing how we implement them (a post for another time). The fundamental shift needed is in how we think about agile development. The key point being, with agile we can deploy faster, which means we can react to and mitigate threats faster. However, to react we need effective threat visibility and protections. This is why a layer of self-protection is important

More RASP Reading

Before moving on, I’d be remiss if I didn’t mention relevant posts from my colleagues. James Wickett talks about why legacy WAFs just don’t cut it in his post, “Web Application Security: The New Way Forward”. And Tyler Shields expands on RASP in his post, “What’s in a Name? RASP Smells like a Rose”. That is a truly eloquent post on RASP 🙂

Let’s Get to the Brain Dump…

My first encounter with RASP was several years ago from a few of the early vendors in this space. At the time I was running application security programs at a large investment bank and we were always interested seeing what was new in the market place, and open to modifying or adding to our layers of defenses. After going though their pitches and demos here were my take aways:

• Very intriguing approach — it certainly was new and different compared to what had been on the market for the last decade or so.
• Given the platform support limitations, I would not be able to cover all the applications I cared about.
• Given the limitation of threat coverage, if I’m going to add another layer of protection I wanted more than typical OWASP type injection attacks. I want traffic source anomalies, request anomalies, and coverage over application business logic, e.g. high risk transactions.
• Given the implementation of policy management, and in one case “learning”, the RASPs I reviewed would require per application oversight and management.
• Given the deployment implementation, I could not see how it could be deployed at scale. It would require a lot of political capital to achieve buy-in across the board from application teams. Also, if things go wrong or break, and they will, I would be spending more of my time and developer time troubleshooting.

For these implementations of RASP, my conclusion was simple. While very interesting technology, it was a lot of effort (deployment/implementation struggles) for relatively little gain (limited scalability and coverage). I needed to wait and see how the RASP market evolved.

RASP Coverage Matrix

Since then, the market has definitely evolved, however more so on the number of vendors in the space, rather than on the implementation and coverage. As an example of this, see the coverage matrix I compiled based on publicly available information (as of April 21, 2017) below. Note, for languages not listed there is no coverage for them. 

After having conversations with many other application security practitioners in various enterprises, I’ve collected a few sound bites based on their experiences. Here is the collection of sound bites for your consideration.

• The RASP implementations evaluated introduced too much friction into the process.
• Due to how the RASP solution hooked into the application, it conflicted with and broke a performance monitoring service the development team relied upon.
• After a year of attempting to deploy to dozens of applications the effort was abandoned. The first three deployments encountered issues, then subsequent application teams did not want to attempt installing the solution.
• The development team migrated applications to a new application stack, which is not supported by the RASP solution. Now a new solution is needed.

RASP Done Right

So what is the conclusion that should be taken from all this? The concept of runtime application self-protection is certainly a great one. In fact, due to today’s evolving development cycles it is a critical layer of defense. However, it has to be implemented the right way, which is to say it provides the following:

• Scalability — frictionless deployment, and coverage over all applications regardless of technology stack or language.
• Visibility — threat visibility across applications, and access to the data that will enable teams to react to threats in real-time.
• Integrations — integrations with development lifecycle tools, ability to integrate with other security solutions in the environment enabling security automation.
• Business Risk Coverage — the ability to address risks associated with business logic, or high risk transactions.

As you navigate your way through the evolving world of agile development and DevOps, you will likely find yourself considering RASP. The key is finding the right approach and solutions that make the most sense for your developers and your business. I hope you find the considerations offered here helpful in your efforts. Finally, I do have one additional consideration for you, which is to make Signal Sciences a part of your RASP evaluation (or even re-evaluation). Signal Sciences was built to address scalability, visibility, integrations and application business risk, and with these capabilities it provides a coverage matrix that looks like:

Signal Sciences provides web application security solutions that encompass both Next Generation WAF and RASP technologies. Signal Sciences was built in response to our own frustrations of trying to use legacy application security approaches while enabling business initiatives like DevOps, cloud adoption, and CI/CD.