Securing Serverless – Blog Series – Episode 0x04 – The Six Most Common Reactions to The Words “Serverless Security”
Having talked with many organizations about serverless security lately, I can pretty much classify the initial CISO reactions when I bring up the topic of “serverless security”:
Reaction #1 (CISO in denial):“Serverless?! I don’t believe we use that…I need to check”
Reaction #2 (CISO believes in fairies):
“Serverless security is not an issue, the cloud provider has it covered….”
Reaction #3 (The procrastinating CISO):
“We’ve just started adopting serverless, we’ll deal with security later in the process…”
Reaction #4 (The misled CISO):
“We use strict IAM roles and scan all 3rd party libraries for known CVEs”
Reaction #5 (The narrow-sighted CISO):
“Our serverless functions are internal and never consume input from external sources directly, so they are not under any kind of risk”
Reaction #6 (The smart CISO):
“I don’t have enough knowledge on this subject, I’m all ears”
I’d like to share a true story. In my previous role, prior to joining PureSec, I asked a team member to develop an application for tracking platform vulnerabilities on a daily basis. The purpose was to allow customers and internal users to search for old or new vulnerabilities, manage them, provide visibility, send SMS notifications, cron-based daily updates, etc. It took my team member about 5 days to develop a terrific full-fledged python application. We deployed it locally, protected it with a WAF, and blissed out in for 10 minutes, until we suddenly realized that the whole darn thing was installed on our internal network, which meant that customers won’t be able to access it.
We started looking for a more suitable deployment solution and the first natural choice was to deploy it on an AWS EC2 instance, however, that would mean provisioning a server, taking care of scalability issues, operating system patches – thing we didn’t really plan on doing regularly. We then stumbled upon Zappa ( https://www.zappa.io/ )- a terrific mischievous little framework that does magic. Zappa takes your Python WSGI-based web applications, and deploys them on AWS using Lambda and API Gateway, and all of this magic happens pretty much instantly, without much hassle or hard work.
10 minutes later – Voila! The thing is running on AWS, completely serverless, no servers to manage, no security patching required…bliss…..[for another 10 minutes]…
Then my team member turned to me with a worried look in his eyes and asked – “But what about the security of the app?!” – it was on that specific moment, that the same thought dawned on both of us – by serverless-ifying the application, we pretty much got rid of the responsibility to secure the infrastructure, the operating system and the network (Yay!), but at the same time, we also gave away our ability to deploy any kind of application security controls (Doh!).
===
Here are a few takeaways from my story, and from the common reactions mentioned above:
- Me and my team member did not consult with our IT group about our little serverless adventure. It was accessible, fast, and simple to build and deploy. I’ve already seen numerous organizations that have similar Shadow-IT serverless application deployments – make sure you are aware of them, and make sure they are secure!
- It’s a shared responsibility model, the security of your serverless application, is still your responsibility – there are no fairies that sprinkle magical security dust on serverless applications. Application security is still critical for serverless applications.
- If you are building serverless applications, you should take care of security as early as possible. Don’t build (or even experiment with) serverless applications now, and leave security for later. Security should be introduced early in the process rather than being bolted on when it’s too late.
- Hardening your serverless environment is a terrific first step. However, it’s not enough. You wouldn’t deploy a web app in production after only hardening your Apache configuration, right?
- Yes, third party dependencies have vulnerabilities in them, but in many cases, your own code will also introduce vulnerabilities. Securing serverless applications is much more than just patching 3rd party components.
- If you don’t threat model your serverless applications thoroughly, you won’t really know what kind of input they consume. The fact that there’s no direct access to your serverless function, doesn’t mean they don’t consume untrusted input. Functions consume event data from a wide range of sources, which in many cases can be controlled by malicious users in all sorts of unexpected ways
- Traditional security solutions will not fit your serverless applications as they are all deployed on the infrastructure – which you no longer control. Take a monolith application, which you currently protect with best-of-breed security solutions, migrate it to serverless, and you will soon find that you’re left with no runtime security protections.
- Last but not least – while serverless is a choice made mostly by development organizations, the security of serverless applications should still be the responsibility of your InfoSec team / CISO.
Talking about CISOs and InfoSec teams – do them a favor and send them our “Serverless Security Top 10 Most Common Weaknesses” guide ( https://www.puresec.io/resource-download ), and please also ask them to take our State of Serverless Security survey ( http://bit.ly/2ocGvXO ).
In case you missed the previous episodes in this blog series:
*** This is a Security Bloggers Network syndicated blog from PureSec Blog (Launch) authored by Ory Segal, PureSec CTO. Read the original post at: https://www.puresec.io/blog/the-six-most-common-reactions-to-the-words-serverless-security
