Okay, let's start. Hi everyone. Thanks for coming. So my name is Tal. I'm leading the research for our cloud native solutions at contrast security, and I'm going to talk about securing or automatically securing serverless applications. Just a quick question. How many of you or in your organizations are actually using serverless like Lambda functions, Azure functions, GCP functions? Okay, got it. Okay. So you are all here. So you probably already know that the transformation to the cloud has begun already a while back and we assume to see more and more organizations moving into the cloud. Some of them move to serverless, some of them are hybrid and some of them use mostly containers and institutes in the cloud. But what is serverless? Serverless is an event driven architecture, fully cloud based, mostly unmanaged by the organization, the developing organization. And it doesn't fit for every workload, but it does allow very quick value to developers.
Developers love it. If you give developers the ability to use serverless functions, you will see them in popping up like mushrooms after the rain, I once went to an, we went to a customer, a potential customer. We talked to the seasaw, the security organization there, big organization, and they just moved to serverless. So I asked them, how many functions do you have in your organization? Do you know? And he said, yes, I think around 400, 300. We just started two months ago to give the developers the access. He said About 200. Then we said, okay, let's connect your to your cloud and let's see what you have. We connected to their account and they had more than 5,000 functions because once developers start working with functions, it's so easy for them, everything that they need, they just pop up a new function and it goes into production really quick.
So at aws, this is taken from AWS presentation where they estimated hundreds of thousands of customers using serverless and trillions of lamb execution per month. This was three, three years ago. I assume it's, it grows. Why am I here? Why am I talking to you? So in, in 2017, just a little bit after serverless came into our into the world, I joined ProGo A that did serverless security, runtime protection. As head of security research, we got acquired by Checkpoint at 2019. After that, I created my own company called Cloud Essence. You probably haven't heard about us because we got acquired really quickly by contra security and this is why I'm here. So basically in the past five, six years, I've been solely focusing on serverless and serverless security. Why now? Actually it's not now. It should have been like two years back at least because people use serverless, but they don't realize that security might need a little bit of a, of a different approach.
Okay, security is still security, application security is still application security, but cloud security and serverless is a little bit different and application is a little bit dif, could be different. So there could be some different aspect to your security. And I did this Google trends and you can see serverless computing is increasing waste time. The dropdown there during covid. But other than that, a lot continuous increase in serverless. But several security is basically a term that no one search, no one look for. And you can see it's kept between one and two. And I'm pretty sure that this one is me throughout the entire time. So maybe some two, three more people are looking for this term serverless security and it's not good enough. We have to talk about it. Why? Because serverless application look a little bit different than what you're used to. So this is an, A screenshot from our product is serverless security, security and monitoring tool.
And I just showed you the graph of a small, a very small application that we have. This application has maybe few dozen, a couple of dozens of functions. The orange, the orange small dots, and the purple ones are the API rest APIs connected to them. There are some other cloud resources there and you can see that from security perspective, even from monitoring perspective. There is no real way for you to get this information as a security practitioner or developer man development management to see your entire application. How does it look in the cloud? This view doesn't exist in your cloud. Why? Because the cloud gives you great tools and you can do everything inside your application using serverless and cloud resources, cloud services. But it doesn't give you a whole view of your application because it's your own application. They doesn't know, they don't know the code, they don't necessarily know what is connected to what.
So each service you have to get separately. This allows you also to understand better the security and the security challenges because those resources in the cloud, they are not secured by themselves. You have to secure them. You have to understand how to authenticate, how to secure your configuration to secure infrastructure and secure your communication between them because you don't own the communication between them. So how do you do that? But before driving into what you can do, just some words about what, why serverless different and why we need a new approach. So the architecture as I showed you is different is not monolith application. Not even microservice application where you have, and we saw before the containers talking to each other microservices wise, different, well, they are both in the cloud, the microservices and your serverless resources. But the microservices are containers with images that usually you develop as as a group and as a, maybe even a black box.
But you manage it. Yeah, you don't manage the scale. Maybe the infrastructure, the image maybe is given to you or the base image, but you need to manage the the network. I hope you do because if you leave it as default or unsecure, insecure is a problem. Your network, your your code, your services inside, your processes inside are still managed. In serverless, all of this is taken away from you. So a lot of security aspects are given or taken away from you and are the under the ownership of the cloud provider. For example, you don't have to take care of your operation systems, you don't have to scale. They're auto scale. You don't have to manage your or patch your, your system. Your run time is given to you. All of this is not under your responsibility anymore. Yet there could be problems and you might need to solve it with your cloud provider, but it's not under your responsibility.
So what is your responsibility, your code and the configuration And these aspects need a little bit of a different thinking when talking about security. The cycles, the cycles, development cycles are a little bit different. They are not mon waterfall, but we left that a while ago when we moved to the cloud, but they are not even agile or DevOps. We tend to call it maybe dev SecOps or SEC DevOps or something like this or hyper agile cycles. Because when you use serverless, your developers will ship into production every day multiple times without passing in, many times without passing, passing through security cycles that you did before. So you have to have some automation. The reason for that is that it's very easy to spin up a new Lambda function or a new Azure function and just run it in the, in the cloud. You don't have to make sure or take to have some maintenance or you don't have to make sure it doesn't hurt other components unless you touch other components as well.
But you can put it into production and it's, it is own life into production. So they tend to really just put it quickly in production. And we are too because our product is a server security product but is also 100% serverless security serverless product. And we do ship into production multiple times a day and there is no way security teams can stop development for every function that is comes, comes up to life and we will talk about it. So how can we manage the security? The processes are different. Again, you don't own the infrastructure, you don't have the network, you don't have the visibility that you had before. So usually everything is automated, otherwise it's a nightmare. If you have to go into the console or use API CLI tools to get logs to c debug, to debug your code or to automate your or to check your security is going to be very time consuming.
So everything is automated in the cloud. Usually when your organization move to serverless, the developers use Lambdas also for their development process because it's really easy. They can define something that will just trigger a code when needed, check whatever information needed and send them, send it back to them to their Slack channel, JIRA or whatever channels that they use during the day-to-day operations. Also, the decision making. So I said developer push into production in serverless, many times the decision is given to the developer to do it because it's easy, because it's a small resource and because it doesn't necessarily affect the other parts. So let's talk about the security. What can go wrong when you use serverless? Well, if you, if you have APIs, well APIs connected to your Lambda function, that kind of the same as maybe a web applications, it's a little bit different because the permissions are handled differently.
The configuration of the API is different and maybe the impact is also different because you need to understand the impact. But it's still, maybe the thought about the security could be the same as we used before. So it's kind of a maybe easy to start approaching it. But what if there is an Alexa dot behind it or an S3 bucket or an email? This is a little bit more tricky to secure. And I gave a talk a few years ago at Black Hat and I show how with my voice, I can hack into your application with an Alexa dot. The problem was a code problem in your lambda, but the idea was that it's not always easy to understand the, the attack surface. And after the talk, some people talk came to me and they said, yeah, you're right. I do some things with Lambda which are not connected to APIs, so I didn't think that maybe I need to secure them cuz how do you secure voice commands that they are translated into code, but the translation is owned by your cloud provider, in this case aws.
So you don't really own the traffic, let's say between them. So it's not like you're going to say, record yourself saying some bad things and then play it against your echo dot, right? It's not going to work. So how do you automate the security? How do you secure this at all? Well, you have to understand first that the perimeter in serverless is lost completely. There is no one traffic, one network entry into your servers because there are no servers, well not yours anyway. So you cannot put security into your gateway and control it. You cannot control the network. Sometimes the network or the code will run based on events in the cloud. So the events can be files, they can be emails, they can be statistics, they can be analytics, they can be code commit and all those events, again, they don't, they are not owned by you.
You just put the configuration that says whenever someone sends an email to this address, please run my code. This is the code. But you don't own the email that is, or the, the network, the traffic that comes into the, the, the Lambda. You do not, you cannot secure it before it runs your code. You can only secure it inside your code. So your code should be zero trust and self-protecting. Otherwise, how would you secure your code? You can make some assumptions if the, if you trust the entry point, let's say it's an organizational internal email or maybe it's a, an A blocked, a closed S3 bucket. So you can, but not always. Also there is a permission problem in your cloud. This is very common. How do you set SEC security boundaries or security rules, permissions to your lambda? Well, in your cloud it is very good there.
There is a very good way to make your permission really just what you need, just this privilege. They are very, you can just set whatever you need, but it's very hard to do it. You can do it manually, not easily. Where you can decide what resource and what specific action the code is needed and set this. Imagine this is like a dream come true in your traditional application. You assume that you can say, oh, this part of my application can only read into the right, into the log and this part of my application can only read one entry from this specific database. And even if someone hacks my server, they cannot do anything else other than that. This is a dream come true, but it's very hard to achieve at a good level. Well if you have 20 lines of code and the developer sits on it and understands it, maybe you can.
But how can you scale when you have thousands? 10 thousands, hundreds of thousands? I have customers, we have customers with millions. They say we didn't count millions of functions in their entire organization. You cannot really expect developers to to do it because it's not easy to do and you definitely cannot make security teams do it because one, they are outnumbered by a lot and two, they don't know what the code should do. So it's not really feasible. So we can use tools, right? Okay, we can use tools, but traditional tools don't really apply to serverless for some reasons. And for example, SCA is a great tool. You should use it to scan your dependencies, right? V unknown vulnerabilities that you import, but it's a relatively small part of your code and it doesn't contain your infrastructure. It doesn't have any code coverage and it doesn't have custom code coverage and it doesn't have any context.
So you can use sas, right? Well you can use sas but if you put a SAS on a serverless application, I ensure you, you will get a lot of false positive and a lot of false negative because it doesn't recognize the cloud as your infrastructure. You can have API call to your function, then it goes to a queue, then it goes to another function. There is no way the, the SaaS tool will understand it. Infrastructures code could also be good, but it doesn't have context or code dust. Well if you don't have URLs then it's hard to scan. So maybe is, is is a good tool but it requires a specific solution. I'm done in one minute. What we do is we connect to your cloud and we automate this entire process looking at your infrastructure as code together so you can get specific vulnerabilities for your lambdas. Also, I want you to follow the OS serverless. Top 10 is an opensource project where you can see, see security aspects of your serverless. This is the link and thank you very much. That's it. If, I don't know if thank you to have time for a question or two.
Thank you. We have really time just for one last question. Anyone wants to join the discussion? I really have one last question from my of my own hub. Okay, great. So basically we have learned from your presentation that several functions are a huge risk, right? And the only basically reason people are doing it is because they want to get rid of the infrastructure and your suggestion is to build another layer of infrastructure if you will, security one security. Well, is there any compromise solution where you don't have to actually do
Well? I think serverless is really great. You can get into value, ship value very quickly and developers love it. I don't think it is more risks than other, I think it's a new risk that you should consider because it's a little bit different. Like when containers came, some people proposed security form containers and at the beginning it was not so known. But now people under need to under and understand that containers need security. So they need to also understand that SEC serverless needs security. I just think there is a great opportunity with serverless also for security. I showed it. You can get very granular and very secured, but you need a designated tool for this. Okay, the cloud, you can get this like build your own from the cloud information, but there are also third parties that can help you. That's it. I think it's a, it is a good, a good infrastructure to work or a good technology to work with, but I think people when the organization are moving to serverless need to also take into consideration that some security aspects are different.
Okay, great. Thank you very much.
Thanks.
Thank you Todd for this very interesting present.
