How to best defend against cloud-native malevolence
I spend a lot of time in a dance with customers and partners. On the one hand, I strive to best understand what keeps them up at night as they ponder the security of their cloud-native applications.
On the other hand, I also try to provide them with new insights into how the threat landscape is shifting.
This is critical because a prerequisite to securing something is to understand what you’re up against. Too many organizations spend their security dollars trying to prevent things that are not actually going to happen while neglecting scenarios that are far more likely.
Nowhere is this problem more notable today than the shift to cloud-native applications, and especially serverless computing.
Cloud-native applications are applications that are purpose-built for the cloud model. These applications have been built from the ground up to be deployed and operated in a cloud environment.
The key pieces are:
● Decompose applications into small independent microservices
● Utilize the rich services that cloud providers and third-party partners provide via API
● Leverage the cloud for automated stability, scaling, and recovery
Serverless computing is shaping up to be the cloud-native as the cloud-gods intended. That’s because serverless disposes of the notion of “machines,” and allows development teams to actually focus on implementing architectures that are optimized for how the cloud scales.
Serverless applications are deployed as a series of event-driven functions, which the cloud provider will execute for you as needed. You’re billed for what you use, and you’re free (for the most part) from worrying about scaling resources up and down.
So the point I find needs highlighting is how these shifts in application development are beginning to affect how attackers approach these applications. Consequently, we security practitioners must move in concert, and adjust how we defend them.
Let me preempt the opposition some of you are already starting to type into the comments section. No, attackers motivations haven’t changed. They are after the same goals, including stealing your data, encrypting it for ransom, or just generally trying to degrade your services. The “what” hasn’t changed. But attackers are refactoring the “how” in this new environment.
I want to focus on three key changes in how attackers are gearing up to attack your cloud-native applications.
The Groundhog Day
Compute services in cloud-native applications tend to have short lifespans, especially in serverless architectures. Serverless functions are designed, by necessity, to be completely ephemeral, and cloud providers don’t keep them running for all that long.
For attackers, this presents a challenge. They may not be able to easily achieve “long-term” presence in your system since nothing runs more than a few hours.
One shift we’re seeing is the Groundhog Day Attack in which an attacker crafts a much shorter attack that just steals, for example, a few credit card numbers. This single round of the attack is then repeated until the full attack is complete.
Here attackers are leveraging the automatic scaling of the cloud-native application, to get by the ephemerality of it.
Poisoning the Well
Another approach is the upstream attack, or what we call Poisoning the Well. Here attackers aim to gain more long-term persistence in your application, despite the aforementioned ephemerality. They may try to, for example, steal patient medical data as it’s accessed, over a long period of time.
Cloud-native applications tend to comprise many modules and libraries. The modules often include many other modules, so it’s not uncommon for a single serverless function, with less than 100 lines of code your developers wrote, to include tens of thousands of lines of code from sources you are blissfully unaware of.
Attackers scour common projects looking for ones where they can easily get their malicious code included. After poisoning the well, they patiently wait as the new version makes its way into your cloud applications. Once inside, the malicious code can call home, get instructions, and start wreaking havoc.
Another challenge that cloud-native applications face is that often they encourage paradigms of rapid deployment and best of breed technologies. It’s very common to find a diverse mixture of programming languages, runtimes, database technologies and monitoring tools in use at the same time.
This diversity can spawn some incredible tales of rapid deployment, but it also provides a much richer attack surface for attackers. This is driving attackers to approach cloud-native applications with a much more heterogeneous set of techniques. Attackers will bring all sorts of packages and toolboxes to bear, essentially throwing malicious spaghetti at your application with the hope that something sticks.
It’s Not All Bad
First, serverless architectures tend to be harder to attack, not easier, at least for the time being. This may be a combination of the freshness of the technology, and the fine-grained compartmentalization these applications have. Now you need to focus on putting barriers up between you and your attackers that will mitigate the changes I mentioned above.
Here are some brief recommendations:
- Ensure that every service/function is allowed the smallest set of privileges possible.
- Use tools to look for repetitive patterns in attacks.
- Protect your supply chain.
- Impose standards on what languages and tools should be used.
- Get security into your CI/CD pipeline.
It’s certainly early days in cloud-native and serverless computing, but we’re already seeing the positive and the less-positive effects it’s having on our deployments. The trick now is to stay educated, stay vigilant, and stay ahead of the curve.