Understanding and Selecting RASP 2019: Use Cases
Posted under: Heavy Research
As you might expect, the primary function of RASP is to protect web applications against known and emerging threats. In some cases it is deployed to block attacks at the application layer, before vulnerabilities can be exploited, but in many cases it processes a request until the attack is clear and then halts the action. This is different than many other types of
Astute readers will notice that these are, by and large, the classic use cases for Intrusion Detection Systems (IDS) and Web Application Firewalls (WAFs). So why look for something new if there are other tools in the market that already provide application security benefits? It’s not what RASP does, rather how it does it, that makes more effective in a wider range of application deployments.
Let’s delve into more detail about what clients are asking for to put this more into focus.
Primary Market Drivers
As RASP is a (relatively) new technology, current market drivers are tightly focused on addressing the security needs of two distinct ‘buying centers’ which are unaddressed by existing security applications. And this is where the hundreds of conversations with buyers we have had since 2017 comes into play because there has been remarkable consistency with the stated requirements. The two ‘buying centers’ are security and application development teams. The security teams are looking for a reliable WAF replacement without the burdensome management requirements, and development teams state they are looking for a security technology to protect applications and fits within the development process.
The discussion of the security team requirement is going to be controversial, so some background on WAF functions and usability are in order beforehand. This is critically important to understand the problems as this is why so many firms looking for a solution like RASP.
Web Application Firewalls typically employ two methods of threat detection; ‘Blacklisting’ and ‘Whitelisting’. Blacklisting is detection – and often blocking – of known attack patterns spotted within incoming application requests. Think SQL injection as an example. Blacklisting is useful in screening out lots of basic attacks against an application, but as new variations of attacks are regularly created, these lists are not complete and attackers find ways to bypass them. Again, think SQL injection as there are many different variations.
But it is Whitelisting where WAFs provide their real value. A Whitelist is created by watching and learning acceptable application behaviors, creating a list of acceptable behaviors over time, and preventing any requests that are not on the approved behavior list. This approach offers serious advantages over Blacklisting as the list is specific the the application being monitored, it is far easier to enumerate the list of good functions – as opposed to every variant of malicious requests – and therefore easier (and faster) to spot unwanted behaviors.
Now here is the bad parts: Developers complain that in the normal course of application deployment, the WAF can never complete the Whitelist creation – or ‘learn mode’ – before the next version of the application is ready for deployment. In essence, WAFs true value is never realized as it can’t create the Whitelist fast enough, so it devolves to a Blacklist enforcement tool. Developers and IT teams alike complain that WAF is not fully API enabled and that setup requires lots of manual work. Security teams complain that they need full time personnel to manage or tweak rules. And they all complain that, when they try to deploy into Infrastructure as a Service public clouds, that the lack of API support is a non-starter. Couple that with additional comments of a genuine lack of vendor support beyond a basic ‘virtual appliance’, including no support for cloud native constructs like application auto-scale groups, ephemeral application stacks, templating and scripting/deployment support for the cloud environments. As application teams become more agile, and as firms have a greater footprint in public cloud, the less value they get from traditional WAF.
To be clear, WAF can provide value, especially the commercial WAF ‘Security as a Service’ offerings, which focus on Blacklisting and some additional protections like DDoS mitigation. These are commonly run as a proxy cloud service, often filtering requests ‘in the cloud’ before they pass requests onto your application and/or RASP solution. But they remain ‘Half-a-WAF’ in function. Traditional WAF platforms continue to work for on-premise applications with a slower rate of deployment, and thus the WAF has time to build and leverage a Whitelist. So for most, WAF is not being ‘ripped and replaced’, but it’s not being used in cloud or for more agile development teams.
Simply stated, security teams are looking for an effective application security tool (re. WAF replacement) that is easier to manage. They need to cover application defects and technical debt as not every defect can be fixed in a timely fashion in the code.
Developer requirements are more nuanced; they cite the same end goal, but couch the request in terms of what solutions can be fully embedded into their application build and certification processes. More to the point, security tooling must go the extra mile to protect against these attacks and mesh well with the disruptive changes occurring in the development community. The solution needs to be as agile as the application development process, which often equates to automation capabilities. It needs to scale with the application, commonly seen as the ability to be bundled with the application stack during the build. It should understand their application and tailor protections to their runtime. It should not require that developers be the security experts. And for those development teams who embrace the concept ‘shifting left’ to get security metrics and instrumentation earlier in the process, they look for tools that work in pre-production as well as production.
RASP offers a distinct blend of capabilities and usability options which makes it a good fit for the above two use cases. It’s why, over the last three years, we get several calls each week to discuss RASP.
Functional Requirements
The market drivers mentioned above change the traditional functional requirements (i.e. what features a buyer wants).
- Effectiveness: It would seem cliché to think of effectiveness as a buyer requirement – why buy if the product does not actually work? – but there are lots of security tools that don’t work, produce false positives to the point the product is not usable, or require so much maintenance that you could have built your own solution for less investment. RASP typically provides full capabilities without the need for run-time learning of application functions, provide broader coverage to application threats as they work in context of the application itseld, and given threats to todays applications (see Capital One cloud hack) can and should be run in blocking mode.
- API Support & Automation: Most of our readers know what Application Programming Interfaces (APIs) are, and how they are used. Less clear is the greatly expanding need for programatic interfaces in security products, thanks to application delivery disruptions caused by cloud services and DevOps principles. APIs are how we orchestrate building, testing, and deployment of applications. Security products like RASP offer their full platform functionality via APIs, sometimes as build server plug-ins or even as cloud services, enabling software engineers to work with RASP in the manner their native metaphor. And they provide agents, containers or plug-ins that work within the application stack.
- Application Awareness: As attackers continue to move up the stack, from networks to servers and then to applications, attacks tailored to application frameworks and languages are the norm. RASP is differentiated by its ability to include application context in security policies. Many WAFs offer ‘positive’ security capabilities (i.e.: whitelisting valid application requests), but being embedded within applications provides additional application knowledge and instrumentation capabilities to RASP deployments. Further, some RASP platforms help developers by specifically reference modules or lines of suspect code. For many development teams, potentially better detection capabilities are less valuable than having RASP pinpoint vulnerable code.
- Pre-Deployment Validation: For cars, pacemakers, and software, it has been proven over decades that the earlier in the production cycle errors are discovered, the easier — and cheaper — they are to fix. This means testing in general, and security testing specifically, works better earlier into the development process. Rather than relying on vulnerability scanners and penetration testers after an application has been launched, we see more and more application security testing performed prior to deployment. Again, this is not impossible with other application-centric tools, but RASP is easier to build into automated testing, can often determine what parts of an application have vulnerabilities, and is commonly used during red-team exercises and pre-production ‘blue-green’ deployment scenarios.
When we wrap this series with a buyers guide, we will go into other technical aspects of differentiation that come into play during an evaluation.
Next up we will discuss the three major architectural approaches RASP vendors employ to deliver their solutions.
– Adrian Lane
(0) Comments
Subscribe to our daily email digest
*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by [email protected] (Securosis). Read the original post at: http://securosis.com/blog/understanding-and-selecting-rasp-2019-use-cases
