News Stay informed about the latest enterprise technology news and product updates.

Prevoty offers context-aware, automatic RASP

Though I’ll admit to a bit of skepticism about Runtime Application Self Protection (RASP), I was nevertheless impressed with a recent look at Prevoty. The two-year-old company’s product, which currently has support for Java and .NET Web applications and services, can be dropped into production systems without recoding being required, uses a separate server (either on premise or in the cloud) to do the heavy compute parts, and seems to have a smarter-than-average approach to determining the application context in which requests (such as SQL queries) are made within the running application.

Getting the context right is important in RASP, because otherwise you’re more or less just melding the brains of a web application firewall (WAF) to each of your applications—to no particular advantage over just using a real WAF. Nor is context all that easy to get. It’s not simply a matter of scanning the code or scanning user input on the fly, and Prevoty does no static scanning or signature hunting, according to Prevoty CTO Kunal Anand, who started his career working on Mars rovers at NASA, moved on to build and run the security team at MySpace, then graduated to be the technology head for BBC Worldwide.

“We don’t believe in pattern matching at all,” Anand says. Instead, Prevoty has recreated the parsing procedures that browsers and other components use. “If you think about SQL databases today,” he says, “the SQL database typically has what is called a query planner, which looks at a database query and can understand things like which indexes they need to pull.” Prevoty has built in a query planner that replicates how the planners in all the major SQL databases work. “We can see every field that’s going to be accessed, every function that’s going to be invoked, every table where information is going to be coming from, and we’re also able to do this recursively, so we can see subqueries and joins.” Protection against things like injected JavaScript works in similar fashion.

Like some other RASP products (Arxan’s, for instance), Prevoty can either be used in a completely automatic fashion, where programmers don’t have to change a single line of code. “They’re simply including the Prevoty JAR files and adding it to the XML file for execution,” Anand explains.

There’s also an SDK approach where developers directly call Prevoty functions at appropriate moments in the control flow of their applications.

The automatic approach offers both a passive learning mode and a mode that will take action when problems are detected. The passive mode, being asynchronous, does not impact the normal performance of the application. The active mode’s performance impact depends on whether the deployment is using an on-premise engine or the cloud engine. If it’s on premise, Anand says customers are seeing round-trip times between app and engine in the range of one to two milliseconds. Cloud users see round trips of 20 to 40 milliseconds. Processing at the engine takes seven milliseconds.

I was walked through a demonstration of adding Prevoty to an application, in this case the WebGoat application (OWASP’s sample application that’s intentionally built with a number of significant security flaws). Before installation, it’s trivially easy to inject malicious JavaScript into the application from a text field (in this case, an alert popup that says hello). After installation (which literally takes seconds), the same injection is detected and the response is bracketed so that it’s returned in a non-executable form that the browser simply ignores.

One important distinction between this form of detection and the sort of input validation that developers are generally encouraged to include with every input field is that Prevoty doesn’t perform this function by searching for strings of JavaScript—again, no pattern matching. If static scans for matching expressions were performed, the Prevoty engine would be fooled by hackers that obscure code by transforming it into characters that, when evaluated as script, evaluate to perform the same functions as the original code, even though the obfuscated version doesn’t appear to be script at all. There are a number of ways to do this and I won’t dive into it here, but poke around and you’ll find several online tools for doing this in various ways. To be fair, most of the obfuscation approaches have sufficiently characteristic appearances that new signatures for those obfuscations can be added to a static scanning engine, but there’s always the chance of some new approach to obfuscation that one isn’t scanning for. Anyway, since Prevoty is aware of the context and what’s about to be executed, it recognizes that nothing should be executed from the text field and catches the problem whether it’s obfuscated or not.