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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
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.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "Well I dont run on MacOS, so I need to take extra precautions"
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-10136
PUBLISHED: 2020-06-02
Multiple products that implement the IP Encapsulation within IP standard (RFC 2003, STD 1) decapsulate and route IP-in-IP traffic without any validation, which could allow an unauthenticated remote attacker to route arbitrary traffic via an exposed network interface and lead to spoofing, access cont...
CVE-2020-13757
PUBLISHED: 2020-06-01
Python-RSA 4.0 ignores leading '\0' bytes during decryption of ciphertext. This could conceivably have a security-relevant impact, e.g., by helping an attacker to infer that an application uses Python-RSA, or if the length of accepted ciphertext affects application behavior (such as by causing exces...
CVE-2020-13758
PUBLISHED: 2020-06-01
modules/security/classes/general.post_filter.php/post_filter.php in the Web Application Firewall in Bitrix24 through 20.0.950 allows XSS by placing %00 before the payload.
CVE-2020-9291
PUBLISHED: 2020-06-01
An Insecure Temporary File vulnerability in FortiClient for Windows 6.2.1 and below may allow a local user to gain elevated privileges via exhausting the pool of temporary file names combined with a symbolic link attack.
CVE-2019-15709
PUBLISHED: 2020-06-01
An improper input validation in FortiAP-S/W2 6.2.0 to 6.2.2, 6.0.5 and below, FortiAP-U 6.0.1 and below CLI admin console may allow unauthorized administrators to overwrite system files via specially crafted tcpdump commands in the CLI.