 Hello to all my DevSecOps streaming friends. It's time once again for another episode of DevSecOps is the way. This is episode nine. And this month is all about remediation. And we have our great partners here from Palo Alto. Before I let Hari introduce himself, I just wanted to let everybody know that this is a series, a monthly series. Sometimes we have two shows, but we also produce some podcasts. And you can see the different monthly categories that we've been exploring over the last few months around DevSecOps, everything from vulnerability analysis, compliance, identity, application analysis. And this month, November is all about remediation. So without further ado, Hari, why don't you introduce yourself to our audience? Absolutely. Thank you, Dave. And first of all, thank you very much for having me here. So welcome you all to this month's edition of the show. Hope I can add a little bit more value to you. My name is Hari Srinivasan. I'm a Senior Director of Products for Prisma Cloud Compute, which is responsible for compute workload protections. I've been tinkering with Docker for quite a while since Docker project came in play from Berkeley. It's been two years in Palo Alto Networks. And prior to this, I was instrumental in getting cloud and container security on the radar for QALUS. And I was working previously with Oracle on the cloud front, on some of the virtualization technologies and security around it as well. So that's my background. And at Palo Alto, I'm responsible for the compute workload protection. I'm hoping today we can have a nice conversation about how you can benefit and out of utilization tools which are there in the market and kind of get some new perspective about how to protect your environments in a DevSecOps way. Thank you, Dave. You bet, yeah. And Palo Alto has been a great partner of Red Hats for a while now. We've been working together on several different projects which have been great. For example, recently, you all were certified with the vulnerability scanning certification that Red Hat has created, which allows your product to consume data from Red Hat and minimize discrepancies between what the vulnerability sources that you consume say and what Red Hat says as well. That certification is a long time coming. It's great to see. And it's actually helped both parties, both Red Hat has fixed some data on our end to help you guys consume the right amount of data as well. So I appreciate all the work that you've done there. And yeah, you mentioned the compute workload protection. That covers a couple of different tools, correct? It does. So when we think about compute, it actually kind of has compute workload. It actually does primarily two things. One, our different kinds of architecture, containers, the most prevalent and popular and up-growing ones, container, Kubernetes, host or the virtual machines, serverless functions, and the application which actually also runs on top of it as well. Like we actually have a solution for web application and API security. So the compute encompasses both of these things within the Prisma Cloud family and it does so across the entire pipeline, if I may. Yeah, yeah, cool. So if we think about today's or this month's topic really is remediation, which is always sort of a silver bullet or a holy grail of trying to fix issues automatically. I guess in the market today, where do you see this space in terms of how customers are adopting it? What processes, what technology you see? That's a great question, Dave. So talking about remediation, right? There is the in the security world remediation has been there for a long time. There's a established process for detecting of incidents and having a response and even remediating in different layers. But very specifically in this new world of cloud native technologies, the new people, new players involved into the space. Remediation becomes a very interesting thing because like when you are addressing developers, they want the fast and the efficient way to kind of deliver their application. And they're all happy to say that, hey, if you could tell me what are the problems I have from a security standpoint of view, which will be at for a risk for my application later, there would be more than willing to kind of make those modifications and kind of forget, get moving with the software development process. So remediation for their world is actionable information for them within their tool set so they can quickly kind of remediate. So it's like being more prescriptive and being more easy to accomplish compared to a lengthy analysis process is the new way of or a modern way of thinking about remediation, right? Be prioritized, be prescriptive and be programmatic in a way that you can actually kind of accomplish it faster. So that's where I see market, like that's where I see customers moving as they adopt these new technologies, they are kind of reevaluating things, how different tools, security tools to play into the role in different parts of the pipeline and remediation kind of becomes a dovetails into that exercise. And at all of it, I could say that it's all about automation, automation, automation. Yeah, absolutely. And so where do you, I guess, where do you see mentioned pipeline but where do you see remediation fitting in a DevOps pipeline? That's a great question. So when you say a DevOps pipeline, I think we can extend it from all the way from the developer IDE into moving into the CI process, into the CD process and even into CT or what is called as continuous testing, right? Before actually delivering the software. So analyzing of issues and across all of these three parts become extremely important. To take an example, I'll probably show a couple of examples on the screen as well as a part of a demonstration of what the product offers. But in general, the intent is if a developer is using an IDE, let's say let's take Visual Studio for example, they're kind of constructing their infrastructure and these days infrastructure as a code is more popular which means that you can programmatically define what infrastructure you need, being able to analyze it and provide remediation within the IDE is a start point and comes the next rest of the channels which is like pushing these infrastructure code into let's say an ACM repository, a GitHub repository or I'm using some other tools to kind of push or pull templates of infrastructure pieces into my repository. How can I get a visibility into it? That's a second layer. Third layer is as I continuously build the applications and test it, integrating security into it. With that, I'll just take one moment to kind of show you this interesting functionality which I think is actually pretty popular across the user space which we see. I hope you can see my screen. So what you're seeing is an integration of the code element into the Prisma Cloud platform. And what you're seeing is, if I have a Kubernetes YAML file, can I identify issues ahead of time and can I fix it? And if so, what will end up happening? So in this case, we're integrating with a repository, pulling in a Kubernetes YAML file and analyzing that against misconfiguration issues. In this case, like for example, my file, this particular cluster shows that it's like the endpoint is accessible to public, is publicly enabled. This other one which actually says that this overly permissive traffic, you actually also have things like the logging plane is disabled. So you have some of those infrastructure elements, but also detail level about the pod structure and whether it is running as root and everything. I as a developer can integrate this tool into my tool chain, either an IDE or in my repository. The best part here, that's the one which actually not just about telling you what the problem is, tells you the different definition of like why this problem exists and all the history behind it. And I can also go out and say that, hey, fix. When I say fix, it basically submits a PR. So you get to have the rest of all the PRs created for it. And now I am in the, the security tool is in the developer pipeline chain to kind of do the city sharing. Of course, from follow all perspective, we have this tool integrated into the product. We also have an open source offering called Checkoff. With Checkoff, users can actually kind of integrate that independently into their tool chain to kind of do it. So to your question, where does it apply? It starts, the journey starts here, if I may provide before even you kind of move on to a continuous integration testing. It is about when I'm developing, can you tell me the problem I have? Yeah, I think the age old question with remediation is, when do you automatically fix? When do you need some sort of manual review before you apply the fix? So what do you see like your customers doing? Are they one, integrating that fix into the CI CD? So PRs are automatically created, or do you see customers more taking the stance of well, we wanna look at this data first, make sure. So it is, it's the conversation of maturity and kind of, it's also the conversation of like, it's almost like you get trained and used to certain level of checks, right? So nobody wants to fix automatically, because every application, that's the reality, right? Every application is a little unique. But again, it's the journey which they take towards that if I know the known problems, it can be fixed faster, they would like to, but that's where the automated PR comes into place. We are creating a PR, not merging it automatically. We are not committing to that fix automatically, but users can have the next leap of faith after they get comfortable with their processes, they can move forward so too. Because what's interesting, and one of the things that you talked about user space, one of the things which I kind of know from Kubernetes administrators is, it's not like every Kubernetes administrator is creating a new, new YAML file for every incarnation of an application or a piece and most of it is like copying from a different version, modifying a bunch of things and kind of repurposing it. In this case, the number of issues which you find, some of them are kind of very standard in your organization which you can fix automatically, you will accept an automated commitment to a PR. Now, most of the cases you want to take it to the end where you as in as a dev actually has an opportunity to review it and before going forward. What do you see about like, from when you hear to your interactions with customers? Like where are they in that maturity model? Yeah, similar. It doesn't seem to be a dominant answer in the market. There are some that are really risk adverse and want to make sure that they're seeing everything. I think it all also depends, like you mentioned, on maturity but also volume. So in business, critical application type stuff, but if they, it's not much of a lift when you're automatically creating PRs but you can always deny those PRs and delete them versus having somebody go to a tool like Palo Alto and just viewing the details there. Some folks like to go and see all the details. Some developers will look at the PRs and say, yes, no, yes, no, yes, no. Yeah, we actually annotate those PRs with as much as information as needed, Chris speak, so that they have some context and most of it is straight forward, but I agree with you. In general, nobody wants to push a commit button automatically from a tool, but rather they would allow to take you to the end which says, I have a PR, this is a reason for the PR and then take it from there. Yeah, cool. Before I get to my next question, I should have mentioned anybody who has a question, feel free to chat it out. I'm watching the chat stream here as well, so get your questions in, I'll be happy to ask Hari. Now you mentioned the remediation piece is sort of on the left side of DevOps. What about on the right side? What kind of remediation functions, technologies, processes are out there? That's a great question, so as much as we always advocate, like shift left, I think it's a new mantra for 2021 or probably 2022 will be like, everything should shift left. Being said, there's also a need for shifting right as well, but things don't disappear. If the problems happen, they don't disappear automatically. From a utilization standpoint of you, some of the older tools still exist, the IR tools like ticketing systems and SIM systems and other things are all there. As a security tool, most of them would look for a easy, quick integration into their existing processes. So remediation can have two kinds of motions. One, can I prevent a problem from happening? These new architectures like Kubernetes and other things, it's wonderful in a way that you can actually even prevent a problem from happening if some of those standard configuration issues, which can lead into a potential, opening up a potential threat vector in runtime. So you can prevent them from happening. And in some other cases, once a problem happens, how do you react to it? What kind of data do you collect? And how do you kind of audit it? And how do you move forward? In that case, all the tool integration is still valid. I can take a quick detour. I'll show you one interesting aspect when it comes from a preventing standpoint of you before even talking a little bit deeper about how to take an action, right? Let me share the screen quickly. So what you're seeing on the screen, like you saw about the YAML file which you're doing, in addition to that, we also have this option for preventative measures, which is like as you kind of go down to Kubernetes, Kubernetes provides you with this beautiful capability for admission control. Admission control kind of wets what can go onto a deploy, which can be deployed, right? Basically onto a runtime. With open policy agent, this is extremely popular with a language called Rigo. This has been defined. So what you see on the screen here is from Palo Alto, of course, we kind of have an integration in this sense, the same sense with an admission controller. So we can deploy admission controller, which can help you in. If you look at some of these interesting things, privilege part being created, alert on particular privilege part being created, you can actually move down to from an alert perspective, down to a block, which means that it will even stop something from actually happening. So you can enable a quick policy, you can say that do not allow privilege parts into the picture. And of course, you can also import rules from outside, other Rigo libraries, which you see on the internet, which you want to pull in and kind of have copy those policies over, you can import those policies, and you can set those things. As soon as you set those things, everything kind of switching screens here to show you all the events, anything which gets created is got alerted. But that's where I said, like if you have a policy of an applicant, so this is a form of remediation, I would even call it like it's the preventative measure towards actually being remediated. Since you also really mentioned this thing, the whole volume business. So a lot of environment things are very flexible, FMRO spins up and spins down. So how do you manage things? And of course, the second part of it, if things happen in runtime, then you need two things as a part of remediation. One, context and information, two, being able to pull this context or information into the other tools. So we provide taking all of those incidents, applying a lens on top of our judgment layer on top of it to know if it's actually an event, if it's actually just an event or an incident on top of it, like something is happening to your container or a Kubernetes environment, provide you with enough context and you can use this information to be pulled into your remediation tools, which you can either trigger a playbook to kind of automatically kick off things. In the Kubernetes world and container world, the best part is to kind of, you can drop the container pod and have the Kubernetes spin up a container from a known good previous image. So in no time, you actually have an application up and running with a better one. So you don't need to kind of live with the malware, quarantine it, have a terminal in to this process. Some of those things have actually changed over the spirit of time. And that's quite true with all of a cloud native and it can be achieved directly with the tools as well. Yeah, I've always heard, well, you don't wanna shut down mission critical applications, but I think Kubernetes OpenShift allows you to do that on specific issues, suspicious activity because it'll gen back up another pod. And if you have auto scaling and a bunch of pods out there, you're right, you can boot back up from a known version. So what are some of the typical suspicious activities that you would want to destroy a pod on, that you see? That's a good question, right? Typically, we offline, we see like a bunch of these kinds of activities, right? One is malware, malware coming into your system from the whole supply chain process, right? Like people picking up images which are probably not completely vetted or probably not clearly kind of analyzed so that kind of kind of jumps into the system. The other one which actually kind of also happens here is the cryptojacking thing, thing pods being used for multiple other processes. With the over a period of time, it has moved from just being able to kind of signature, identify those binaries to now having a clear set of heuristics and AI-driven methodology to know if there is an actual crypto miner activity happening. I've seen customers kind of set some of these things to be like auto block. And again, not on all environments and some of the environments I've seen are larger customers because of the scale of it. Some of the lower end environments, auto block these things, which means that it basically kills the container and the Kubernetes takes care of spinning it up from a better one, right? So those are the primary ones. And of course, there are some suspicious binaries and other thing, you basically lock down the image that the whole container world and not just containers, even the virtual machine world is moving towards a very immutable way of dealing with stuff. So they want to lock down as much as processes like say having an SSH open, you know, that's supposed to not supposed to be there. So take those things off, which actually has an SSH process is open and spin something up, which actually from an image which without that particular process we've been actually being actively open. So I have seen a varied set of adoption or issues which people can have done these things to that extent of like actually blocking or dropping the containers. Yeah, cool. So thinking about Kubernetes versus traditional architectures, how does traditional incident response tools, do they still hold water? Are they effective in these new environments? Absolutely. The traditional tools are very much embedded into deep into the process chain within the industry. So they are like the ticketing or an IR tool doesn't go away. But there are modern incarnations of those kinds of tools or tool chain. The new vendors in the market who actually do better soar than the previous ones, better threat intelligence on top of the incidents that have been identified to be able to distill better. So there's always an evolution in that space. From a user standpoint of you, things have also changed a little bit to kind of previously nobody is terminating into a container to take it like a dump of all those artifacts you can move forward. Rather, they were like kind of flip and replacement for model, right? So I would say that the traditional tools or I would actually say that the IR tools are there, they're deeply embedded, but they're evolving in terms of accommodating for this new architectures, as well as there's a new set of playbooks which are emerging in the market, right? And one interesting playbook I would actually kind of also see is it's not just about, one is about reacting to it, but also kind of using the learning which is there from the shift right, if I may, in the right side of the runtime, kind of a cyclical process, like pulling this back into your CI city pipeline, which is like a common action, right? If you prevent, you detect, you take the detection back and kind of channeling back from a SOC to a DevOps cycle. These new tools are actually also involved in kicking off some of those automation processes which are data policy set, which are primarily used in the CI city thing. New malware being identified and new CV breaks out, there's some identification just falls back. So it's a change in evolution in terms of IR processes and evolution in terms of a tool chain. Traditional tools may or may not work, some of them have modified, some of them are kind of still in the order space and still order ways of doing things. Gotcha, yeah, interesting. Sort of shifting to the people part of DevSecOps and remediation, one thing we always talk about on this show is DevOps equals DevSecOps. We understand security has always been part of DevOps, but we like to say DevSecOps because we want the security teams to have a seat at the table and that they're as much involved in the process as the dev developers and operations folks that they share the same sort of KPIs, things like that. What do you see security teams doing or that they can do to sort of help implement these type of remediation processes, technologies with developers and operations folks? Absolutely, as we start off this talk track real we've been talking about like how everybody is intended to deliver software faster, better and secure. Security teams have that the last part, the security has a primary agenda, that's their KPI which they want to kind of move this forward. And of course we always been saying with this like, they're always the no sayers of particular deployment and if you've told me before, I would have fixed it before. Now there's an opportunity, you're telling you before, fix it early on and then the best part here is security can bring in a lot more interesting context. If a zero day comes in, if a new thing gets identified, they have their intelligence to kind of distill and say what they need. So it's actually a good handshake where security can help remediate better is by A, being able to help developers to kind of look at what to remediate forward. And there's a good level of handshake which is required of course we saw about requiring detailed information for a dev perspective. The security team still have the control or they have the guidance factor. I wouldn't even use the word control here. They are actually able to guide the team a little better with their insights on these things. Let me give you an example. I think I can, this will be better demonstrated. Something which I recently did with another user of ours and then they kind of really liked this idea. So let's say if I am a dev developer, I live in Jenkins. I live in Jenkins, I live in my build outputs. I get a Slack message saying that, hey, this build failed because of these high critical vulnerabilities. What do I do next? I get to know the details. So I get to kind of come to Jenkins, look at like that my build failed. I can have two options, drop the build, make something else or make, figure out what to fix it. So a tool will help you to tell you what needs to be fixed, like what area needs to be fixed and they can kind of react to it. Or the better way of visualizing this a little nicely into the product consoles you can visualize is where the security team comes into play where they want to know what the developers actually seeing. They get to see that, okay, the same image, same thing which actually happened on the CI pipeline. They get to see what is going on in that thing, which layer is actually failing? What are they incorporating? Where does those vulnerabilities exist? So this is from a view perspective, but where does security team become a better guide? Is they have some level of influence in terms of helping teams do a little better and also get exceptions as well. So from our product, we have this option for adding a rule for the CI process. It can have a very minimalistic way of like, let me say my demo rule. I say Dave favorite application. I'll just use this one here. And say that Dave is my developer who has his favorite application. He would like to know if he has high critical, he would like to fix it. But at the same time, Dave does a lot of work during the process he generates multiple builds and he just doesn't want to keep on kind of looking at an output to do. He wants to kind of even help him manage it a little better so they can set up like a, if a sort of critical vulnerability is identified, set it to critical. And of course, not all the things can be addressed sooner. Some applications you might want like critical is like I need like five days of like a day of grace period or I would like to kind of go to say that I need like few days of grace period, right? So that the Dave has actually has 72 hours, right? Let's say three days. Now comes the security team play, right? Like when they create these things specifically for your application, which is basically I'm setting it for the scope for Dave's application, your application. And I can, as a security team can also say that, you know what Dave, Dave sent me a message saying that I need to have some exceptions on some CVEs which you've read it because I don't understand I cannot fix it right away. I'll have a day's time. You have an opportunity to kind of create exceptions either by a tag or a CVE. In this case, for instance, vulnerability, you're an exception to kind of provide Dave and his application to kind of move forward. This is that happy medium. This is where security teams in Dev are working together in this new terminology, DevSecOps or SecDevOps, however you wanna call it. But eventually they are having a seat at the table where A, they are giving you or enabling you with the tool which gives you information. B, they're able to guide you through the process and more importantly, C, all of this, C for collaboration. They're able to collaborate with you to tell you a little bit better that if you want to raise an exception, yes. Bring me back on Slack, bring me back on JIRA. How can I take this forward? Nice. Yeah, and just as you were showing that demo, we actually got a question from the chat from Indigraph and they're asking, could you show an example where Shift Right gives feedback to CI CD which I think you talked about a little bit. And then what could you think about stack trace runtime and how does that help CI CD? Absolutely. So that's a great question. Thanks for asking that, right? So we talked about, I can break this into three parts. Part A is we talked about prevention is better than remediating at some point of time and the Kubernetes environment gives you the flexibility. Now let's take this example from Kubernetes. You don't have these admission controllers turned on, you don't have these rules turned on. Now you have this new thing which is actually kind of spinning things up and you would like to kind of, maybe I can use a screen to kind of take a walkthrough and analogy here, right? You have an option to say that, okay, I don't know, I have not turned on the admission controller and my team is not responsible yet to kind of take this up yet. It's time away. What can you do to kind of do the loop cycle and how does it loop back? The loop back actually happens by in terms of audits. So if you have audits from admissions, you get to kind of see all these things being created. You either have a Kubernetes audit of things that just happened or you have audits from a security team perspective, these are the things which you get alerted on. Can trigger this back to a policy to be added into the previous policy for admission controller, which we saw, wherein these now can be a new set of policies which we've been enabled. Again, some of the tools including us and Prisma, we are completely GitOps friendly, which means that everything is scriptable. You can just kind of dial it back into the process. That's a way of detecting and pushing it into the cycle. That's one, but more importantly, as we identify more issues, like let's say this is my demo application, not a real application, not to have these numbers on my real application for it. But if I'm a security team, if I have this much amount of problems, I at least would like to see a matrix of where the problem lies. So one of the things which we also do is when we identify some problems and we want to kind of funnel it back into the process, we have these opportunities to kind of, because we do this whole profiling and modeling when I say VS and Prisma Cloud Tool does this profiling and modeling of your application. If you identify something to be a false positive, false negative, or if you want to identify something as to be a thing which you want to kind of push forward, you can extend the learning back. So we extend the learning back, which means that it learns this new application. In addition to it, vulnerabilities being detected, new things being detected, automatically gets added to the intelligence stream. So that's an invisible layer of threat intelligence which actually kind of rolls into the product. The better way of showing this is, I think maybe I can show it this way, like when I define the rules, I define these rules. And one of the things which we always have for anything is use the, use the intelligence stream to kind of detect something, use advanced threat protection. So one of the things which we do in the tool is, automatically keep updating this advanced threat protection rules. So these things get keep, dischance, this is the third part, it keeps churning, we identify new things, we automatically kind of loop back into the system. So you don't need to do anything as a end user, you actually are consuming threat intelligence feed, which is actually live and kicking and reacting to it. So those are three parts, maybe helping in prevention, helping in terms of better modeling of application to kind of add new thing, detections back into it so to prevent better across all the other applications of the same kind. Three is this invisible layer, which actually exists within our system, which we help in kind of populating. So when we apply the rule set in CI, we get to see the new malware which are previously not being seen. So we kind of loop back automatically. Hopefully the person who actually asked the question, it'll be great if you could actually kind of respond back on chat, because we don't have any easy way to kind of know it. So respond back on chat to say that if that kind of helps you understand this question and really appreciate asking this question. Yeah, absolutely. Thanks for the question. Okay, they answered back. So runtime audits, for example, give back to the base images or applications so that they can be improved? Yeah, so the runtime audits, for example, kind of helps you to kind of point out the gaps which are there in the system, which you can actually plug it with this new set of rules. And if you identify vulnerabilities and you kind of moving into the new vulnerabilities that have been identified, and you can actually, as you're controlling these things, it actually automatically feeds in, as you're detecting these things, it automatically gets fed into your, into the intelligence feed for you to be detecting in those things. So that's when I say base images, I believe that our applications, I believe that how are you taking these audits and moving it into venture? Okay. Sounds good. Thanks. Thanks for the questions and the graph. That's good stuff. So we have, I think we're soon gonna be wrapping up, but was there anything else that I missed or we wanted to talk about, Hari? I think we covered a lot of ground here. We talked about shifting left, importance of shifting right, doing prevention with admission controllers and stuff. I think one thing I would like to say is, as a part of remediation, one of the important things is, the information context, logs and being able to kind of funnel it through multiple channels. So if I can take one moment, I'll tell you, I'll use this to share this one here, which is basically all being said, I'm sorry, all being said, you do need an integration into the process thing, which we talked about. So all being said, A, you need the logs, you need the data, you need the context, and you need to be sent to certain tools. So we in Proxima Cloud integrated with a wide range of things, right? It can be a simple Slack, Rajira, I think I, for my teams internally here, we actually have a Slack channel, we keep getting some reports, if at all anything gets anything, it's a second of a threat from a QA environments. But if you have a tool of your choice, integration of your choice, so be it or be it much more open-ended, take it to our web book, take it to any of those tools. And as you could see on this side, it's not just like as much as I would say that everything should be automated. I would say everything could be a close loop system, it automatically runs. There's also a little bit of intervention here, wherein you want, based upon the problem statement, you can flexibly choose to say which tool and whom to reach to, where they became the decision makers. So human personal involved in the process are at least enabling them to act more efficiently by integrating into the tool chain, which they're used to. So that's extremely important. We and other vendors, we're all cognizant of this fact and we can do it in Prisma Cloud, a wide range of integrations in that front. So I think that's the last one I wanna add, Dave, before we have any other questions. Yeah, that was good. And I think about, when we talked about the IR traditional tools, does a SIEM tool play into that as well? Have you done integrations with SIEM tools? Yes, yes, so we do have integrations with like say the popular ones like Splunk and some other things. And of course, we have all our logs being flushed to SysLog as well. So people can take those as a part of your SysLog agent integration into what if they choose to or via API, we can do directly. We actually have an application in Splunk that can actually be deployed directly to kind of pull data from Prisma Cloud into Splunk. Nice. Splunk is one of Red Hat's partners. So if anybody has any other questions, feel free to add them to the chat. In the meantime, I'll just put up the monthly security series slide again. Again, this is a part of a monthly series that we do called DevSecOps as the way. We do podcasts, live streaming shows. I would direct you to Prisma Cloud for OpenShift on the Palo Alto Networks.com site. I found it was the first link after just searching for Palo Alto and OpenShift. Another good site to learn more about Red Hat's DevSecOps point of view. And we have a framework around these different categories is red.ht forward slash DevSecOps. And we actually are doing another live streaming show next week. We're bringing in an internal Red Hatter talking about Ansible. We're doing some Ansible stuff with Palo Alto as well. That's gonna be exciting. And then next month, last month of the year is all about platform and platform security. And that's gonna be a lot of what you get with OpenShift out of the box on top of what you would not get with Kubernetes upstream. So look forward to that content. And I wanna thank Hari for joining us today. That was great talking with you, wonderful demos and continue to look forward to working with you in the future. Great, thank you, Dave. And thank you all for attending the session. Please send us your feedback and add more questions if you have. And Dave, thank you so much for inviting me into this conversation. It's been fun. Good luck. Totally my pleasure. Well, that's it for today's DevSecOps is the way show. I hope everybody stays safe. Take care everyone. Bye-bye.