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. 

WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: White Privelege Day
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-17282
PUBLISHED: 2018-09-20
An issue was discovered in Exiv2 v0.26. The function Exiv2::DataValue::copy in value.cpp has a NULL pointer dereference.
CVE-2018-14592
PUBLISHED: 2018-09-20
The CWJoomla CW Article Attachments PRO extension before 2.0.7 and CW Article Attachments FREE extension before 1.0.6 for Joomla! allow SQL Injection within download.php.
CVE-2018-15832
PUBLISHED: 2018-09-20
upc.exe in Ubisoft Uplay Desktop Client versions 63.0.5699.0 allows remote attackers to execute arbitrary code. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of URI ha...
CVE-2018-16282
PUBLISHED: 2018-09-20
A command injection vulnerability in the web server functionality of Moxa EDR-810 V4.2 build 18041013 allows remote attackers to execute arbitrary OS commands with root privilege via the caname parameter to the /xml/net_WebCADELETEGetValue URI.
CVE-2018-16752
PUBLISHED: 2018-09-20
LINK-NET LW-N605R devices with firmware 12.20.2.1486 allow Remote Code Execution via shell metacharacters in the HOST field of the ping feature at adm/systools.asp. Authentication is needed but the default password of admin for the admin account may be used in some cases.