Serverless computing is among the newest trends in cloud computing and also among the most complex. And as with any new technology, particularly a complicated one, serverless computing also brings with it new technology risks.
With serverless computing, cloud computing is expressed at its most pristine level, without the need for organizations to run any long-lived servers. Advocates of serverless computing praise its pure service-based approach, while skeptics have their own complexity and security concerns.
So what exactly is serverless cloud computing? And perhaps more importantly, how can organizations take proactive steps to secure it? That's what this eSecurity Planet guide is all about.
- What is Serverless Computing
- Serverless Computing Risk
- How To Manage Serverless Security
- Serverless Computing Security Vendors
Serverless computing is also sometimes referred to as Functions-as-a-Service, which is perhaps a more descriptive term. Serverless is also referred to as Event-Driven Computing by some vendors.https://o1.qnsr.com/log/p.gif?;n=203;c=204660766;s=9477;x=7936;f=201812281312070;u=j;z=TIMESTAMP;a=20392931;e=i
With cloud computing, instead of organizations needing their own servers, cloud services provide virtual server compute instances on which to run applications. In the serverless model, the services component is taken a step further and the server itself is abstracted away.
In a nutshell, with serverless, rather than needing a long-running server or container, as is the case with other cloud computing services, a simple function is executed to achieve a given task based on an event trigger.
For example, rather than having a long-running email service, with a serverless email function, an email function can be triggered whenever there is a need to send an email.
Serverless is an idea that was pioneered with the AWS Lambda service and is now an approach that is also available on Microsoft's Azure public cloud as well as the Google Cloud Platform (GCP). There are also multiple open source options that enable serverless for private cloud and Kubernetes container orchestration system deployments.
Serverless Computing: Pros
Cost - only pay for the time needed to execute a function
Speed - There is a small amount of latency to execute a function that might not be present with a long-running server
Disaggregated Services - serverless enables a full micro-services approach, where every specific function is a service
Complexity - microservices can add complexity to an application delivery workflow
No Server Management Required - Serverless providers manage all the server and compute instances
Skills Gap - Existing server management skills and policies don't always apply to serverless deployments
While serverless computing offers organizations a different, more agile approach for service delivery, it's also a different deployment and management paradigm that could introduce new risks.
Among the serverless computing risks that organizations should consider are:
- Vendor security: Serverless functions execute on a provider's infrastructure, which may or may not be secure.
- Multi-tenancy: Functions in a serverless service often run on shared infrastructure that is running code for multiple customers; that could be a concern when it comes to sensitive data.
- Injection attacks: In an injection attack, unauthorized or unexpected content or data is injected into an application flow; in the serverless model, an injection attack can come from an event that the serverless function calls to execute.
- Encryption: Serverless functions can often call out to databases and other privileged resources; if the connection isn't encrypted, data can potentially be leaked
- Security misconfigurations: In order to enable access to different resources, a developer could potentially input access keys, tokens and passwords directly into the function; not protecting those secrets is a risk
- Function permissions: Often serverless functions are granted the same permissions as a server might get. A serverless function, however, requires only a bare minimum permission to execute, and overprovisioning permissions opens up the function to potential risk
- Component vulnerabilities: Functions often rely on a supply chain of third-party libraries and components. If there is a known (or unknown) vulnerability in one of the components, the serverless function could potentially be exploited
Managing serverless security is all about having appropriate controls and policies in place. While cloud server security policies may well be effective for virtual compute server instances in the cloud, additional levels of control, granularity and visibility are needed for serverless computing.
Reduce Serverless Permissions
Among the greatest risks to serverless computing are functions that have more permissions than are needed. With serverless, it's possible to significantly reduce the attack surface by implementing a least privilege model for all deployed functions. Reducing the number of privileges can be done during the development phase for a function, with automated checks set up in staging environments. By profiling function behavior, it's also possible to see which privileges a running function actually uses. With that visibility, an administrator can dial down the access to only enable the required privileges.
All functions that call out to a service, be it internal to the same cloud provider or not, must require access control and authentication to help limit risk. Cloud providers provide guidance on best practices for how to enforce serverless authentication, which administrators should follow.
Use Cloud Provider Controls
Cloud providers also have multiple built-in services that can help users identify potential misconfigurations. For example, AWS Trusted Advisor is an option for those running AWS Lambda.
Log Function Activity
Since serverless functions are event driven and stateless, looking at real-time activity will often miss most activity. By using cloud provider (or third party) logging and monitoring for serverless, it's possible to have an audit trail that can be useful when and if threat hunting is required.
Monitor Function Layers
Functions can have multiple layers, which call in different code and third-party libraries. By monitoring layers, an administrator can potentially identify attempts at injection and malicious activity.
Consider Third-Party Security Tools
While serverless platform providers often integrate some security controls, they tend to be limited in scope, focusing just on the platform on which the functions are running. There are multiple third party tools and technologies that provide additional layers of visibility and control for serverless computing.
The market for serverless computing security tools is a relatively new one, but there are already multiple vendors in the space. There is some overlap with container security vendors (see eSecurity Planet's list of top container security vendors), since serverless technologies typically involve the use of short-lived stateless containers.
Aqua Security provides a full container and serverless security platform that can help organizations assess and mitigate serverless risk.
Nuweba is a newer entrant into the serverless space, emerging from stealth in February 2019 with its own secure Functions-as-a-Service platform that can integrate with serverless services from major public cloud providers.
The PureSec Serverless Security Platform is purpose-built for the challenges of serverless security and can integrate into an organization's existing Continuous Integration/Continuous Development (CI/CD) workflow.
Protego Labs is also focused on serverless security, aiming to provide full lifecycle security from development through deployment.
The Snyk platform enables organizations to continuously scan functions to help identify any potential risks.
Twistlock's platform provides security for both containers and serverless functions across the full development and deployment lifecycle.
Sean Michael Kerner is a senior editor at eSecurityPlanet and InternetNews.com. Follow him on Twitter @TechJournalist.