Serverless functions are currently revolutionizing application development. Devs can now discard the tedious and resource-draining process of setting up and managing in-house servers. However, does such rapid architectural change come at the cost of data integrity? This is what users, businesses, and developers can do to bolster serverless function security.
Table of Contents
The Rise of Serverless Functions
Applications require connectivity. To power the connection between an app and the World Wide Web, developers – alongside coding the application – also had to manage the apps’ servers and computing resources themselves.
Microservices is a software architecture that has totally changed the format of app development. Instead of hours of employee time – and bucketloads of expensive resources – being poured into the maintenance of developers’ own in-house servers, it is now possible for devs to simply outsource these elements. Function-as-a-Service platforms remove huge swathes of complexity from this system. Now, a relatively inexperienced app developer can build and deploy applications – without the previous roadblocks of complex runtime environments.
So, serverless computing isn’t technically serverless – it still depends on a cloud platform and its physical servers to run the lines of code involved. On paper, allowing developers to focus on development – and a separate company, such as Amazon AWS, or Microsoft Azure, to focus on server maintenance – allows for the best of both worlds: highly-polished apps, dependent on an always-available platform.
The third-party providers for these serverless functions ensure a suite of tempting features, including almost-constant uptime, and a high degree of scalability. It not only streamlines the process of app development but also helps guarantee a consistently high level of app performance.
Alongside great peace of mind and incredibly low prices for hosting, it’s no surprise that soon one-quarter of app developers will be utilizing cloud-native, serverless technology.
So, what’s the catch?
Serverless and Security-Scarce
Serverless infrastructure may provide a host of benefits to the speed and cost of development. However, it places even greater demand on security protocols within the development process. Unfortunately, rapid development often comes at the cost of such security. Here are a few instances in which serverless could show a severe disregard for users’ and developers’ data integrity.
The API Issue
Like tiny cogs within a watch, serverless infrastructure makes use of many small pieces of independent software. These interact and transfer data using Application Programming Interfaces (APIs). When a user requests a piece of data, this is handled by each link in the chain of serverless software.
While APIs make this process highly adaptable to each developer’s needs and allow multiple mechanisms to communicate, it has serious ramifications on the security of the overall application. One major issue with APIs is their occasional tendency to just assume the correct authentication. This results in data spillages with far-reaching implications.
Microsoft Power Apps is a product that supports “low code” app development, specifically those in the business intelligence field hosted on Microsoft’s cloud system. Last year, a major authentication issue was found within its OData API.
Take a public-facing application – such as an app that provides the location of your nearest Covid-19 vaccination clinic. Within this app, some data types need to be publicly available, while other pieces of data need to remain hidden. The app should recall the locations of nearby vaccine clinics to anyone who requests that information – but, at the same time, needs to block any attempt to recall the sensitive data of the people being vaccinated.
Unfortunately, these out-of-the-box APIs often come with default settings. In the case of Power Apps’ OData, the default setting made sensitive data accessible to the public. Not only was this data accessible, but there was no prior authentication process required – meaning that anyone could anonymously pry and collect this data.
Ultimately, Power Apps’ broken APIs exposed 40 million records. These contained personal and company email addresses; social security numbers; and employee IDs. It involved dozens of organizations across almost every industry, including American Airlines, the Maryland Department of Health, and Ford.
And That’s Not All…
API data leakage plagues public-facing apps in particular. However, APIs have their own security implications for private architecture, too. The lack of inbuilt authentication means that serverless functions can be highly susceptible to Server Side Request Forgery (SSRF) attacks.
SSRF attacks allow an attacker to point a non-public server in the direction of a malicious site. For example, an attacker can use a trusted API to make an organization’s internal server download a malicious payload, such as ransomware. This was potentially the attack vector in the 2021 NorskHydro attack. The Norwegian power plant was forced to switch to manual operations after a severe ransomware attack grounded the entire IT department.
Serverless Protection
A Web Application Firewall (WAF) – though a fantastic piece of security artillery – is not enough to single-handedly protect against serverless security flaws. A WAF only monitors the flow of web traffic into and out of the application and is unable to protect against other attack types. For example, if the app’s vulnerable API pertains to data processing, notifications, or cloud storage, then a WAF will be completely blind to these security events.
Alongside a WAF, a Runtime Application Self-Protection (RASP) system needs to be on the lookout for internal security flaws. RASP intercepts all types of traffic, automatically detecting ones that indicate malicious activity, such as cross-site scripting. Its innate ability to discern between genuine attacks and legitimate behaviors makes RASP a next-gen security solution, as it greatly decreases the number of false positives.
Finally, RASP offers a short-term fix for many zero-day exploits. Thanks to its behavior-focused monitoring, it doesn’t require a recognizable file signature in order to block a malicious script from executing.
Ultimately, though serverless removes many of the traditional server-based considerations within app development, developers and customers need to prioritize a security-first approach. All too often, organizations treat apps as fully out-of-the-box solutions. With today’s development process, this is becoming increasingly false – not to mention risky.
Minimizing the permissions of each individual function helps to regain some control over serverless’ ever-broadening attack surface. Though it may seem a daunting task, the implementation of custom permissions needs to be a requirement, instead of a mere suggestion.
