Editors note we have been having some VPN interruptions so I apologize for the uneven cadence these posts are being delivered. We are working on fixing the issue.
In this section we outline how RASP fits both into the technology stack, both during production deployment and build processes to create applications. We will show what that looks like and why it’s important to fit within these models for newer application security technologies. And we will close this section with a discussion of how RASP differs from other security technologies, and discuss advantages and tradeoffs between 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. And they wanted to know if RASP could effectively block attacks and fit within their process.
I filtered the hundreds of the customer call notes over the last two years, and the following are the top 7 RASP questions customers asked, more or less in order of how often often it was asked:
- We presently use static analysis in our build process, but we are looking for solutions that scan code more quickly and we would also 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/month. Is RASP a suitable protection to fill in the gaps between scans?
- We would like a solution that provides some 0-day protection at runtime, and sees the application calls.
- Development is moving to a micro-services architecture, and WAF only provides visibility at the edge. Can we embed monitoring and blocking into micro-services?
- We have lots applications with technical debt in security, our in-house and third party sourced 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 with RASP?
- We want to ‘shift left’, both move security as early as possible, but also embed application security into the application development process, and we would like to know if RASP can help?
Why do we bring these questions up here? To show how the changes in application deployments, speed of application development, and the reduced capacity for WAF are generating the interest in RASP. And it is those changes we want to show here to provide a better understanding of how RASP addresses the new requirements.
The majority of firms we spoke with are leveraging automation to provide Continuous Integration — essentially automated building and testing of applications as new code was checked in. Some had gone as far as Continuous Deployment (CD) and DevOps. To address this development-centric perspective, we offer the diagram below to illustrate a modern Continuous Deployment / DevOps application build environment. Consider each arrow a script automating some portion of source code control, building, packaging, testing, or deployment of an application.
This is what the build pipeline looks like. Each time application code is checked in, or each time a configuration change is made in a configuration management tool (e.g. Chef, Puppet, Ansible, Salt) the build server (e.g. Jenkins, Bamboo, MSBuild, CircleCI) will grab the most recent bundle of code, templates and configuration, and build the product. This may result in the creation of a machine image, a container or an executable. If the build is successful, a test environment is automatically started, and a batter of functional, regression and security tests are started. If the new code passes these tests it is passed along to QA or put into pre-production to await final approval / rollout to production.
This degree of automation in the build and QA processes is how development teams are faster and more agile. Some firms release code into production ten times a day. It is because of the sheer speed created by automation that security needs to find ways to deploy security technologies that can keep pace with development. That means selection of tools that embed into this pipeline.
If the build pipeline gives us a mechanical view of development, if we take a more process centric view, we get a different picture of where security technologies can fit. The following diagram shows different logical phases in the process of code development, each phased staffed by people who perform a different role (e.g. architects, developers, build managers, QA, release management, IT and IT Security). While the step by step nature of this diagram may imply a waterfall development, do not be mislead, as these phases apply to any development process, including spiral, waterfall and agile.
The graphic below illustrates the major phases teams go through. The callouts map the common types of security tests at specific phases within a Waterfall, Agile, CI, and DevOps frameworks. Keep in mind that it is still 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 their tests on new code, and others do not offer 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 best 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 the application, typically installed and configured under a configuration management script, so it starts up along with the application stack. RASP offers two distinct approaches to help tackle 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, and to ensure that it is detecting pen tests, red team tests or other synthetic attacks launched against the app during testing. In the later, it is deployed as a monitoring and blocking tool. Either way, 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 being launched. 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 while security tests are invoked in an attempt to break the application, with RASP performing security analysis and transmitting its results. Development and Testing teams can learn whether RASP detected the tested attacks. Finally, RASP can be deployed in full blocking mode to see whether security tests were detected and blocked, and how they impacted the user experience. This provides an opportunity to change application code or augment the 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 afterwards, 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 in live runtime behavior. 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, which means 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 forgeries (XSRF) or other drive by attacks, but malicious code execution, weak authentication, improper session management, use of vulnerable 3rd party software, and misuse of custom code. And it understands attacks specific to the platforms (e.g.: .NET, Java) and application frameworks (e.g.: Spring, Struts, Play). RASP is in a unique position to protect application from a broad set of application attacks. Again, monitoring and protecting at the application layer provides subtle context and behavioral clues that provide substantial improvement in detection with low to no false positives.
- Development & IAST: Some RASP platforms also double as IAST – or Interactive Application Security Testing – tools. This means they can be ‘shifted left’ to the point of code creation, and provide testing benefits before code is checked in or built. Testing in development is not as common as many developers are not in the habit of – nor are they incentivized too – test prior to checking in code. But these types of testing tools have the benefit of finding many security flaws early in the process and educating developers on how to build secure code.
To WAF or not to WAF
Most organizations we spoke with stated their basic requirement was for something to work within their development pipeline. WAF’s lack of APIs for automatic setup, the time needed to learn application behavior, and most importantly the ability to pinpoint vulnerable code modules, were all cited as reasons WAF failed to satisfy developers. Granted, these requests came from more ‘Agile’ teams, more often building new applications than maintaining existing platforms. Still, we heard consistently that RASP meets a market demand unsatisfied by other application security technologies.
Note that WAF was already in place with almost every client we spoke with and there was no intent to remove the existing technology. Some cited PCI-DSS as the reason for leaving it, some cited a ‘defense in depth’ strategy, while others were still not fully comfortable with RASP to perform a ‘rip & replace’. So for most who adopt RASP, it is run with WAF.
It is important to recognize that these technologies are complementary, not necessarily competitive. There is absolutely no reason you can’t run RASP behind your existing WAF. Some organizations use cloud-based WAF as 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 ‘white listing’ capability. Still others double down with overlapping security functions, much the way many organizations use layered anti-spam filters, accepting redundancy 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 until RASP is viewed as an acceptable compensating control for regulations like PCI-DSS.