 All right, everyone, thank you for joining us. Welcome to today's CNCF live webinar, how to achieve comprehensive protection for your applications and workloads. I'm Libby Schultz and I will be monitoring today's, moderating today's webinar. I'm gonna read our code of conduct and hand over to Yvonne Malia, Senior Manager, Product Marketing Prisma Cloud and Mohit Basin, Senior Product Marketing Manager both with Palo Alto Networks. A few housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There is a Q&A chat box on the right-hand side of the screen that you'll see. Please feel free to drop your questions there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such 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 and please be respectful of all your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF online programs page at community.cncf.io under online programs. They are also available via your registration link and the recording will also be available on our online programs YouTube playlist. With that, I will hand things over to Yvonne and Mohit. Thanks so much Libby. Hi everybody, good morning. I'm Yvonne Melia with Bellata Networks and I'm joined today with my colleague Mohit. Hi Mohit. Yvonne, thanks for having me and thanks everyone else for tuning in to this webinar. What prepared today is a set of slides to talk a little bit about application security at runtime. I'll talk a lot about workloads. I'll talk about different risks in this stage of application lifecycle, starting with level setting on market requirements, business trends around workloads and overall security. And then we're gonna go into more details around some specific risks and countermeasures at the run stage pertinent to containers and applications in general. And then we're going to show a little demo of our product and how it maps to that application security continuum story that we will present. All right, so I have my slides up. Okay, so let's kick this off. As cloud workloads evolve, there's a need for flexibility and that need becomes pretty important. We need flexible security architectures that can easily be switched between different agentless options for that quick visibility, agent-based defense and depth protection in order to provide a full comprehensive security. In a hybrid cloud world, distributed environments and mixed workloads are a norm. There's a growing number of entities to secure which resulted in adoption of many point products on the market and that's the reality today. The way I see this ultimately drives the investments and a maintenance and operational cost up which inevitably increases the complexity brought by these solid operations that leaves many blind spots. On one side, we have many different environments, infrastructure as a service, platform as a service, containers as a service. On the other hand, we have complexity that's increasing due to various benefits of cloud. We have microservices, we have containers and so on. And we believe in a unified platform-centric approach that includes a customer's choice for everything from agentless scanning to defense and depth with agents. And then finally, a web application and API security. And in this ever-changing environment with the adoption of DevOps, microservices and API, security is often part of a trade-off such as we're trading security for development velocity because we want to ship products faster. We want to ship products and features faster. Security operational teams are the integral part in the grand scheme of things. And we believe that security needs to be spread out across these different layers and all the teams that are involved for that shared responsibility model. And there are two types of responsibility models. One that you have with your cloud service provider where they're responsible for everything from the infrastructure below and onus is the need to manage your applications and security and then there's responsibility model that you have within your teams, everything from developers to ops teams, everything through code, build, deploy and run stages in the application's lifecycle. So we really need to lessen the burden especially for the SecOps team and allow developers and infrastructure teams to incorporate security instead of being it either a trade-off or a burden. That's something we really want to avoid. So these are some of the requirements and design notions that we took into account when we are developing Prisma Cloud. Now, how workloads have changed allowing for more degrees of freedom where attack surface effectively expands and what the workloads have become, I will describe with these four characteristics. We have location, size, duration and architecture. And the way I would rationalize this from a location perspective, workloads are portable, they can be on and off cloud and data center air gap environments. From a size perspective, it's about granularity of workloads. We have technology and products around microservices that effectively enable this. It's much easier to manage an application this way throughout their lifecycle. From a duration perspective, workloads are ephemeral and that's a good thing. Some need scaling up, down or scaling out. Some are updated, released on a daily basis. And then from an architectural perspective or immutable workloads, again, microservices containerization proliferated use of serverless functions. Effectively workloads are deployed using these heterogeneous tools across distributed environments. And why is all this important for us? Where if we look at the four stages in this modern application lifecycle I mentioned across code, build, deploy and run, the attack surface effectively increased. There are many attack vectors along the applications lifecycle, especially in the run stage. And this is our focus of today conversation. When we read about different breaches and incidents in the news almost always is about a breach in production. Some of the things that you see on the slide, most exploits are really expected to be known vulnerabilities. And there's no such a thing as 100% patch rates. And we are hearing constantly where different attackers would go on a NIST CV database and look at different vulnerabilities of the day. And then they would scan the internet, which we can do today in minutes. And then look for unpatched CVs or unpatched packages and then try to use some brute force or some reconnaissance techniques there in order to enter in the system. My bottom line here is that traditional security controls don't fit multi-cloud environments. There's an overall lack of visibility into vulnerabilities across the application lifecycle. Everything from cloud misconfigurations to vulnerable software components of our applications that attackers can use to enter a system. Containers and microservices based applications, serverless functions, they all require a very different architectural option for enforcing application security. And legacy systems can't provide the actionable insights into these heterogeneous environments. So chances are you have a distributed environment, you have mixed workload types, different application stacks, you know that a subset of your deployment will need threat detection, anomaly detection and runtime prevention. You will need that defense in depth, maybe not for 100% of your assets in the cloud, but for some. So instead of a making that leap to that state of full defense in depth that could leave you with more questions than answers, we invested in agentless workload scanning to provide this application security continuum. And again, chances are you don't have the visibility into what's running across your cloud workloads. So maybe start with that visibility into running environment, map that environment based on your known onboarded accounts, understand the workload types you have, the application deployment you have and then review these reports and craft your application security strategy that leverages both agents and agentless capabilities together. Some of the key questions that are driving the decisions as you're starting or looking to change something in your application security's first visibility initially, you may not know what you don't know and you're looking for a quick way to gain insights into the running environment. Plus there is a very fast pace of change, as we all know with applications and containers specifically on a daily basis. So that's something that needs to be incorporated in a tool, that visibility of that pace of change. So any new applications, workloads that are being provisioned and deployed, we need to know very fast about those and then scan them for vulnerabilities. Two, you may be thinking about how deeply integrated you want security to be with your environment, what permissions you need to set, what's your level of comfort, you need to run an agent here or not for that defense in depth. And three, it's really about what is that you would like to accomplish at the end of the day. I think both agentless and agents are in your future, so maintaining that possibility to switch at any time with the same pricing model is something we have built. Now, we're a quick slide here on the anti-agent view that we have out there. There's certainly building a good case for agentless scanning, but it's not really about one versus the other. The truth is there are many agents that are running in an environment today, everything from monitoring services, Kubernetes schedulers and so on. There is nothing inherently different with any workload security agents. Do firewalls impact line rate? Yes, but we still need them. So take agent resources into considerations for your planning. And lastly, maybe difficult to get the ops team to pretty much install anything, but that's not the reason to drop security. And in my view, working together across your teams is more difficult than protecting against a zero-day threats. You have to implement tools and processes that benefit all stakeholders. And I think the insights you gain with agentless scanning can also help you get the better sense of what after that initial scan. The abstract story does not end there. We need to apply the appropriate model on a per workload basis, based on the risk requirements, calculate that risk as you map your environments, leverage agentless, where frictionless visibility is required, and then leverage agents where criticality and exposure warrants runtime protection. And then throughout this presentation, also show why this is also important from a web application security perspective. And for that, we'll show a little animation here around web-based attacks. So between your application and the internet, there is a routing element by design, a router or a firewall that provides some sort of L2, L3 protections, IP port filtering, intrusion prevention, and so on. Everything else would appear as a legitimate traffic. In this case, we're looking at HTTPS traffic. It's a known fact that web attacks are most common type of external attacks that are facing applications. And Mohit is gonna talk more about this overall. Web attacks and API vulnerabilities are just one piece of the puzzle when it comes to securing your cloud native apps. They are effectively an entry point into the system. Isolated point solutions lack a broader context into misconfigurations, vulnerabilities, and application attacks and are creating unwanted noise. So some of the attacks here, we like to mention cross-site scripting. Web security vulnerability that allows an attacker to compromise the interaction that a regular user would have with the backend application. It allows an attacker to circumvent the origin policy which is designed to segregate between different websites. And the way cross-site scripting works is by manipulating a vulnerable website so that it returns that malicious JavaScript to users and involves an attacker uploading a piece of malicious script onto the web app. And then when a malicious code executes inside the victim's browser, the attacker can fully compromise the interaction with the application. They can steal user's active session cookie, could be used to steal data or perform other kinds of application abuse. This is a more unsophisticated strategy but still quite common and can do significant damage. One thing for web-based attacks specifically that we're adding and it follows that overall application security in the runtime journey when we go from agentless to agent-based security and how that enables web application, AVS security is really that vast product that is part of a platform. It includes a web application firewall, also known as WAV. They operate on the application layer and they're highly effective gatekeepers when it comes to filtering, monitoring, blocking HTTP traffic to and from a web service. A majority of web apps today are built using cloud native architectures. The ideal approach to secure against web-based attacks changed and we feel the web apps, this app security particularly coupled with API security should be factored in overall cloud security strategy. So having a solution across a full app lifecycle that includes securing workload, whether it's a VM container or a serverless function as well as protecting the web apps and APIs that run on those workloads. And this is the reason we're introducing WAVs at this level on this slide here. WAVs are desegregating because these capabilities need to be closer to the application, they need to be more app aware. Microservices based application deployment models require that app aware security. And in addition to having a full-fledged WAV against the things such as OSP top 10 type of attacks. And if you're not familiar with this I strongly encourage you to look at the OSP top 10 attacks and get familiarized with that attack landscape. WAV solution adds the API security which is one of the major problems today in addition to bot protection, DOS protection and also distributed denial of service at the app level specifically distributed denial of service for HTTP HTTPS traffic. And you may or may not be aware about the recent breach of data with tier one service provider in Australia, Optus. Basically there was no authentication method anyone from a public IP address could have initiated an API call. And what did that could effectively did initiated that API call 11.2 million times to get the data of 11.2 million customers. So this is definitely something that with the tools and processes that we have today it's fairly easy to put in place different protections at the different points in the infrastructure to really prevent these kind of attacks such as anomaly detection rate limiting and sound specifically when it comes to abuse of the APS because they're effectively a very good entry point into the system. And if the infrastructure is not secure it will allow a pretty large attack vector there. And then now see, so for example in that case of an API abuse that wouldn't appear as a legitimate traffic. It would bypass any routing element at the network perimeter bypassed any controls if they had between the application and the internet. So that's why I'm showing in this one my slide to show that there is still something that appears that legitimate traffic that in fact it's not. So cross-site scripting, SQL injection, API abuse is just one of the ways to abuse the system and then effectively gain access to the system. So we'll go now through that code to build the program and run from a risk and threat landscape perspective and we'll focus on the run more than anything else. Okay. So we have a number of risks in the run phase and the best way to look at the situation is to the lens of an operating system where we have everything from network access to host operating system, to micro configurations, our runtime and the application software. And how a system is compromised. I just mentioned a number of ways just using from a L seven perspective, HTTP, HTTP traffic through different attacks at the web applications and API. These are some of the other aspects of the system that could be compromised. So definitely web apps are the face of applications that is running and attackers use this as an entry point as I mentioned. The attacker would find a vulnerability and effectively exploit it to land in the system, bypassing controls if any, and this is enabled by a few shortcomings. In addition to web app shortcomings, it could be open port, unencrypted storage, any secrets that are embedded in our images, malware embedded in our images, vulnerable code packages or independency. Once in the system, the attacker would typically perform various reconnaissance techniques to find other exploits and what other nefarious things could be done. This would include similar techniques that we would use in penetration testing and ethical hacking, things involving operating system fingerprinting, file permission analysis. It would try to run a new process, typically a network service and it would try to expand laterally from one container that was that external face and then laterally go to other containers, look for that crown jewel, look for that data that they could steal. Now, here's my selection of risks at the runtime level across network, host OS, runtime config, runtime software and then application itself. I will cover some of these. I would select some of these that are really relevant to our conversation today and then also to web applications, vulnerabilities and I will show in a demo to how this really works. So I'll pick the first one here, vulnerabilities within the runtime application. They may be relatively uncommon and rare but are particularly dangerous in scenarios where a malicious software can attack resources in other containers or even the host OS. It would allow an attacker to access another container or monitor intercontainer communication. From account to measure perspective, a vulnerable runtime exposes all containers it supports and the host itself to risk. So what we need to do is carefully monitor for vulnerabilities and when problems are detected they should be remediated or otherwise patched quickly. You should use tools and monitor for CVEs stands for common vulnerability and exposures and manage any instances that are at risk and then patch as soon as possible. The other one I would pick up the application vulnerabilities not so much about a container but the application it runs in it. Now consider again, a web application I mentioned subject to cross-site scripting or a database subject to SQL injection. This will be considered a compromised container and it can be misused in way that would grant the non-authorized access to sensitive information. Now there are a number of things here we could do. Existing host-based intrusion detection processes and tools are often unable to detect and prevent attacks when containers within the containers due to different a technical architecture operational practices. What we should implement is additional tools that are more application and container aware. So I mentioned a little bit on the web application and API security side. One other thing that we could do is automatically profile containerized applications by using some of the behavioral learning techniques and build these security profiles and models for containers to minimize any human interaction. And then these profiles could then be used to prevent and detect anomalies at the runtime. Now typically the events that would be looked against in order to create these models would effectively be across a file system network and processes. So we would look at things such as invalid or unexpected process execution or invalid unexpected system call because why would a random container spawn a process that would peek and poke in our memory, do something to our file system or issue a number of system calls that we don't expect. So changes to protected config files, I think to unexpected locations and file types, creating network listeners and then sending traffic back and forth. So this is all what should be used to create those models based on which you could understand whether the things that are happening in production are expected or they're more of an anomaly. The next one, large attack surface, it's an easy one. It's about optimizing the attack surface. And lots of people do this today, it's about minimizing the channels that can open up for a potential attack such as a network accessible service provides a potential entry point for attackers. Now, a lot of people, what they do here is they use a container specific operating systems where a threats are typically more minimal to start with since this minimalistic operating systems are specifically designed to host containers and they have other services and functionality disabled by default. These optimized OSs are designed specifically for hosting containers. They typically feature read only file systems. They deploy various hardening practices by default. And I think whenever possible, organizations should use this minimalistic operating systems to reduce the attack surface, mitigate the typical risk and the different hardening activities that are associated typically with hardening general purpose operating systems. And then lastly, hosts should be continuously scanned for vulnerabilities. And then as I mentioned before, updates should be applied quickly, not just to the container runtime, but also to a lower level component such as the kernel that containers rely upon for secure compartmentalized operation. And then let me see the last one maybe here, host operating system file system tampering. So here is about insecure container configs that can expose host volumes to greater risk of file tampering. So for example, if a container is allowed to mount sensitive directories on the host OS, that container can then change files in those directories and these changes could impact the stability and security of the host and all other containers that are running on it. Here, what we need to do is ensure that containers are run with the minimal set of permissions. Very rarely should container mount local file systems on a host. Any file changes that containers need to persist to a disk should be made within storage volume, specifically that it's allocated for that purpose. And I think in no case should container be able to mount sensitive directories on a host file system, especially the containers that contain any config settings for the operating system. So we got to use tools that can monitor what directories are being mounted by containers and prevent the deployment of containers that violate these policies. I think many of these countermeasures you could start implementing tomorrow. The question is that you need to ask yourself is how to do this efficiently, add speed in this scale? What could be automated here? And one thing I want to mention as I close my section here and just slowly introduce a little bit around our product, the Prisma Cloud. Mohit and I are representing Prisma Cloud Compute portion of our platform. This is about that predictive model I mentioned and I'm calling it out here. In my opinion, it's one of the best features here, especially if we're looking at that runtime defense. If you're looking at really prevention and near real time, what we do here is we start with static analysis that's a testing methodology that analyzes application components to find security vulnerabilities that would make an application susceptible to an attack. Using machine learning for correlation and model input would give us a predictive model of this application. Now, a couple of things I'd like to call out here. The first one, if we pair this with a threat intelligence stream, we get automated defense. The second thing I like to call out on this model specifically is that that model effectively builds applications DNA and prevents malware in real time, even without any security policies in place. So there's a few learning modes here. Learning mode initially would look across, as I mentioned before, processes, file systems and network and then build out that DNA for us to use in real time. I think it's a powerful combination of tools and processes that would provide both visibility and real time protection for applications. Now tying this all in into application security continuum, I talked a little bit about agentless scanning. This is something that we have available in our platform in our offer. I see this as a first step in securing cloud environments. I talked about first step being that visibility, turn on the light switch, map your environment. It's ideal for that easy quick visibility into your distributed environments when you need a quick posture overview. We do this by creating a snapshot on a customer environment, extremely low cost from a compute storage. We do this by design because the data stays with you. There are various configs here that could be managed, a frequency of scans periodic on demand scans where we furnish you with the report and different remediation options, integration into ticketing systems so that there are lots of value in actions that could be taken in this step alone. And what I want to call out is I think this is an important step in crafting that winning application security strategy. And this really works hand in hand with the Defender Workhold Security, which is my bottom part of the screen here. It's the now first step in defending cloud environments because this part is now about defense in depth where you detect and prevent threats in real time by doing runtime scanning and anomaly detection, things that I just mentioned in the previous slide when we create that model. So it's great for that defense in depth and for active prevention of exploits where we have agents deployed on the application infrastructure. And then the last piece to this application security continuum is the web application and API security that I mentioned earlier in the call. At this point, I would like to hand over to Milhit to continue down the web application and API story and share a little bit of his insights and slides. Thanks, Yvonne. I can start sharing my screen. Like Yvonne said, like agent lists is great for visibility scanning and insights that provide a lot of value into your cloud workloads, whether it's a container, host, or serverless function. And then defender-based protection is to implement some actual protection. But where RAS plays a role in this is it's an added layer of protection for your web apps on these containerized or hosts or serverless workloads or APIs that are talking to each other, whether it's the North-South API traffic or whether it's East-West when it's from one workload to another, one application to another. And what we're really doing here is we're looking at all of those requests over HTTP and HTTPS and then analyzing them to see if there are any threats against the class top 10 malicious attacks such as SQL injection, cross-site scripting and more. And then on top of that, we're also looking at the API applications to make sure that they're safe and secure as well as protecting against DOS and BOS bot protection. And the reason why we're doing this is because we realize that web application exploits are the most common form of an external attack. In fact, there's recent study by Forster that said that 39% of external attacks are web application attacks. And there's another study by a bleeding computer that said that there's about a 600% growth in attacks to APIs just in 2021. And as developers and companies start leveraging APIs more and more heavily, we're gonna see that attackers will then go and target this much larger attack surface because a lot of these APIs aren't secure like Yvonne said earlier. There was a breach from Optus where they made about 11.2 million calls to an API. Like how can someone make 11.2 million calls to an API without it going unnoticed? And that's the point that we're trying to make is a lot of these avenues into the application are unsecure because an API is just a form of communication that allows you into the application. And that's what attackers are leveraging as their entry point. And what we're offering with WAS as we call our web app and API security solution all within the same Prisma Cloud Platform that we're sharing with you here today. We're offering, we built a built-in web app firewall as well as a built-in API security solution for those applications that have vulnerable web applications or vulnerable APIs. And then on top of this, we're able to also protect against bots whether they're good bots, known bots, search engine bots or bad bots, as well as bots that you can define. And on top of this, we're also able to protect against DOS attacks by rate limiting some of the requests we're seeing towards the application. And we also give you insight into all the request analytics events and whatnot within one screen so you can prioritize risk. And all of this is backed by our Unit 40 Threat Research Team where they're constantly researching for new vulnerabilities and as soon as we discover new or known vulnerabilities, we try to place them into the product so that the end user can either patch their application with a custom rule or a virtual patch that we've designed for them. The biggest benefit is that all of these solutions is that you're getting better security with fewer tools because all of this has been integrated into the same Prisma Cloud Platform, whether it's workload protection, WAP, API security, CSPM, or CWP, it's all through that single platform. And the reason why we made WAP as a part of our cloud native application production platform is because we realized that the legacy solutions fail to really protect cloud native applications. We wanna really emphasize that we're looking at this from a cloud native perspective where your traditional WAP was usually a box that would sit in front of your old data center and it would protect a VM or a old school machine. And they didn't really look at APIs nor did it scale on demand because it was an actual physical box and you had to stack more boxes on top of each other. And it couldn't be deployed for private, public cloud, or hybrid cloud use cases. And your cloud WAFs, they don't really look at VMs, containers, or serverless functions as a whole. Nor do they address that East-West API traffic. And your RAS solutions, which kind of have come and gone in the market where they do provide some sort of runtime application security, they don't offer a lot of flexibility on the actual workload itself. And that's where we separate ourselves from the rest is that WAFs is built on the idea of, let's understand and familiarize ourselves with how we can secure the container and the underlying workload of the application and then add another layer added protection for the APIs, like I said, whether it's North-South APIs or East-West APIs or this from application to application or microservice to microservice. And the cool thing with WAFs is because we take a completely different approach to looking at application security, we're able to scale easily because we place our solution on top of the workload. So as the workload or application scales, the security solution scales with the application. So you never have any downside of, hey, you know, my WAF or API security is like breaking my application because it's limiting number of traffic or requests. And that's really big in cases for large deployments. And on top of that, we offer a lot of flexibility on how customers want to consume WAF, whether they want to consume it for applications on their private cloud, public cloud, they have a hybrid approach or want to use it on-premises, we have all the flexibility within the product. And then on top of this, we also offer inline and out-of-band protection, meaning that you can have inline protection for those critical applications and APIs that need protection on day-to-day basis. And you can also have out-of-band observability, which is just greater visibility to understanding all the risks and threats associated with your application without actually having something in the middle that can break your application. And here's just some other reasons to why customers have been choosing our WAF solution over there and ditching their classic WAF or their first-gen API security product is because of the fact that we are able to be deployed on your public cloud, private cloud, take a hybrid approach or whatnot, whether it's inline or out-of-band, we offer a lot of flexibility to customers. And then we also scale really well with the application like I said earlier, because as I want to point out, we sit on the actual workload, whether it's the container or the host machine. So as your application scales, we scale with it as well. And then on top of that, we are integrated into a cloud-native application protection platform, meaning that we're the only WAF and API security solution on the market that's built into a holistic cloud security solution. So we give you a holistic view into security for the applications, whether it's a CSPM point of view, whether it's a vulnerability management point of view, whether it's a WAF or API security point of view, we give you a 360 view of security for your application, because we know that like I said earlier, the web app attacks or the API attacks are just one entry point into your application. So you want to complete visibility of everything, even the backend databases and whatnot. And then with that, let me pass it over to Vaughn. Vaughn, do you want to do a quick demo for everyone? Yes, let me share my screen again. I'd like to show a few things around vulnerability management, runtime security and so on, things that I've talked about before. And then I'll hand over back to Mohi to talk about WAF specific and then show a little demo around that. I've preloaded here a radar view, but and I'll come back to that. I wanted to show one other thing before that. It's really onboarding or unblocking Prisma Cloud, if you will, or you would start with adding a cloud account. These are the clouds that we support currently, where you would choose your preferred cloud provider, choose the onboarding type. Vaughn, you might want to refresh your screen because I don't need that demo up. Oh, it's not coming through? I see it stuck on the radar view. Oops, see it now. I can see cloud onboarding set up. Yeah, it was my VPN was connecting in that moment. We'll just go back here. All right, so settings, cloud accounts, add a cloud account. These are the cloud service providers we support currently, they can AWS here. Basically naming your account, it's choosing an onboarding type and then choosing between a read-only mode or monitor and protect mode. The other thing here is about repositories. One of the great things about Prisma Cloud, it's not part of the topic today, it's about as going as upstream as possible. When we look at the code build, deploy and run, we really want to go as upstream as possible, shift security left, integrating with code repositories, which is GitHub, your automation servers for CI CD, such as Jenkins, and different development environments where we're looking to secure code everything from infrastructure as code, through usage of various open source components and scanning open source software for different vulnerabilities as you go from code, build, deploy, and enter the run phases of the application security. So it's very easy that the initial step with unboxing Prisma Cloud, adding your cloud accounts or any account where your workloads are located, add if you need repositories, your CI CD automation servers and so on. And then I'd like to go back to that radar view for containers. And we talked about that flexibility that we have with agent-based and agent-less approaches for a comprehensive vulnerability management for hosts, containers, serverless functions. We believe customers should not have to choose between simple or secure, we should have both simple and secure. So we mentioned use agent-less for that quick scanning, agent-based approaches for more sensitive environments once you map your environment, you figure out what to deploy where. And this is an example of an application that runs. So here I'm looking at the book info application where I can see color coded based on my application risk. And if this feels a little bit overwhelming in terms of how many stuff there are, that's because application security is overwhelming but I assure you that there are other parts of the Prisma cloud that, and we constantly work on this simplicity and automation to really get to you to that risk profiling, risk prioritization, a very fast, so that you can focus on things that matter. But now I'm peeking and poking around just to show in detail some of the capabilities that we talked about previously. So I selected here one container and there are a number of things I can see here. I can see vulnerabilities, compliance score. I can see here that an unprotected web application was detected. So maybe I want to deploy a defender for that specific web application and provide L7 capabilities there. So this is very handy for as a single pane of glass to see all vulnerabilities, compliance, and runtime issues at the workload level. So I would like to go now to compute, monitor, and then vulnerabilities and then show a few things here. For example, if I click on hosts here, I can see my running hosts here and then here I can see how are they scanned. So there's a combination of defender based scanning which is an agent or an agent list based scan. I can see the different vulnerabilities that are identified in these hosts and then the risk factor that has been calculated. I will go to images and registry specifically show things such as container registries, container images here and pick this one here, the first one. Again, there's the risk score similar that you see on the host side that shows what kind of items were found for that specific image. And here we see there are lots of critical severities, high severities, medium severities, low attack complexity, attack vector through the network, the NILO service, and so on. So we can click on this registry details and then look at the different vulnerabilities here as we go through vulnerabilities, compliance and different aspects here. So just to call out a few things. So if we go on compliance here, I can see that this image was created with a root user and that's something we should avoid. So it's been called out here as a compliance check. If I go back on vulnerabilities and choose something critical here, so I see here that the ZLA package has number of vulnerabilities and then I can drill down on a specific packages that are part of this image and here I can see a different risk score. I see specifically for this CVE, this is a critical severity and a very low complexity and there is a fix. So this was something that popped up about two months ago. ZLA is a popular data compression. It's written in C and typically with languages that provides you great control over memory management, you may have sometimes introduced a buffer overflow issue and if your application expects 12 bytes and an attacker throws in 20, the question is what's in those eight bytes? They will effectively be in the memory. They may get executed but they are on your side of the fence. And that's why typically buffer overflow are very interesting and important to look at from a cybersecurity perspective. So this is called out here, what it says, it's fixed in this release and then some more instructions and data here and you can go and look through all the different packages that are part of this image. Another thing I'd like to show if I go back on compute, defend and runtime, I can show about how to go about creating a rule. So here we talked about processes, networking file system aspects. So I could go on a process here and then create a rule for my container runtime that would look at different things, processes that could modify my binaries, scan for crypto miners, look for that reverse shell attacks, scan for processes that are used for lateral movement and lateral breach expansion. And then you could choose alert, prevent or block. This is something you have when you deploy an agent for that defense in depth. So you can choose to prevent that from happening. You can block entirely entire container from executing or you can simply choose alert for that. Similar things at the network level where you can turn on things just port scanning, raw sockets and so on and then file system too. We talked about peaking and poking and the file system changes to binaries, changes to SSH admin account config files and all the things that we could be alerted on. And then you can prioritize that risk going forward. And then the last thing I'd like to show on the compute runtime here are the container models. So we talked a little bit about creating that model. So just pick the first one here. So this maps through static analysis methodology is also behavioral as well. These are the processes that have been identified as a known expected processes. So one thing calling out here, Kubernetes agent is there and various other processes also from a networking perspective, we can see that Kubernetes agents would listen at this ports. We also behaviorally learned about the outbound internet port 443 that's open from not so much from a file system perspective except that Kubernetes agent has a number of paths here that it's using. So this would be constituted as a known expected behavior and everything outside of this bounds would be an anomaly that would be flagged for a user to do something about it. I'll stop sharing here and hand over to Mohi to show a little bit on the west side. Thanks, Yvonne. Let me take over. And if you guys have questions, feel free to throw them in the chat and we can answer them. So Yvonne was showing like this is all within our workload protection product. So we have everything based off the workloads. On the radar view where I can see all the, you know, coast machines, containers and serverless functions and I were to really drill down into one of these actual containers. Let me widen the screen and actually drill down. There's an application about book info where we save all the information about books. And if I click on it, I can see everything like Yvonne said from one pace, the vulnerabilities, the compliance, the runtime events and well as WAFs. And as you can see, we automatically detected that there's an unprotected web app on running on this container and we've profiled it as well. And it's simple as clicking it once to go and defend it. So here I created like a test rule to go and protect this web app on my container. And from here I can just add on protection as well as discover any API endpoints or any ports running on this container as well. So if I were to go and add protection, like I said earlier, we have a built-in WAF where you can come in and simply click the type of protection you want, whether it's disable, the protection you want to alert, you want to prevent the SQL injection or you want to ban it. The difference between prevent and ban is prevent, prevents the request. The ban is that we deny all requests coming from that known IP for the next five minutes, kind of like a penalty box. And we do this for everything across the OOS top 10, such as code injection, cross-site scripting and more. And then we also provide DOS protection, which is we do it by rate limiting some of the requests coming to the application. So it's not DDoS, but this denial of service by understanding the request, putting an average request rate and limiting some of the IPs that we would like to exclude. And then we also have access control. And access control determines who can actually access the application based off IPs, based off their geo regions. And then we can also protect against file upload, tax if there are uploads to your application, we can then review them and sandbox them. And then look at, hey, which types of files would you like to allow, alert or prevent? And then we also provide bot protection, kind of like a bot mitigation tool where we look at known bots, like search engine crawlers, unknown bots, bad bots, bots that you might define, that you wanna let through and allow as well as more. And then if we haven't solved any of your concerns out of the box, we also provide custom rules for your application where you can write a custom rule to prevent certain requests for your application. And then there's our advanced settings, but we also have out of the box virtual patches, which our unit 42 threat research team creates, which customers can then go and implement on their application for like zero day vulnerabilities that block for shell and Azure escape. Here you can go and find some of the virtual patches, whether it's for CVE, spring shell, and more than our threat research team defines. And there's another, like I said, all this can be done within a single pane of glass where you can see all the results for your application in one holistic view, which gives you complete comprehensive protection and visibility for your workloads and applications on any cloud native environment. That I'm gonna pause to see if there's any other questions before we wrap it up. We have one question. Last protection for a container, is it container workload? Is it a side card or per host? So Philippe, the question is really good. So how last works is because you already have an agent deployed on your container workload, it's not really a side card. It actually sits on the actual workload. So we are able to protect inline requests coming to the application, but if you don't want it to sit inline, we can have it sit out of band as well, where it kind of sits as like a side card, where we just give you the complete visibility for your container. And it usually sits on the container node itself or the host OS. So if it's on the container node, you can look at all the containers within that node or on the host OS where we can look at all the activity per that host. I think we have time for a summary and a call to action slide. Yeah, a lot. I mean, Yvonne, do you want to take over that one? Yeah, we can both take that one. I prepared a quick slide. Yeah, here, a little bit on the summary of what we discussed. I mentioned this to one point during the call. Number one best practice is enable partnership between teams. Everyone from developers to sec ops, dev ops, dev sec ops, cloud infrastructure engineers. I think that's a big one because it's about people, it's about trade-offs, it's about what's the most important thing for you that day when you log in and security should not be taken for granted definitely and should not be overlooked. So we really need a solution here that provides, in my opinion, frictionless non-intrusive value to everyone, every stakeholder in that application lifecycle chain. So that I put this as a number one point here. Two, modern agent-based and hybrid models with agentless scanning for both cloud native workloads and workflows designed for on-premise data center environments. I think this is really a big one just to really help you map your environment without any blind spots and so on. The protection that cloud workloads really need is that proactive, comprehensive approach. Specifically, when we talk about investment in technology, people and processes, I think you can have all the tools in the world but the number one best practice is to enable the partnership between the teams and use modern tools that are application aware and it can help you prioritize that risk and re-scan for things that matter. I talked about defense in depth. So this is a big item for real-time threat detection and threat prevention and anomaly detection and so on. So I think it's a big one for very sensitive parts of your environment that you can learn from your initial scan to understand really where you need to deploy defenders and provide that defense in depth. We talked a lot about WAFs. We mentioned these solutions are disaggregating on the market right now and it started a few years ago because really you need an application aware web app and API security. So they're coming closer to the app, they disaggregated and became virtual and then application API security came in as an offer and the way we are integrating it is a very neat module that is part of the overall Prisma Cloud compute offer. So if you can really go from agentless to defenders and then really enabling that web app and API security. And then lastly, obviously simple one, look for a solution that provides you with more insights with less effort. I don't think you need a solution that is focused on one piece of the puzzle. We'll just leave you with too many blind spots. You need a comprehensive solution where really each capability is best of breed. You really need to cut through the noise to get what you need. Mo, is there anything to add here? Who's this comprehensive? We just like to iterate on your first point. Our job here is to enable collaboration between teams to help you guys secure your workflows. There's all vulnerabilities and secure your applications. And I think that's like really important. It's like trying to figure out that process internally can be tough and trying to pair it with a good solution that works for you is just as tough. So really try to understand how you can take a complete holistic view into application security and that can enable your teams to collaborate and be more efficient together. Yes, yes. And then our last slide called to action. Some of the accolades here, leader in a fostered way for cloud worker security, SC award for the best cloud worker protection and so on. Here's a link to request a free hands-on trial. Please do reach out to me and Mo hit as well if you would like any specific, if you have any specific questions or if you need any follow-ups we'll be happy to provide a demo and talk about your specific use case and spend some time around it. This link you can use to request one of the trials specifically and then start your cloud native application protection journey with Prisma cloud. That's all for me. Thank you everybody for the time. Really appreciate it. Thanks everyone. Thank you everyone. And thank you, Yvonne and Moheats and we will catch you all next time on next week's live webinar from CNCF. Everybody have a great week and we hope to see you at KubeCon. Thanks.