Why Serverless Architectures Are the New Cloud

Serverless architectures provide you with the benefits of automation and unlimited scale potential. It gives developers the freedom to deploy code quickly, which accelerates time to market while making it easier to maintain and test individual functions. With no infrastructure involved, serverless architectures are ready and available out of the box. As an added benefit, you only pay for what you use, thus reducing your costs.

By offloading certain duties to the cloud provider, your operational costs are significantly decreased, and you can focus on developing solutions that serve your organization and customers instead of managing infrastructure. This means that as development teams shift their focus from technology to business value, you can get more done with fewer people. Serverless can also fill in any gaps in your architecture faster and cheaper than by building more infrastructure.

Security Risks with Serverless Computing

By nature, the move to serverless makes many areas more secure, but it does raise new challenges that security teams need to consider. For instance, you no longer need to patch servers, and the ephemeral, stateless nature of serverless computing makes attackers’ lives harder. The fact that your application is now structured as a large number of small functions in the cloud enables you to see each unit of compute as a separate entity.

In many ways, the security around serverless architectures becomes easier, but it also requires a unique, nuanced approach. Here are the distinct challenges of securing serverless apps.

• Security visibility: It’s difficult to make sense of all of the disparate data.
• Many more points of attacks, protocols and vectors: Every function, API and protocol is a potential point of attack.
• Erosion of the perimeter: Serverless apps have more porous, fragmented boundaries.
• More permissions to manage: Challenging and time-consuming permission and access management.
• Where to deploy security?: There’s nowhere to put traditional network or perimeter security, such as intrusion detection system, firewall and web application firewall.
• More functions and more changes equals more risk: The ephemeral and fragmented nature of serverless can mean more frequent changes to posture and more risk management and security auditing requirements

Threats to your apps will still persist, but will just look and act differently. It becomes important to understand what to look for to proactively secure your applications. Maintaining control and security requires a paradigm shift in your thinking. Defenses need to focus less on handling the specific event and become more attuned to the overall pattern of repetitive stateless attacks.

Whose Job Is It to Secure Serverless Apps?

With the advent of new technologies, it is important to look at past security issues and apply the lessons you learn to today’s technologies. This is how you stay ahead of attackers. For modern microservices, developer and security teams need to partner together — devs must not be careless and security teams must not be blockades. Serverless is no exception to the need for collaboration.

However, there is additional confusion regarding where the responsibility for serverless application security lies. Given the fluid nature of serverless application development, a traditional AppSec approach takes time and can slow things down, negating the serverless benefit of rapid feature deployment. Developers cannot possibly keep up with the hyper-accelerated velocity they themselves created if they need to wait on security to open ports, IAM roles or security groups. While security pros do not want to get in the way of developers, they still need the ability to control policy and visibility, and are challenged as to how to integrate with DevOps without causing a slowdown of the pipeline. This leaves everyone in a quandary.

Make Secure Serverless Computing Everyone’s Problem

The solution to secure serverless applications is truly everyone’s problem and requires a close partnership between developers, DevOps, and AppSec. Security teams need to find a balance where developers are trained and empowered to implement secure coding best practices, the more automated the better. However, security teams are not absolved from responsibility. Security vulnerabilities and issues are their responsibility, and they need to be fixed early in the life cycle. They need to help with defining the risk of the problem (i.e. is this something we can deploy the application with?) without introducing risk to the business. Finally, creating cross-functional teams and working toward tight integration between security specialists and development teams is part of this solution. Collaborate with DevOps so that your organization can resolve security risks at the speed of serverless.

Finally, I’ll leave you with three best practices to think about:

1. Map your app and observe the ongoing flow of information.
2. Apply perimeter security at the function level.
3. Craft suitable, minimal roles for each function.