Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud Security

06:00 AM
Joe Vadakkan
Joe Vadakkan
Joe Vadakkan

Serverless Computing: A New World of Security Risks

Serverless computing, or function-as-a-service (FaaS), is a new cloud paradigm gaining significant momentum in the developer world.

Serverless computing, or function-as-a-service (FaaS), is a new cloud paradigm gaining significant momentum in the developer world. At a high-level, serverless computing gives developers the ability to write code for a particular function and then deploy it in the cloud on platforms such as AWS Lambda and Microsoft Azure Functions. It brings the cloud one step closer to true "utility computing" because companies only pay for the resources consumed when functions are executed, rather than having to pay for underlying resources, as is the custom with traditional cloud models.

Serverless computing is most commonly used for event-driven functions. To put this into context, think about the tire pressure warning light on your car dashboard. Many people assume there's an operating system running an application on the dashboard that receives data about tire pressure. In reality, the light is triggered by a piece of code that only activates when tire pressure is too low or high. (If only the "check engine" light were as precise!) Fundamentally, architecting car systems into these different functions is more efficient and reliable than if all of the functions were written into a single application, which had to boot up and run every time you started the car. This is what we're seeing with serverless computing -- functions that would traditionally be part of an "always running" application are deployed independently in a FaaS environment, where they only activate on an as-needed basis.

Serverless security risks
Serverless computing is rapidly growing in popularity because of the many benefits it provides developers. There's the obvious benefit of not having to worry about all of the plumbing required to run a traditional application, and there are the cost-benefits of a true utility model. Beyond that, there are also benefits around reduced security overhead, increased productivity, quicker time-to-release and greater scalability. But, like with any new technology or innovation, serverless computing also comes with a host of new security concerns:

1) Lack of understanding about serverless security risks
Many IT security teams are still struggling to secure traditional cloud environments, never mind serverless environments. And because, for many organizations, serverless computing is still such a new concept, IT security teams don't yet have a proper understanding of the FaaS model's unique security challenges and how to overcome them.

This will change over time, as serverless computing becomes more pervasive throughout enterprise infrastructures. But, in the near-term, one of the most effective ways security teams can mitigate risk in serverless environments is to identify and learn from the mistakes they made with cloud security, to avoid repeating them in this new world.

2) Altered attack surface
In serverless environments, the attack surface is no longer at the server level, but at the code level. This means cyberattacks aimed at traditional endpoints (denial-of-service attacks, for example) are no longer valid threats, but attacks targeting the code itself are rearing their ugly heads. Some of the most common examples of code-level attacks are code-injection and code-manipulation attacks, which introduce or alter code to change the course of execution (e.g., instead of doing X, do Y).

Beyond external threats, there are also internal security issues to consider, such as developers inadvertently writing insecure code with vulnerabilities that leave an open door for attackers to gain entry, and developers deploying code in the cloud with misconfigurations that leave data exposed.

What can be done about code-level threats? Security teams must integrate security controls and guardrails into the code itself. It's also important to implement continuous monitoring technology, to ensure code integrity. There are only a few tools out there that can actually do logging, monitoring and anomaly discovery of serverless events, but, given the uptick in serverless adoption, this is an area of tremendous growth potential.

3) Excessive access
Many organizations provide their entire development team with access to serverless environments. This means that all developers have privileged access to write code and add functions, without any security guardrails in place. This is not a sound approach organizations must properly implement access privileges. They don't give all developers access to all data and every system on traditional corporate networks, so why should all developers be able to access serverless environments? They shouldn't.

Because writing code is so important (in serverless environments, code is all there is), a much better approach is to ensure least-privileged access, which gives developers only the access they need to successfully perform their jobs and ensures that all developers who are writing code for serverless environments are actually authorized to do so. As code gets promoted toward production, there should be more and more automation used for deployment and management. Ultimately, the production environments should only be modified via continuous integration/continuous delivery (CI/CD) processes automating the deployments with appropriate approvals. Write access to the production environments should be restricted to administrators only.

4) Developer autonomy
Serverless computing makes it possible for developers to deploy code in the cloud without having to gain approval and designated server space from IT. While this greatly improves developer autonomy and productivity, cutting IT security teams out of the process can introduce significant security risk.

As with any DevOps process, security teams need to be involved from the start. When security is integrated throughout the development process, developers can leverage the latest innovations -- in this case, serverless computing -- without bringing unnecessary risk to their organization.

New problems, same solutions
Serverless computing is still a relatively novel concept for many organizations, but how they secure these environments is nothing new. As with traditional infrastructures, IT security teams must understand the unique challenges associated with serverless environments, along with the ecosystem of likely attackers and the techniques they're likely to use, and then optimize their security strategy, operations and technologies to effectively mitigate risk. Most importantly, as with any DevOps process, security needs to be a priority from the start and integrated throughout all phases of the development lifecycle. Only then can serverless computing become a secure business enabler.

— Joe Vadakkan is the global cloud security leader at Optiv Security. He also serves as the president of the Cloud Security Alliance, Southwest Chapter.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...