Serverless computing has unlocked huge benefits in terms of scalability, productivity, and cost savings by making it easy to build, run, and deploy functions that encapsulate the business logic of an application. However, the ephemeral nature of serverless functions has made traditional security tools obsolete, while making it essential to have security tools that provide visibility into security risks and vulnerabilities in real-time and in context across a multi-cloud environment.
Compute workloads have changed substantially since the early days of the web—from running applications on physical servers to virtual environments like hypervisors and containers. Over the last decade, serverless computing has unlocked huge benefits in terms of scalability, productivity, and cost savings by making it easy to build, run, and deploy functions that encapsulate the business logic of an application.
All big cloud providers provide Function-as-a-Service offerings to their customers with the promise of abstracting away the painstaking details of application development, albeit presenting unique security challenges to the engineering teams. While cloud providers assume the responsibilities of securing the underlying infrastructure components where your functions run, development teams are left with the burden of securing this relatively new, obscure resource—serverless functions.
Contextual security for serverless functions
The ephemeral nature of serverless functions has made traditional security tools obsolete, while making it essential to have security tools that provide visibility into security risks and vulnerabilities in real-time and in context.
CloudHealth Secure State supports AWS Lambda functions, Google Cloud Functions, and Azure Function App, allowing you to detect and mitigate security misconfigurations in your serverless functions across all three major cloud providers.
In this article, we’ll look at examples of how you can use CloudHealth Secure State to secure your serverless functions, including how to identify misconfigurations, control API access, enforce network boundaries, prevent malicious actors from lateral movement, and more.
Enforce the principle of least privilege
Serverless functions are not usually deployed in isolation. Rather, they’re triggered to perform a task in response to an action or an event. In a typical distributed architecture, they serve as the glue between different application components—the source for one component and the destination for another. As such, it’s important to scope the permissions associated with a function following the “principle of least privilege.”
For example, consider a function that only requires read access to your database, but is granted permissions to also create or delete cloud resources in your account. If malicious code is deployed on this function, an attacker can bring down your entire system by either wiping out production resources or creating too many dummy resources, and emptying out your account quota. Either way, both scenarios jeopardize the availability of your application.
Although scaling back and revisiting who has what level of access permissions can seem like a tedious process, it is paramount to the security of your system. Figure 1 (below) shows how CloudHealth Secure State accelerates this process by providing a single pane of glass for all your serverless functions and the permissions associated with each of them. You can also perform search queries to quickly identify functions with admin privileges.
Additionally, make sure that no two serverless functions share the same resource that defines the actions they can perform, such as the IAM execution role in AWS.
As demonstrated in Figure 2 below, sharing an IAM role across multiple serverless functions makes it impossible to provide granular permissions for each function and causes you to associate all permissions required by multiple functions with the same role—which again, violates the principle of least privilege. This is important because assigning more permissions than necessary increases the attack surface that can be exploited from a vulnerable serverless function.
Lock down API access to your serverless functions
Since developers can program serverless functions to perform arbitrary tasks—and with that, grant arbitrary permissions to the functions—it’s important to secure API access to the function itself so that only authorized entities can interact with the function. Using CloudHealth Secure State, you can see if an external user or service is authorized to invoke your function or deploy a new version of your function—either of which could have catastrophic consequences if performed by a malicious user or service.
Figure 3 (below) shows a Google Cloud function that provides full ownership and permissions to any user on the internet, with or without a Google account. This is dangerous because if abused, this permission allows an attacker to run arbitrary code in your account undetected and move laterally in your application stack.
Draw network boundaries for your serverless functions
Depending on the sensitivity of the data processed by your serverless functions, enforcing network boundaries on your serverless functions can be as important as locking down network access on your hosts and VMs. If, for example, malicious code is ever deployed to your functions, an attacker could be able to send confidential data outside organizational boundaries.
To avoid situations like this and prevent data from leaving your network, you should restrict traffic leaving your functions to only its intended destination.
CloudHealth Secure State can help you detect serverless functions that allow unrestricted flow of traffic, and help you fix them via auto-remediation. Figure 4 (below) shows how to find Lambda functions in your AWS account that allow outbound IP traffic.
One-click access to resource configuration history
If you’ve found a critical misconfiguration of a serverless function, you can gather additional context about the violating object(s) in CloudHealth Secure State on the resource details page, which provides comprehensive resource metadata over time. You can use this page as a deep-dive dashboard for any misconfigured cloud resources and find gaps in your administrative workflows that allow critical security misconfigurations to propagate in the first place. For example, failing to rescind access to users who are no longer part of your organization or those who shouldn’t have administrative privileges in your cloud accounts.
Figure 5 shows details of an Azure Function App, such as the security findings associated with it, the cloud account it exists in, and changes in configuration over time, along with detailed activity logs—all in a single pane of glass.
Serverless security best practices: Confidentiality, integrity, and availability
When thinking about security best practices for your serverless resources, we recommend falling back to the three fundamental pillars of information security—confidentiality, integrity, and availability.
Confidentiality
- Manage access by only allowing authorized users and services to interact with your serverless functions
- Follow the principle of least privilege when assigning permissions to your serverless functions
- Restrict network egress and ingress to and from desired destinations and sources
- Exercise separation of concern and minimize blast-radius by creating separate roles and policies for different functions
Integrity
- Ensure that function data and state is encrypted at rest and in transit
- Leverage logging and monitoring tools offered by cloud providers or third-party tools to gain adequate visibility of your serverless functions, including audit trails, interdependent resources, and actions performed on or by your functions
Availability
- Enforce adequate limits on compute, memory, execution duration, concurrent executions, etc., to prevent Denial-of-Service caused by runaway functions
- Monitor headroom for account-level resource limits and if necessary, request a limit increase from your provider
These security best practices are geared towards serverless functions, but you can see our top seven best practices for overall cloud security posture management, in our in-depth guide: 7 Best Practices for Cloud Security Posture Management
Final thoughts
It’s imperative for enterprises to keep up with the ever-changing landscape of application development. Serverless computing trends mandate the use of security tools that not only help detect risks and vulnerabilities in isolation, but also provide context and visibility into connected threats in an enterprise environment.
This is where CloudHealth Secure State shines, by providing a contextual, graphical view of serverless resources and their interactions with other cloud assets across a multi-cloud environment. In this article, we discussed how CloudHealth Secure State helps improve the cloud security posture of your applications that are built using serverless functions in AWS, Azure, or GCP. To learn more about other important features, such as real-time threat detection, auto-remediation, alerts, and third-party integrations, contact us for a free demo today.
As a final note, it’s important to remember that each of the best practices we’ve covered in this article should be incorporated into your organization’s overall cloud security and compliance practice. For more information, see our complete whitepaper: Building a Successful Cloud Infrastructure Security and Compliance Practice
