The state of serverless security
How are we doing as a community of builders? With serverless, are we building more resilient systems?
The state of serverless security is strong.
We — the serverless community — have mostly ignored security. That’s ok. In fact, it’s excellent. The serverless designs provide a robust security foundation by their very nature…if you make the right choices.
The question is how do you make those choices? What are those options in the first place? What does security look like in an environment where you don’t control 99% of the infrastructure that helps to deliver your solution?
The Wrong Way To Secure Solutions
The good news is that the way security is traditionally applied is wrong. Security controls are — by definition — an admission that there was a failure somewhere in the build chain (development-to-deployment).
Instead of tackling these core failures, various forces and complexities have pushed cybersecurity into a more comfortable role: to stop hackers and breaches.
This reduced role is the cause of most “security” problems and results in poorer outcomes. In reality, the goal of security is simple:
The goal of security is to ensure that your system works as intended…and only as intended.
When defined as stopping hackers and breaches, security controls get bolted on to existing solutions. To be effective, security controls should be integrated into solutions and deployed as an explicit trade-off between development resources and delivery time.
As the headlines over the past few years can tell you, bolting on security controls is a not a robust approach.
With serverless designs, we can do better. We can build security into the fabric of out applications will minimal effort.
This work starts with the shared responsibility model.
The Shared Responsibility Model
There are six major areas where work — maintenance, monitoring, etc. — needs to be continuously done;
3. Operating System
In the cloud, the most responsibility you take on is from the operating system up (3–1). In serverless designs, you’re operating exclusively at the data layer. You’ve delegated 5/6 areas of responsibility to your service providers.
That’s a massive win for security right out of the gate.
With that understanding, you can now focus your efforts exclusively on the data responsibilities. In a serverless design, this means;
• Choosing services that support your risk appetite
• Writing quality code
• Mapping data as it flows between services
Each of these areas is critical to the overall security of your application. Let’s look at each in depth.
When it comes to selecting the services that will make up your solution, the critical question is whether or not they meet your security needs?
Are you storing personally identifiable information (PII)? Or just random gifs? There’s a significant difference in how you would approach the security of each of these choices.
Remember, you are going to delegate 5/6th of the day-to-day work to your service provider. You need to make sure that the service provides an appropriate level of security and that the provider is following through on their end of the bargain.
The way you do that is by evaluating the available feature set of the service (what options and features are available) and understanding the provider’s operations.
Determining what features are available is easy. Understanding the provider’s operations requires transparency.
Fortunately, the primary providers are leading the way in this area. They are releasing whitepapers and videos that explain some of the steps they take to secure their services. Compliance attestations are a way to get 3rd party validation of the work the provider claims to be doing.
A little bit of paranoia can be healthy. A suite of significant compliance attestations can but that paranoia to rest.
As is stands today, the community gets an A for services when it comes to security.
Code is complex. There isn’t a strong track record of quality code being written and delivered. You only have to look at the latest headlines to understand that we are not doing as well as we should in this area.
The OWASP Top 10 list of common vulnerabilities has remained mostly unchanged since 2010. Making matters worse, the some of the top 10 — <cough>injection</cough> — should be a simple fix.
Never the less, the community continues to struggle in writing quality code. One way to tackle this problem is via code reuse and sharing. The downside is that this can lead to new issues as various dependencies expose your applications to new threats.
In a serverless design, your code will run in a FaaS (functions as a service) offering. This method reduces the attack surface and limits the path to call it, but there are still challenges around quality.
Until development culture shifts the definition of done to align with the modern definition of security (code that does what it’s supposed to and only that), we will continue to deal with code quality issues that create poor security outcomes.
Current grade: B+ but because we’re writing less code, not better code.
Your serverless application uses various SaaS services stitched together with your code running in a FaaS. Monitoring the flow of data between these services can be a challenge, but it’s critical to ensuring the safety of your data.
As it stands today, this is a gap in serverless tooling.
If you want to evaluate the flow of data between services the best tool available to you at the moment is some time with your team and a large whiteboard.
Working together to map out the types of data, where it flows, and how to verify it’s integrity at each stage is still a manual exercise. That’s somewhat acceptable but monitoring that flow and providing assurances what you designed is active through the system’s lifecycle is difficult and requires a home-brew solution.
That’s not a position we want to be in and why the current grade is a C-.
Good But We Can Do Better
Overall, serverless designs are more resilient and robust than their traditional counterparts. That’s due to the nature of these architectures rather than any specific effort on the part of the community.
The next three to six months, we (the community) should focus on building out tooling that helps visual and verify the flow of data between various services. This focus will be critical to the safety and performance of our applications.
Still, we should take a minute to pat ourselves on the back. We’re in a good place security wise. Our overall grade: B.
As you work on your serverless designs and toolchains remember that security is an integral part. It’s not a separate activity or discipline. It’s a fundamental piece of everything we do.
What do you think about the state of serverless security? Where can we do better? How can we do better? Let me know with a response below.