Keeping your serverless architecture secure
Serverless architecture empowers organizations to build and deploy software at scale without in-house servers. The prevalence of Function-as-a-Service (FaaS) models like microservices is a testament to the popularity of serverless architectures. The cost-saving impact alone is enormous, as is the flexibility for growth afforded by massive scalability.
In this article, we’ll outline the key areas you should consider if you want to keep your serverless architecture secure. While the solution that best fits your own ecosystem will be unique to you, the following will serve as strong foundations upon which to build your approach.
A fluid attack surface
Simply put, the attack surface of your software environment consists of all the points through which an unauthorized user can enter or extract data. Understanding and monitoring these points is the key to effective serverless security.
Serverless systems are composed of dozens, hundreds, or even thousands of components. There are new points of entry for malicious and unauthorized users added with each new tool, service or platform that gets integrated into the ecosystem. Every time your architecture is scaled and pruned the attack surface changes.
What’s more, because of the multiplicity of entry points and complex topology of serverless architectures, a serverless attack surface is multi-layered and multi-dimensional. The high complexity and fluctuating nature of your serverless architecture’s attack surface make manual mapping and monitoring almost impossible.
Automated mapping and monitoring of serverless architecture
Automating the monitoring and discovery of your systems allows you to stay a step ahead of threats. You can only protect what you can see. Unless your monitoring tools can increase the range of their visibility as your systems scale, large segments of your architecture will disappear from view very quickly.
In your serverless architecture, there is a high chance automated continuous deployment will be employed. This means that new weak spots on your attack surface are also being created on a continuous, automated basis. If your monitoring and discovery capabilities can’t keep up, new segments will be vulnerable.
Fortunately, there are platforms available that can map and monitor your serverless architecture in real-time. Many of these also have features that extend to security and pinpoint where unauthorized users can maliciously manipulate data. Some of these platforms are designed specifically with serverless security in mind.
Event-data injections: The most common serverless security risk
The most common risks for serverless architectures come from data injections. Injection flaws have been a prevalent feature of serverless security discussions since the first serverless system went online.
Every component and function of your serverless architecture takes input from a vast range of sources. These could be cloud storage events, commands from API gateways, message queue events, database changes, signals from IoT telemetry, even emails. The list is practically infinite and limited only by the scale and contents of your architecture.
Suffice to say that the larger you scale, the more variety in the sources your functions ingest data from.
We’re sure you can already see the problem here. Each of these different source types brings with it a unique message format and encoding scheme. Any of these can contain untrusted or attacker-controlled input. Predicting and eliminating these malicious injections can be a daunting challenge.
Invest in function monitoring and logging for robust serverless security
“Invest” in this instance doesn’t necessarily refer to a financial investment. Time and effort are more important, although if you find your stack has shortfalls, it may carry additional costs. Don’t be put off by this. The cost implications of a major security breach far outweigh the relatively low-cost expenditure of protecting yourself from them.
Many cloud vendors provide a basic form of logging facility or functionality. Common examples include AWS CloudWatch or Azure Functions. While these enable very basic logging for your environments, they can be costly and may not meet your requirements once your serverless architectures scale past a certain size or level of complexity.
Out-of-the-box solutions aren’t always suitable for your needs. While they have basic functionalities they can lack the power for full security event audits at the application layer. This becomes truer the more your serverless architecture scales and shapes to your unique design. There are many expert-built platforms and tools available which make up for these monitoring and logging shortfalls.
Create unique logic and utilize intermediary cloud storage services
As we said, function monitoring and logging is something that will require (but is worth) some investment of time and effort. The main obstacle to overcome with function logging in a serverless environment is that monitoring and logging exist outside of your organization’s data center perimeter.
This can be reconciled by having your engineers, serverless developers, and DevOps teams create a logging logic that is unique to your architecture. You’ll need a logic that can collect logs from your various cloud functions and services, pushing them onto a remote SIEM (security information and event management) system.
Some log types that are known to be of particular importance in serverless environments include reports on authentication and authorization, critical errors and failures, change, malware activity, network activity, and resource access.
Many of these are critical reports regardless of your architecture model. But, in a complex and ever-changing serverless environment, monitoring and visibility can be tricky. Creating a logic that can isolate, extract, and collate these reports in a single repository so your entire architecture can be monitored in real-time is vital.
The logs collected by logging logic need to be stored somewhere. This is where intermediary cloud storage services come into play. By having a single, external system collating the logging information from the entirety of your serverless ecosystem you’ll enable real-time monitoring of security events.
You can track and contain attackers and malicious/unauthorized input across all of the serverless functions in your architecture’s topology, regardless of the layer.
Overprivileged function permissions and broken authentication
A deadly combination of weaknesses can exist in your serverless architecture if due diligence and proper scrutiny aren’t applied to your functions and users.
The first is robust authentication. Serverless usually means a microservices-oriented architecture design. Microservice architectures can contain hundreds of individual functions. As well as serving as proxies to other processes, many serverless functions can leave public web APIs exposed. This is why applying a robust authentication scheme is vital.
A broken or inefficient authentication scheme creates a potentially limitless number of access points for unauthorized users as your serverless ecosystem grows. This on its own is dangerous, but if your functions are also overprivileged it can be catastrophic.
Managing the function permissions and roles can feel like an uphill battle in a serverless environment with dozens, or even hundreds, of components. One of the most common security errors made by engineers is to attempt to cut corners and apply a catch-all permissions model. While this saves time, it leaves everything in your serverless environment incredibly vulnerable.
If both flaws are present due to due diligence not being followed you have a system easily accessible to malicious outside users. Broken authentication holds open the door, overprivileged function permissions hand them the valuables once their inside. Both can be avoided by being thorough and thoughtful during design, build, and deployment.
Further serverless security considerations
There are of course other considerations. For example, remember to decommission obsolete functions and cloud resources. Not only does this help streamline costs, but legacy and unused components add unwanted dimensions to the attack surface of your architecture. Automate regularly decluttering your environment and removing unused roles, identities, and dependencies.
It’s also important to avoid reusing execution environments. Carrying over an execution environment between invocations can be tempting for cloud providers. It makes their platforms more efficient at handling new invocations. However, when execution environments are carried over, valuable and sensitive data could get left behind. Be sure that efficiency isn’t achieved at the cost of security.
Your serverless environment is unique, so your approach to serverless security should be, too
This is always the overriding consideration. Whether it’s your deployment configuration, your permission model, or your logging tools, an out-of-the-box solution will only give you so much protection. Your unique environment demands a security approach that’s just as unique.