Cloud Access Management with Apono’s Rom Carmel

This is Textron tv. Hey guys, thanks for the thrill. 5 million for well cloud access management, but I guess they got a new spin on this rom welcome to the show.

Yeah, great to, great to join you, Mike. Thank you for having me. I think we've been struggling with cloud access for a long time now, and I guess, but I'm a little bit confused as to, well, what can be done about this than we haven't done before and what's possibly different?

'cause I think we've all just accepted the fact that maybe this is difficult and we're never quite gonna get our arms around it, but perhaps things are changing. Yeah, I think things are changing from the solutions that could be provided and also from the evolving landscape of challenges when it comes to, to cloud access. Uh, and, and, and being able to manage that in a way that's, on one hand, allowing your organization to reduce the attack surface, while on the other hand, creating frictionless process in the organization to allow the engineers and other end users to receive the access that they need when they need it.

Some of the, I think, largest challenges that we're seeing these companies are facing today, they're involving over privileges in the environment. And the thing, the thing to note is that these environments, especially in the cloud, are constantly expanding and growing, right? With, um, infrastructure that is being spun up with a live code that's been written essentially.

Um, you have a constantly growing environment that now need to betain to and to gain back control of the access to combine that with the ever-changing dynamic needs of, uh, permissions to be able to support, um, the more agile way of working, the more, uh, fast product time to market, uh, uh, organizations that we have today. It makes it, you know, especially hard to keep up and quite a challenge of getting access, right, uh, in, in these, uh, in these environments today. And I think you've come to it quickly, there's a tension in the system.

We have developers and engineers that want to be able to provision resources themselves, but a lot of them don't have a lot of security expertise. And so bad things happen and things are left open or exposed, or people steal credentials and then they can escalate privileges. And the security people there don't seem to be able to provide some adult supervision.

So how do we kind of get to some happy medium that both sides can work with? I think you really touched it there, and I think the, you know, our mission in PON is to empower organizations to run into the cloud by bridging that security operational gap that you're talking about when it comes to access management, trying to help companies achieve those zero standing privilege approach with our just in time, just enough access across their, you know, cloud services, databases, servers, and so on. And we're helping those companies achieve that balance that you're talking about.

I think it starts, uh, from a shared responsibility model. We've moved to, you know, in the past we might have had it organizations that are fully in charge of the infrastructure. And with our move to the infrastructure in the cloud, there's a shift, um, to the management of that infrastructure by the engineer organization.

As security practitioners though, we want to, on one hand be able to gain back some of that control, as you mentioned. On the other hand, we wanna allow the organization to continue to move fast and not stifle their ability to work. And I think this is that understanding that now there's this kind of shared, uh, responsibility when it comes to, when it comes to also the security because these engineering teams are the ones managing the infrastructure today.

I think sometimes the devil is in the details for that shared responsibility. I think everybody kind of nods their head and says, yes, I understand, but then the actual execution of that then gets lost somewhere. So, um, how should we be thinking about shared responsibility?

How do I actually achieve that? Yeah, that's a, that is a great question. Um, I think it stems from the type of tools that we're bringing in.

Um, today a point, one of our focuses was building a solution that actually speaks the language of the DevOps or the, uh, you know, the persona that is within the engineering organizations, managing that infrastructure and able to connect to the tooling that they're using today, um, to be able to support, um, the environment and on the other hand also be able to provide the, uh, the security teams the way to put in the right access guardrails into the same solution. That kind of communication layer, if you will, thatno is able to bring to the organization, I think is, is a big part of it, making them being able to speak on the same language over this new new, uh, frontier new infrastructure. Essentially.

Another piece of it is the connection to how the end users work, so that you're able to, uh, as an organization adopt very quickly, uh, these new types of solutions connecting to how, uh, the engineering teams work, connecting to how, you know, data scientists, whoever it is that need access to these more privileged type assets in their organization can continue working in the same way that they're used to, therefore being able to adopt it much faster as an organization. So how does your platform work exactly? What's involved in kind of setting this thing up?

Yeah, so from setting up perspective, it's super easy to deploy. Um, even more importantly, seamless to adopt. Usually customers deploy within few hours to and have it deploy within, you know, two weeks to their whole organization using the platform in terms of how it works, one will continuously discovers the environment, able to enforce the access guardrails, and over that, the auditing, the access, providing alerting on top of it and leveraging ai, we're able to even further narrow the policies, um, and further right size it to the organization.

Now, our access guardrails, and this is kinda where you mentioned devils in the details, leverage the organization's dynamic context. That dynamic context could be the identity context that we're bringing in, whether it's your groups location, MFA is on or not, uh, ticketing systems and so on. Pretty much any context that you can think of in terms of something that's attributed to the identity.

We're bringing in the resource context, like the sensitivity of the resource environment type production, customer facing, whether it's in the EU or the US location, and more type of context. And based on these contexts, we're able to put in the guardrails to help you enforce access in a way that's connected to the business unit's needs, and therefore achieving this desired state of zero standing privileges in the environment with just in time and just enough access to the task at hand. That almost sounds pretty straightforward.

So what was the hard part about doing all this? 'cause the issue's been around forever, so what was the technical challenge? Yeah, so I think there's, there's multiple technical challenge that they're facing, a solution like this to be built, and I think one of them stems from managing access to some of the most privileged parts of the environment.

And you wanna do that in a way, um, that keeps the customer secure on a solution, is able to do that without having access to the customer environment, without storing their secrets, and therefore is able to be deployed very easily and confidently from a security perspective as well. Another piece of it is being able to integrate to all your environment and, um, and to do that with the expanding amount of services across multiple clouds, dozens of databases is something that needed to be taken into consideration as we were building the architecture of the solution and understanding that we need to be integrating to all your environment and to keep up with constantly being, being able to do that. And How do you keep up?

Because developers will reconfigure databases and occasionally misconfigure them along the way. So yeah, how do you know who's doing what when? Yeah, so Apollo is able to directly integrate into the resources themselves from the cloud level, but also down to the specific resources and discover and understand, uh, who and how is being accessed to what and so on.

And we're constantly doing that, and I think that's super important as you're thinking about a solution that's fitting the cloud environment, bring a solution that's set and forget, won't just, you know, won't be relevant because it's a static way of kind of thinking of things as it was in the past. But today the environment is changing, as you mentioned, people's work is changing and you need to constantly be connected and monitor, um, you know, the what is being received and how, and even further have a solution that's able to automatically, uh, enforce dynamic type of policies that are able to keep up with your changing environment. And I think that's a very, very important point that you're touching on here.

Who ultimately is in charge of this. And I'm asking the question because, well, if I leave enough to developers and the engineers, that's kind of like asking the fox the guard, the henhouse, right? But if I go with the security people, there's only one of them for every a hundred of those other folks.

So how do we kind of figure out, you know, who's in charge and how to manage this thing? I'll add to that complication that security teams sometimes have a hard time speaking the language of these parts of the environment, which makes it even more complex to, for them to fully be in charge, um, in that sense. So yes, I think there is that, that kind of gap that we were talking about.

I will say that even on the engineering side of the house, there's the clout platform teams, um, there's the, um, develop DevOps, just dev operations teams and so on. These people are also seeing themselves as in charge of the infrastructure. And with that, the access to this more sensitive parts of the infrastructure, they don't necessarily have the security, um, mentality in place.

And that's why it is a team effort in terms of, uh, in terms of governing the access when it comes to these parts of the infrastructure. And I think one of the things that we're seeing is upon being able to act as that method of communication between these two somewhat siloed parts of the organization, especially in larger enterprises. Um, so to your question, that's exactly where the shared responsibility comes in.

Um, and it needs to, and it needs to be, uh, like that from the start. Um, yeah. Do you think the bad guys out there are kind of sometimes laughing at us because they, um, they, we talk about all these vulnerabilities and yet fundamentally I feel like we just keep leaving the doors unlocked and the windows open, so they're like, why are they gonna go to so much effort to write sophisticated malware when access is easy?

I mean, you, you said it for sure, and, and I, I didn't share this, but my background is more on the, uh, vulnerability side of the house. I was a researcher, um, you know, for many years, um, looking for zero day attacks and so on. So really very familiar with that side.

But then coming to, you know, more of the commercial world, seeing how much access and not just access misconfigurations, it's probably the largest attacks service that you can think of. You don't necessarily have to find this, you know, unused zero day attack to be able to gain access to the organizations today. So very much agreeing with what you're saying here.

Um, and I think that's where you, that's definitely where companies should start making sure they're governing their access, right? They have auditing on top of that, they have these type of tools necessary and, and then we can move on to the more, uh, complicated, sophisticated stuff that might even be more relevant for nation state, uh, type of, uh, um, you know, type of organizations as well. So it's, it's definitely something that I agree with on this.

So with this a little bit more perspective, it's a technical challenge, no doubt, but as we discussed, it also seems like it's as much a cultural issue in these organizations and how do I kinda instill the right culture inside an organization that probably hasn't thought about this issue at the level of depth they should? I agree completely. Yeah.

This has a huge human element to it, um, for sure. And I think it is, it is a combination of, of being able to come to meet, if you will, the engineers or the end users where they're at as opposed to trying to, um, enforce and, and, you know, uh, uh, come, uh, top down with a solution that is not speaking their language and that kinda meeting some, someone where, where they're at essentially creates that, uh, shared culture, the shared responsibility that we're talking about. Um, but definitely, definitely there is a, um, a huge human element when it comes to, to managing access, right?

Both from the people that are getting access and from the people that are managing it, And then access too. I sometimes think we don't think through the, um, the privileges we're giving those folks because we're always like, well, everybody wants access to everything just in case. But, um, the fact of the matter is they don't use that stuff 99% of the time, but once their credentials are stolen and the bad guys are anywhere they want to go, Very much so.

And a lot of the time you're getting more access than you need because of the process that in to get the access. Then you're, you know, if it's such hard, so hard to get the access that I need, I might as well get a lot more than I need. Or it's hard to know exactly what you need to be able to perform your task and therefore you're getting much more.

I will say that in many solutions in the privileged access space, in the past, there was no differentiation between more than just user and admin. There was no breaking apart the tasks of an admin that might need, and this is definitely one of the pieces that up tries to solve. We're not just a just in time, it's a just in time and just enough access, breaking apart that admin and making sure you're getting only what you need to solve it to.

So to, to the task at hand, you know, without creating the friction that's usually involved with getting the access that you need. And, and, you know, I couldn't agree with you more on this. All right folks, I heard it here.

Hey, if we focus on the fundamentals, we might just solve 90% of our problems and then the other 10% become a little more manageable. But right now we just make it too easy for the bad guys. Hey Ron, thanks for being on the show.

Thank you for having me, Mike. Appreciate it. All right, and back to you guys and sitting.