In this week’s Whiteboard Wednesday, Mark Hamill, Product Manager for Application Security Products, discusses emerging technologies in the application security space, sheds light on WAF and RASP, and explains how to get the most out of both of them. Learn how to increase the security of your apps through these new technologies.
Video Transcript
Hello, and welcome to this week's Whiteboard Wednesday. My name is Mark Hamill. I'm the Product Manager for Rapid7's applications security products. Today I'm going to talk about some emerging technologies in the application security space, but more specifically, trying to help explain a couple of the current cryptic acronyms, WAF and RASP. When we talk about application security, we often use many technical terms describing the tool sets, and it's easy to forget that application security is something you do, not something you buy. The use of tools is a sensible strategy, but it's easy to lose sight of the end goal, which is more secure apps. Previously we have spoken about DAST, and just as a quick recap, that stands for dynamic application security testing, which navigates a running web application as a regular user would, discovering all of the available pages and elements, and probing to discover vulnerabilities, albeit a bit faster than a user would.
Show more
Show less
First, let's talk about web application firewalls, commonly referred to as WAFs. Web application firewall is a piece of software that sits between your web applications and the requests coming in from the Internet. Original WAFs would use a static set of rules that they would apply to incoming requests over the web, checking which ones were legit and which ones were coming from nefarious actors. That will be described as stateless. The problem with static rules is that they match on very specific patterns, and if an attacker were to change their approach, the WAF wouldn't be able to block it. So, what do you do? You update your rules, followed swiftly by the attacker updating their methods, and you can see where this is going. The loop only ends where one player in the game quits. Your attacker may give up, but that's not an option when you're defending your own applications.
Web application firewalls needed to evolve. The next step was to what we described as stateful WAFs, allowing the search for attacks to span multiple requests and responses. Now you can check how fast requests are coming in, whether or not they're from the same source, and a bunch of other indicators about behavior. While this generated a ton of useful alerts, all of a sudden we became really aware of a new problem. Too many alerts. This makes it hard to zero in on the issues that matter. To complicate the process further, apps that are being constantly updated in an environment where new attacks crop up all the time, it means the checks have to keep up, and maintaining those checks becomes a full-time job. So, WAFs are cool, but they have their limitations, as rules to block attacks are based on models using the app behavior and the attack behavior. How can we address this? Get ready for another acronym.
Next we're going to talk about RASP, or runtime application self-protection. Runtime application self-protection works a lot like a WAF, blocking bad traffic, but does so without the need for static rules. Rather than build a model, we use the actual application. Instead of predicting that a request calls a database, opens a file, or starts to shell the executed command, you watch the app at runtime to see if it actually performs those actions. This makes alerts highly relevant, because they are based on application behavior instead of a prediction. There's no need to teach a security product what's bad behavior, because you know what the application should and shouldn't be doing. When the app changes, it's no problem because your security is based on the app, not a set of rules and educated guesses about how it might react. So, that's it for WAF and RASP, and that's it for this week's Whiteboard Wednesday. We'll talk to you next week.
