Securing your serverless app can feel overwhelming. Do you ever have that sinking feeling in the pit of your stomach, worrying that you’ve forgotten something? The agonizing fear that you’ve left the stove on and will burn down your home?
If you’re deploying serverless applications, you may be experiencing that twisting apprehension with regards to securing this relatively new tech. While we’d love to reassure you that all is well, chances are good that you have indeed made some mistakes. (C’mon, we’re a security company. What did you expect?) Read on for the top mistakes you’re likely making securing serverless apps. Hopefully you can sleep well after some tweaks.
Since application layer firewalls are only capable of inspecting HTTP(s) traffic, a WAF will only protect functions which are API Gateway-triggered functions. Your WAF will not provide protection against any other event trigger types.
A WAF won’t help if your functions are triggered from different events sources, such as:
That is not to say it is useless, but it is a critical mistake to assume the WAF takes care of it all. Relying solely on a WAF leaves many gaping security holes that you must take care of with a different solution.
Setting policies that are larger and more permissive than functions need is a common serverless security mistake. Check out our on-demand webinar on this crucial topic.
Failing to minimize individual function roles and permissions makes your attack surface larger than necessary. You must sit down with the developers who wrote the functions and review what each function does. Only after determining what functions actually need to do, can you properly create a unique role for each function and craft a suitable permission policy.
OK, now that each function is permissioned correctly, with a strict focus on least privilege, you should be all set, right?
Hold it, don’t rest your head on the pillow just yet. Our next mistake is thinking that every piece of code in your app is actually your code.
In what we refer to as ‘Poisoning the Well,’ attackers aim to gain more long-term persistence in your application by means of an upstream attack. Cloud-native applications tend to comprise many modules and libraries. The modules often include many other modules, so it’s not uncommon for a single serverless function to include tens of thousands of lines of code from various external source, even with less than 100 lines of code your developers wrote. Attackers look to include their malicious code in common projects. After poisoning the well, they patiently wait as the new version makes its way into your cloud applications.
“In 2017, Black Duck Software researchers found through an audit of 1,000 commonly-used applications in the enterprise that 96 percent utilized open-source software, and over 60 percent contained security vulnerabilities due to these components. Some of the bugs found were over four years old.”
Code vulnerabilities can be mitigated through careful CI/CD… but can you be certain that every function you have deployed went through your CI/CD?
Malicious functions can slip in through a variety of means which can make securing serverless apps difficult. Means such as being deployed by a rogue employee. Additionally, the workstations of your developers could be a target for attackers, rather than the deployed apps themselves. To be fair, developers tend to be less susceptible to phishing scams than some. But accessing a workstation would enable attackers to deploy malicious functions through legitimate channels. Such functions could sneak in and wreak havoc, undetected.
As outlined in our Serverless Security Scorecard blog, visibility gets harder with serverless. The shift to serverless significantly increases the total amount of info and number of resources, which hinders your ability to make sense of all the data.
Obtaining intelligence from the mountains of data is challenging, and thus so is securing serverless apps. As the quantity of functions continues to increase from hundreds to even thousands, it’s more difficult to determine if everything is behaving the way it’s supposed to. Only a few hundred functions can generate billions of events in your log every day. It’s difficult to know which are important.
Even if you are familiar with the attack patterns that are unique to serverless apps, visually scanning them all simply can’t be done by humans. Much like driving, AI is superior. (Yes, yes, autonomous vehicles are better drivers than you.)
Functions should have a tight runtime profile. Admittedly, crafting appropriate serverless function timeouts is often not intuitive. The maximum duration of a function can be quite specific to that function. You must consider the configured timeout versus the actual timeout. Many developers set the timeout to the maximum allowed. And why not? ¯\_(ツ)_/¯ We don’t pay for that time, so we might as well.
If an attacker is able to succeed with a code injection, they have more time available to do more damage. Shorter timeouts require them to attack more often, which we refer to as a “Groundhog Day,” attack. That makes the attack more visible.
So, shrink not just what a function can do, but how long it can run.
Securing serverless apps requires a variety of tools and tactics, including collaboration between the people involved in the application and the security. For additional resources, check out our on-demand webinar “Serverless Security Quick Wins.” You can also watch “Serverless Security Step by Step,” and download our eBook, “Serverless Security Primer: Top Risks and How to Mitigate.”