Hi and welcome to the OASP top ten for serverless applications. Securing your application could be a hard task to do if you don't know how. Luckily, we have organizations like OASP to point out the common threats and the right tools, open source tools you could utilize in order to make your application much more secure. Hi, my name is Shlomi. I'm a system architect at JIT, an engineer, an A 200 veteran, and a cloud enthusiast. Let's get started. So what do you do if you suddenly realize that your application is home alone? You need to first map the common threats, the parameter threats, and then understand how top utilize the right tools in order to secure your application. So let's take a look at a common structure of a modern application and first let's take care of the parameter. So let's take a look at different areas that could be problematic. First, you have the CI CD pipeline. When everything flows into your cloud, you have users that access your application. It could be internal users like developers or administrators or your clients themselves. You could use public resources like ips and buckets. You need to make sure they are secure. And if you are using third party services, well of course you need to make sure you do it right. How can you do it? You have different controls you could set in place in order to make sure it's much more secure. You could make sure you have least privileged access, don't give more than you need. You could use multifactor authentication to make sure that credentials are not stolen and then taken advantage of. And of course you need to make sure you don't have different cloud misconfigurations in order to make sure you don't have attack surfaces that could be used against you. So you have different controls that you could use in different areas, like the traffic secrets that you use inside your application and cloud access top services. When something happened, you probably want to investigate it. You are using third party libraries, packages and third party services. And of course you need to make sure that if something happens, you have a game plan in order to recover. So let's take a look at a common modern app and its structure. And let's try to understand first what is the difference between a common app, a common modern app, and a classic app. So for instance, in these applications, in this application, you have users, you have gateways that lead the user inside your application. You may have different public resources like s three buckets in order to serve assets and resources faster. And of course you have your logic running inside the lambda functions. Then you have different databases that you could utilize in order to store the data. So what are the differences between a common app, a common classic app, and a common serverless app? So you have different shared responsibilities. As we will see in a second, serverless functions are mostly ephemeral, which means that it has memory, it has resources, but once it completes its execution, everything is disappeared. Nothing is permanent, nothing is stored mostly. Right. And you have maybe an increased attack surface because as we saw in the parameters slide, you have a lot of different things that you use inside your application, and you also have the ability to have much more fine grained control of the application and resources. So this is the shared responsibility model for a classic application. If you run on AWS, you can see that you need to take care of where the application is located, the hardware, the global hardware, your compute, storage, database and networking. Everything is taken care by AWS. But from that point on, the customer, which is you, you need to take care of it yourself, right. You need to make sure the data is encrypted and also the traffic and addressed as well. You need to make sure that the operating system, the network, the firewall are properly configured and updated. The platform, the application users and identity, you need to take care of them yourself. And of course the data that you store in the databases in a serverless application, well, the model looks a bit different because AWS, if you run on AWS, but it's the same probably for every cloud. The cloud provider takes care of a lot more things for you, right? Which makes you responsible mostly for the logic of the application, and that's a great difference. So let's take a look at a security plan. Translation, what should we do? For instance, if you have a threat that does injection, the solution will be to validate the input to the application and you are going to use a tool like OSAP in order to test the different inputs to your application, find those issues and solve them. So who are the Ospay foundation? What is it? So as we can see, it's an open web application security project. It's an open source, it's nonprofit foundation in order to improve the security of software in the Internet. Right. So they are here to help us in order to make sure our application and services are much more secure. They have a list of the top ten risks for basically different areas, right? And we are going to focus on the serverless top ten risks. We can see the list right here. We are going to go in depth in most of these in just a second. But these are the ten top risks for the OASP serverless. So let's start by mapping them out. So this is the same list, but mapped in categories. So you can see that you have five different threats in your come area. Identity and access. You have two data and then you have log and monitoring. Let's take a look at a few of them. All right, so injection, what is the risk if you don't validate your input? It cloud lead to exploits like SQL injection. How can you secure yourself from something like that? You could validate the data input. You could make sure you don't have too much privilege. If something happens, then the resources, they cannot access other resources. And you need to make sure you monitor and log your resources at runtime to make sure that if something happens, you know about it. So you have different controls that you could use and utilize. We'll see some of them soon. And in order to make sure that you could achieve what we just talked about here. All right, so you are using next one. You're using third party or open source code, right? We all do. We love open source. It makes our job much easier and faster. But the thing is that if you're using an outdated resource, JIt could have known vulnerabilities. But the thing is, because it's open source, it's scanned all the time. And common threats are common. They are known. So if you make sure that your dependencies are updated by scanning the different version of your dependencies and find the common vulnerabilities, you could update them and make sure that all known issues are taken care of. Next, let's talk about authentication and identity access. The risk if, for instance, a credential is stolen, data could be stolen as well, right? And the flow of execution could be broken. So in order to make sure that you are not allowing threats through authentication, you need to make sure you don't have unauthorized endpoints, right. Don't have public endpoints without authentication and authorization that could access data and make sure that you're managing your users correctly. Make sure you use your infra in a central authentication method for interservices. So inside the services as well. If something happens, you need to make sure that the data flow is secure as well. Make sure that all compute services and lambdas, they require authentication in order to make sure you prevent these things as well and verify you don't have any unmanaged resources like s three buckets or IP addresses to make sure that nothing could be penetrated from the outside world. So you could use tools that actually scan your cloud after deployment the real cloud to try to test and find these issues misconfigurations. All right, so access control. If it's broken, data leakage from the cloud, cloud happen, and you need to make sure you protect yourself from that. So ensure you have list privilege for all resources, for your functions, for your databases, and make sure that you don't have too wide privilege. So if something happens, the result is not top bad. You could check your rules of the IM rules and roles with open source tools. All right, so sensitive data exposure. The risk of course is data leakage. So make sure your data is not accessible through public endpoints. Make sure it's encrypted at rest because if for some reason the disk is compromised, if it's encrypted, you're probably good. And make sure the transition of data is encrypted as well. Right? Always use SSL so you could have controls that make sure you don't have unencrypted data. Scan the cloud, scan your code, find secrets and check the transit of your data as well. Security misconfiguration well, you need to make sure you have the proper logging and monitoring because information could leak and attackers could happen. You need to make sure that if something is not configured properly, you need to make sure that you know about it. And you could also check that everything is configured in your cloud properly by scanning it. Cool. So now let's start by talking about some of the available tools that we have we could utilize. The first one we are going to talk about is OASP zap. It's a web security tool. It could can your web app and your API in order to find misconfiguration and vulnerabilities. It cloud find different things like SQL injection. It works with URL and API endpoints using open API. You could provide it a swagger and it will test your API and it will only work for your API endpoints. So if you have async flows, it will not be tested with this tool. We could test it with other tools. The next tool we are going to talk about, it's something that will scan your code and will check the dependencies that you use by scanning known vulnerabilities. In libraries. There are known databases like NVD that you could utilize to make sure that the version of the packages that you use are updated and don't have known vulnerabilities. Secrets let's talk about this tool. It's called Gitlix and it scans for secrets in git, right? So if by a mistake like us, we are developers, we write code. Sometimes we need to debug something and we put maybe a password in order to connect to a service or a database. Oops, maybe we forget it and it's in the code and it goes to Jit GitHub for instance. And once it's there, it's there forever. So first off, you want to make sure you don't have already secrets inside. Of course, if it's an open source project that it's even riskier. You need to make sure that there are no secrets in the code. If you find them, you need to make sure you mitigate it properly, replace the secrets, invalidate them, and make sure and try to understand if something was compromised. And if you want to make it even more secure, you could even use precommit hooks in order to, in the developer's computer, utilize tools like this in order to make sure you don't even push secrets. Top git next we are going to talk about Prowler. Prowler is a runtime infrastructure misconfiguration tool. This is a very strong tool that actually complements the OASP zap we talked about just a second ago. Because if OSAP scans your parameter, your web app, and your APIs, prowling could can your entire cloud. JIt works with Azure and AWS, and it could find misconfigurations in your cloud. You could see that it has roughly 200 checks, probably more by now, multiple output formats, and it also supports AWS organizations. And for instance, if you have async flows without API gateway, Jit will scan those as well, along with a lot of different resources it supports. Next, we are going to talk about Airim by bridge crew. It's a list privilege access tool. JIT scans, IAM rules, roles, policies to make sure you don't have more than you need. It's easy to test that. Think about it. If you have a role with a certain policy, it could check the logs, the cloud rail logs, what was actually accessed, and if it doesn't match it, cloud find issues in your IM rules, right? All right, so after we talked about different threats and different tools, let's try to see how they match together. And let's talk about the different threats that we saw and see which tools could help us out. All right, so injection. What was the risk? If you don't have input validation, it could lead to exploits and data leakage. So the tools that we could use here, we have two tools, one to make sure we do have input validation. If we don't OSAP is going to find that out by trying to attack the API. The other tool we could use is to make sure that if something like that happens, we don't have too wide privilege access. So we could scan using RIM and try top have least privilege access control everywhere in the system. Next, we didn't talk about this threat, but you could use XSe text leveraging old XML processors. So this is something a little older, but you could do the same thing using OSF. Find these issues and make sure you don't use these old versions by make sure your dependencies are updated. Same goes for XSS. So basically you could use OSAP, you could use OszAP in order to find anything that is related to your API or to your web application. It's going to use a wide variety of tests and inputs in order to try to break the application to find these vulnerabilities. All right, so if we are not using secure serialization or deserialization, we could actually have the same risk, the same type of risk and you could use the same tools again, right? We cloud see that the same set of tools give us a wide variety of protection in different aspects. So again, zap will find these issues and the dependency check will make sure that if there are known issues like this, we are going to be protected just by updating to the right version. All right, so this is a bit easier one to understand. We talked about this as well. If you are using libraries and packages of open source tools and packages, they could have known vulnerabilities. We have databases for these known vulnerabilities and tools that utilize these databases in order to find be versions, all versions that you use in your come. So by scheduling a daily scan, a weekly can of your dependencies, you could make sure that you are always protected and you always use the right version, the protected version of the packages that you use. All right, so authentication, especially in the serverless world when you have a lot of endpoints, right? Everything is microservices, everything is distributed. It could happen that you have points that are not protected. So we have two cloud tools that complement each other in order to find these misconfigurations. You could scan the parameter using OWASP, zap and you cloud use prowling in order to find internal things, or maybe async flows in your applications in order to find these issues. So great tools. And by creating scheduled scans you can find a lot of issues in your application. All right, so if you don't have the least privileged access rules, roles policies for the users or the resources that you use, it could be problematic. And we talked about this a few slides ago. RIm is a great tool in order to help you do that. All right, so that was a run through a lot of different risks, a lot of different tools. Maybe it's a bit too much. Let's try to summarize those by looking at the different areas of the application and trying to put tools where it should be protected. So first off, your come when you are writing code, this is the easiest part to understand. When you secure your code, when you write your code, you want to make sure it's secured. You want to make sure you don't have secrets, because maybe you're a developer, you're debugging something, you don't want to push it to jit. You could use git leaks to make sure you don't have secrets in the code. Secrets, environment variables, just passwords, keys and certificates. It will find everything. Then, because we all use open source libraries, we want to make sure they don't have known vulnerabilities. So we could scan dependency checks of these packages using OAS depth check. And of course we could use OASP zap in order to make sure that we don't have broken endpoints. And if we do find that, for instance, if you do not have input validation in your code, you can find it by using this tool. And then you could modify your code in order to make sure that you protect yourself from these issues. Next, when we talk about the cloud, we want to manage identity and access, right? So you want to make sure that you have least privileged access to all the resources in your application. You could use these three tools in order to do that. We talked about OS DESA, which is a tool that could actually scan your parameter, also the web application and also your API to try to find out issues, misconfigurations and vulnerabilities. We then talked about Prowler, which could scan the internal of the cloud, not just a parameter, and find different misconfiguration issues and help you mitigate them. And last but not least, we have rim that will check that you have the least privilege policies that you need in order to make sure that your application is securely tight and secure, to make sure you don't have too wide permissions. Next, we are going to talk about the data, right? Because we need to make sure our data, the customer's data is protected. We could use OSAP in order to scan the parameter and find out if there are data leakages from the application. And we could use tools like prowling in order to make sure that the data is stored securely. For instance, if it's not encrypted at rest, we are going to find things like that using prowler. And the last part, we need to make sure that we know what happens in our application. So if something does happen, we need to know about it. So we need to monitor and we need to log in order to find these issues when they happen and in order to help us first mitigate them, learn from them, do the right research and close them when we find them. So this is an important part as well. And for instance, Paolo could find out if you don't have cloud trader logs in your system in order to know which resource. Access which resource. All right, so let's talk a little Jit about what we do at JIT. We try to leverage all these tools and help you configure it painlessly. So we took it to the next level. We are recommending a plan, a security plan for you based on your needs, based on your applications, and based on the right tools for each of these threats. And we help you configure them and do it for you with smooth and serverless experience in order to make sure you have your application secured without the hassle and need to configure everything to understand what it does and how to do it yourself. Right? So we do it as code, which basically means that you could configure it in any way you want. You could say, I want to secure this, this and that, and we are going to do it for you. You could automate it. If you have different environments like dev staging and production, you could modify it as code, security as code for your needs. And you could scan based on events or schedules, and then you could get the issues, and then we could help you actually understand what these findings say and how to resolve them. Right? It's not just scanning and finding an issue, it's also what do I do when I do find it? How do I mitigate it? How do I make my application much more secure? All right, so now our home alone is much more secure using the OASP top ten for serverless, the open source tools, and we feel much better. So thank you very much for listening and these are my details. You could find me right here. You can scan the barcode and try the application out, see if it works for you as well. Thank you so much and have a nice day.