• *Editor’s note** We have been having VPN interruptions, so I apologize for the uneven cadence of delivery on these posts. We are working on the issue.

In this section we will outline how RASP fits into the technology stack, in both production deployment and application build processes. We will show what that looks like and why it’s important to fit into these steps for newer application security technologies. We will close with a discussion of how RASP differs from other security technologies, and discuss advantages and tradeoffs of differing approaches.

As we mentioned in the introduction, our research into DevOps unearthed many questions on RASP. The questions came from non-traditional buyers of security products: application developers and product managers. Their teams, by and large, were running Agile development processes. They wanted to know whether RASP could effectively block attacks and fit within their existing processes.

I analyzed hundreds of customer call notes over the last couple years, and following are the top 7 RASP questions customers asked – roughly in order of how often often they came up.

• We presently use static analysis in our build process, but we are looking for solutions that scan code more quickly, and we would like a ‘preventative’ option. Can RASP help?
• Development releases code twice daily, which is a little scary, because we only scan with static analysis once a week (or month). Is RASP suitable for providing protection between scans?
• We would like a solution that provides some 0-day protection at runtime, and sees application calls.
• Development is moving to a microservices architecture, but WAF only provides visibility at the edge. Can we embed monitoring and blocking into microservices?
• We have many applications with technical debt in security, our in-house and third-party code is not fully scanned, and we need CSS/XSRF/Injection protection. Should we look at WAF or RASP?
• We are looking at a “defense in depth” approach to application security, and want to know if we can run WAF alongside RASP.
• We want to “shift left”: move security as early as possible, and also embed security into the application development process. Can RASP help?

These questions clearly illustrate how changes in application deployment, increasing speed of application development, and declining applicability of WAF are driving interest in RASP. Those changes are key to RASP’s increasing relevance.

Build Integration

The majority of firms we spoke with are leveraging automation to provide Continuous Integration – essentially automated building and testing of applications as new code is checked in. Some are farther down the DevOps path, and have reached Continuous Deployment (CD). To address this development-centric perspective, the diagram below illustrates a modern Continuous Deployment / DevOps application build environment. Each arrow could be a script automating some portion of source code control, building, packaging, testing, or deployment.

This is the build pipeline. Each time application code is checked in, or a change is made in a configuration management tool (e.g. Chef, Puppet, Ansible, or Salt) the build server (e.g. Jenkins, Bamboo, MSBuild, CircleCI) grabs the most recent bundle of code with templates and configuration, and builds the product. This may result in creation of a machine image, a container, or an executable. If the build succeeds a test environment is automatically started up, and a battery of functional, regression, and security tests begin. If the new code passes these tests it is passed along to QA or put into pre-production to await final approval and rollout to production.

This degree of automation in modern build and QA processes is what’s making development teams faster and more agile. Some firms release code into production ten times a day. The speed of Development automation is forcing Security to look for ways to keep pace. Such tools must be automated, and embed into the Development pipeline.

Production Integration

The build pipeline gives us a mechanical view of development, but a process-centric view offers a different perspective on where security technologies can fit. The following diagram shows different logical phases in the process of code development, each staffed by people performing a different role (e.g. architects, developers, build managers, QA, release management, IT, and IT Security). The diagram’s step-by-step nature may imply waterfall development, but do not be misled – these phases apply to any development process, including spiral, waterfall, and agile.

This graphic illustrates the major phases which teams go through. The callouts map common types of security tests at specific phases within Waterfall, Agile, CI, and DevOps frameworks. Keep in mind that we are still in early days for automated deployment and DevOps. Many security tools were built before rapid and automated deployment existed or were well known. Older products are typically too slow, some cannot focus tests on new code, and others lack API support. So orchestration of security tools – ,basically what works where – is still maturing. The time each type of test takes to run, and the type of result it returns, drives where it fits into the phases above.

RASP is designed to be bundled into applications so it is part of the application delivery process. RASP components can be included as part of an application – typically installed and configured under a configuration management script, so RASP starts up as part of the application stack. RASP offers two distinct approaches for tackling application security. The first is in the pre-release / pre-deployment phase, while the second is in production. In pre-release it is used to instrument an application to detect penetration tests, red team tests, and other synthetic attacks launched during testing. Pre-deployment integrations perform monitoring and blocking. Either way, RASP deployment looks very similar.

• Pre-release testing: This is exactly what it sounds like: RASP is used when the application is fully constructed and going through final tests prior to launch. Here RASP can be deployed in several ways. It can be deployed to monitor only, using application tests and instrumenting runtime behavior to learn how to protect the application. Alternatively RASP can monitor security tests attempting to break the application, with the RASP tool performing security analysis and reporting on its results. Development and Testing teams can see whether RASP detects the tested attacks. Finally, RASP can be deployed in full blocking mode to see whether security tests are detected and blocked, and how they impacte user experience. This provides an opportunity to change application code or augment RASP rules before the application goes into production.
• Production testing: Once an application is placed in a production environment, either before actual customers are using it (using Blue-Green deployment) or under customer load, RASP can be configured to block malicious application requests. Regardless of how the RASP tool works (whether via embedded runtime libraries, servlet filters, in-memory execution monitoring, application instrumentation, or virtualized code paths), it protects applications by detecting attacks during runtime. This model essentially provides execution path scanning, monitoring all user requests and parameters. Unlike technologies which block requests at the network or web proxy layer, RASP inspects requests at the application layer, so it has full access to the application’s inner workings. Working at the API layer provides better visibility to determine whether a request is malicious, and more focused blocking capabilities than external security products.
• Runtime protection: Ultimately RASP is not just for testing, but for full runtime protection and blocking of attacks. Not just the typical Cross-Site Scripting (CSS), SQL Injection (SQLi), Cross-Site Request Forgery (XSRF), or other drive by attacks; but malicious code execution, weak authentication, improper session management, use of vulnerable third-party software, and misuse of custom code as well. And it can detect platform-specific attacks (e.g. .NET and Java) as well as attacks on application frameworks (e.g. Spring, Struts, and Play). RASP is uniquely positioned to protect applications from a broad set of attacks. Again, monitoring and protecting at the application layer provides subtle contextual and behavioral clues which can provide substantial improvement in detection with few or no false positives.
• Development & IAST: Some RASP platforms also double as IAST (Interactive Application Security Testing) tools. This means they can be “shifted left” to the point of code creation, and provide testing benefits even before code is checked in or built. Testing in development is less common, because few developers are in the habit of (or incentivized to) test prior to code check-in. But such testing tools have advantages at finding more security flaws earlier in the process, helping to teach developers how to build secure code.

To WAF or Not to WAF

Most organizations we spoke with were primarily seeking something to work within existing development pipelines. WAF’s lack of APIs for automatic setup, the time needed to learn application behavior, and most importantly WAF’s inability to pinpoint vulnerable code modules, were all cited as reasons WAF failed to satisfy developers. These requests came from more ‘Agile’ teams, more often building new applications than maintaining existing platforms. But we consistently heard that RASP meets a market demand unsatisfied by other application security technologies.

Note that WAF was already in place at almost every client we spoke with, and none of them planned to remove their existing WAF. Some cited PCI-DSS as their reason for leaving it, some mentioned “defense in depth”, and others were not yet comfortable enough with RASP to “Rip & Replace”. So currently most who adopt RASP run alongside WAF.

It is important to recognize that these technologies are complementary, not mutually exclusive. There is absolutely no reason you can’t run RASP behind your existing WAF. Some organizations use cloud-based WAF for front-line protection, while embedding RASP into applications. Some use WAF to provide “threat intelligence”, DDoS protection, and network security, while using RASP to fine-tune application security – often supplanting WAF’s whitelisting capability. Still others double down with overlapping security functions, much the way organizations use layered anti-spam filters, accepting redundancy in exchange for broader coverage or unique benefits from each product. WAF platforms have a good ten-year head start, with broader coverage and very mature platforms, so some firms are loath to throw away WAF until RASP is fully proven, or RASP is more accepted as a compensating control under regulations like PCI-DSS.