This is the third installment of the “Securing Serverless” blog series. Our first two episodes, covered the following topics:
- Episode 0x01 – An overview of the unique security requirements serverless applications pose, and a thorough explanation of why WAFs are not the right solution
- Episode 0x02 – An overview of how SAST solutions work, and why current solutions present accuracy challenges when scanning true serverless applications
Today, I’d like to discuss the third (and last) real time application security technology – Runtime Application Self-Protection (RASP). Gartner (who also coined the term RASP, define this category of products as follows:
“Runtime application self-protection (RASP) is a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.”
That’s nice, but it doesn’t really explain how the technology works. Let’s try Wikipedia:
“Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software. The technology differs from perimeter-based protections such as firewalls, that can only detect and block attacks by using network information without contextual awareness. RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering. When a threat is detected, RASP can prevent exploitation and possibly take other actions, including terminating a user’s session, shutting the application down, alerting security personnel and sending a warning to the user.”
Current RASP products are deployed in one of two deployment models:
- By instrumenting the application server, the web server, and the application’s code, through a runtime instrumentation agent
- For languages and environments that don’t support runtime instrumentation agents, RASP vendors offer a framework or an SDK, which needs to be added to the application. This framework will then intercept the relevant calls, and will send the data for inspection, which is usually done in the cloud (SaaS model), or on a dedicated server
The installation of a RASP instrumentation agent requires that the developer will modify the application’s execution environment. For example, a common approach for instrumenting Java code, is as follows (taken from a market leading RASP installation guide)
“To start analyzing an application, install the Java agent by adding it as -javaagent JVM parameter. After installation, continue to use the application as you normally would. (If it’s a web application, just click on links, submit forms using normal data, and so forth.) The Java agent’s sensors gather information about the application’s security, architecture and libraries. “
…Hold on! Adding a JVM parameter? but I don’t control the JVM in a serverless environment?!
Installation in .NET environments is pretty similar, as described:
“To start analyzing an application, download the .NET agent installer from the XXXXX interface and run this installer on the server where the web application is deployed.”
I thought we were going all-in with serverless.?! I guess that’s not an option as well.
Other RASP vendors, offer a different approach to instrumentation, by sending data (in real time) through an API call, to a dedicated analysis engine which lives in the cloud (SaaS), or on a separate server. For example (taken from a different RASP vendor’s installation guide)
“The XXXX security engine is the heart of the XXXX solution. All analysis and prevention is done in the engine in less than a tenth of a millisecond. The engine can either be accessed in the cloud or delivered on-premise as a virtual appliance.”
Ok then – at the moment, it seems like the first option of deploying RASP by using an instrumentation agent is not feasible in serverless architectures for the following reasons:
- We are not in liberty of installing instrumentation agents on the local machine
- The instrumentation agents require us to modify the loading process of the runtime environment they hook into – again, we are not in liberty of doing this in most serverless environments
Since the only thing we control in serverless architectures is our own code, the second deployment alternative – i.e. adding an SDK to our application’s code is feasible, however, if the SDK sends the data to a Cloud/SaaS analysis engine, or to a virtual appliance nearby, we are looking at 4 major drawbacks:
- A substantial performance penalty that is probably unacceptable to most organizations using serverless (the data has to do a round-trip back and forth to the analysis engine each time an analysis is required)
- Data needs to be extracted from the function’s execution environment, and traverse the network to the cloud or to a remote virtual appliance
- Nobody knows how scalable is the analysis engine – can it auto-scale with your serverless architecture and provide reasonable performance?
- If you are trying to go serverless, installing an analysis agent on a servers sort of beats the point (in the non-SaaS deployment model)
In additional to the above existing RASP solutions might have another technological limitation – that is the fact that most products were designed specifically for instrumenting web applications. Serverless functions are invoked by the serverless runtime environment and not as part of the web/application server. As such, it is unclear what kind of instrumentation coverage such RASP solutions actually provide for serverless applications.
To summarize, similar to the WAF case discussed in Episode 0x01, while RASP solutions definitely provide tremendous benefit for protecting modern web applications from within, current deployment options and RASP technologies, which rely on deploying an instrumentation agent on the local machine, or by extracting data for inspection in the cloud or on a virtual appliance, are unsuitable for serverless architectures.
This is a Security Bloggers Network syndicated blog post authored by Ory Segal, PureSec CTO. Read the original post at: PureSec Blog (Launch)