Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:30 PM
Hillel Solow
Hillel Solow
Connect Directly
E-Mail vvv

Securing Serverless Apps: 3 Critical Tasks in 3 Days

Serverless workloads in the cloud can be as secure as traditional applications with the right processes and tools. The key: start small, scale as your application scales, and involve everyone.

For many organizations, serverless is already a part of their day-to-day operations. Often it has permeated from the ground up, with developers embracing a software development, deployment, and operations paradigm that empowers them to do more with less. For security professionals who are still reeling from the move into the cloud, this change sometimes conjures up the instinct to just declare defeat and move on.

You may be in one of those organizations. In fact, if your organization has a significant software operation on a public cloud, there's a pretty good chance that some teams have already started experimenting, if not deploying, serverless workloads. While there are a set of new security tools and technologies that have emerged to help security in this new world, there are also many steps security professionals and advocates can do on their own to help contain the situation.

I always like to clarify that, in and of itself, the move to serverless doesn't make things worse, in terms of security. In fact, in some areas, such as patching operating systems and protecting runtimes, cloud providers are taking the load off of you and will usually do a great job. The challenge is that once you cede control and responsibility of the platform to the cloud provider, you will often need to find new ways to deploy the application security you need to protect your valuable business services.

I like to view the shifting needs of serverless security in three buckets:

  • Same old attacks, but where do you put the firewall? In other words, how do you protect serverless applications from attackers when you don't or can't put your classic security tools in the way.
  • New attacks for serverless applications. These are mostly attacks that leverage new event triggers that were externally accessible in the past, or attacks that take on new forms in serverless.
  • New opportunities for security in serverless. This is where the shift to serverless actually has the potential to make security better. For example, the shift from rather large multipurpose services in traditional applications, to small single-purpose functions, creates an opportunity to leverage identity and access management to tightly constrain each function and prevent malicious activity.

Long term, you probably need to be thinking more fundamentally about how you're going to handle serverless security as serverless becomes an ever more significant part of your ecosystem. But there are things you can do right now to get a better grip on the situation — especially when your serverless infrastructure is still small. I'm going to give you three tasks. Pick one each day and try to make as much progress as you can.

Task 1: Know the Unknowns 
The single biggest challenge with securing any cloud native application is knowing what resources are deployed in the cloud and how they are connected to each other and to the outside world. If you don't have a tool that will do this for you, don't worry. Open a spreadsheet and make a list of all the serverless resources you have, including functions, storage buckets, database tables, and APIs and service meshes. Try and list how the resources can be accessed (this can be tricky, but do your best).

The goals of this exercise are to:

Find and prune all the old stuff you're not using anymore. Serverless encourages clutter and hoarding, since you pay almost nothing for resources that are lying around unused. But these resources could be your biggest security liability, so look for things that haven't been accessed for a while or seem redundant.

Have conversations with the owners of these resources. Review the necessity and the risk of the resource. Ask whether this function could live in a virtual public cloud or if that bucket should be marked private?

Task 2: Become a Small Target
One of the biggest advantages of serverless architecture and deployment is that you can do a lot to minimize your attack surface. This can be labor intensive if you do it manually, but the upside is huge. Focus on:

Roles and permissions: Sit with your developers and review each function. Start with the ones that are most risky — ones that can be called from an external trigger or can access sensitive data). Make a list of what the function needs to do and compare that to what it is allowed to do. Nine times out of 10, you'll find gaps, sometimes scary ones. But you can close the gaps, by reconfiguring function IAM roles. I strongly recommend using a unique role for each function; otherwise, you'll almost always be overprovisioning something. Use a naming convention so you don't get lost in them.

Timeouts: This is something of a hang-up of mine, and some may disagree. But here's the gist of it: developers will often leave timeouts set to the maximum (usually 5 or 10 minutes). Since you only pay for what you use, they figure why not? But these unnecessarily long timeouts increase the potential for attackers to do more damage. Keeping timeouts close to the most your function actually uses, severely limits the amount of damage an attacker can do when exploiting your weaknesses, and it makes attacks more complicated to execute and easier to spot and defend.

Use your cloud providers dashboards to look at the longest your function runs, usually on cold-start, and pick a suitable margin of error so you can sleep at night. That's your new timeout. Work with developers on this, as these timeouts might be controlled in their deployment scripts. For extra credit, set alarms in your cloud providers monitoring platform to alert you if the function comes close to the new timeout so you can reassess your decisions before you break something.

Third-party libraries: Your functions likely include much more third-party code than your own developers' handy work. That's how development rolls these days, and it makes for big gains in application velocity. Catching these vulnerabilities early can mean the difference between safety and mayhem by:

  • Making a list of libraries or modules that your function uses
  • Checking those against known CVEs to see if you're at risk
  • Replacing or upgrading anything vulnerable
  • Repeat periodically.

Unfortunately, this can be labor intensive, so if you have more than a few functions, you may need to automate the process.

Task 3: Communicate
The move to serverless creates an additional challenge for many organizations because even these basic suggestions involve both security engineers and developers. This is not by chance. Increasingly, developers have ownership of configuration and security controls, and any attempt to improve security without close partnership between developers, DevOps, and security is doomed to fail. The solution is to create cross-functional teams to review security. Make it everyone's problem. Enable communications with shared Slack groups or joint Jira accounts. If you're choosing security platforms to help you, don't just evaluate what they detect or what they can defend but also how they enable this dialogue natively.

Related Content:

Why Cybercriminals Attack: A DARK READING VIRTUAL EVENT Wednesday, June 27. Industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Go here for more information on this free event.

Hillel Solow is the chief technology officer and co-founder of Protego. Prior to this he was chief technology officer in Cisco's IoT security group, where he worked on innovative security solutions for new technology markets. View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
6/29/2018 | 9:14:50 AM
Third-party libraries
Third-party libraries: Your functions likely include much more third-party code than your own developers' handy work. I think there is good and bad aspect of it. Sometimes third-party libraries are better than what you can do on your own, such a encryption, do not do your own.
User Rank: Ninja
6/29/2018 | 9:12:35 AM
Re: Practise and theory
So of course, better to keep attention on all necessary things and practice as much as possible for you. I agree, practice, practice, practice. We get better at it and apply.
User Rank: Ninja
6/29/2018 | 9:11:41 AM
Re: Practise and theory
Because practice and theory are two different things. That makes sense. Some theories do not have any practical approach either.
User Rank: Ninja
6/29/2018 | 9:10:39 AM
Re: Practise and theory
Of course, the theory of everything is really important, but, without practice, you won't get all the needed results. That makes sense. We should get theory right the implement it correctly and adjust theory as needed.
User Rank: Ninja
6/29/2018 | 9:09:10 AM
Serverless apps
For me, apps in the cloud or on-premises are the same for security point of view, we need to secure wherever it is on a shared envirement or not. So encrypt communication in transit and data at rest.
User Rank: Apprentice
6/27/2018 | 3:02:23 AM
Practise and theory

You get these tips by your own experience, I can see this, and that is really great as for me, as practical knowledge are better towards theoretical one. Of course, the theory of everything is really important, but, without practice, you won't get all the needed results. Why? Because practice and theory are two different things. It is like on casino games - you know all winning spinit casino review strategies, all great combinations, but you won't be sure that everything will be as you want. So of course, better to keep attention on all necessary things and practice as much as possible for you. 

7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-12
Use After Free vulnerability in nfc sockets in the Linux Kernel before 5.12.2 allows local attackers to elevate their privileges. In typical configurations, the issue can only be triggered by a privileged local user with the CAP_NET_RAW capability.
PUBLISHED: 2021-05-12
Exposure of System Data to an Unauthorized Control Sphere vulnerability in web UI of Argo CD allows attacker to cause leaked secret data into web UI error messages and logs. This issue affects Argo CD 1.8 versions prior to 1.8.7; 1.7 versions prior to 1.7.14.
PUBLISHED: 2021-05-12
Deskpro Cloud Platform and on-premise 2020.2.3.48207 from 2020-07-30 contains a cross-site scripting (XSS) vulnerability that can lead to an account takeover via custom email templates.
PUBLISHED: 2021-05-12
Cross Site Scripting (XSS) in LAOBANCMS v2.0 allows remote attackers to execute arbitrary code by injecting commands into the "Website SEO Keywords" field on the page "admin/info.php?shuyu".
PUBLISHED: 2021-05-12
An Information Disclosure vulnerability exists in dhcms 2017-09-18 when entering invalid characters after the normal interface, which causes an error that will leak the physical path.