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.

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
Oldest First  |  Newest First  |  Threaded View
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
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.
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18214
PUBLISHED: 2019-10-19
The Video_Converter app 0.1.0 for Nextcloud allows denial of service (CPU and memory consumption) via multiple concurrent conversions because many FFmpeg processes may be running at once. (The workload is not queued for serial execution.)
CVE-2019-18202
PUBLISHED: 2019-10-19
Information Disclosure is possible on WAGO Series PFC100 and PFC200 devices before FW12 due to improper access control. A remote attacker can check for the existence of paths and file names via crafted HTTP requests.
CVE-2019-18209
PUBLISHED: 2019-10-19
templates/pad.html in Etherpad-Lite 1.7.5 has XSS when the browser does not encode the path of the URL, as demonstrated by Internet Explorer.
CVE-2019-18198
PUBLISHED: 2019-10-18
In the Linux kernel before 5.3.4, a reference count usage error in the fib6_rule_suppress() function in the fib6 suppression feature of net/ipv6/fib6_rules.c, when handling the FIB_LOOKUP_NOREF flag, can be exploited by a local attacker to corrupt memory, aka CID-ca7a03c41753.
CVE-2019-18197
PUBLISHED: 2019-10-18
In xsltCopyText in transform.c in libxslt 1.1.33, a pointer variable isn't reset under certain circumstances. If the relevant memory area happened to be freed and reused in a certain way, a bounds check could fail and memory outside a buffer could be written to, or uninitialized data could be disclo...