The term serverless typically describes an application operating model where infrastructure is completely abstracted away. This means that there are no servers to manage, and as application owner, you rely exclusively on higher-order services for all aspects of your applications. Since the release of Lambda by Amazon Web Services (AWS), the term serverless has evolved from referring to function-as-a-service (FaaS) offerings. It now encompasses sets of interconnected services that share the common trait of not exposing any servers. As an example, services such as AWS Fargate and Google Cloud Run are being referred to as “serverless containers.”
With the evolution of how we talk about serverless comes the evolution of all other aspects of handling serverless applications. Chief among them is security.
Why Is Serverless Security Different?
When you use serverless, you have no control over the infrastructure – specifically with function-based applications, where you have a cloud service triggering a function, which in turn triggers another cloud service. This means that there is no network to inspect, no image to scan and no server to deploy agent-based security on. The paradigm shift that serverless brings to application development also extends to security, forcing security teams to reimagine how they lock down these workloads.
So, what’s left to secure? With serverless, the shared responsibility model shifts heavily to your favor. You own less, and the cloud provider owns more. The flip side is the things you own become critical attack vectors that can be leveraged by bad actors. Serverless security boils down to having strong code and tight permissions, as well as inspecting triggering events – and how they impact function behavior.
How Does Prisma Cloud Secure Serverless Workloads?
Prisma Cloud approaches every type of workload with the understanding that not all compute is the same. Containers require a certain type of security methods, while functions require others. Prisma Cloud takes a layered approach to serverless security.
Step one is gaining visibility into how your functions interact with other cloud services. Step two is performing vulnerability and compliance checks, and step three is implementing real-time protection against injection attacks or attacks that alter function behavior.
Visibility
Prisma Cloud gives you an overview of how your functions interact with other cloud services, and what permissions govern these relationships. This is a crucial first step to understanding the possible risks in your application.
In the example below, we can see an application where a Simple Notification Service (SNS) topic triggers a Lambda function, which in turn makes a call to a DynamoDB table. We’re able to see which topics are involved, and what permissions the Lambda function has when interacting with the DynamoDB table. In this case, the Lambda function has greater permissions than it actually needs, and this triggers a compliance violation.
Vulnerability Scanning
Prisma Cloud scans your functions for vulnerable third-party dependencies. You can initiate the scan on functions that are already deployed and running on your cloud account, or integratevulnerability management into your Continous Integration/Continous Deployment (CI/CD) process and catch security issues before they ever reach production.
Runtime Protection
Once your application is up and running, permissions are tight and the code is strong, you still need to make sure you’re actively protecting it against threats. With serverless, there are hundreds of cloud services that can trigger your functions, each with their own unique payload. Each of these events can be used as a vector for an injection attack.
Beyond inspecting event-data, you also need to look at how your function behaves. It could very well be that a triggering event appears to be normal, but somehow affects the behavior of a function. Examples of this could be causing the function to resolve a DNS name it wasn’t supposed to or access a file it shouldn’t.
Prisma Cloud covers both event-data inspection and behavioral protection. For all protected functions, Prisma Cloud inspects event-data, and according to your configuration, blocks or alerts on injection attacks. Function behavior is continuously monitored to ensure it only acts as intended. Any attempt to force a function to run an unsanctioned process, connect to an unknown host or perform any action outside normal behavior will be blocked, or will generate an alert or both.
In the example below, we can see a command injection attack that was caught by Prisma Cloud’s Cloud Native Application Firewall (CNAF) for Serverless :
We can also see any attempts to change function behavior. In the example below, an attacker attempted to resolve a suspicious DNS name, most likely a script hosted on Pastebin. We can also see an attempt to time-out the function with a sleep command.
When to Use Serverless
Serverless is just one of the latest in a long line of cloud technologies, and many organizations are still determining when to use it. Just like any other advancement, it comes with its own set of strengths and weaknesses: considering the new attack surfaces it introduces, these workloads require their own unique security. But no matter when your company chooses to use it, Prisma Cloud is purpose-built to help you manage it.
Want to learn more about the top serverless security risks? We recommend checking out the Cloud Security Alliance (CSA) whitepaper on the top 12 most critical serverless security risks.