rvlsoft - Fotolia
Three steps to secure function as a service
Securely setting up function as a service, or serverless computing, is complicated. Learn how to secure function-as-a-service cloud environments with three standard principles.
Serverless computing -- or function as a service -- can be confusing for practitioners who are not familiar with it. This is partly because there are as many different flavors of function as a service as there are providers themselves, and the service offerings from individual providers can vary.
It can be hard to reconcile the variability -- of everything from APIs to language choice to implementation details -- from one service to another. For example, Cloudflare's Workers platform is built on V8 Isolates, AWS Lambda is built on containers, and Azure Functions and Google Cloud Functions are also in the mix.
However, there are a few central principles that function-as-a-service offerings have in common. Understanding what they are is key to helping security practitioners understand them -- and key to ensuring that they are robustly secured.
What is function as a service?
Function as a service is a type of serverless computing, which means the underlying implementation -- the substrate on which the service runs -- is abstracted from a consumer's point of view. A serverless platform exposes an API to the developer, whereby they can create functions -- hence the name -- i.e., discrete, usually small modules of RESTful code that implement a particular subset of business logic.
Function as a service (FaaS) is similar to PaaS. In fact, some argue that FaaS is a subset of PaaS. The key difference is that, with a traditional PaaS, some elements of the underlying mechanics and implementation are still exposed to the user despite the generic goal of service abstraction.
For example, there could be usage thresholds when you add additional compute, bandwidth or other resources to increase scale, or perhaps there may be specific services, like email, that require users to understand the underlying implementation to use it properly. With FaaS, these details are fully hidden, as only the API is directly exposed.
With FaaS, users pay for the incremental services consumed, working within the API offered by the service provider to build modular units of code that can be mixed together to implement a larger application or a portion of functionality. These APIs differ by service provider and service offering, as different service providers support different languages. One platform might support a variety of languages, like C#, Ruby and Python, while another might only support JavaScript.
Likewise, different service providers might offer differing capabilities: some are closer to the application edge -- operating closer to the end-user's browser -- to help streamline performance, while others operate further in to maximize flexibility.
How to secure function as a service
This diversity of operating parameters makes securing FaaS more difficult, specifically because doing so depends on the type of service the organization uses, the type of application it is developing, and other salient points related to the specific use case. That said, there are a few helpful principles that you can apply to secure function-as-a-service usage that will apply regardless of the type of service you're considering.
First, it's important to thoroughly understand the security model of the service you are considering. If an organization uses a particular platform or set of platforms, the security team should understand how they work. This includes not only the principles around how the service operations and functions are built in, but also the details of platform administration.
It also means knowing about any best practices associated with securing the platforms. Security practitioners need to stay on their toes; when they discover that function as a service is being incorporated late in a development cycle, there may be relatively little time to react appropriately.
The second thing that's important is understanding the application you are developing. This is the kind of thing that sounds easy until you actually do it. It's a moving target and requires a specific skill set, particularly in application security, which many organizations haven't implemented well historically.
Application threat modeling can be particularly helpful here; for example, to map out the various interaction points between functions and systematically analyze them in the context of how they're intended to be used and how they might be misused.
Lastly, it's a good idea to analyze how the use case fits into the broader technology strategy. The manner in which serverless functions are developed -- in smaller, modular functional chunks -- can help forward security goals like creating well-maintained, well-managed and well-understood microservices.
However, the reverse is also true; like when stale or obsolete functions remain available after they have been replaced, for instance. Keeping track of what functions are in active use can be more time-consuming and difficult than it sounds, so it's a good idea to keep an eye on what you have, what's being used and for what, and to remove anything that's no longer required.
It can be advantageous to automate this process -- for example, using your service provider's capabilities to alert you to stale functions that haven't been used in some time, enabling you to further investigate or decommission them as needed.
Trying to secure function as a service or serverless computing doesn't have to be scary. The mechanics of securing it might be a little different from securing on-premises apps or apps built on IaaS platforms, but it does take a bit of preparation and legwork to get the job done.
