Hello everyone and welcome. Today we're gonna have some fun discussing proactive strategies for risk prevention and container based workloads with our friends from PwC.

Joining us today, we have Tsvi Korren, Aqua Security Field CTO, Ryan Grabowski, Senior Manager of cloud and application security at PwC, and Cameron Chilson, Senior Associate of cloud and application security at PwC.

Guys, thank you so much for joining.

So everyone in the audience, we all know we're living in a fast paced world. Secure software development is not just a priority, but it's a necessity. And with the rapid adoption of cloud native application assembly and containerization, organizations large and small face very unique challenges that require proactive measures and robust security practices from the very beginning of the deployment lifecycle. So together today, we're gonna shine a light on these specific challenges and discuss some actionable strategies that you all, that can help you all mitigate risks and ensure the security of your container based workloads. That's enough for me. Let's dive in. Let's explore these strategies for proactive risk prevention and container based workloads.

Ryan, I'll pass it over to you.

Hey, guys. Good to be here. So I think when we think about container security, we have to think about the actual threats that we face and why we should even consider securing our container based workloads in our cloud native applications. And in order to do that, I just wanna sorta go through kind of, you know, what kinds of threats you actually face and what people are trying to actually exploit across the cloud delivery life cycle.

So when I think about cloud delivery life cycle or the cloud delivery life cycle, I think about code, and some of the vulnerabilities and and issues that can be present within the code portion of the process. I'll just sort of reveal the rest of the slide. But, I think about code, build, run, and deploy. So as we're doing our development and and sort of pushing everything through the pipeline, you know, you can you can accidentally put, you know, secrets in code, misconfigure an infrastructure as code template, make a repo accessible from the Internet.

During the, the actual build process, you can accidentally leverage a vulnerable container image or or a container image that has an open source dependency from a library that it's leveraging.

You could, misconfigure your Kubernetes, and then ultimately that exposes you in production and at run time, to a lot of different things, whether it be, file list execution that would go undetected if you didn't have a solution that could monitor for it, actual vulnerability exploit, container drift, etcetera. So, you know, whether we wanna think about security or not, threat actors are thinking about it every single day, And it just takes one small mistake at any point left of, deployment to make yourself vulnerable out there in production.

Just like a quick state on the market and and and why, you know, sort of what emerging threats, are looking like and then how AI AIML sorta exacerbates the prominent it's a big buzzword lately, but, attack volume has grown forty eight percent year over year from last year. Fileless attacks that would go undetected by an agentless solution on, you know, Kubernetes, etcetera, have grown fourteen hundred percent year over year.

Most attacks or more than half of attacks focus on actively effading the defense mechanisms that we enable. And then the top ten vulnerabilities in the past year, despite some of the things that have been in the headlines, still center around remote code execution. So it's just a good thing to to keep your your finger in a pulse on, as you secure your environment.

So as it relates to threat actors and why it's easier for them to, actually, become threat actors and and exploit some of these vulnerabilities.

AI and GenAI, we've seen it. It it lowers the barrier to entry. It certainly has lowered it for me in terms of, like, anything that I wanna research or look up how to do. You know, there's an engine there that can tell me exactly how to do it and, you know, make it super easy.

AI provides attackers with the ability to, like, automate and evolve, you know, increasing their scale, volume, and, you know, kinda the way that they can change.

And then in terms of exploitability ranking and analysis, it can, you know, take what would be a a large effort to understand the exploitability of a list of potential vulnerabilities and and really narrow in on what's actually exploitable.

And then lastly, you know, in relation to, some of the remote code execution components. Right?

AI and ML, allow for the creation of sophisticated malware that can change every time it's executed. So, I mean, the threats in the landscape are changing. So if we don't think about it, I promise you that threat actors still are. And and we actually do have to think about how we're gonna manage it in a cloud native environment.

So with, a bit of what's at stake and why we have to be thinking about it, I'll pass it over to Cam to talk about why, containerized applications or or a few misconceptions around, you know, VMs versus containers and code sec versus app sec.

Real quick, Ryan. Let's do the poll. Yeah. Yeah. Poll number one. Quick poll.

Sorry. I blew right through you, Joe. How how how confident are you that you're currently managing, you know, threats, and how confident are you that you you could stop a a cloud native attack today in your organization's environment?

Pretty good split up and down the board. Right? Kind of varying levels of of confidence across.

Yeah. It's actually pretty much in line with with what we're seeing. I think the the the security controls that we had, you know, pre cloud native are still applicable.

They might be applicable in different places, but, we see most organizations having a a fair degree of confidence that they can tackle anything, but there's definitely some gaps that we need to close. And, we can talk about those gaps, in the later this hour.

Let me pass it over to you, Cam, to quickly chat on some of these differences.

Awesome. Yeah. So I think next, we're gonna dive into some of the the common misconceptions that we see. So the first is around transition from VMs to containers. I think everyone can agree that's been pretty transformational for how applications are are run and deployed and managed, but it also requires a big shift in thinking for how we go about securing them. While a lot of the kind of traditional areas, you know, patch management, access, configuration management still apply, We have to change the way we think about them, you know, going from managing it to pipelines and how things are constantly being redeployed and and updated, as well as the varying levels of access that are needed, you know, managing things more through code versus through actual hands on configuration.

Yep. So the the next thing we want to talk through is what the difference between a code and application security is. You know, similar to talking about managing code. Right? Code itself does not equal securing the entire application, and that's something that we commonly see is organizations saying, hey. You know, we're we're scanning our code.

We have measures in place to secure it. Our application should be good to go. Right? When really there's more of a layered approach that you wanna be looking at as everything kind of builds on top, and those vulnerabilities that we see will transition from one layer to the next.

So code is absolutely critical, and it's one of those key layers. As we start to go down the stack, it's important to go through all of those. Right? So next, looking at containers, and the dependencies and configurations that lie there, right, are just as critical.

At the platform layer, whether it's Kubernetes or another orchestrator that's being used, ensuring that the configurations are in place, leveraging something like an admission controller, to ensure that the resources are being deployed meeting your standards is key to making sure that no right, employing right, employing some of those traditional security techniques that we all know and love and have been using for many years, to ensure that the underlying foundation is solid is key to to building that whole application stack in a secure manner.

So next, we wanna dive into what the the solution looks like for how we really think about going through the process and securing all of this.

So when it comes to securing containers, we like to think about it as a process, right, a continuous pipeline to to go through and get steps along the way. It's not individual discrete components, but something that's really linked together. So starting at the very beginning of the build, identifying what your golden images, what your secure configurations are, and conducting scans to make sure that what you're building and those images really meet those, and providing assurance around those images.

From there, pushing those images up to registry where they'll continue to live until they're deployed and running continuous scans of that registry.

Suddenly vulnerable even though we had previously said they were fine after they were built.

Suddenly vulnerable even though we had previously said they were fine after they were built. So having that continuous scanning to ensure things don't go stale is key as well going into deployment.

Finally, the last thing prior to deployment is having that pre deployment check. It's something you can gate on, making sure that those containers are ready to go, meet your standards, and can be deployed into a production environment.

Once things do get deployed, right, it doesn't stop there. We wanna continue to to monitor and make sure that things are remaining with secure configurations, that there's no malicious action happening at runtime or Sys calls that we're not expecting, as well as looking for drift. Right, we don't want people going in and modifying these containers at run time, after we've already signed off on those configurations. So having some monitoring around that as well.

The last thing, to call out is just, you know, similar to what we talked about before with that underlying platform and ensuring that we're monitoring the configuration of that with something like a Kubernetes cluster posture management solution, looking at configurations there and seeing how that might affect what and how these containers are being run.

Now to actually get to that point, it's definitely not straightforward process. There's, you know, different varying levels and activities that need to be worked on by different organizations. So one of the key kinda foundational steps is really around the governance. So identifying what your controls are, what your golden image looks like, what the processes in place have to be is pretty foundational, right, to to building that whole organization.

So being able to enhance your government around that code to cloud process and have everything defined is very helpful.

Next is around identifying what that process is for creating that golden image, really nailing down how those scans play and having some assurance around what you're building is crucial.

Once we have those things, we can start going towards, building out scanning both in the pipeline and at runtime, starting in an audit only state so that you can provide feedback to developer teams as well as news operational teams can really tune in what you're looking at. And once you have that audit kinda nailed down, start moving things to enforcement. So blocking things before they go to a deployment or go to production. Once they're in production, blocking risky actions, is crucial to ensuring that vulnerabilities aren't being introduced to the environment.

I think one thing that we found is that this can absolutely be very difficult to do at scale.

So often starting with a small pilot team, an app team that's, you know, willing and wants to start going through this and then using that as a success story, throughout the rest of the organization has been really helpful.

Yeah. And I think it's a gradual process of training people how to think. Right? The governance sort of lays the foundation and communicates out what's going on.

The golden image creation process is gonna slap on the wrist to say, hey. I I would have blocked this particular image that you were trying to to say, hey. I I would have blocked this particular image that you were trying to leverage, or, hey. I I would not have let you deploy this.

You know, in the future, you know, this is gonna be out of policy. And then you do some some minor enforcement and then ultimately get to a point where you can, you know, take action at run time and inform your incident response function. And, and, you know, going about it in this sort of gradual way where you take a process based approach and and really communicate out what's going on, I think, has proved successful at, at several different organizations as, like, a a baby stepped approach to runtime enforcement.

Yeah. Let's rock it. So I guess, out of this, how close are you to runtime enforcement and blocking would you say?

You know, if you if you turned on runtime enforcement today, how many people would be, upset with you, versus, versus you're kind of ready to rock it and it's already maybe going within your environment?

Awesome. Yeah. No. See some tens up there. Always great to see and absolutely see people in varying stages.

Right? It's not a straightforward easy path to get to. There's definitely a lot of steps and checkpoints, you know, each building on the rest. So it makes sense.

Awesome. So with that, we'll transition to Svi, who's gonna talk a little bit about where Aqua fits into this larger process picture.

Thanks, Ryan. So, you know, we talked about and the last poll question was about the the ability to block. And we said we we talked about blocking. There there are several places in the application life cycle where we can affect security. So if you look at, you know, a CICD pipeline, modern CICD pipeline that has the ability to, generate images and then push those those deployments, there are, a few natural places where we can put security. So if you look at the left side of the pipeline, as developers and as application teams, pour open source components and design their applications, we have the ability to then scan those and start to get a measure of the risk of what are the things in that application that might affect, the ability to protect it at run time. And we usually talk about vulnerabilities.

Those are the things that everybody's after, but there's also secrets. So are there embedded, credentials or something hard coded inside of the environment? And then the configuration. Right?

Because the the development organization is in charge not only for the content of the application, but now in the modern application pipeline also, the prerequisites and how it's going to be deployed. So those Kubernetes files and the files that that bring up the the cloud resources. And we have an opportunity right after usually after a commit or after a, a a an image build to then do a mandatory security scan of both of vulnerability secrets and configuration and have an acceptance gate. Now that acceptance can be hard or soft.

We have the ability to block, images or, configuration items from advancing, into the cloud or into the registry. Or we can just give give advisories. But the idea is that that that before you actually commit your, artifacts to a public place where it can be used in the environment, we wanna make sure that it is, agreeable to the, security guidelines of your organization. Every organization is gonna have different security guidelines based on the regulatory environment that that you live in.

So that is our first acceptance gate. And when we say, you know, can we block it? That's one of the things that we mean. Do we have the ability to then deny, let's say, a image to be pushed into a registry if it does not have the right security posture that we're after?

The second place where we can do some enforcement is on the, right side of the equation. So that would be the ability to, maybe allow risky components to go into our repositories, and they may be used in, you know, testing or maybe used in staging, with some allowance to the to the security risk that they bring. But when we go into actual production, we wanna make sure that we have a hard gate there as well. So we have the the ability to do those acceptance gates.

One of the things that is really important to to understand is that that we need those security controls to be consistent. You can't say I'm gonna let, you know, high vulnerability pass in in development, but not pass in productions because then then you're confusing everybody. So the idea is to have consistent controls. If we do not allow critical vulnerabilities in our environment, let's do it from the get go.

But we could not enforce until we actually go into production to give opportunity for for for for changing. So as we as we go through the pipeline, pipeline, we need to give people the right information so that they can fix, those those problems. And then, you know, issue another artifact that we can then push into into the environment. And when we talk specifically about vulnerabilities and the vulnerabilities that are that everybody's know because they're published in in our in our in the news.

If you look at at vulnerabilities on the next slide, we have the the ability to see a lot of data points on those vulnerabilities. So it's not just, you know, the the vulnerability name and score. Right? You know, CVE one, two, three, four is critical based on the NVD.

Therefore, we should not have it in our environment.

Usually, that kind of statement is is a kind of a rookie mistake for for a security organization that tries to take control over cloud native because we are putting an impossible goal in front of our developers. We need to be a lot more nuanced. We need to be a lot more, I think thoughtful in the way that we put our security controls in place. And when we talk about specifically vulnerabilities, there are, you know, a couple of dozen, data points that are probably applicable.

In the Apple solution, we provide you with a lot of information, that can help you decide whether or not you want that vulnerability fixed and whether or not you want that vulnerability fixed fast, meaning that you would maybe catch it in the earlier acceptance gates in in your process. So one of the things to to look for are, you know, the vulnerability severity, the score, but also the exploitability.

Aren't is that vulnerability exploitable from the inside or the outside of the organization?

Because cloud native environments are not usually administered, at least not by people, any vulnerability that requires console access can be usually deprioritized, while vulnerabilities that have remote access or can operate via the network usually should be prioritized higher.

Another thing is whether or not an exploit is available in the wild, if there is an exploit available that anybody can use, that lowers the barrier for that exploitation. And therefore, we probably need to fix that that vulnerability.

The age of the vulnerability, when it was discovered, when it was discovered in general, when it was discovered in your organization, where is it coming from, All of these things are really important to make an assessment of really how much you need to push in order for that vulnerability, to be fixed. And I'll and I'll point you to the the number sixteen on the list here, which is the source image of the build. Right? When we talk about golden images, when we talk about approved base images, we wanna make sure that those are clean or as clean as we can have them so that whatever we build on top of them will not inherit vulnerabilities that go outside of the the, of security posture that we want for our our organization.

Now one thing that that this this should provide, it should provide you with the ability to then, prioritize which vulnerability needs to be fixed. And one of the things that we've, put in in place in the Apple platform is to use AI, but they're like a white hat AI. Right? Use AI to fix that vulnerability.

A lot of times the the problem is that the developers don't really know what to do with specific vulnerabilities. You know, the the description in the NVD, the the finding, even upgrading to a next version may not be be feasible. So we need a little bit more help. We need to tell them how to update to a next version if one is required or how to work around it if we can't update to to another version.

So this should all promote that cycle where as early as we can, as early as feasible, try to weed out the risk from your images from both vulnerabilities, configurations, and secrets so that as you push those along the the pipeline, they will get cleaner and cleaner.

And clean images provides you with, with with less of a chance that somebody is going to be able to intrude into them because we know that what attacker wants to do, they basically wanna take ownership of your environments and and and your workload. So on the next slide, we have kind of a chart of really what are the options that that attackers can use in our environment. Right? They can use a misconfiguration.

They can use a vulnerability.

They might even exploit the supply chain attack, you know, like we saw in the, you know, the XZutile, a few weeks ago where we had, actually a lot of work being done to introduce a vulnerability or backdoor actually into into a a an open source component. And all that is kind of the entry point for external attackers. We also have internal attackers, right, potentially internal attackers that could also, go right at at our workloads. And from there, once you have some kind of footprint on a workload, things can go very bad, very fast.

You can because we are living in an orchestrated environment, getting into the container engine, getting into the Kubernetes engine, getting into the host. These are all possibilities that are open to, to attackers, depending on what they want to do. They might want to just take over the host in order to run something, or they might want to run more images on your Kubernetes, or they might want to expose your Docker or your container engine environment to, to external attacks. So all these things are really unique.

And and one of the things that Aqua does is it can put those controls in place to help you mitigate or counter some of those actions in an attacker. Now on the next slide, we have the list of things that that attackers actually can do in a cloud native environment. Right? So access to Kubernetes secret, access to the Kubernetes API, access to the container exactly from one container to the other, hijacking resource like storage in the Kubernetes environment.

There's a lot of things that that that we need to pay attention to because Kubernetes is really a data center in a box. And and everything that we know about a big old data center really needs to be thought for, for Kubernetes.

And, and we also need to map those so that we know which phase of an attack and action denotes so we can understand, you know, how far we are, in in in in into an attack. And for that, Akko provides a lot of controls at run time. Time. Right? We had the ability to see vulnerabilities and and misconfigurations, but if we go into the controls at run time on the next slide, if we over overlay the, the controls that Aqua provides over what attackers wish to do, each one of those blue bubbles here is a control that Aqua provides in order to mitigate that action. So by scanning cloud, Kubernetes images, putting those acceptance gate, we can, deny external attackers the initial way to get into the environment.

But doing things like, you know, blocking exec into containers, blocking shell access access to containers, blocking movement of, commands from one container horizontally to another or to the Kubernetes or to the Docker engine.

Understanding, drift prevention, which will deny the execution of anything that was added after the container was running. This is kind of a catch all for anything that has remote code execution in it. And then as we go down to the host, we have specific capabilities to deny some of the popular actions that attackers are trying to do. And those are, things that span both behavioral detections, but also rules.

Right? You may decide that there is no good reason for somebody to use, let's say, user ad inside of a container, which is actually a very plausible thing to do because usually users, you know, containers do not need more users. But if that user ad is there, an attacker can absolutely use that to add a backdoor even to a running container. And by denying we can do that.

And that's one of the differences. Right? You can't have a denying user ad on a on a server because it needs to be managed over time. But it's very easy to do that on a container because it lives a short time and it's only doing one one thing.

So on but if we understand the difference between monolithic application servers and containerizations, we can actually have much more granular controls, which will help us put some prevention along the way. And when, you know, organizations that are afraid of prevention, and we saw a couple of of answers there. People said like three or four on the whether or not you are comfortable in doing any kind of blocking.

This kind of blocking that you see on the screen before you is very granular. So if you block something, it will only block that that action.

And it also helps with incident response. Because when we talk about incident response, and and on the next slide, we have kind of the the the building blocks of an incident response in the, in a cloud native environment. Even if we do some heavy handed incident response, even if we block, because of the kind of self healing nature of cloud native, we, we won't cause any damage by even, you know, taking down a specific workload. Now not a whole deployment, but if we just take out a specific workload, let's say we have a security event and we can isolate that workload, we can clean it up, another one is gonna pop up in its place.

If we have good Kubernetes, deployment structure, whenever a pod is down for whatever reason, including whether or not we blocked an action that was, countermanding an attacker, another one is gonna pop up in its place. It's gonna come up pristine because it's reinstantiates from the image. And even if we have to take a whole host out of commission in a cloud environment with auto scaling groups, Even if we do that, another one is gonna pop in its place.

One thing to to understand is that you always always leave a little bit of slack in your deployment. Right? If you think that you're gonna need four workloads for the flow deployment, you know, put another one in place just to compensate for any security event, that, that that that might happen. And that should allow you to have kind of an autonomous system that will fix things and, and and compensate for those, over time. So when we talk about, just the tooling that Apple can provide, we can provide tooling at the beginning of the pipeline, scanning, acceptance gates. We can provide tooling in the deployment, understanding what a workload is doing in both behavioral and rule based. And then on the incident response, can facilitate that action where, workloads are replaced and then security incidents can be closed.

Awesome.

Thank you, Svi, for taking us through some of the capabilities that Aqua provides. So, really, what we're trying to say, guys, is, you know, combining a best in class solution like Aqua that can help across the entire life cycle as well as, you know, enabling some core processes within your environment, really make for a comprehensive solution as it relates to the entire container and and frankly, cloud native life cycle for whatever it is you're you're deploying out into the environment.

So we're gonna talk about some common challenges quickly.

So, look, you can have a a best in class tool and built out processes, and you will face issues out there when you go to implement this at an organization. Right? It's just the nature of any sort of technology implementation. There'll be different friction points. So here are three friction points that, you know, are fairly common and, you know, I can make a list of ten friction points, but, really, we'll just focus on three for the purposes of today's discussion.

So one would be shift left remediation friction. All of a sudden, you're going to developers and and people kinda managing the infrastructure and telling them that there all these vulnerabilities that they have to now fix before, production. And that has its own level of, friction and pushback. And you get everyone in security has been in a conversation where they're being asked, is this vulnerability you're asking me to address even exploitable? So, some some common friction points there that you'll probably run into. Two is container life cycle management, especially if you're not blocking at the point of deployment and you're you're relying on clean repositories, managing stale images and and image tags and, archival processes, etcetera, associated with keeping a clean repo.

Definitely a challenge that a lot of organizations face. And then once you have all this information. Right? So Svi showed a list of, you know, a hundred different factors that you could know about a vulnerability.

Now combine that with your asset management solution that tells you sort of what the criticality of your app is, provide it with your other security tooling. Sorry. Combine it with your other security tooling. And now you're like, what do I gate on in this scenario?

At the point of release, I have this plethora of information. So I think that's also a common friction point we see people see see people go through where they're trying to figure out exactly how they should go ahead and gate, at the point of release. So in terms of solutions, one of the things for developer friction that I've seen that's been super successful is, actually just giving yourself a data backing for why you're telling them to actually fix something.

So give them the factors that would make something actually exploitable out there in the environment. You know? Is the file deployed? Is it in memory? Is the code reachable?

Do stack trace logs exist, etcetera. Right? Like, what combination of factors is gonna make, you know, combined with, I guess, an application severity is gonna make something completely nonnegotiable, for remediation so that you can get out of these arguments of, like, subjective, is this vulnerability actually exploitable? Like, let's come up with a criteria and and put some, you know, put some objectivity behind some of these decisions that, we're making when we're going out to remediate. And I think it removes a lot of the friction when you bring the data to the table.

And then in terms of the life cycle management, Cam is gonna briefly talk through, some of the potential solutions around that.

Yep. So, you know, as Ryan was mentioning earlier, right, one of the common friction points, similarly, is managing the life cycle of these containers.

As they're going into the registry, they end up staying there for a while.

And, you know, if you're not doing that gating or scanning prior to deployment as well, it can introduce some additional vulnerabilities.

So, you know, leveraging a tool like Aqua for that continuous scanning throughout the process gives you a number of options for what to do when you identify these older or containers that have, you know, new or existing vulnerabilities that are found in them. So whether it's, you know, urging them and deleting them, sending them somewhere else to kind of be held off for a while, just having solution in order to continuously be updating and looking to ensure that you're not accidentally leaving things in there that are vulnerable and then have teams maybe referencing some older versions of those containers.

Yeah. And especially if you're not blocking, I see all the time people create a golden image. It goes into the repository, and then it's this clean repository that all the images are in. So you're allowed to deploy as long as it's from this repo, and then it's a stale image. And you're just sort of deploying something that it it is stale and building with something that doesn't necessarily have, like, the latest, the latest and greatest on it. Right? So coming up with a formal strategy around that management, is almost mandatory, and it's like where process meets technology.

And and just saying, oh, we're gonna tag them or we're gonna archive them or or what's our exact approach to resolving this issue? So, Kim, and then I'll pass back to you to talk about some of the different things we can actually gate on.

Yeah. So when we think about gating, right, there's a number of things. And I'll hit on a a few of the main ones that we see. I think, you know, first and foremost is those nonfunctional requirements. Right? So ensuring that there's some level of of unit and integration testing that's done, especially if you are, you know, promoting referencing latest tags of images that are being pushed up there, ensuring that there's that testing done prior to deployment so that people's applications aren't gonna suddenly start breaking.

The next one, I think one of the most common ones that we see and talk about are vulnerabilities in general. So as Vee mentioned, you know, gating on high, critical vulnerabilities. Right? Having kind of your threshold defined for what is allowable, within the the vulnerability space.

The last one I wanted to touch on is misconfiguration findings. So this might not necessarily be something that's an identified vulnerability.

But if you have existing rules around things of, hey. You know, we want these containers to run as specific users, or only have certain access or, say we don't wanna allow certain commands within these containers to be run, having that within the pipeline to to block containers that aren't, abiding by that rule set is is another good way to ensure that you're keeping a a clean and secure environment for these containers that are being pushed out.

Yeah. And then, like, start small. Right? Like, you can't just start off, you know, we're gonna gate on all of these factors.

You know, commonly, I see, okay. Let's just, like, begin with gating on critical and high for vulnerabilities, and then we'll kind of gradually move up from there. So a combination of, I guess, you know, some of the integration and regression testing with the vuln with the vuln management component is like a starting point. And then you can start to build in all of these things like provenance or, defect escape escape rate, etcetera.

And, yeah, to to build off that rate, I I think it's important to realize that it's not you know, you you flip a switch, and everything's gonna be fine. Right? It's a continually refined process. There's gonna be, you know, exceptions here and there that you know.

There's gonna be some tuning that has to be done. So just just making sure that it's something that stays top of mind and that you're having an open dialogue with application teams about, for, you know, not only what will make it more secure, but but what will help them as well. A lot of these things are are built to help make sure that their applications are are running smoothly and then operating in production as expected. So having that dialogue is is key to being successful around your gating strategy.

Yeah. Cameron, I think you sold short the the communication, requirements here because, we are we are living in in a new world. We're living in a new world where, you know, the lines between security ops, which kind of disappeared, and development have been blurred.

And we really need to have that that communication in place. I remember in the in the early days, you know, Aqua had been around for eighty years even before Kubernetes started. And in the, you know, in in the early days, we would go into into organization that just started to experiment with containerization. It was really the first time that, many people from the the security side were talking to actual application developers. I mean, they were introducing themselves in the room as we were introducing ourselves.

And and those kinds of discussions really have to happen. Right? We we can't be unreasonable with our rule set and just impose things on the development and application side that they're not ready to do. And we really need to have that communication. So everything that you see on the screen here, all these processes and all these controls that that need to happen, rely on communication, on agreement.

There, you know, we can't agree to anything as security. Right? We gotta have some some red lines, but we also need to understand that this is new for everybody. It's new for developers that now have to, you know, be responsible for things that they were never responsible, for before, like, you know, the base operating system. We usually got got that from ops. And for for security, we have to go down to the left side of the, of the equation here in ways that, you know, as a, you know, twenty plus year security professional, I really never had to do before.

And so this is this is still a new situation. We're still evolving. And, the more we communicate, the more we come to agreement, the more we understand why things are done, I think the more success we have in implementing those controls and implementing them in a sustainable way.

Yeah. Totally agree.

So if if everyone's alright, we'll jump to, the next section, which is just, like, how we can help, you know, where technology meets process.

So we put a couple of personas on the screen, and I'll just go through them really quick and, you know, where we can help in each of those areas. So, you know, if you're ready to start moving to containerized workloads and you haven't really ventured out at this point or you already have a a footprint but haven't solved for security yet, you know, it can be a really daunting problem to say, wow. I have to do all six of these steps, deploy all these enforcers. Right? It it can be, like, you know, kind of a lot to take in at once, but it's important to start small. And I think where we've seen success, with with these types of personas is helping to make a case for change, whether it's a current state assessment to tell you where you currently are, and road map for how you actually plot the path to the future, or a proof of value leveraging aqua or or a technology that, you know, is able to sort of help protect you across the life cycle.

I think that these really help everybody understand why we're doing what we're doing and really show what's under what's been under the hood the whole time, whether we were looking or not.

And come making sure that we combine it with, you know, the cloud security strategy as well, I think, is a a major component of, you know, helping folks who are just getting started. And then let's say if you're medium maturity, right, and, you are leveraging containerized work loads and you've built out some processes, but you're really lacking the consistency and execution. I think we see this all the time where pockets of the business are having success or, you know, you do have a golden image creation process, but the repo has gotten out of control, or you're gating a bit, but you got tremendous pushback from security, etcetera.

You know, we can help out to build those, golden image creation processes, help set up continuous registry scanning and maintenance, you know, do some pre runtime assurance and release gating or set up runtime protection and incident response. And the only way we can do that is if you have a best in class solution like like Aqua. So, really, this is where the, you know, white glove service meets the the process. White glove service meets a a best in class tool to deliver, you know, an end to end solution.

And then lastly, if you're advanced, right, you only need help in this one specific area or you're really having a tough time with just gating or you're really having a tough time fine tuning or integrating with your incident response or or really getting some of those downstream integrations going, I think that's another area where we can definitely help and maybe reimagine. And you may be looking at a problem an inch from your face, and sometimes it's helpful to have someone with, outside experience to take the thousand foot view so that we can get back to that one inch view and sort of get back to day to day operations. So I think whichever persona you fall into, I you know, we've we've helped someone similar to you and definitely would love to, to continue to help. So I think there's a a quick a quick poll.

So where do you think you fall on, on this scale of just getting started to advance? I'm expecting you tens out there to put to put your, your you yourself into the advanced bucket.

Medium's off to a big lead.

I love it.

Medium's the fun part. Yeah. That case for change is fun too. I I think they're both fun parts.

Just give it a little bit more.

Thank you everybody for participating participating in the polls, by the way. Appreciate it.

Alright. I'll share the results now, team.

Oh.

Yeah. Pretty interesting split.

Yeah. I think where wherever you are, like, between the between Aqua and and, you know, some sort of services, I feel, you know, we can help you kinda get over the line on some of these items. So good good to see sort of where the different crews are.

With that, you know, classic bell curve. Yes.

I can't say yeah. Classic bell curves.

So, yeah, how to get in touch with us? Look. It was great talking to you guys. We have a we have a a a few more slides, but just in case you wanna continue the conversation, there are two major ways to get in touch. So Aqua is gonna be at RSA, and, and they have an awesome booth set up and some cool giveaways going on. So if you're at RSA, come reach out. It's booth eighteen thirty five.

And then, obviously, for those of you who, are trying to dodge the hotel prices for RSA, as I as I know, I I am myself, the, email is also a great way to reach out. So if you guys wanna reach out to, you know, either John or or Dylan, I I think they'll help redirect your request. And, of course, if you wanna reach out directly, to me, feel free, and, and we can help, help direct everybody.

Thanks, man. I love seeing all the the, reactions popping up. I don't know if you guys can see that.

I can. I'm missing it. So I'm I'm only sharing in half the fun. But, Joe, if it's not inconvenient, if you don't mind just putting the three emails in the chat, I think that would be super helpful.

Yeah. Yeah.

And then while Joe is throwing those into the chat, we're just gonna talk about a real world success story. Like, where have we taken the the process piece and, and and a strong technology to drive real change? So, Cam, I'll pass it over to you.

Yeah. Absolutely. So ending off on, you know, know, one of our success stories here. So we had, you know, working with a company, global technology company, footprint all over the world in small private cloud environments set up in multiple different countries.

And they had a bunch of technology. They were working to string together, you know, a series of different open source pieces to try and build this larger picture. And they're they're really struggling, both correlating results across the different tools that they were using as well as just managing the the operations of all these various tools and how they fit together. So what we were able to do was partner with Aqua, be able to bring in Aqua as their their end to end solution, and really help drive consistency across all of their processes as well as, you know, kinda take a white glove approach and take away things from just being worked on at the end of the desk and build out the processes to support that, as well as really help them operationalize the tool so that they were able to derive some good metrics from it, have more targeted conversations with the app teams, and really be able to look at these results and and understand saying, hey.

You know, we're not trying to get four different tools together and figure out how they correlate, but see everything all in in one place and be able to to trace things all the way from the bill through things that were happening at runtime, in in one consistent location.

Yeah. I think the the points to emphasize from Cam are are one, this team we were working with was highly technical. Like, they were stringing together all these open source tools and really build almost like building their own homegrown platform. And they realized that it was just better off buying the enterprise solution and having someone else sorta string those things together for them and and stop working on something on the end of their desk, to Cam's point.

And then the the last thing was, again, they had all of these other responsibilities going on. So having, a professional services firm come in and just bootstrap the process and get them set up, and build out some of these components so that they could get back to operations and focus on all the other things that they were managing. And, you know, more so the one offs and things that come out of the tool versus building it from the ground up. I think between the two, they really had a lot of success. And they're in the order of magnitude of thousands of enforcers at this point just sort of scaling out, their environment. So I think it was a real success story, and and they're really happy that they they stop they let their, they stop trying to be overly technical and let someone else take, hands on the keyboard for for a minute. So cool.

Well, yeah. Well, I think, our email should be in the chat.

You know, feel free to email us and reach out and and ask any questions, even if it's just like to set up an informal discussion. And then obviously, RSA is a great place to get in touch.

I think look out for, Dylan or or Joe at RSA and, you know, go ahead and, tap their shoulder and and and they'll get you in touch with the right the right folks. But anything else from from the the team here before we close out?

I'm cool. Ryan, Cameron, Steve. Thank you guys so much.

I'd say thanks to everyone for joining. Thanks to everyone for participating.

And as Ryan said, yeah, we're we're happy to meet with everyone at RSA if you'll be out there. But again, please reach out directly to the folks here that, that put on this great webinar for you today, and we'll be more than happy, to answer any questions you guys have and and assist in your journey. So thanks again.

Love it. Thanks, guys. Appreciate it.

Thanks, everyone.

See you at the next one. Bye. Bye.