Why are Traditional Application Security Tools Inadequate and Less Relevant?
Serverless is a new way of building web apps. As such, they require new security tools. In addition to explaining the ways serverless security is different, we outline here specifically why traditional application security tools are inadequate for securing your serverless apps.
Why is My WAF Not Enough?
Serverless applications have many entry points, each with a small part of the app behind it. Functions can be triggered by various event sources such as cloud storage events, databases changes, and notifications. We refer to this as, “The Erosion of the Perimeter.”
Since application layer firewalls are only capable of inspecting HTTP(s) traffic, a WAF will only protect functions which are API Gateway-triggered functions. Your WAF will not provide protection against any other event trigger types. That is not to say it is useless but relying solely on a WAF leaves many gaping security holes.
Why is My RASP Not Enough?
According to Gartner, “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.”
Traditional RASP technologies instrument the application server. RASP solutions directly integrate their protection engines into the application server and therefore, still rely on the existence of an application server. Yes, “serverless” is a misnomer, since there are still servers involved in serverless application architecture. However, from the perspective of the application owner, there really is no server. There is no possibility for app owners to install RASP solutions onto servers running their serverless applications.
While trains may be an excellent mode of transportation, they are simply incompatible with a journey across an ocean. Likewise, RASP solutions can offer protection for some modern web applications, but cannot function in serverless environments.
WAFs and other high-level protection are known for generating many false-positives, resulting in a high level of “noise.” In general, RASP evolved as a solution to avoid that noise. RASP technology lives with the application, and not on the network – so it had better sense of what is going on in the app.
If you make a call to the database, the RASP agent could see that. See Picture 1 for example of SQL Injection.
In this case, you can build some more “intelligence” of what should be sent to the database. However, this isn’t feasible with serverless. Traditional RASP solutions have agents that hook to the server (apache, nginx, etc.) and monitor the server’s behavior. This will not work on serverless, because you cannot deploy the agent on the server or in the environment itself.
Picture 1: SQL Injection
I Do Code-Scanning, Why Should I Care?
Code scanning can be automated or done in a time-consuming manual way. In either case, it can enable you to find potential vulnerabilities as well as areas for improvement and is a worthwhile practice that we advocate. However, it is not adequate to secure your serverless applications.
Code scans often generate many results and lack meaningful, actionable insights. Additionally, while code scanning can find known vulnerabilities, it will not reveal many issues that significantly weaken your serverless security posture.
Specifically, code-scanning will miss many of the OWASP Serverless Top 10. For example, #2, Broken Authentication, is usually part of the configuration and not code. It can also be caused by other resources, like API Gateway or S3 Buckets. To identify this we should have a broader picture of the serverless application and all its resources.
Considering #3: Sensitive Data Leakage, a code scan can find some issues like hardcoded keys. However things like sensitive data in the environment could only be detected in runtime.
#5: Broken Access control – Attackers will target over-privileged functions in order to gain unauthorized access to resources in the account rather than having control over the environment. Traditional code scanning, which is not serverless-oriented, will not reveal which functions are configured with excessive permissions.
#6: Security Misconfiguration – Again, some cases could be found during a code scan. However, access controls to buckets or insecure APIs are not part of the code.
#10: Insufficient Logging and Monitoring – Once again, this is something that is part of the cloud account and the serverless application as a global view and not particular to function code.