 Thank you all for joining and as Ken has mentioned today, we'll talk about misconfigurations and I'll be able to just catch me if you can because we're talking about something that might be or can be a bit elusive sometimes to notice and detect. To kick this off, I'd like you to imagine the person on the left, it's your first day at a new company, you're the first security hire, maybe in a small startup and as you're walking in, people welcome you, they hand you your computer, like any other things and as they're welcoming you into your new job, they also hand you a really long to-do list. They ideally would like you to start working on like immediately, right? You might be wondering, so what exactly is the job then in that case? Like what am I supposed to do specifically as a security person in a fast-moving startup or up-and-coming startup? And what it comes down to or what we'll at least focus on today is making sure that you keep the company and company data safe or the company infrastructure and company data safe in an environment that can move really quickly. And what I mean by moving quickly is that we have developers or like other teams that are delivering changes really quickly, we want to make sure that whatever they do is all like whatever anybody is doing in a company right, like it's all safe and secure. To make this a bit more specific, when we look at security and security engineers and software developers, we put this like on a spectrum, if you will, we have security on one end and developers on the other and I'm oversimplifying a bit to make the point here, but so bear with me, but when we think about it, developers, the measuring stick, like in a simplified case, is how many features can you deliver in a period of time in a week, in a sprint, quarter or whatever your time frame is in that case. Where for security, on the other hand, we want to make sure whatever changes are being introduced that is everything safe, that we're not accidentally opening like a door or like a back door for an attacker to come in and do whatever, like steal data or compromise our system in any kind of way. And so ideally, we'd like to make sure that like every change, like in this case, I'm just going to like we'll see a pull request and I'm going to platform the GitHub synonymously with like a change, right? So every change that comes in, we want to make sure is this like safe and secure and like ideally we could sit down and review each change manually or like separately to make sure that whatever they're doing is up to spec. But then coming back to all being like the first day at work, the CTO or your boss might be sitting down with you or like standing at a whiteboard and just to introduce it to the company infrastructure, right? So starting with okay, we have like our main application is comprised of this many microservices. We have some databases here, some databases there, and maybe even like a few other managed services that are double leveraging to build this tool or like this product. And we're talking about a complex system here, right? Like this might be like a bunch of, as I mentioned, like a bunch of microservice and everything. So the application in itself is already complex. But then and this is what we're going to focus a bit more on today here is it's not just the application that's complex, but also the environment we're going to deploy this into maybe AWS, GCP or Azure, right? Because there's like a myriad of different platforms we can deploy this onto like a EC2 compute, Kubernetes, serverless, or whatever else there is, right? Like there's like a long list of possible deploy targets and the kind of services we can use. But then with that in mind, what is it that we're what we're trying to prevent, right? And think about in the morning, you just you're just at your first cup of coffee or cup of tea, and you're turning on the news. And suddenly this happens, what turns out your company is on the news and not in a good way. Your company is your company is on the news because somebody managed to break in or compromise your environment. And they managed to walk out, maybe even the front door with all your customer or company data. And this is what we're working against what we try to avoid at all costs. Even if your company doesn't hit the news, right? I mean, this is like really the worst case that can happen. I mean, breakings happen and the news won't notice, which either way, it's still bad. And so this is what we're trying to avoid at all costs. And to change gears a bit, what we want to look at next is like a bit of like the day to day business of working at this company. So we might have a developer here who works on a new feature, and they write their code, write tests, test or check out everything past, then create, they do all their commits, and then eventually, once they're done, they push everything to GitHub or their source control platform, create a pull request, have somebody else or like other team members review their code, and then it's time to merge the pull request. Then we might have to take our automated deploy, you know, like deploy pipeline or mechanism in place, so that the deployment is successful eventually. And then it's time to try to feature. And then we just see this. And I'm sure all of us might have, all of you might have encountered something like this before, where we just faced like some generic error message. We just wanted to, one last thing, we wanted to try this out in production because everything checked out locally as we tested this and then we'll present it with a generic error message. And just frustrating, right, because you're already ready to move on to your next ticket or like the next task. And then now there's this that needs to be, needs to get fixed. So when we're looking at the logs or start to troubleshoot this, eventually we'll find out, okay, apparently there's a permission denied error. So we're lacking some kind of permission here. And that's what's causing this problem in the first place. And you might be thinking, okay, that's not a big deal, but I really need to get on with my to-do list. I like keep working on all my other tasks. So I'm just going to go ahead and it seems like a policy was missing. I'm just going to go ahead and deploy as your policy, allow access on all resources, et cetera, just to make this go away because people want to use this. And then we already see the first tickets and customer support coming in. People are complaining. Why am I seeing this error message? Like I can't do my work. And so we just need to make this go away. And that's where we encountered our first misconfiguration. And you might be saying like, but seems a bit doesn't seem right to just blame this on like software developers or developers, right? And you're right, like this is not, this here is not about assigning blame to a team or specific group in the company. But what I'd like you to take away from this small example is how easy a misconfiguration can happen. And granted in this case, it's very exaggerated, right? Well, like somebody comes in and just applies or like grants all permissions on everything just to make some error go away. But the important point here is a misconfiguration can happen faster than you might think. And it also might happen unintentionally. And that's the, the bigger thing here, a spoiler to consider. So as I said, we just encountered our first misconfiguration. And if you might start thinking of like, hmm, have I encountered any similar situations in the past? Have I done anything like that before? And just your mind starts wandering off and wondering, okay, it seems like suddenly things start to become much more complicated or complex. It might be feeling like a person on the right or you think like, I'm just going to do A and then do B and then my job is done, right? Or like, I'm going to do A and then B happens and then we can move on to the next thing. But suddenly we have this, this, I'm just going to call it like the complexity jar on the left that as soon as we open this, then there are so many more things to consider and to take into account. And it's just really overwhelming. That's certainly the first time I learned about misconfigurations and what's associated with that. That's how I felt about it. The look at the, the, it's like a more official definition of what or the misconfiguration really is. It is an incorrect or suboptimal configuration of the system that may lead to vulnerabilities. And as I was researching this in preparation for this webinar for the session, like another definition I came across mentioned, or like was very similar to this one, but it also mentioned that it's something that we don't do on purpose. And I think that's the big thing here that misconfiguration can happen easily and unintentionally. I think that was what I was looking for unintentionally. So we're not doing this on purpose, but this happens as we're just for instance rolling out a new feature into production, into our systems. And so to give you a better understanding of like a better feeling for what counts as a misconfiguration, what should I start looking for in my own code or systems, et cetera. I have a few examples here we like to consider. The first one here is an example and also already contains a bit of the remediation. And so this is a bit of Terraform code that we might run to or allow somebody to assume a role. And the misconfiguration here is that we might allow a user to assume a role without checking for multi-factor authentication. Or in this case here, we want to make sure that somebody can only assume a role if they have multi-factor enabled or configured. Otherwise an attacker or in code just needs to guess my password. And then they have access to the system and then maybe like already allows them, allows lateral movement or something like that. And so here what we're looking at is we say, okay, we need to assume roles or we need entities to assume roles in our AWS infrastructure. But then we might have considered that enabling MFA is something that we should do and also helps to prevent possible breaches. Another example that I think has been very prominently featured on the news is exposed storage buckets as publicly accessible as three buckets even though they were supposed to be private instance. In the worst case we have a bucket that stores or will restore sensitive data and it's world readable. Everybody can access this and that's and there's been lots of cases in the past war that has happened. But even if you think more like today, like whenever you create a new bucket on Amazon from online AWS, for instance, I think it's private by default. So that's something not as easy anymore to make this mistake. But even if you think about it, even if the bucket is not world readable, but you have a bucket where you store workers contracts, salary information or something like that. And it's readable within the organization, suddenly it becomes a problem again, because now we're sharing information that wasn't supposed to be shared across the entire organization. So this also counts as a misconfiguration. And the last example here is open ports. So in this example here, we might have one or more EC2 instances, and we associate a security group. And in the security group, we just open all ports to maybe even the public, right? Or like, yeah, in this case, to the public. I might be wondering, so what's the big deal with this? Because you might say, you know what, I just need to deploy something on this machine and to access some of the services there. And I don't want to worry about what kind of ports are open or closed or go back into, I don't know, my material form code or the AWS console to open more ports or close them again or whatever. So I'm just going to open all of them. And the problem here is that an attacker can go ahead and perform port scan on the machine and see in the results, see, okay, what kind of services are running here. And then if the service, like, test example, FTP, for instance, if we're running FTP in a version that's vulnerable to some kind of attack, then they can attack that right away. Or if FTP in itself is misconfigured in a sense that it allows anonymous access, then suddenly I might expose data to attackers or to outsiders that I didn't intend to share in the first place. And so these are just three examples of a, almost like an endless, like a really long list of possible misconfigurations. And it's a bit like coming into an archive, right? And like you have a stack of boxes sitting in front of you with what it says here, right? Like this is all the stuff we know about so far. But we're sure if you go down the aisle, there's much more that we'll find much more stuff. And the important bit here is this is a problem you're unlikely to solve with just discipline and work ethic. And what I mean by that is, because there are so many possible misconfigurations and also if you're in an environment where there's a lot of changes happening on a daily basis, like thinking of people sending pull requests and scheduling deployments, it is not just not possible to keep track of all that manually, right? Like to just sit in front of the GitHub pull requests, tap and just go in and review each pull request one by one. Because even then, even if you manage to do all of that, it's going to probably consume a good part of your day, your work day. And also, if somebody chooses to go into the AWS console directly to make some changes or to create a new bucket or something like that, you're not even aware of that. And so this is a problem that we need to solve with a, we need to solve with or by introducing new software. And that's where Panoptica comes into play. Panoptica is the Cisco's cloud application security solution and we're part of Outshift. Outshift is the incubation group within Cisco. And in a broad sense or like in a single sentence, to describe what Panoptica is, it is focused on cloud security. If you heard the term CNAP before, CNA double P, Panoptica fits into that category. CNAP is a, I think it's called by Gardner, and there's a handful of software solutions that are in this category and Panoptica is one of them. And as I mentioned in a general sense, I'll explain Panoptica focuses on cloud security. And what that means is if you, if you sign up for an account and the first thing you do is you connect your instance, your AWS or GCP or Azure accounts. And what happens next is that Panoptica starts scanning and then you're presented with a dashboard like this where you see an overview of all the different findings. And while there's a lot to explore, there's a lot of different aspects to cloud security. Well, here we'll focus mostly or like exclusively on misconfigurations. But what you see here is that as soon as you connect your one or more accounts, then it starts scanning and then you get overviews of, okay, how are we doing for instance in terms of compliance or are there any attack paths to consider and when I explain that in a second, what that means, or what you see on the right hand side, is there any, since there's any malware that's found that I need to, or do I need to address or need to remove? And so we're looking at, before we look at the very specific misconfiguration features one thing I'd like to highlight is attack paths. What this does is it also shows us one ever, there's a misconfiguration and an attack path highlights how an attacker might take advantage of a misconfiguration or in this case a CVE to gain access or for instance, steal data. It doesn't mean that somebody has already done it. I think that's very important to highlight here. It just shows the possibility or like how somebody could do it. And I think that's a, because we're in such a complex environment, this is a very critical piece to that, to make sure that we understand, okay, how does somebody take advantage of a misconfiguration or CVE? And what we see here is in this specific example, on the right hand side, we have an EC2 instance that has a handful of CVEs associated with it. An attacker can come in from any IP or any of these two security groups to access this machine and then, for instance, explore the vulnerability. Excuse me. And if we had any misconfigurations within the environment, then these also would show up here. And then the attack path is a tool that helps us to, yeah, like this is like a very reactive kind of work, if you will, right? And if you think about it, you come in in the morning, you open your computer, you sign in. And if you think, okay, I really just need, first of all, I need to know, is anything on fire right now? Is there any, anything that is like, drop everything and fix this? Is there any kind of work? Well, like, are there any kind of issues like that in our system? Attack paths highlight that very well, like what can go in and work these off one by one, for instance. Before I, yeah, consider like doing anything else. So, the next screen, I would like to highlight all the capability really is security posture. This is what we see, what you see in the middle here. There's a bunch of different risk categories too, like that they were scanning for, what we show results for. But the thing I'd like to highlight here, we're going to talk about here is insecure configurations. And we drill a bit deeper into this, or looking at one in detail, we see here, what we have here is the example of the permissive access to S3 objects. This is like more like, maybe even publicly accessible S3 bucket. That's the case what we're talking about here. What you see in the background is there's a bunch more findings around IAM misconfigurations or databases, cluster roles. So, it's not just focused, I mean, I only used S3 and a bit of IAM as examples here, but the scope is anything in your AWS account. And so, what this allows us to do is, first of all, to drill into, look at this in more detail. So, what exactly is the problem? We see related assets, which means, okay, there's in this case, one bucket that is affected by this. And we also get information on how to remediate, like instructions on how to remediate this. What's important here to take away is that Panoptika doesn't automatically remediate anything for you, which means you're always in the driver's seat, you're always the person to make the decision of are we going to address this? And then also if we do, how are we going to do this? Panoptika only has read-only access to your accounts. And so, there's no way or no chance for us or for this tool to change anything without your notice or without your consent. And so, the way how to use this or how to look at it is, we look at the findings and then if we decide this needs to be addressed, which is very likely given like the severity rating here, then we can either send a link to somebody else to have them look at it and fix it or create, for instance, create a ticket in like a system like Gero to have somebody work this off or like to fix this. And the next one, the next thing we want to look at is the CICD capabilities like the names changed a bit recently on the screens. But what is this all about us? Let me go back one second. Here we're looking at what's happening in production right now or in our environments. And it's a very like a more reactive kind of working, right? Like somebody already deployed something. And now we see what we get inside into what are all the problems and what do we need to fix? And then if we fix this right now, then there's no guarantee on like that this is fixed forever, right? Because if somebody runs their Terraform script again, for instance, then or like some Terraform script, they might, they might introduce this reintroduce this vulnerability again. And so what we'd like to do is we'd also like to become more proactive in the sense, which means we also want to start scanning not just our clusters and everything and configurations, but also our repositories where we, for instance, keep Terraform code or Kubernetes definitions and things like that. And so as soon as I connect my GitHub repository, Unoptica also starts scanning those and then it's like what you see in the background here, for this repository here, there's a few findings, for instance, a generic secret, right? First of all, that there's a hard coded secret or API key that was found. And then with the link to the file and then also with a bit more explanation on what the actual problem is. And this screen here doesn't provide as much information yet, but we're working really hard right now to deliver more features here. So this is something that like this is a capability that will improve a lot over the next few months. And so to wrap this up, what I'd like you to take away from this is that first of all, in the security space, we have reactive work, we have reactive work. Reactive is really what we talked about before in the previous screens, looking at what's happening in production right now. Is there anything that we need to fix right away or fix eventually? And then we also have the more proactive work where we want to catch these kind of mistakes or misconfigurations before they even get deployed. And a tool like Panoptica can help you to be more conscious of your time, right? Because there's there might still be a lot of work to go through. Like if you go back to one of these screens here, you see there's a lot of findings. So it might still take a while to get through all of these. But it's what it's, I guess like the advantage here is that you don't have to find all of these manually. But this all happens behind the scenes as changes are being made, as people roll out new features, fix bugs, etc. This happens behind the scenes. And so you can, so you have more time to either fix this and also work with other team members to maybe even educate them on, hey, like we should talk about our, how we handle this three buckets or policies around that. But then also to come in and fix this, right? So if you think this was interesting or just picked your interest or you think, or you feel like you'd like to learn more, I would like to invite you to join our academy. It's free, so sign up for free. And we are currently in the process of adding a lot of cloud security content. So if you sign up right now, you see that there's really content there and we're rolling out new content every few weeks. Anything around CNAP, cloud workload protection, misconfiguration, the vulnerability management, these are all things that are already either there or yet to come. And that concludes my slides. And I believe we have like a few questions in the Q&A box. So let's see, we have, yeah, I think there's like two or three questions about how an applicant compares with Prisma Cloud from Palo Alto. It's a good question. I don't have specifics on like a feature by feature comparison. What I can say is that we're very much or like somewhat on par with most of the features that the competitors have and we're currently working on enhancing that as we speak. And I know it's like a not very definitive answer of like, we do this better and that better or like the others do this and that better. The reason for that is that we're much newer to the market than some of our competitors. So when you look at our feature set right now or compared to others, you will see some gaps, but we're working really hard right now to catch up and to just be on par, but also to deliver more value that others don't have. So I hope that answers your question though. And let's see. So if you have any other questions, I believe we have like a few more minutes, at least please feel free to tap them into the Q&A box. Otherwise, I really appreciate taking the time today to join the session. And I hope that we can, yeah, that we can welcome you as learners in our Panoptic Academy. I think I'll see any more questions coming in. Back to you, Candice. Thank you so much, John, for your time today. And thank you everyone for joining us. As a reminder, this recording will be on the Linux Foundation's YouTube page later today. We hope you join us for future webinars. Have a wonderful day.