Serverless is a bit of a misleading term, along with its famous predecessor “cloud.” Our digital world remains very dependent on physical servers and hardware, and the only question is who owns these servers and hardware that power our digital world.

With infrastructure as a service, cloud providers take on the responsibility and headaches of setup and maintenance of the servers, network, storage, virtualization, connectivity, and the physical environment. Your organization remains responsible for the operating system, middleware, runtime environment, databases, and more before you can start deploying applications, storing data, or uploading files. Functions as a service (FaaS) adds another layer of abstraction so that your teams can concentrate on writing the code specific to the business and you only pay for compute used.

Great news, your security team can take a much-deserved vacation! But wait, before you slather on the sunblock and start sipping piña coladas, consider that:

  • Serverless functions are stateless, ephemeral, and distinct but not impenetrable. With serverless, you pay for compute usage; therefore, a best practice is to design short-running, independent workloads. The median Lambda invocation, for example, is only 60 milliseconds. The ephemeral nature of serverless and the abstracted infrastructure pose a challenge to adversaries hoping to launch an advanced, persistent threat attack. But attackers are not so easily dissuaded. The old security technique of putting a web application firewall in front of applications to detect malicious traffic no longer holds when you have tens, hundreds, or even thousands of distinct functions that can be triggered by a number of different events — more than just an incoming HTTP/S request. Your perimeter is no longer defined by your network; it’s a sprawling landscape across cloud providers, services, and serverless functions. And adversaries are quick to realize that, if the front door is locked, there are plenty of windows and side doors to go through.
  • Serverless functions are written with code. There is no magic here. But part of the attraction with serverless is the ability to quickly write and deploy code to production. The pressure of being first to market and continuously releasing features that delight customers is ever increasing as more business activities are digitized. It wouldn’t be unheard of in the rush to get new functionality out the door that corners are cut, best practices for serverless development are not followed, or that the unique security challenges that serverless poses are not well understood. Whether it’s a lack of time, knowledge, or resources that leaves your serverless applications and environment vulnerable, malicious attackers really don’t care. In fact, they are more than happy to take advantage of any weakness to compromise a system for their gain.
  • Serverless functions don’t exist in a vacuum. Serverless functions are architected to perform a single task and are great for inconsistent traffic where there are spikes in demand, because the cloud provider takes care of scaling the service. When demand rises, functions will automatically scale to meet the need, and when demand decreases, functions are scaled back. The best part is that you only pay for what is used. An application that utilizes serverless functions, however, also needs to utilize a host of other cloud services such as cloud storage, NoSQL databases, event queues, and API gateways to connect, commute, and glue all the pieces together. Your development team is the one in the driver’s seat, determining what gets deployed, what services are selected, and how resources are configured. It’s in these configurations where security mistakes can be made. The cloud providers are willing to take responsibility for the hardware and software that they provide, but they will not take responsibility for how you use and configure the services. Ultimately, you need to understand where cloud providers’ responsibilities end and where yours begin, ensuring that your teams are aware and following best practices.

Read my report on how to avoid the security inconsistency pitfalls when transitioning to serverless to learn more about what you need to do to ensure serverless security.