I was at Gartner’s Security and Risk Management Summit in National Harbor, Maryland last week, and as always one of the best parts of the conference was the conversation that started after the analyst presentations were done. After one session on runtime application self protection (RASP), I found myself chatting with one attendee who asked, “How does RASP relate to the Simian Army?”
My initial reaction was to say, it doesn’t. For those who don’t follow cloud application development or security, the Simian Army, created by engineers at Netflix, is a set of open source tools that can be run against an autoscaling distributed cloud application to test the scalability and availability of the application in abnormal conditions. The best known example is Chaos Monkey, a tool that randomly shuts off production instances (virtual servers) in Amazon to ensure that the application can survive this common failure occurrence—but there’s also Latency Monkey, Conformity Monkey, Doctor Monkey, Janitor Monkey, Security Monkey, and the Chaos Gorilla (which simulates the outage of an entire AWS availability zone). At first blush, the Simian Army may seem to have nothing to do with RASP. But as I thought about it some more, I realized that they are philosophically aligned.
RASP’s purpose is to reduce risk from vulnerable applications by protecting the applications against exploits. A family of technologies rather than a single approach, the general thread tying all RASP offerings together is detection and blocking that runs within the application’s runtime environment, via an SDK, runtime agent, or even by replacing the runtime environment. The promise is that by being so intimate with the application, RASP avoids the “arms-length” problem that many believe was the architectural failing of web application firewalls (WAFs). Of course, RASP currently has its own challenges – incomplete language and vulnerability class coverage among them, as well as the immature nature of the solution. But ultimately the idea is that RASP is a shield against attackers for an application that is intimate with the application, has full knowledge of its weak points, and protects it at runtime.
Does the Simian Army share the goal of protecting an application? No—on the contrary, the Simian Army makes applications fail. But the goal is the same. The Simian Army seeks to make software safer by making its runtime environment unforgivably hostile, so that flawed programs actually cannot run. This form of risk reduction may be the most sophisticated form of culture-hacking the industry has seen, leveraging Darwinism—only the strongest applications survive—to drive changes in developer behavior. If Chaos Monkey can take your application down, you haven’t done a good enough job at ensuring the application’s availability. It’s certainly not for everyone, requiring a fully cloud-enabled and autoscaling application platform, but it’s an interesting way to think about reducing application risk.
I’d note that these two approaches represent two schools of thought in how to reduce application risk. RASP assumes that applications will always be vulnerable and seeks to protect them, like WAFs. The Simian Army attacks the problem by seeking to reduce the number of points of failure in an application by changing developer behavior. This is a similar approach, albeit more forcefully implemented, to developer education (e.g. eLearning), which seeks to change developer behavior by educating developers about root causes of security issues and best practices in secure coding. Done right, developer education can lead to reduction of risk by accelerating the rate of fix of software flaws—which we will discuss in the upcoming State of Software Security Volume 6.
There is, of course, a third school of thought, which is that the best way to reduce application risk is to eliminate it by finding and fixing software vulnerabilities. By finding vulnerabilities (or potential vulnerabilities) and giving application producers (developers or software vendors) the information they need to fix the flaws and the tools they need to verify that the flaws are gone, application security testing works to make the organization more secure. It’s a common mistake to think that application security testing (using technologies like binary static analysis, dynamic analysis, and software composition analysis) is about finding flaws; it’s about fixing them.
Is it sufficient to take just one approach? In general, the agreement is that you need all three. Keeping developers from making mistakes doesn’t address flaws already in applications; for that you need to find and fix the flaws or protect against their being exploited. But the bottom line is that the Simian Army and RASP (and application testing) are more closely related than it might appear—they all have risk reduction as their goal.
