Cloud

6/21/2018
10:30 AM
Boris Chen
Boris Chen
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

AppSec in the World of 'Serverless'

The term 'application security' still applies to 'serverless' technology, but the line where application settings start and infrastructure ends is blurring.

"Serverless" computing is essentially an application deconstructed to its atomic unit: a function. Function-as-a-Service (FaaS) would actually be a better name, but the whole XaaS naming scheme is a bit, shall I say, PaaSé. (Oops, couldn't resist!) So, instead, we have "serverless" to drive home the idea that application developers don't need to think about servers any longer. They can focus their energies on creating countless glorious functions – and in the cloud, no less.

In concept, this continues the industry trend of making a starker separation in software delivery services, as well as extending the micro-services trend to the next stage of decomposition, or the breaking down of monolith applications. Here are some key concepts to understand about serverless in the context of application security (AppSec) and infrastructure.

Code Still Matters
A serverless function is a piece of application code. As such, little changes when it comes to AppSec fundamentals – for example, defending against injection attacks. Query strings and string concatenation of file names are still bad. Not paying attention to encoding is bad. Serialization attacks still occur, and so on. Similarly, applications still use third-party libraries, which could have known vulnerabilities and should be vetted. Serverless doesn't make those problems go away. (For an excellent talk, see "Serverless Security: What's Left To Protect," by Guy Podjarny.)

On the other hand, because security practitioners have placed a great deal of attention on infrastructure settings and services, the line where application settings start and infrastructure ends is now blurry.

Infrastructure Shift
Because serverless extends what the infrastructure provides, it shifts the shared security model. Just as in the case of cloud computing, where the provider takes responsibility for the security "of the cloud" (hardware, network, compute, storage, etc.) while leaving the customer responsible solely for security "in the cloud" (operating system, authentication, data, etc.), serverless reduces the responsibility of the customer further.

Serverless infrastructure eliminates the need for operations to constantly update OS patches. Further, the execution environment is in an ephemeral container, with a read-only file system and highly restrictive permissioning. Controls like these greatly improve inherent security. But they also have their own limitations, such as /tmp being writable, and "ephemeral" doesn’t strictly mean a repaved instance between each invocation.

Most attacks against serverless applications succeed through a combination of the aforementioned limitations (which are still significant improvements over typical containerized instances), app-level exploits, and taking advantage of services in the cloud infrastructure, such as poorly configured AWS IAM. (The talk "Gone in 60 Milliseconds," by Rich Jones, outlines chaining examples.) It's highly instructive to understand the anatomy of such attacks. My main takeaway: The road to hell is paved with default settings.

Greater dependency on infrastructure also mutates some of the threats. In the case of DDoS attacks, the infrastructure can scale to meet the demands; hence, DDoS effectiveness is diminished. However, it's not the sky that’s the limit but your wallet. Major cloud providers simply do not put utilization caps in place for many reasons. One reason? They don't want to be held responsible for an involuntary shutdown of service based on a monetary threshold. The most you can do is set up billing alerts – and thus was born the "denial of wallet" attack.

The Threat of Serverless Sprawl
Fundamentally, the above concerns present few unique risks not shared by customers with apps running on plain EC2 instances. However, managing sprawl does present a novel challenge for serverless. The reason: Serverless functions are like tribbles. They start out small and cute, but then they proliferate, and you end up neck-deep in them. Suddenly, what was meant to be simple is simple no longer.

As the number of functions multiply without a means of easily managing the access controls of serverless functions, the application security posture is greatly threatened. For instance, the principle of least privilege is easy with few functions, but as functions proliferate, often with ill-defined requirements, maintaining secure settings rapidly becomes harder.

Fighting Fire with Fire
Serverless provides a way to scale, so why not use it to scale serverless security? When it comes to the "three R’s of security" (rotate, repave, repair), serverless functions provide an excellent mechanism to build security into deployment. For instance, AWS already provides a means to rotate keys using Lambda functions. Moreover, serverless functions are basically in continuously repaved containers, and practitioners have been writing lambdas to automatically fix security mistakes. In fact, there’s a lot of untapped potential in No. 10 on the OWASP Top Ten: Insufficient Logging and Monitoring. Lambda functions that operate on CloudTrail logs to identify threats and perform automatic remediation have intriguing potential.

Serverless is neither the end-all and be-all, nor does it make irrelevant lessons learned from AppSec. It nonetheless provides an exciting opportunity to build more secure apps in the cloud (serverless or otherwise), with some pitfalls to beware of along the way.

The Future 
Vendors, tools, and processes will need to evolve to fit naturally into the structure of serverless application construction. Some solutions, such as host/container security tools, may become less relevant in some respects due to the shift in responsibility. But those that can manage security concerns on the functional level (both build and run times) and manage infrastructure at scale will enable serverless to fulfill its goal of providing a more secure means of delivering cloud applications.

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.

Boris Chen is vice president of engineering and co-founder of tCell, an AppSec startup providing next-generation real-time attack detection and prevention for applications built for the cloud.  He has over 20 years of industry experience building high-performance web ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
boristcell
50%
50%
boristcell,
User Rank: Author
6/25/2018 | 5:09:41 PM
Re: Overwhelmed by servers and serverless = loss of data control
Good points. To me, "serverless" is more a sub-category of "cloud." To be sure, security concerns using serverless also can apply to cloud services in general. The article you reference is a good description of thinking through data handling and controls in general, such as by the practice of storing passwords using bcrypt, rather than in cleartext to limit the damage of data loss. That applies regardless of what infrastructure or programming model one chooses. It goes to illustrate that in the end, security fundamentals don't change; the art is in the application of those principles as the landscape changes.
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
6/22/2018 | 6:08:21 PM
Overwhelmed by servers and serverless = loss of data control
To a certain extent, "serverless" is becoming a fancy word for "cloud". And at some point, data has to get stored and processed on some server somewhere, serverless or no. The phenomenon you describe here is similar to the loss of data-control issues in an SDLC similar to those recently discussed on Dark Reading, here: darkreading.com/putting-the-s-in-sdlc-do-you-know-where-your-data-is/a/d-id/1331185
New Cold Boot Attack Gives Hackers the Keys to PCs, Macs
Kelly Sheridan, Staff Editor, Dark Reading,  9/13/2018
Yahoo Class-Action Suits Set for Settlement
Dark Reading Staff 9/17/2018
RDP Ports Prove Hot Commodities on the Dark Web
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
How Data Breaches Affect the Enterprise
How Data Breaches Affect the Enterprise
This report, offers new data on the frequency of data breaches, the losses they cause, and the steps that organizations are taking to prevent them in the future. Read the report today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-3912
PUBLISHED: 2018-09-18
Bypassing password security vulnerability in McAfee Application and Change Control (MACC) 7.0.1 and 6.2.0 allows authenticated users to perform arbitrary command execution via a command-line utility.
CVE-2018-6690
PUBLISHED: 2018-09-18
Accessing, modifying, or executing executable files vulnerability in Microsoft Windows client in McAfee Application and Change Control (MACC) 8.0.0 Hotfix 4 and earlier allows authenticated users to execute arbitrary code via file transfer from external system.
CVE-2018-6693
PUBLISHED: 2018-09-18
An unprivileged user can delete arbitrary files on a Linux system running ENSLTP 10.5.1, 10.5.0, and 10.2.3 Hotfix 1246778 and earlier. By exploiting a time of check to time of use (TOCTOU) race condition during a specific scanning sequence, the unprivileged user is able to perform a privilege escal...
CVE-2018-16515
PUBLISHED: 2018-09-18
Matrix Synapse before 0.33.3.1 allows remote attackers to spoof events and possibly have unspecified other impacts by leveraging improper transaction and event signature validation.
CVE-2018-16794
PUBLISHED: 2018-09-18
Microsoft ADFS 4.0 Windows Server 2016 and previous (Active Directory Federation Services) has an SSRF vulnerability via the txtBoxEmail parameter in /adfs/ls.