When a newsletter publisher asked Ory Segal to try to hack his serverless application for registering subscribers, it didn't take long to find weaknesses in the application's design.
Segal, chief technology officer at serverless-security firm PureSec, found that the registration system's email server used a Python package for parsing email addresses and did not put sufficient limits on the inputs. The result: The system accepted a 100KB-long email address made of special characters, causing a lag. Sending 1,000 of these email addresses through the service's API saturated the registration system and effectively caused an application-level denial-of-service attack.
The incident demonstrates that, while much of the serverless computing infrastructure is managed by large providers, the security of such applications should be of continuing concern to developers. Segal stressed that the issue was not a vulnerability, or even a security weakness, but showed that problems can arise from poor design of serverless applications.
"It does come to demonstrate that you should pay attention to how you design your serverless applications to withstand attacks, and how you protect them against abuse," he said in a write-up of the incident.
Serverless adoption has grown tremendously in the past few years, with 75% growth in use of the technology in 2017 and 50% growth in 2018, according to data from cloud-management firm RightScale. About 36% of companies have adopted the approach to application creation in some way.
Developers are driving much of the adoption as many move from environments based on cloud infrastructure to creating applications based on cloud services. For that reason, developers have a great deal of responsibility for the security of serverless applications.
Here are five ways that developers can take control and secure their serverless applications.
1. Embrace serverless as the next evolution of cloud
The evolution of application development and deployment to one that abstracts the actual servers is natural, according to a group of prominent researchers from the University of California at Berkeley. A decade ago in an influential paper, the group predicted that cloud computing use would accelerate, but it identified eight areas where user responsibilities for cloud infrastructure would cause friction for adopters, including ensuring redundancy for availability, autoscaling to meet workload requirements, logging and monitoring, and system upgrades and migration.
In a new paper, Cloud Programming Simplified: A Berkeley View on Serverless Computing, the group identified serverless architectures, starting with Amazon's AWS Lambda in 2015, as the next generation of cloud infrastructure that gives developers the ability to work with capabilities—or functions. Combined with automatic maintenance of cloud infrastructure, the further abstraction removes many of the headaches that remained in cloud computing. Much of the back-end maintenance became the cloud provider's responsibility, rather than the cloud user's responsibility.
"The aim and opportunity in serverless computing is to give cloud programmers benefits similar to those in the transition to high-level programming languages," the researchers stated in their latest version of the report.
Yet security remains a responsibility that the developer shares with the provider. While security patches of the underlying operating systems, virtual machines, storage systems, and application code become the responsibility of the provider, the application logic, higher-level code and configuration remains the responsibility of the developer.
"Since most serverless functions today run in public clouds, security is based on the shared responsibility model, where the cloud providers secure the infrastructure, but the code in the functions themselves, as well as controlling their permissions—which resources they can access and who or what can activate them—falls under the users’ responsibility."
—Amir Jerbi, co-founder and CTO, Aqua Security
[ Also see: Securing serverless apps: What IT Ops needs to know ]
2. Reuse functions, but customize security
Serverless computing, which includes functions-as-a-service, gives developers the ability to use computing service without having to worry about the resources needed to provision those services.
While that architecture allows for a great deal of reuse and abstraction, security configurations should be tailor-made for each deployment, Aqua's Jerbi said.
"The specific controls will vary and need to be adjusted, for example in how functions access network or storage resources in the cloud account. This means that you can’t just reuse functions from one cloud to another without some adjustment of the security configuration."
—Amir Jerbi
3. Lock down access controls
A fundamental security problem for many serverless applications is allowing too much privileged access to various functions. Often, developers without proper security training allow too much access to pre-empt any potential blockers to development.
Application secrets and keys are a significant issue in potential access-control security issues. Serverless providers often give developers the tools to manage secrets and securely work with encryption keys, but the approach may be confusing, said PureSec's Segal.
"By far, the most prevalent issue we're seeing is over-permissive IAM permissions, where developers grant functions way more permissions than they actually need in order to operate. While this is not a vulnerability by itself, when coupled with an application layer vulnerability (such as injection based attacks), it can turn into a colossal disaster."
—Ory Segal
Developers should create configurations that apply the least amount of privileges as possible, while focusing on properly architecting microservices to protect against misuse and attack.
4. Manage your open-source components
Developers should be managing open-source components already, but with serverless architectures, the issue becomes more critical. Any application that relies on third-party components and services can be open to attack through unvalidated input—such as the email list registration application vetted by PureSec's Segal. In addition, many security solutions designed to catch common attacks—such as exploiting injection vulnerabilities—may not work with serverless computing.
"At the end of the day, data doesn't just appear out of thin air—it had to arrive from somewhere. So even if you think that your functions consume data from internal sources, that data probably originated at some point at a source you don't trust, and then traversed different cloud services."
—Ory Segal
[ Also see: The essential guide to serverless technologies and architectures ]
5. Continue to scan functions for vulnerabilities
Because many security technologies do not work with the service-oriented architecture of serverless computing, developers should look for tools that specifically address their situation. In addition, because developers don't know how often an underlying service is updated, they should scan their functions frequently, perhaps continuously, to catch any vulnerabilities introduced by updates.
Aqua's Jerbi said they should continue to scan functions that were developed in the past but are used today, because there may be new vulnerabilities present that were as yet undiscovered when those functions were developed.
Take responsibility
While the cloud provider becomes responsible for a greater portion of maintenance and security in a serverless architecture, the cloud user still shares a significant amount of responsibility, said Jerbi.
"[Serverless] enables developers to rapidly ship new software to the cloud without having to rely on traditional IT teams. As such, IT is losing their grip on their ability to govern what's going on, what it being shipped, and their ability to enforce corporate security policies."
—Ory Segal
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
