We talk a lot about the need for a different security paradigm for AWS lambda security, and it’s easy for these messages to get conflated with messages like “this thing isn’t secure.” While it’s sort of early days for serverless, there are a few good reasons to believe that security teams should be pushing their organizations towards serverless, not away from it. While many believe serverless frameworks present new security challenges that are hard to deal with, especially manually, the truth is serverless brings forth many security advantages, and big opportunities for better, in-context, security. There are new risks, and organizations should definitely consider new techniques and automated solutions, but, if done right, serverless is a massive opportunity for the best security one can ever achieve.
In general, when you approach serverless security, as with anything new, there are really three types of issues that drive you to redefine your security strategy. The first is where your risks are the same, but your mitigations need reimagining. This is clearly true for serverless and Lambda, where we need to consider how and where to deploy cloud and application security, in a world without servers and with true autoscaling.
The second is where the new technology allows us new opportunities for security that were previously difficult or impossible. Here too, serverless is clearly in this category. The fine grained “nano-service” architecture that most serverless applications follow allows much more tightly applied security policies. And the orchestration of resources on the cloud fabric in a visible way provides a wealth of information that security tools can take advantage of to protect applications.
The third category is where the new technology creates new risks that need to be mitigated. While there are some new types of risks to address in serverless applications, like the fragmentation of the perimeter and the challenges of security orchestration, in this case, it’s pretty clear that, on balance, there is less risk, not more.
Let’s try and take stock of some of the reasons your move to use AWS Lambda and serverless deployment will make security better.
Remember, despite the name, there are still servers, operating systems and runtimes in the platform. You just don’t have to manage them anymore. And you don’t have to handle their security anymore either. Amazon will undoubtedly do a better job than most of us at keeping these parts of the system secured. Plus, since you no longer need to handle that, you can repurpose the extra time you used to spend on patching OSs doing something else to improve security.
Perimeter security is less applicable in serverless, and some might argue that makes security harder. On the other hand, I think that the past few years have shown us that the Zero Trust model is a better model for security. The perimeter was never as hermetic as we imagined, and moving to a Zero Trust model for our applications is going to make things more secure, not less. Much of the work we’re doing on application defense at Protego is around this model, and it’s going to make application security better
We talk a lot about the challenge of getting optimal security configuration when deploying serverless applications on AWS Lambda. Hundreds of functions means hundreds of IAM roles to craft, and most organizations aren’t yet taking advantage of this gift. But it is a gift. With the right tools and processes, you can have what we call “shrink wrapped permissions” around each function, allowing that function to access exactly the resources and services it needs, and nothing more. With security posture done right, the vast majority of potential attacks on your application are prevented, and you can then focus your security energy on defending against the remaining risks.
Often, when talking about if AWS lambda is secure, we talk about the challenges in deploying security without state. But let’s not forget that the fact that functions execute for a short period of time, and this makes attackers lives very challenging. If you focus on configuring your function timeouts to be as short as possible, you will actually make many attacks almost impossible. The fact that your functions don’t live long will make your application more secure.
Well, no. Obviously there are inherent risks in doing anything new and unexplored, and you need to get ahead of those risks by learning what works well for your organization. And potential security advantages, like visibility and granularity, are only potential advantages until you use the right tools and create the right workflows to realize those advantages.
But once you do, I’d wager you’ll find those applications that you reimagined with Lambda, API Gateway and DynamoDb, that you secured with the right platforms for serverless security, are the most secure applications in your organization.