 Hey everybody, welcome to Cloud Native Security Day's presentation from Checkpoint. My name is Hillel Solo from Checkpoint Security. And what I want to talk to you today about is what we call Cloud Native DevSecOps, which is a long word, which I'll try to explain in a minute. But first, a little background about myself and about Checkpoint. My name is Hillel Solo. As I said, I'm the cloud innovation architect at Checkpoint's cloud CTO office. I've been in Checkpoint for about a year and a half and it came there by way of an acquisition that Checkpoint made of a company that I was one of the co-founders of called Protego. And we were focused in Protego on cloud workload security. So we looked at things like Lambda functions and Azure functions, trying to understand how cloud native security changed in the new serverless world and the world of functions and cloud native containers and things like that. And so we were purchased by Checkpoint a year and a half ago. And since then we've been part of the Cloud Guard organization at Checkpoint, really trying to drive forward how Checkpoint helps customers solve cloud security challenges. And Cloud Guard is a big suite of products from Checkpoint that deals with everything from cloud posture, workload security, analyzing logs and looking for anomalies and so on and so forth. And our serverless piece is now part of that environment. So I've been in Checkpoint for about 18 months. I've actually been in this room for about 13 months. So I'm really appreciative of the opportunity to find a reason to put a shirt on today. So thank you. And if there are any questions afterwards, if you're looking for me, I'm H.Solo at Checkpoint.com, feel free to reach out. So what I want to cover today in a really short time slot. And so I apologize for how quickly I'll speak. Is first of all, what is DevSecOps? Why DevSecOps? Why is it my problem as developer? And I'm really primarily talking to you developers out there and trying to convince you that security is your problem. It's not someone else's problem. So why is DevSecOps a thing? What do we mean by that? And then why do I claim the cloud native DevSecOps is a different thing or an evolution of that thing? What's different about it? And then finally try to give you some tools and tips and technologies to how you can try to solve that problem and own it. So focusing on what DevSecOps is to me, DevSecOps is it's the philosophy that as a developer, I own security just like I own any other feature of my product. Security is just another important product feature making sure that my product works securely. It's just as important as making sure my product works at scale or any of the other non-functional requirements we tend to think of when we think of a product. And the idea that till now, security was something else that someone else's problem is kind of a silly thought really. It doesn't really work all that well and particularly as we move into more modern applications it's really challenging to stick with that paradigm. And so DevSecOps, and really I'd like to just call it DevOps to be honest, is just saying security is yet another part of the functional and non-functional requirements for our application. It means that we as developers are responsible for deploying and operating secure applications, right? Once you own that, once you say, okay, it's me. It's not somebody else's problem. I'm not helping them. It's my problem. Maybe they're helping me. Well, that changes a lot about what you feel like you have to solve, right? So security teams are still there. They're still there to help you. They're still there to provide guidance and tools. They're still there to look at the overall security posture of the organization. They're gonna worry about your on-prem and cloud network security posture and things like that. But when it comes to product and application security, that's you. That's part of your product. It's part of your application and your responsible for it. And what that means is things like making sure that you do code scanning to look for mistakes that your developers are making and things like that and make sure your application is being deployed securely. Make sure you've got an operational regime that gives you security and protects you. And so that's really DevSecOps is just saying, hey, security is your problem, Mr. Developer. Now let's see how you address that. But I think that was last year's revolution or two years ago's revolution. The thing I'm really trying to convince you of today is that cloud native DevSecOps is equally your responsibility, if not more, but also it's a slightly different thing. And so why is it a different thing? So first of all, when you move to cloud native, you, the developer, you own controls for security that you perhaps didn't own in the past. You are responsible for things that make a huge impact on security that were somebody else's problem several years ago and are now your problem. Things like network configuration, VPCs, IAM role configuration, RBAC things like that, monitoring, logging, all of those things are things that you are operating and deploying. You're deciding on your controlling and they have a huge impact on security. And so it's really, really crucial that you're looking at that and saying, okay, if I'm responsible for product security, if I'm responsible for making sure that my thing is gonna work any hour, any scale, no matter what the attackers are doing to it, that means I'm responsible for making sure that IAM roles are configured correctly. That means I'm responsible for making sure workloads are in a VPC if they need to be and that the security groups around those things are correct. That becomes my responsibility. So part of it is that you now own things that you didn't own in the past. A big part of that is your infrastructure is code revolution. The fact that all the infrastructure in the cloud can be managed as code and as part of your code repository gives you incredible velocity. You love it. I know you, I love it as a developer and I'm sure you love it. Yes, it means you're responsible for more things but it means you can change those things as you need them to be. You don't have to call somebody and ask them to provision a machine, just provision a machine. You don't need to change around network configuration through somebody else. You can just go do that in Terraform script. That's really powerful but it means that all of that configuration is yours. And I've seen studies that claim that up to 90% of cloud risk comes from that misconfiguration. Now that's really scary because it means a mistake that you make can have a huge impact but it also means you have the opportunity to do it right. So if you plug those two things together it's my responsibility and I have the opportunity to do it right. Well, that really gives you a path forward, right? And the second thing is that there are increasingly a large number of tools out there that can help you do that. There are tools to help you scan code, there are tools to help you scan infrastructure as code and Terraform scripts and cloud formation. There are tools to help you scan container images. There are tools to help you with monitoring and logging, et cetera. And so those things are at your disposal to help you solve this problem but step one again is identify that it is your problem to solve and that you're responsible to solve it. And so then what I want to finally take to that is well, what are the pieces of this that we need to do? So the pieces that you want to think of first of all, all the scanning things are really important but now you need to make sure that I'm using tools to scan my infrastructure and scan my code for cloud problems. So for example, if I'm scanning deployment scripts, Terraform, cloud formation, those are cloud constructs that I need to scan. I need to scan those things in the context of a cloud environment. How do I make sure that my cloud formation template is going to deploy something with the least amount of risk? How am I going to make sure that my Terraform plans are all deploying things that minimize my risk, right? And so there are tools out there to do that and those are things you need to be using. The same is true for IAM roles. IAM role lease privilege is super important in the cloud. It's perhaps one of the most important things you can achieve. It might, don't tell me, don't tell anyone to check on this but it might be more important than network security. Getting IAM roles properly configured into cloud at least privilege may make your risk diminish more quickly than getting your network configuration correct because today increasingly we're talking about sort of zero trust interactions between resources and workloads and things in the cloud and then network is important but it's not the most important thing. The cloud fabric is using things like IAM and RBAC to ensure that only the things that should communicate do communicate in a way that they need to and you doing that configuration correctly is going to make a huge impact on security. So getting those things right are really important. And then of course making sure that all of the operational parts of the application are secure as well. So making sure your login is connected to something that can analyze it for anomalies and find problems and you're looking at things in runtime and not just relying on the fact that you rely deployed it securely, it must be okay. It's not dev, it's dev ops and make sure that the operations piece of it is really properly done for security as well. And then finally what I wanna leave you with is a couple of things or a few more, a few things that Checkpoint provides today where we're starting to really try to look at you the developer as one of our customers and figure out how we can help you do your job better. And again, let's agree three slides ago your job includes security. Now how do we help you do your job better? Traditionally things like Cloud Guard are aimed at security people with their dashboards and their integrations and their JIRA notifications and their Slack and all that's great and you can leverage some of that stuff but you need to find tools that meet you where you wanna be. So for example, Checkpoint source guard product is a new tool that helps you do source code scanning in your repositories and pipelines so that you can look for things like developer error you can look for third party components that provide risk, et cetera. The shift left component which is part of the Cloud Guard suite allows you to do that through the source guard system but also allows you to scan container images allows you to scan infrastructures, code templates scan your staging environments if you have them to make sure they're compliant before you deploy to production allows you to do all sorts of other useful things around security. And then there's a serverless piece as well within the Cloud Guard family that allows you in CI CD again to protect serverless functions and workloads automatically during deployment to aim for least privilege really tightly and automatically so that as a developer I don't have to go try to read through hundreds of pages of documentation to figure out what least privilege is but rather I get to home in automatically on least privilege for my workloads and then also what we call no code runtime security so the ability to deploy without having to modify code add all sorts of hooks inside my code deploy runtime security in a way that as developer I can understand and manage but I can do it automatically in the pipeline so that's again part of the serverless workload and capabilities of Cloud Guard. So these things and others from Cloud Guard and again I know that I'm using Cloud Checkpoint as an example because that's where I come from there are a ton of things out there there's open source and sort of other products these things are all your friends and will help you drive to more secure deployment in the cloud something that is now your responsibility. So thank you very much for the opportunity to present that today. Hopefully I got the message through by saying enough times that cloud security and product security is your problem and hopefully you see that there is a path forward to creating and deploying more secure applications.