Why runtime application selfprotection is critical for app security

Today most of us go about implementing security from the outside in. The common practice is to start by defining a perimeter and trying to defend it with various security tools. Even though perimeters have been porous for more than a decade, we still can’t give up this notion that if we build a better wall we can keep our enterprises safer.

Certainly that is where most enterprises are spending their security budgets. Gartner estimates we spend more than 20 times as much protecting the perimeter than on the actual apps that we know and love and run every day. (The actual figures are $11.5 billion compared to half a billion.) But that kind of investment needs to end. It is time to start thinking about our enterprise security from the inside out, and start protecting our most precious IT assets, our apps.

Apps are hard to protect, to be sure. They are on devices that aren’t always owned by the enterprise, and these devices operate outside our corporate perimeter protection. The operating systems are easily out of date and many apps on them have bugs: Gartner estimates a majority of apps have programming errors that can be easily exploited by hackers.

The world has become more mobile

Keeping up with these exploits isn’t easy. As the number of mobile apps in use continues to grow, “Technologies and services that we use to test and diagnose our applications for security vulnerabilities fail to scale to test all applications and to test them with the necessary accuracy. There are too many apps, testing skills are scarce, and tools are too complex and inaccurate.”

On top of these challenges, there are a variety of mobile security standards that make it hard to enforce best app security practices. Each mobile device vendor is more focused on ease of use rather than built-in security.

Adding this all up, having mobile apps means managing more risk. “When one considers the huge number of applications run by major institutions, the third-party libraries included, and the frequent updates to those applications, it becomes clear that application security is an extremely challenging task indeed.“

Malware is getting more complex

In addition to the difficulty of securing mobile apps, malware is getting more complex and sophisticated at finding weak spots in the enterprise infrastructure. It is more than just creating fake mobile apps, but leveraging the actual program code that every app uses.

Malware used to be more easily detected through residues of files or simple signatures that were an obvious sign of infection. Those days are sadly gone. Modern malware is more insidious, and can gather small bits of code that is already written. Using techniques such as return oriented programming, malware can execute standard libraries and other executable sequences of code that can compromise an otherwise uninfected system.

This means that apps themselves - even ones that have been carefully crafted - can be a threat.

The rise of agile development cycles

There is one final wrinkle in the story to secure our apps, and that is the nature of how these apps are being constructed has changed radically in the last several years. Gone are the days where an IT shop would take months to refine requirements, build and test prototypes and deliver a finished product to an end user department. The idea almost seems quaint nowadays. Instead, we have new working methods, called continuous deployment and integration that refine an app daily, in some cases hourly. Feedback is nearly constant, which means changes are too.

This presents a problem in protecting these apps. “Security products must do more than address application security issues; they need to mesh with continuous integration and continuous deployment approaches, while offering automated capabilities and better integration with developer tools.”

Enter the world of RASP

To solve some of these issues with insecure apps, a new kind of app protection is required. As we said earlier, we have to start protection from inside of the apps themselves, and add security that can be part of the app’s actual source code. This is the concept of runtime application self-protection or RASP. The idea is slowly catching on. The term comes from a 2012 Gartner report and has several supporting tools vendors.

RASP sounds like a good idea: One blog post on SearchSecurity has put it this way: “It is every app for itself out there, and having firewall-like capabilities built into runtime environments may turn out to make a lot of sense.” And Gartner emphasizes this: “There are two capabilities that should be built into any application’s runtime - self-protection and self-testing/self-diagnostics.”

These RASP products cover a variety of circumstances, use cases and protective methods. There is no single deployment model in common, and many RASP products support a wide variety of programming languages and integration methods, along with different detection and prevention features.

There are two basic RASP implementation methods: One way is for the RASP products to use agents that monitor the apps. This doesn’t require any code changes to the apps themselves. Another method is to use some kind of code libraries or build protection in a software development kit, which has to be integrated into the application. This could take the form of replacing existing code libraries, with ones that are RASP-enabled. These tools will require recompiling the apps to include the RASP libraries.

RASP’s protection measures include one or more of the following elements:

- The ability to terminate user sessions
- The ability to terminate an app, without affecting other apps on the server or device, or at least identify a misbehaving or compromised app
- When an app is compromised, an alert is sent to a management console or to the user directly
- The ability to inspect application logic flow and data flow
- The ability to connect to the application runtime processes and environment

Typically, the RASP tool supports a variety of programming environments, such as Java, Objective C and Swift along with most common development frameworks. Some tools are just designed for desktop apps, while others can handle apps running across a wider range of desktop and mobile OS’s. This is also a challenge for RASP products: the sheer diversity of languages, frameworks, web-facing interfaces and data types means that these products have to support a lot of different circumstances, use cases and environments.

Some RASP vendors offer specific features that are mapped to threats (such as a feature that detects and blocks the SSL Heartbleed compromise). This helps the security team show particular compliance and can make a RASP product more appealing to management. Leading providers offer a more comprehensive protection scheme. Here is an example of the kinds of intrusions that are either prevented or detected by a strong RASP solution:

What intrusions are Prevented or Detected?

As you can see, RASP protection has a lot of depth and can manage the increased risks of rising mobile app use and more sophisticated malware in today’s enterprises. They can be a proactive means of protection that other security tools can’t easily deliver.

The cost/benefits of RASP

The benefits of RASP are clear: make your app portfolio more secure, and your apps more reliable. But once you get beyond this platitude, it is a lot more difficult to articulate why you should invest in RASP. For example, if you have a lot of internal app development, it might be more difficult to justify the costs.

This is because protection has to be applied to each app, and has to be included as part of the DevOps process. There could be performance impacts on the apps that use RASP. It isn’t a magic bullet: if you write substandard code, it will still be substandard code with RASP.

One issue for RASP is that it bridges the divide between the infrastructure and app server owners - typically these are IT and an end user department, respectively. Another is that you are injecting code into production apps, which may be a political hot potato; depending on how long these apps have been in production and what effect the RASP code has on the production app itself.

In short, there are a number of considerations around how best to secure applications with RASP to ensure a good fit with the development process and cost/benefit. However, there remains no question that natively integrated RASP technology is a very compelling solution that helps address the overall strength of mobile applications.

The rise of defense in depth

Although RASP shouldn’t be your sole security solution, and most experts recommend it is just one part - albeit an important one - from an overall defense in depth and using a series of layers to protect your enterprise. But RASP can be complementary, rather than compete, with these other layers, because it operates at the app level and protects individual apps. Other protective products, such as web application firewalls and mobile device managers, don’t have the granularity of protection and can’t get down and dirty with the code used to construct apps. RASP tools can also handle automated setup and can learn app behavior to examine what is defective in terms of overall security. As Securosis has said, “There is absolutely no reason you can’t run RASP alongside your existing WAF. RASP solutions are much more effective at attack detection than web application firewalls because they actually see what’s really happening, and can more effectively apply security controls.” Neil MacDonald, a Gartner analyst, feels that WAF and RASP are complementary, and have great synergy. “The trick with either technology is realizing that you can’t find every potential exploit or vulnerability when you develop your code.”

Enter DIGIPASS for Apps

VASCO’s RASP solution is part of its DIGIPASS for Apps solution. It contains features such as jailbreak or root detection, along with the ability to determine if an app has been tampered or otherwise repackaged or code injected into the app programming process. It can also determine if execution flow of the app has been modified and check for the integrity of various app processes. Finally, VASCO’s RASP solution can determine if keyloggers or debuggers are being used and if the app is being run inside an emulator.

RASP is just one of numerous other protection features available in the DIGIPASS for Apps product: there are other tools such as next generation biometric authentication methods (i.e. Face recognition), sophisticated risk based authentication and others. Additionally, the product offers end-to-end encryption to completely protect communication channels.

Summary

Yes, it is an insecure world out there, and today’s app portfolio is responsible for the numerous vulnerabilities businesses face. But RASP can be a solid defense and a way to isolate and neutralize a potential threat, so you can operate your business safely in these uncertain environments. VASCO’s DIGIPASS for Apps with RASP technology offers a comprehensive approach to app security and critical tools supporting the future of app development and security.

---

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

---