 Okay, so thank you everyone for joining us. Welcome to today's CNCF webinar, securing your serverless journey. I'm Sanjeev Rampal. I'm a principal engineer at Cisco and I'm also a CNCF ambassador. I'll be moderating today's webinar. We would like to welcome our presenter Ron Harnick, who is a senior product marketing manager at Prisma Cloud by Palo Alto Networks. A couple of housekeeping items. During the webinar, you will not be able to talk as an attendee. There is a Q&A box at the bottom of your screen. Please feel free to drop your questions again. Note, please do not put your questions in the chat window. Please put them in the Q&A window. This is an official webinar of the CNCF and is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be respectful of yourself, your fellow participants and presenters. With that, I'm going to hand it over to Ron to kick off today's presentation. Thank you so much. It's good to be here. Thanks for the opportunity. Yeah, so just a little bit of context of what we're going to be talking about today. We're going to be talking about an introduction to serverless security. So we'll discuss a little bit about what serverless is at a fairly high level just to make sure that we're all on the same page. And then we'll get into what are some of the risks or some of the things that you have to think about differently when you're trying to secure serverless workloads. And then at the end, we'll do a fun little demo just to understand how one might carry out a serverless attack. So just real quick about myself. So my name is Ron. I'm part of the Prisma Cloud product marketing team. Prisma Cloud is the cloud native security platform from Palo Alto Networks. So over the past 10 years or so, I've been in the IT and networking and security and cloud space moving around between all these different companies. I started out as network engineer and then slowly moved through different roles within the engineering organizations and product before I eventually sold out and moved to a marketing role. So I was with PureSec, the serverless security platform that was acquired by Palo Alto Networks, I think just over six months ago. And then I got the opportunity to join the Prisma Cloud product marketing team. So even though now I get to talk about cloud native security as a whole, serverless is still something that I'm very passionate about. So I'll take every opportunity that I can to yell at my laptop about serverless. So thank you for giving me another one of those opportunities. I live in Israel with my wife and my two beautiful twin girls, which I'm obsessed with throwing a picture of them in everything I do. So here's a picture of them now. All right. So let's quickly go over the agenda for today. And just like we said at the top, please feel free to send your questions through the Q&A panel. I'll try to get to most of these as I go along. But if there'll be any unanswered questions by the time we wrap up, we'll try to get to those in the end. So we'll start off by covering what serverless security is in a nutshell at a high level and make sure that we all understand just generally how a function based application works. We'll focus on a few risks and pitfalls. Obviously there's a lot that we can talk about and we can even broaden the discussion to cover application security as a whole. But we'll very much focus on function based applications and we'll take a look at a few of the things that you need to be on the lookout there. And then we'll wrap it up by doing a quick demo of how we might carry out an attack. You know, I'll tell a fun little story that happened to us while we were at PureSec that I think really helps illustrate the importance of permissions on functions. So yeah, should be a good time. Okay, so the first part of almost any conversation that you have about cloud security, not just serverless security, almost always starts with this idea of the shared model of responsibility. And I'm sure most of you on this webinar have heard this a million times. When you move to the cloud, when you start using something like Google Cloud Platform or AWS or any other public cloud platform, the shared model of responsibility at its simplest form divides into two. The cloud provider is responsible for the security of the cloud. So that is anything like the data centers themselves or anything underneath the virtualization layer that you care about. And you as a user, you care about the security in the cloud. So everything that you put into these workloads, so your code, the user permissions into into these workloads, things like that. With serverless, there's an interesting shift that that happens within that model. So when you're talking about infrastructure as a service, you're essentially taking a lot of responsibility to on you're taking basically a big part of that pie as responsibility for yourself. You own pretty much anything that sits above that lowest level of virtualization. So anything beyond, for example, like an EC2 instance is completely your responsibility. So fixing patches in your operating systems and scanning your images for vulnerabilities, all that kind of stuff, preventing data leaks is completely your responsibility while the cloud provider really only cares about the physical infrastructure and the configuration of like the underlying infrastructure beneath the virtualization. When you go serverless or when you start, this is offset a little bit, sorry about that. So but when you adopt more of a serverless framework, there's something really interesting that happens to the split where the cloud provider actually takes on a lot of responsibility and you take on less responsibility when it comes to what is left to secure. So it almost ends up being like this 50-50 split. And it's interesting for someone in my position because working for a security company, typically you would go up on stage and you would talk about this scary new technology that you have to do all these things in order to leverage successfully. While with serverless, the conversation is more like you just have to think about a few things differently, but your starting point in terms of security is actually pretty strong because now you don't have to think about patching your operating system. You don't have to think about networking or a big list of other things that you used to have to worry about. Obviously there are new attack vectors and new things that you have to worry about and most of the things that are relevant to application security as you know them today are still going to be relevant and that's exactly what we're going to be covering today. So just to make sure that we're all in the same page, I try to make this as accessible as possible to folks who are veterans with serverless and folks who are new to serverless workloads and even the term serverless can be sort of like a point of contention in terms of what it actually means, but for the sake of our discussion today, I'm talking specifically about applications that are based around functions. So around function as a service, services like Lambda or Google Cloud functions, for example. So typically how these applications would work is something like this. You would have a developer commit code to a code repository and then that code will go into a function. For example, an AWS Lambda function. Then that code would sit there and it would wait to be triggered by some sort of an event. So some sort of an event will happen. It will trigger this piece of code. Then the function will do whatever it is it was designed to do. Maybe it will interact with another cloud resource or maybe it will just have some sort of output. For example, in a little bit we'll be covering a serverless application that is essentially used for HR for hiring. So someone sends an email with a PDF resume attached to it. That gets intercepted by a cloud service that then triggers a Lambda function and then that Lambda function takes that file, converts it to text and puts it in database table. So roughly follows the sequence of events that we're seeing here. The core of serverless or the core of these types of function as a service tools that you can use is that typically this will be a very small piece of code that represents a microservice. It will usually not be some massive monolith of code. It's very much towards the cloud native approach of adopting microservices because these functions will typically be short lived. So they'll typically live for only about 15 minutes. So it's really not a discussion of should you go 100% serverless or should you evolve from, for example, containers into serverless. It's more of like a spectrum. A spectrum of compute options where you might have your virtual machines on one side and you'll have something like Fargate or Google Cloud Run and then you might have something like Lambda or Cloud Functions. And every different tool is going to be good for different types of jobs. All right. So if we agree that this is a good baseline for how an application looks like when it's based on functions, let's talk a little bit about what are some of the attack vectors or attack surfaces that we need to talk about. And most of these are going to be familiar to you if application security is something that you've been interested in. Okay. So let's say that this guy is our attacker. Let's focus on what ways, not what what the actual risks are, but what are the paths that he could possibly take in order to compromise our application. So the first and maybe the most unique to serverless that that we need to take a look at is event data injection. And I'm sure we're familiar with injection attacks like SQL injection, for example. But with serverless, you have to remember that there are thousands of event sources that you could potentially use in order to trigger your function. So it's not necessarily going to be an HTTP header that we can be very familiar with with the fields and the cookies and the different parameters within there, but it can be an S3 bucket or it can be a Kinesis stream or, you know, any of those types of things. Each one of those event sources is going to have its own structure in its own format of how it conveys information. And those are things that could potentially be manipulated in order to compromise the function. Another would be unauthorized deployment. So this would be, for example, a phishing attack where someone was able to deploy code out of band directly into your Lambda function, for example, because they got the credentials to your AWS account or anything in that way. Something that's going to be less far fetched and much more common, not just in serverless, but in application security in general, it's going to be dependency poisoning. And dependency poisoning, really what we mean here is, you've used some sort of open source third party library within your application within your code. And there's a vulnerability, a CV or something else within that NPM package or whatever that dependency might be. And this is exactly, or at least part of what the whole discussion around shift left revolves around, like you have to be able to detect vulnerabilities as early as possible in the lifecycle to make sure that they don't make it all the way into your production environment serverless or otherwise. So that would be something to look out for this vector. I just want to add dependency poisoning. It's something that is that exists as an attack vector in pretty much all forms of application security, specifically with serverless, the challenge is going to be how do you detect that? And what can the attack were actually do if they compromised your function? And finally, the last vector that I want to talk about is tampering with data or really compromising the cloud services that your function interacts with. So a typical function based application or serverless application is not going to be made just out of functions. You're going to have maybe a storage bucket talking to a function that's talking to a database table and maybe that is talking to another function, or maybe you have a website where you have multiple different functions doing the login or one is loading the pictures and one is storing all the user data, whatever it might be, there's going to be interaction to a lot of different sources within that process. If one of those other services gets compromised, then that entire application could get compromised. And that's actually exactly the example that I'm going to walk through in just a little bit and a little story that we put together for you. So I think the most famous example of this is S3 buckets that are open to the internet. So maybe your function itself is locked down tight, but it stores lots of data on an S3 bucket that is open to the internet and then an attacker might be able to compromise your function through there. What can an attacker actually hope to achieve with these types of attacks? Well, these are typically the same things that you will find with typical application security. So they might be able to compromise data. So for example, let's say that you have a function that's talking to a DynamoDB table. If that function has permissions to essentially do whatever it wants with that DynamoDB table, once that function is compromised, then the attacker will be able to exfiltrate data from the DynamoDB table that they're talking to, which again is relevant to the example that we'll see in a little bit. So this is just a quick overview of some of the vectors that you might need to look out for with Serverless. So what can you do to educate yourself about this? So one thing that I would definitely, definitely recommend is to read this white paper from the Cloud Security Alliance. This is something that a lot of different experts from different companies came together and put this together, definitely not product related. So it's not a product pitch for any specific product. It focuses on functions. And it's essentially the OWASP top 10 version for Serverless. So this white paper, which is very long and very exhaustive, I would still, if you're considering Serverless or using Serverless, I would very much recommend that you go through it and read it. Just because it goes into much more detail, then we'll have time for today for what are the attack vectors that that you should be worried about or should be on the lookout for? What can you do to hard view your applications? And it also just has a lot of really great insights about how function as a service tools work. So I cannot recommend this enough. And this was done by the Cloud Security Alliance, which is a fantastic organization. All right. So if we kind of likened the security on serverless application to applications to applications security in general, let's talk a little bit about what why we need serverless security or security that is specific or purpose built for serverless. Well, with traditional security, you're essentially protecting applications with tools that are being deployed on servers or networks. With serverless, you don't have access to any of that underlying infrastructure. So for example, if you have that S3 bucket that's talking to your Lambda function, there's nowhere for you to put a firewall between those two. If you're only using something, for example, that looks at an API request at the HTTP headers, that's only going to cover a small percentage of the things that could trigger your functions. So that is typically where you have to think about this a little bit differently. So with serverless, the application owner doesn't have any control over the infrastructure. So traditional security tools, I don't know if traditional is the right word here, but traditional security tools are unsuitable to secure 100% of these types of environments. Having said that, I'm very much laser focused on serverless for this conversation. It is important to remember that in most environments, it's going to be some sort of a hybrid, right? You're going to have your serverless applications, you're going to have your containers, you're going to have your different, your GKEs and EKS and Fargate and your actual VMs. So security is a much broader conversation, but specifically about how do you secure, for example, a Lambda talking to a DynamoDB table? Yeah, you're not going to be able to do that with an agent deployed on a server or or with something that inspects anomalies on the network. Let's take a look at how typically you would protect an application. You might have your application code and you might have something for endpoint protection that takes a look at the behavior of the application itself. Maybe you'll have some sort of IPS type tool that takes a look at network anomalies. You might have a secure web gateway that takes a look at outbound traffic or you might have some sort of firewall that takes a look at inbound traffic and you'll have maybe even an external firewall taking a look at your your layer seven traffic and all of this goes on your infrastructure. So this is a, you know, a 360 view of how you lock down that application very, very tight with serverless. Pretty much all of this goes away and your functions essentially live on the internet. And that's something that you have to be on the lookout for, right? So and this is where to me the conversation about serverless security gets really interesting because the code that you're deploying, it doesn't live within a container. Well, technically it does, but I mean, it doesn't live within some sort of structure that you deploy to the cloud, but it lives directly on AWS or Google or Azure or wherever is you're using your fast server. So with that, the entire concept of security is pretty much reduced to strong code and strict configurations. So what can each function do? What permissions does it have? Obviously, there are other tools out there that that you can use in order to take another step. But those are those become the two strongest components of serverless security. So I'd like to take a quick break from just trying to reiterate the same point over and over again about the difference between serverless and traditional applications. And I'd like to go through a story that I think does a really good job at illustrating the importance of permissions with serverless applications. So this is something that happened while we were at pure sex. So this was before the acquisition and we just thought it was a fun story to share. So this guy, Caleb Zima, who I think is with Capital One now, he essentially put up this website called lambda shell.com. It's no longer up. But what he wanted to see is is serverless insecure? Is a tool like Lambda, for example, is it a security risk? Let's find out. So he threw up this website, he put a shell into the application on the website, and he said that if someone is successful with hacking into this application, they'll give them $1,000 bounty. So our CTO at the time, Ori Segel, this is him, saw this and essentially he was like, okay, challenge accepted. So Ori is now with us at Palo Alto Networks, leading a product team. But at the time it was the CTO of pure sex. So we saw that he said, maybe this could be some good PR for us. Let's go ahead and do it. Okay, so the first thing that he wanted to do, you already have access to this shell, right? So from remote code execution, essentially like the holy grail of application security, he thought he was most of the way done already. So the first thing that he tried to do is to get the environment variables and all of this is no longer online. So that's why we have no problem, you know, putting this on a public webinar. But he tried to get the environment variables from the shell in order to try to impersonate the Lambda function. So he exported the secret access key and the access key to his own machine. And then when he did SDS get color identity, essentially, he tried to check how does AWS, how does AWS sees me as the role of this function. He saw that he actually assumed the role of this function. So he effectively impersonated the function itself. So in his mind, he was essentially in like he did it. So right after that, Ori was walking around on the smartest man alive. This is awesome. He was genuinely very, very happy. Afterwards, he tried to playing around with the I'm permissions a little bit. So he tried to list the different functions. He tried to run a few commands. And he saw that he failed miserably. Now, this is interesting because he got access to where the code is, right? He got access to the function. So in any other form of application security, that could have been game over. But because there was a strict I am profile around that lambda function, then he wasn't able to really do anything other than what this function is supposed to do. So there were pretty strict I'm permission. So it's, it's kind of, it kind of reduced the blast radius around that function. If that makes sense. So again, he tried to do a few more commands to see if if he has the permissions and he kept getting these access denied. So at this point, he was pretty bummed out just like moping around the office because, you know, at a startup, you have to move fast and you have to constantly be delivering stuff. It just like breakneck speeds and he was wasting, you know, like a couple of days on it. It was not a good time at the office. Then one of our researchers suggested that there's, there's probably an S3 bucket involved. Just, and typically best practice is usually to use the domain name for the name of the bucket where you host the files for it. So he ran this command head bucket and he saw that he didn't get anything in return. And essentially what this prompted him to think is, is this some sort of quirk of AWS or maybe there is a bucket there. And, and maybe so because he saw that he was not getting an error or like a permission denied. So he tried a few times. He tried to do the same command with just another random domain name. And then he saw that he did get the 404. So this confirmed from him for him that this original bucket does really exist. Okay, so he was able to list the different objects within there. And he saw that he did gain some, some sort of access into this S3 bucket. And his next step was to see, do I actually have right permissions? Can I actually do something with this bucket? So maybe he was a little bit drunk off of the champagne that he had earlier. But his first idea was to delete the index HTML file that he found there, which of course, immediately crashed the website. And again, this is interesting because the function was locked down tight, but the S3 bucket wasn't. And we talked about this a little bit earlier, how you have to take a look at the permissions that wrap around all of the different components of a serverless application. So after this, he immediately got a phone call from from Caleb. And Caleb was at the time, I think it was either Defcon or Red Hat. But he was in Vegas at a conference and he was talking about this and showing the website and we completely crashed it for him. But we were able to take the website down before any of our competitors could, which was fun. But we never did get that thousand dollars. So a key component in that story, one of the main characters there was I am identity and access management. Typically, that's the way it's called across all the different clouds. Most of my examples here were on AWS just because that's where most of this happened. So let's talk a little bit about what you can actually do in order to leverage I am to secure these types of applications. So the challenge with the least privileged approach, which is I think pretty unanimously the best approach you could possibly have with with serverless or with functions, it will essentially mean that you want each function to only be able to do the very least that it that it can or just exactly the task that that it's supposed to do and nothing else. So for example, if you have a function that all it's supposed to do is to put files in a DynamoDB table, then that should be everything that that function is allowed to do. The model around around I am is extremely powerful. It just it's hard to get right. Because what do you do when you have thousands of different functions, right, it gets challenging at scale. So the problem typically is introduced with the human factor and it becomes very tempting to use that star button, right, a wild card in your permissions that essentially will give a function complete permission into whatever it is that that it's interacting with. The issues around functions having more permissions than they should are probably the most common serverless security issues that we're seeing out there. Obviously, serverless is still on the rise. It's still something that is in the middle of adoption. It's not as mainstream as containers just yet. But I mean, with the rate that tools like Google Cloud Functions and Lambda have been growing, there's no doubt that it's on its way. So for example, if all the function actually has to do is to put items in a DynamoDB table, but with the permissions you see here, there's a star. It means that if that function is if that function is compromised, it means that that DynamoDB table, regardless of of its own permissions, will definitely be compromised. So when I do this session live, I like to do a quick quiz at this point and talk about how we how you can kind of name and how you have to know how to name and spell the correct iron permissions. Obviously, we're not going to do that here. But what we typically talk about is how do you spell the exact permission to put item for DynamoDB? Because the permissions when you're talking about what the function can do and what a user can do, they look a little bit different. So you have to make sure that you read documentation and that you use the correct right, the correct form. If you do end up giving your function just a wildcard and the permission, just a total permission to do whatever it needs to do with that DynamoDB table. This is everything that it will be able to do. So it will be able to completely annihilate that DynamoDB table. And I just keep using the same tools for this example, because I feel that if I'll start mentioning millions of different tools, it might just get too confusing. So I'm sticking to Lambda and DynamoDB just because that's the example that we'll be looking at. So you can take you can think about I am permissions kind of like bulkheads in a submarine or on a ship, right? Even if the function itself or whatever service that that I am profile is wrapped around, even if that gets compromised, the blast radius is pretty much contained, exactly like a bulkhead on a submarine, that function can only put more stuff into that DynamoDB table. It's not ideal, but it's better if that function was compromised, and it had just a wildcard in the permissions, it's better than you know, that table being completely compromised. Okay, so a few quick tips for getting I'm permissions right. So like we said, trying to adopt a role per function model where you have a specific role for each function that only gives it least privileged exactly what it needs to be able to do. Think twice before hitting shift eight, the eight here is missing will pop up here in a little bit. Sam managed policies are your friend. There's an example for this as well. And there's an equivalent with serverless framework for this as well. So here's an example of what not to do. Amazon DynamoDB full access just the equivalent of putting a star in that profile. Here's a better thing to do where you only give crowd permissions to one specific table. And here's the even better thing that you can do. Give the give your function just a very specific action that it should be allowed to do for each for each function. There is a free least privileged I'm automatic role generator, which is an open source tool that that you could use. Still available for now. I'll link it a little bit later. But it's still it's still out there for now. So I'll have a link for that at the end of the slide. Alright, so before we wrap up, let's take a look at a quick example. And I think this would be a good way to a good thing to end on. Let's take a look at a sample application that we have built out as an example for how you might carry out such an attack. So we have this CV filtering system this HR automated application that we've built that is completely based on serverless tools. So lambda and other abstracted services from AWS in this case. And essentially what it does a candidate will send an email with a PDF attached to it, a resume that will get intercepted by simple email service and they'll get a receipt back just an email back saying like, Hey, we got your resume thanks. And then that triggers an SNS queue. And sorry, an SNS topic. And then that topic will trigger a lambda function. All that lambda function does is essentially it receives the PDF, it converts it to text, and it stores it in a Dynamo DB table. If you've been following around this presentation, you probably know where this is going. But this is the application that we have here built up. So let's let's take a look at it. So I have this Gmail account open here. Since this application rests on essentially receiving emails with PDFs attached to them. So there's no kind of web portal for me or like web page for me to attack. So first, let's see that the application works as a chip. So in the subject, let's say my CV. This is my CV. And let's go ahead and attach my johnsmith.pdf file. So I'm going to send this over and the application will work as we as we saw it illustrated the the file will get intercepted by simple email service. It will talk to SNS. It will talk to lambda and will do the whole things. And in about 10 seconds, we should get a receipt back. So here it is. Thank you for contacting us. One of our recruiters will contact you shortly. Great. The application is working as expected. Now let's say for the sake of discussion that I did not get the job. And now it has become my sole purpose in life to destroy this company that didn't give me the job. So I want to do a bit of reconnaissance, right? I want to understand a little bit about this, this application. So let's try this. HR email again. And once again, let's say this is my CV. And this time, essentially, if you think about it, I don't really have a lot to work with here, except for the name of the file. So obviously, there's there are a few more steps of reconnaissance that we might be able to do, but we don't have too much time here. So so you'll have to trust me that we fake did a few more steps of reconnaissance. But what I'm trying to see as the attacker here is, can I affect the code? Can I do like a code injection attack into this application? So essentially, will I be able to pass this command into the code of the application? Does it accept user input as is? So I'll attach this. And I'll say this is my CV honest. And let's go ahead and send this again. Now, we're not going to wait 5000 seconds to see that we're not going to get the the alert back, the the receipt back, you're going to have to trust me that we won't, because the function will time out. So once I've done this, and I saw that okay, I do have a path into the application, I can go ahead and start my attack. And the way that I want to start this attack, and this is really interesting because, again, the code rests directly on AWS with this case, because it's lambda behind the scenes. So let's say again, my CV. And here, let's say, how could you? Let's attach another one of these files. And you see that now what I'm trying to do is I'm trying to curl a script from past been into this application. And essentially, what this script will do is it will try to read the application code and send it back to me over email. So I'm going to head and attach this, let's send this over. We can actually take a take a look at the code in the meantime. So this is that code. This is what I'm trying to do. I'm trying to read the application code. And then I'm trying to send this back to the email address. Let's see if we're getting anything back. Should be getting something in a little bit. And here we see that that we did get first, another receipt. So this is the first receipt that we got and we got another one. And second, we see that we got the function code. Let's see what we got here. So this is the actual code of the function. This is really what I'm after. Let's say that I'm going to exact my revenge in the form of data leakage. I'm going to steal the data from the other candidates. And I'm going to, I don't know, sell it. I don't know what you do with it. So I can see that there are some security practices in here. So for example, I see that they're checking that the file ends with thought PDF, which is okay. But I'm also seeing that they are accepting essentially user input here. So everything after the colon, like it was John colon, and then I curled the script there, is essentially accepted into this code. And I'm able to execute that. So this is what I'm interested in. I can see that there's a DynamoDB table. This is where if all the permissions that this function really had was to just put items in this DynamoDB table, there isn't too much damage that I would have been able to do. Maybe I would have been able to like crash the function or like time it out or do some sort of small like DOS attack. But I wouldn't wouldn't have been able to steal the database, which I will be able to do now because I'm going to send one last email, I swear. And let's just say full on villain mode. And let's attach this final file. And this is just again, another pacepin script that essentially what it does is it reads, it scans the DynamoDB table, and then it will exfiltrate it. We can actually take a look at that script as well. So we can take a look at it here. Essentially what I'm trying to do is I'm trying to scan the DynamoDB table. And then I'm trying I want to exfiltrate that data, dump it back into the email, send it back to me here. And we see that we actually did get it. So I got a DynamoDB dump. This is all the information from in there with all the emails and personal information for lots and lots of candidates. I think the most interesting thing here is that this is not a vulnerability of AWS or Google Cloud or wherever you run the function. This is a vulnerability in the code that that the developer wrote in this case, it's us, but this is something actually pretty common. It's because the code is running directly on the cloud platform and the vulnerability in the code itself that we were able to do this. So if you think about it, in this case, AWS didn't do anything wrong, right? Because the function has permissions to read its own code and to export it and it has the permissions to do. And it had the permissions to read the DynamoDB table. So if you take a look at your CloudWatch logs or CloudTrail or anything really, you're not going to see anything out of the ordinary. So it just illustrates the importance of having type permissions around your functions. And obviously there are tools out there that you can use to take security to the next step. But at the most basic level, that is something that you're able to leverage as well as just being aware of the importance of having strong code. All right, so just the last thing that I want to wrap up on in terms of taking action and maybe getting more familiar with this. So once again, I cannot recommend enough the 12 most critical risks for serverless by the Cloud Security Alliance, great, great white paper, very educational for you to go over, read what are the risks, be aware of them. At least some of them are obviously more advanced, but the first few ones really are the ones that you need to watch out for. You can also take a look at the OASP serverless Goat application. There's a link for that up here. That is essentially just an application that you can deploy, attack, play around with and press your friends at parties with your serverless security skills. And finally, there is a least privileged CLI tool. It's currently still available. I'm not sure if it's going to be there for long. So you might as well grab it. It's not the end all be all of I am security, but it's a tool that you can use in order to generate a baseline for a least privileged I am role. So that's definitely something that that you can take a look at. So with that, I'd like to thank everybody for joining us today. And thank you for the CNCF for having me today. I hope this has been useful. That's awesome. Thank you, Ron, for a great presentation. We still have a few minutes for questions. If you have a question that you'd like to ask, please drop it into the Q&A tab. I'll kick one thing off here. Ron, you mentioned that the function had permission to read and export its own code. Is that common? Or is that unusual? So it's, I mean, you have to remember that unless you you deny something, then the function will be able to do it. So in terms of being able to inspect its own code, yeah, that's going to be the default behavior. And those are going to be the the things that you're going to have to watch out for, either with governing them with IAM profiles or finding other ways to block those types of command injection attacks. Got it. Thanks. Looks like Chris had a question. Yeah, so there's a question. What protection does PureSec offer for serverless in context of Prisma? So I don't think we can get to product heavy here, but just for at a high level, PureSec is now part of Prisma Cloud, the Planetary Security Platform, along with Twistlock and RedLock and the other companies that got acquired recently. All of the capabilities in there are all the capabilities from these companies have already been integrated into this tool. And in terms of serverless security, then you can definitely use it in order to detect and block the command injection attacks, behavioral protection for your functions to prevent it from running processes it's not supposed to, as well as getting a very high level of visibility into the permissions of your functions. So a lot of cool stuff that you can do in there for that. But we have a lot of good resources for that online. So we have another question. How does the security policy get stored and applied? Is it via S3 bucket? So the security policy for individual functions, if we're talking specifically about the native tools that you have out there with, for example, with AWS, it will typically be an IAM profile that you assign to the function. So you don't necessarily have to store it in an S3 bucket. If you're talking about other tools like Prisma Cloud or typically or other security tools, then it will typically be some sort of wrapper around your code. So when your function, when AWS invokes your function, so instead of calling your handler, it might call our handler, so we'll be able to inspect the event data. So that will typically be part of it. And the other part will be an authentication with the AWS account to be able to do vulnerability scans and things like that. If I can give any thought, another question is, can you give us any thoughts about security as it relates to alternative serverless systems like OpenFast? I think, so personally, I don't have too much experience with with OpenFast, but I think that it's really different once you're talking about something that that you're essentially deploying, I don't know if on-prem is the right word. The security of the underlying infrastructure is still going to be something that's going to be your responsibility in that case. You're still going to have to worry about the same types of things. If you're, for example, just handing these functions to developers, you're still going to have to worry about the strength of your code. And I'm not sure exactly how permission governance works within OpenFast, but I would imagine that that is still very much something that you'd have to look out for. But I would say that the biggest difference is going to be that you're still going to have to worry about what sits underneath while with public cloud, which again is just where I have some personally more experience with serverless tools. That is something that is just not even on your radar. So for example, the the networking or the operating system, like those things are there, but obviously they're not on your radar. I hope that makes sense. Okay. Any more questions? I think that about wraps it up. So great. Thank you, Ron, for a great presentation. Thank you everyone for joining us today. The webinar recording and the slides will be online later today. We look forward to seeing you again at a future CNCF webinar. Have a nice day. Goodbye. Thanks, everybody. Bye.