Why is Serverless Security Different?

How Does Serverless Improve Security?

In some ways, the nature of serverless improves security.

1.

Cloud Providers Handle OS & Runtime Security & Patching

In deploying serverless apps, you cede control over most of the stack to your cloud provider, and they provide services such as key management. You no longer own OS hardening, admin rights, SSH, and segmentation.

AWS, Microsoft, and Google have, for the most part, proven very reliable in keeping their parts of the stack patched and secured, so giving them a larger portion of the stack certainly improves things on that end.

2.

Stateless/Ephemeral

Additionally, the ephemeral, stateless nature of serverless compute makes attackers’ lives harder. Serverless functions like AWS Lambda run for a few seconds and then die. Containers get recycled. The fact that serverless functions come and go and have no memory reduces the risk of long-term attacks, making it a security plus.

3.

Visibility into Serverless Apps – The Benefit

The fact that serverless apps are now structured as a large number of small functions in the cloud provides a fantastic opportunity for security. Application security tools often go to incredible lengths to analyze and instrument your packaged application just to be able to observe or filter the internal flow of your app. With serverless, the bone structure and nervous system of your application can be visible in the cloud deployment.

It’s a treasure trove of information that serverless security tools can leverage to achieve higher levels of security, with fewer false positives and negatives, and with less overhead, than could be achieved in the past. For example, the Protego Platform uses this attribute to automatically profile function and application behavior. Protego continuously monitors your serverless application activity and automatically creates a white list of actions and interactions on a resource level. You can also define custom policies and enforce behavior on a per function level.

4.

Smaller Microservices = The Ability to Craft Suitable, Minimal Roles for Each Function

Moving to smaller microservices enables you to do more fine-grained IAM around them all. You have the opportunity to apply security policies to each of those small things, which can significantly reduce your attack surface.

As long as any function within a container needs access to read from S3, all functions within that container would also have that privilege. With AWS Lambda, you have the opportunity to apply privileges to individual functions, and ensure such privileges are restricted to only the smallest scope necessary. If there is a vulnerability in one of your functions, an attacker will only get access to the limited capabilities of that function, not the large set of permissions you may have been forced to grant a container.

What New Security Challenges Emerge with Serverless Apps?

With the changing structure of serverless applications, some new challenges arise.

I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

1.

Security Visibility Becomes More Difficult

The total amount of info and number of resources increases with serverless. This hinders your ability to make sense of all of the data. With a billion events in your log every day, it’s challenging to obtain intelligence from the mountains of data.

2.

Protocols, Vectors, and Attack Points have Multiplied

Every function & protocol = a potential point of attack. This requires unique approaches for Google Functions, Azure Functions, and AWS Lambda security.

3.

More Resources = More Permissions to Manage

More resources equals more permissions to manage, creating challenges in determining permissions for all these interactions. This can be automated with technology such as Protego, which detects configuration risks and automatically generates least-privilege function permissions.

4.

Visibility into Serverless Apps – The Challenge

Serverless apps use different services from various cloud providers, across multiple versions and regions. To understand your attack surface and potential risks, you need a comprehensive view of your entire serverless ecosystem. Unfortunately, there is no one place where you can get a detailed view of each function, including the triggers and resources it accesses. As your app propagates, this security-focused view can be increasingly challenging to build and maintain.

Where to Deploy Security

With serverless apps, there’s nowhere to put classic security such as WAF, firewall and IDS. Building walls between attackers and resources is not simple.

1.

Velocity

While faster, more frequent deployments can be very positive, the velocity of serverless can raise new challenges to in configuring security.

2.

Cost

Security tools could add time to processing, which you must multiply by all requests. Fortunately most serverless security best practices don’t require any additional processing time.

3.

Erosion of the Perimeter

Traditional applications had a clear boundary. The outside and inside were distinct, and we could do security at the perimeter. While it’s not ideal to have security remain exclusively at the perimeter, it was still possible to build a wall.

Serverless apps are more porous and fine-grained. Your serverless app probably comprises dozens or even hundreds of functions. Each of these is a tiny microservice with its own policies, role, API, audit trail, etc. First and foremost, this means that your attack surface has changed, instead of a small number of entry points with lots of functionality hidden behind each one, you likely have many more entry points, each with a small part of the app behind it. Think motel vs. hotel. Defending your application now requires thinking about each and every individual door, rather than a few main entrances.
There is no longer one single entry point to the application because functions can be triggered by various event sources such as:

  • Cloud storage events (e.g. AWS S3, Azure Blob storage, Google Cloud Storage)
  • Stream data processing (e.g. AWS Kinesis)
  • Databases changes (e.g. AWS DynamoDB, Azure CosmosDB)
  • Code modifications (e.g. AWS CodeCommit)
  • Notifications (e.g., SMS, Emails, IoT)

Serverless Security Scorecard

Serverless is a new approach to application architecture and deployment. Security becomes both easier and harder, and the changes are nuanced. Read our “Serverless Security Scorecard” blog post to learn what got better, what simply changed, and what new challenges emerged. Or view the summarized “Serverless Security Scorecard” infographic.

 

Read more in our Serverless Security Guide to learn why traditional AppSec tools are inadequate and less relevant and the threats to serverless security.

SEE DEMO
.