3 Years of Serverless Security

6 minute read | Last updated 15-Oct-2019 |  Cloud, Serverless

ServerlessConf NYC 2019 recently wrapped up. The 9th edition of ServerlessConf was jam packed with stories of fantastic innovations, practical approaches to migration, and discussion of where this amazing #serverless community is going.

I was fortunate enough to be invited to speak and to host the conference again this year. Hosting provides a wonderful opportunity to hear the talks (at least most of each talk) and engage with the speakers. It was in these discussions with the speakers that I got a really solid read on where the serverless movement stands…and we’ve come a long way in a short period of time.

2016

Way, way back in 2016 (that’s way, way back in the #serverless world), I published an essay called, “4 Steps to Secure Serverless Applications”. This work was one of the first (if not the first) of it’s kind, well received, and generated some active discussions in the community.

My goal at the time was to push back against the growing “no-ops” movement. There was a growing impression that serverless designs meant that very little had to be done on the ops side of things and since there was a void of security information, that nothing was needed on that front.

I proposed that there were four pillars for serverless security:

1. The flow of the data
2. Choosing the services and APIs
3. Code quality
4. Monitoring production

This was a reasonable baseline and provided teams with a framework to evaluate the security posture of their designs. It was a starting point and expected to evolve as the space moved forward.

2017

In 2017, the serverless community really started to grow, thanks in large part to ServerlessConf. The team at A Cloud Guru—a fully serverless company themselves—started this conference in 2016 and quickly expanded it hosting three events the first year and three much large events the second year, 2017.

I was extremely excited to be one of the keynote speakers at the 2017 event in New York City. There, I delivered a talk, “The State of Serverless Security” that outlined how security had evolved as serverless designs had evolved.

The talk—and blog post—explained the shared responsibility model and fine tuned the four pillars to three:

1. Functions
2. Services
3. Data flow

This evolution made it a bit easier for builders to focus on what matter. The overall state of serverless security at this point was solid…but mainly because of the advantages of the design itself, not so much because of efforts that were being made on the security side of things.

And that’s a problem for me as a security professional.

I think that the security community has done itself and the people we’re supposed to be helping a disservice by making things much more complicated that they need to be.

It was—and still is my hope—that by addressing the builder community directly, that we can modernize security and find a better way forward.

2018

That desired continued through 2018 and was very apparent in the talk that I delivered at ServerlessConf in San Francisco. This one was called, “Calling $@*! on Security: A Cultural Challenge”.

I didn’t pull any punches in the talk but it wasn’t designed to be mean or antagonistic either. The goal was simple: explain to the builder community why security teams are rarely helpful.

It’s worth a listen to, if only to understand a classic security point of view. That should help build empathy and—ideally—start to bridge the gap between the security team and well, everyone else.

In this talk, I re-iterated the same three pillars of serverless security as they were reflective of the state of the community.

This period of time also marked the first real efforts of various startups to build a serverless security product. These products were solid but focused entirely on the “functions” pillar. There’s nothing wrong with that as long as it’s acknowledge that they only address part of the problem.

That’s something marketing teams typically have issues with. Another challenge with positioning was with the term serverless itself. The inner community was long past the days of the “Jeff” debate but with newcomers joining and companies starting to see the space as an opportunity, the waters around what serverless was started to muddy.

I mapped out the three most common uses of the term and started to share that with teams just entering the space. It’s been helpful, especially when dealing with security teams. There is so much potential more change, it’s just one more reason I was and continue to be so vocal about serverless security.

2019

In 2019 Serverless has hit the mainstream. It’s a regular topic during AWS keynotes and most organizations are starting to explore it at some level. That’s fantastic.

There are very real and tangible benefits to these types of designs. Serverless is also a wonderful counterpoint to the growing behemoth that is Kubernetes. When serverless designs started to take off, I was worried that they would be touted as the end-all, be-all of architecture. No worries there as most teams continue to stuff things in containers for the k8s machine to chew on.

Despite that trend, serverless continues to grow. Once a team wraps their head around event-driven architectures and the benefits of the serverless model, it’s hard to stop them.

I think more teams should be adopting a simple approach: serverless first, if that doesn’t meet the need then containers, and finally servers if absolutely required.

Security continues to be a concern of the community but most security teams are myopically focused on securing functions as a service (like AWS Lambda, Microsoft Azure Functions, and Google Cloud Functions). This is a more comfortable area for security to work with as it resembles things they are already familiar with.

The reality is that external threats to functions are largely theoretical at this point. At least anything beyond standard injection attacks (still #1 after a decade of application security efforts).

The primary issue facing serverless applications is simple: misconfigurations.

Misconfigurations have accounted for millions of records being exposed and a constant stream of headlines. Yet, this area is often overlooked when trying to improve the security posture of serverless architectures.

I spoke at ServerlessConf NYC to help raise awareness of this issue. The talk was called, “The Sky Is Falling, Run!”. The video will be up soon but in the meantime, you can read the key points from the talk.

This talk moved back to a four pillar system for serverless security, it closely follows my original work from 2016:

1. Service selection
2. Functions
3. Data flow
4. Configuration validation

The good news? We have access to much better tooling to address these areas now.

What’s next?

Serverless architectures are still evolving and so it the tooling to support building in this manner. The line between what is a security tool and what is an operational tool is blurring and builders are better for it.

For too long security has been treated as a separate and distinct discipline. Yes, there are areas where deep expertise is required specific to security but we are all better off if security is viewed as just another part of building well.

The goal of cybersecurity is simple: to make sure that whatever you build works as intended…and only as intended.

You can’t do that in isolation. It must be a core part of building. That’s why serverless designs are so exiting for security, they are forcing us (the security community) to come in from the cold and collaborate with the team.

Moving into 2020, we’ll see more operational and security tools to help builders deliver more robust serverless designs. There are just too many clear business wins to ignore.