In part one of this two-part series, I explained that runtime application self-protection is a technology that...
plugs into runtime environments for applications—most often, the Java Virtual Machine (JVM) or the .NET Common Language Runtime (.NET CLR)—to provide an added layer of security protection. In this tip, we examine what’s involved in buying and using a RASP product to protect an organization’s applications, and its users and data, from attack or damage.
As it happens, while runtime application self-protection is a mouthful, it’s also a technology that’s absurdly easy to use. That means selecting the right implementation, at the right price, is key to obtaining the best possible return on such an investment.
Runtime application self-protection: The buy-in
In speaking with numerous purveyors of RASP products, including WhiteHat Security, Veracode and Contrast Security, I learned that common financial models for using RASP come in two basic flavors. One is per server, per application instance, where a company pays an annual fee (often, around $1,000 per year) for each runtime instance that uses RASP for added security protection. The other model is based on request volumes, where customers pay on the basis of their consumption of server interactions in need of protection. (WhiteHat Security mentioned various levels of “requests per second,” or RPS, that reflect peak server traffic levels.)
Either way, customers take comfort from added security coverage that provides another layer of defense without requiring immediate changes to their application code. Most of the vendors claimed that customers were happy to pay the fees involved because of reductions in risks to their businesses and reputations. Others mentioned improved peace of mind in view of stringent data protection requirements related to compliance measures.
Plug RASP in, turn it on!
For the common runtime environments, taking advantage of RASP is as simple as tweaking the runtime environment itself (though some tools do permit deeper levels of code integration). For most RASP implementations, no direct changes to application code are strictly necessary, although reports from some solutions may lead to code changes later on. In a Java environment, one need add only one additional Java Archive (.JAR) file to the server’s definitions, and then restart the server to take advantage of its capabilities. Likewise for the .NET CLR, it means adding a dynamic link library (.DLL) to that environment. Other implementations depend only on dropping a light-weight software agent into the runtime environment. In all such cases, there’s almost nothing to it.
Impacts of runtime application self-protection
By integrating into the runtime environment, RASP is able to intercept and inspect all program inputs as they happen. RASP is uniquely well-suited for catching and handling injection attacks, such as SQL injection, LDAP injection, CLI injection and so forth, because it can make sense of the commands involved and distinguish ordinary, safe sequences from those that may contain additional, out-of-scope instructions or requests.
Most RASP vendors are careful to disrupt the applications they’re protecting as little as possible, so in most cases, they’ll simple return an empty string or null result in response to blocked requests. They’ll also alert system administrators or security operations that something untoward or unwanted has occurred, and log system interactions to provide information about what happened after the fact. Typical log reports can identify which functions, methods or modules were involved in allowing an attack to be foisted, so that developers can go back later and try to make necessary repairs.
In the meantime, however, using runtime application self-protection prevents attackers’ efforts from succeeding—a major plus, says Ruchika Mishra, a Senior Product Marketing Manager at WhiteHat Security. Ms. Mishra observes that a recent WhiteHat study shows that in an average company, code exploits of this kind take an average of 200 days to close. “RASP provides ongoing protection when repairs may be underway, but not yet complete,” she said.
Adding instrumentation to code at runtime means adding overhead. But, as is common in instrumentation for performance monitoring and code optimization, RASP developers are keenly aware that they should impose minimal overhead on applications to which they’re added. Jeff Williams, CTO and co-founder of Contrast Security, said their own measurements on real-world benchmarks revealed only negligible impact on round-trip times for request packets (and replies). Likewise, he said that increases in transaction processing times were on the order of 0.5-1.0 milliseconds. I heard the same kind of story from all the vendors I talked to. It sounds like prospective buyers need not be overly concerned about any impact on performance from adding RASP to their application mixes.
Runtime application self-protection is indeed an interesting and potentially valuable technology, well worth investigating for organizations with applications to protect from attack.
Review our glossary to learn more key software-development terms
Enough with neglecting software security, says MIT grad and Carnegie Mellon prof
Early adopter: McGraw on the need to build in security from the start