The revolution came and went. No shots were fired, but lots of chaos ensued. You finally got your head around containers and Docker, and your teams have moved on to serverless. There are many benefits to moving to a serverless architecture (and I am not jumping into the etymological fracas of what serverless means, and how it differs from FaaS…). Your DevOps is more DevOps, your agile is more agile, and your velocity is more… more velocity?
Your security, on the other hand, is not more secure. At least not exactly. The move to serverless has made some things better and some things worse, but pretty much nothing has stayed the same. In my next few articles I’ll dive into some of the details on serverless security, but for today I wanted to try and clarify the ways in which your security wants and needs have shifted while you might not have been looking.
Here Amazon, You Drive…
Some things feel more secure to you as your teams’ services have moved from containers and VMs into AWS Lambda Functions or Azure Functions. Certainly you can feel confident in the platform. AWS, Microsoft, and Google have, for the most part, proven very reliable in keeping their parts of the stack patched and secured, so giving them a bigger chunk of the stack certainly improves things on that end.
On the other hand, loss of control almost always has its security problems. Not owning the platform means not being able to leverage the platform for security in ways you might have in the past. You’re at the mercy of whatever security mechanisms the cloud provider puts in place for you, and those rarely provide the level and granularity of protection you’d like.
It’s a bit like riding in an Uber vs. taking your own car. Sure, the drivers are probably more professional, and perhaps better trained. And the flexibility of paying for a car only when you need it is great. At the same time, you don’t get to choose which safety features the car has, or how many airbags you’ll have around you.
The threats to your serverless applications are, in many ways, the same as they were before serverless. All our beloved OWASP top ten reasons to not sleep at night are as relevant as ever (I’ll touch on them in more detail in future posts). But they may not look and act the same way they did before.
The ephemeral stateless nature of serverless compute means that exploits don’t necessarily turn into persistent presence inside your system. That’s a plus. Lambda functions run in magical containers that self-destruct every few minutes (mostly), and the function calls themselves typically have short timeouts, so gaining a foothold in such a container will not give your attacker the prize it might have in the past. Instead, you can expect repetitive stateless attacks. The attacker leverages the exploit to get in, do some small part of the attack, and get out. Rinse and repeat as many thousands of times as you need until all the data has been exfiltrated, or all the files have been encrypted.
This means our serverless defenses need to be less focused on handling the specific event, and more attuned to the overall pattern of the attack. It’s hard to notice a few thousand extra Lambda calls in AWS. Your security tools need to know how to spot this sort of thing early on, and mitigate it before it becomes a serious problem.
Your serverless app probably comprises dozens or even hundreds of functions. Each of these is a tiny little microservice. It has its own policies, role, API, audit trail, etc. First and foremost, this means that your attack surface has changed, instead of a small number of entry points with lots of functionality hidden behind each one, you likely have many more entry points, each with a small part of the app behind it. Think motel vs. hotel. Defending your application now requires thinking about each and every individual door, rather than a few main entrances.
Additionally, the triggers that launch your function are varied, so an attack might come at you from any direction. You need to consider all the ways an attacker might directly or indirectly cause your resources to do things you didn’t intend.
Extraversion and Serverless Security
On the other hand, the fact that your application is now structured as a large number of small functions in the cloud provides a fantastic opportunity for security. Application security tools often go to incredible lengths to analyze and instrument your packaged application just to be able to observe or filter the internal flow of your app. With serverless, the bone structure and nervous system of your application are visible in the cloud deployment, and security tools for serverless should take advantage of this treasure trove of information to achieve higher levels of security, with fewer false positive and negatives, and with less overhead, than could be achieved in the past.
Running With Scissors
Velocity and agility are great, and serverless application design supports the ability to truly push out new features incredibly quickly. Much of that speed comes from shrinking the DevOps friction down to a minimum. Some of you have already enabled your developers to directly push code into your testing and staging systems. Once tested, this code could be in use by customers in a matter of hours. That is truly amazing!
Unless you’re responsible for application security. If you are, then it’s truly terrifying! Those DevOps folks were the last hope for your sanity in the old world. They were your DevSecOps people, running some last minute security tools, working through those security checklists, and keeping an eye out for security. The last thing you want to do is start reintroducing friction into the process, but you need to quickly find alternative ways to keep ahead of the security curve.
Money, Money, Money
Finally, let’s not forget cost. While not the only reason to go serverless, the ability to be charged only for what you consume may be saving you a lot of money. On the other hand, once you’ve saved that money, you need to watch out what you add.
A logical but ultimately disastrous approach some security providers may propose could effectively be summed up as: you can’t get application security from the platform, so let’s put it all in the application. The problem with this approach is it ends up loading up your functions with an untenable amount of extra work, which can translate into sometimes doubling or tripling your costs, and negating all the cost savings you came here for in the first place.
In Other Words
Serverless is here to stay, and for organizations trying to keep pace with their customers’ needs, it’s pretty much a must. The impact on your security regime is likely to be more profound than you might have expected. Maintaining control and security requires a paradigm shift in your thinking.
In the coming weeks, I will discuss additional aspect of serverless security, including various best practices, things you need to look out for, new perspectives on old attacks, and some of the new technologies that are emerging to provide security in the brave new serverless world. Stay tuned!
The post Your Apps Have Gone Serverless. Has Your Security? appeared first on Protego.
*** This is a Security Bloggers Network syndicated blog from Blog – Protego authored by Hillel Solow. Read the original post at: https://www.protego.io/your-apps-have-gone-serverless-has-your-security/