Cloud

6/26/2018
02:30 PM
Hillel Solow
Hillel Solow
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Dr.T
50%
50%
Dr.T,
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.
Dr.T
50%
50%
Dr.T,
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.
Dr.T
50%
50%
Dr.T,
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.
Dr.T
50%
50%
Dr.T,
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.
Dr.T
50%
50%
Dr.T,
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.
nathanluise92
50%
50%
nathanluise92,
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. 

Microsoft President: Governments Must Cooperate on Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/8/2018
To Click or Not to Click: The Answer Is Easy
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  11/14/2018
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Online Malware and Threats: A Profile of Today's Security Posture
Online Malware and Threats: A Profile of Today's Security Posture
This report offers insight on how security professionals plan to invest in cybersecurity, and how they are prioritizing their resources. Find out what your peers have planned today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19279
PUBLISHED: 2018-11-14
PRIMX ZoneCentral before 6.1.2236 on Windows sometimes leaks the plaintext of NTFS files. On non-SSD devices, this is limited to a 5-second window and file sizes less than 600 bytes. The effect on SSD devices may be greater.
CVE-2018-19280
PUBLISHED: 2018-11-14
Centreon 3.4.x has XSS via the resource name or macro expression of a poller macro.
CVE-2018-19281
PUBLISHED: 2018-11-14
Centreon 3.4.x allows SNMP trap SQL Injection.
CVE-2018-17960
PUBLISHED: 2018-11-14
CKEditor 4.x before 4.11.0 allows user-assisted XSS involving a source-mode paste.
CVE-2018-19278
PUBLISHED: 2018-11-14
Buffer overflow in DNS SRV and NAPTR lookups in Digium Asterisk 15.x before 15.6.2 and 16.x before 16.0.1 allows remote attackers to crash Asterisk via a specially crafted DNS SRV or NAPTR response, because a buffer size is supposed to match an expanded length but actually matches a compressed lengt...