Traditional PAM vs Cloud CPAM for a cloud first world

View Show Notes and Transcript

In this episode of the Cloud Security Podcast, Ashish sat down with Art Poghosyan, CEO and co-founder of Britive, to explore the changing world of identity and access management (IAM) in the cloud era. With over two decades of experience in the identity space, Art breaks down the challenges of traditional Privileged Access Management (PAM) and how cloud-native environments require a rethinking of security strategies.From understanding the complexities of cloud infrastructure entitlements to unpacking the differences between on-premise and cloud-based PAM, Art explains why "Identity is the new perimeter" and how modern organizations must adapt. They dive deep into the importance of Just-in-Time (JIT) access, non-human identities, and the critical role identity plays as the first and last line of defense in cloud security.

Questions asked:
00:00 Introduction
01:53 A bit about Art
02:51 What is IAM?
04:02 What is Cloud Privilege Access Management?
06:08 Why do we need CloudPAM in 2024?
07:52 Non Human Identities
08:39 Privilege in Cloud vs On Premise
09:49 SAML vs PAM
12:21 Just in Time provisioning in Cloud
17:17 Making Access Management Developer Friendly  
19:12 What should security team be looking at ?
21:22 Communicating IAM vulnerabilities
23:45 Tactical steps to level up IAM  
27:20 Zero Trust and IAM
30:56 Fun Questions

Ashish Rajan: [00:00:00] Is the definition of privilege the same in cloud compared to on premise?

Art Poghosyan: It depends who you ask the question. You're going to get a different answer. From IAM team standpoint, the current tooling and the current technology and processes that have been implemented, they are more focused on the coarse grained access.

You brought up something really important in terms of how IAM teams would implement the access vision, but there's also one other important task that the IAM teams fulfill. It's the compliance. It's the audit.

Ashish Rajan: If you have been working at a cloud security posture management tool, especially the modern ones, you would have realized that these days, you also see something which is more around identity and entitlement.

Now, I was fortunate enough to start an identity access management. So I came across a concept called privileged access management ages ago, but turns out we haven't really described that in the cloud world. So cloud privilege access management. And I was lucky enough to talk to Art from Britive, who like me has spent a lot of time in IAM.

And him and I spoke about the challenges of why a traditional privilege access management, something that I worked [00:01:00] on for years and he did as well, does not stand the test of time for cloud. What are some of the things that you should look at from a cloud perspective that are different? We are talking things like containers, Kubernetes, CI CD pipeline, your third party applications like Salesforce and others that access management is not just about fine grain and user credentials anymore.

It's a lot more complex. So if you are a cloud security engineer or an architect, who's trying to explain to your identity access management team, or you are an identity access management person trying to show your colleagues, Hey, this is how complex privilege access management in cloud is. This is the episode for you.

And if you know someone who's working on the IAM space for cloud, or probably looking specifically at privilege access management, Definitely do share the episode with them because I'm pretty sure they'll find this valuable just to understand what some of the tactical steps I can take today to start working on this problem of cloud privileged access management in the cloud.

Hello, welcome to another episode of Cloud Security Podcast. Today I have Art with me. Art, welcome to the show and for joining us. Could you share a bit about yourself and what got you into the IAM space?

Art Poghosyan: Oh, hi Ashish. I'm glad to be here with you today. [00:02:00] What got me into IAM? Gosh, it's been about 20 something years already that I've Been in the space, but I early in my career, I was with a big four consulting firm.

And that's when IAM was starting to become area. So we form as an area within the security domain, right? It was interesting because this was a set of technologies that would enable users to, do their jobs and enable access to resources, data applications. Really, I guess it piqued my curiosity and I started, getting involved in projects and implementing some of the earliest IAM products in the space.

Ashish Rajan: Awesome. I personally had my start in IAM as well from the good old days of CA technologies that doesn't exist. I age myself as I talk about it as well, which I believe you have some experience with that as well.

Art Poghosyan: That's true. Yeah. Yeah. That's always interesting when you start talking about the first product.

First IAM product that you touch, right? So CA SiteMinder for example,

Ashish Rajan: sometimes it's very easy for people to assume that identity and access management is primarily just username password. So just to level the playing field, I would [00:03:00] love for you to kinda explain , for the cloud security audience we have what is IAM, what is PAM and why is it different from access management?

Art Poghosyan: IAM, it's a broader sort of domain that includes multiple different technologies that essentially enable different use cases. So you mentioned one like login and password, that's more along the lines of authentication, right? Authenticating the user, there's obviously technologies in the IGA identity governance and administration space, that's more about lifecycle management, compliance and certification.

Ham is this kind of this unique subset of IAM domain, a subset of IAM technologies in the domain that really focuses on the users and access that goes above and beyond the normal standard user, essentially, admin level of access or privileged type of user and so on. So that's. Privileged Access Management.

That's what the acronym stands for. It usually correlates with higher risk of access as well.

Ashish Rajan: Like admin people trying to do actions in the environment. It doesn't really matter what [00:04:00] environment, but that's where it comes in from.

Art Poghosyan: Correct. Yes.

Ashish Rajan: And I guess you've been talking about cloud privileged access management.

What's the difference there then? You've explained privilege access management. So what's cloud privilege access management then?

Art Poghosyan: As I said, I've spent years in the identity space and worked with pretty much every product that you see in the market today as a consultant, as an implementer, before I started Britive.

In fact, the company before Britive, Advanced Technology Solutions, was an identity access management consulting and implementation business which Optive Security acquired. But what led us to actually start Britive was essentially the start major disruption and the shift that we saw that was coming from the public cloud technologies and really revolutionizing the tech space, the tech landscape, AWS, Azure, GCP, Oracle cloud, you name it.

And cloud essentially was introducing a new way of building applications, managing data, managing resources. Which really had changed the way the security [00:05:00] and, identity and access management was done. And we really saw that opportunity to reinvent the IAM technologies or the IAM tools that could support the cloud, native or, modern, processes, workflows, and tools.

So the acronym CPAM or CloudPAM is more popular now than it used to be. But essentially it is a little bit different from the traditional PAM definition because it's much broader in a sense. It does include a lot more of a broader set of, technologies. Typically traditional PAM environments, the admins or the privileged users are the windows, Unix server admins, network admins and so on in the cloud landscape.

It's the entire, range of different teams from like software developments, infrastructure, admins, platform engineering, SREs, and so on. These are much broader set of, users that interact with a lot of different technologies in the cloud. From the infrastructure standpoint, from that data, as well as applications.[00:06:00]

So meeting the needs of those types of users is what, is at the core of cloud privileged access management. That is different from the traditional PAM.

Ashish Rajan: I would love for you to unpack some of the complexity that you see in enterprise these days in terms of why cloud PAM needs to, as a space exist.

Art Poghosyan: Like you, a lot of people, thought that identity is like at IAM and the teams that manage IAM products are like a, a tribe of their own kind of off to the side, right? The cool security was in the, the perimeter, the network, the IDS and so on back in the old days what we see today, identity has emerged as truly a central kind of a component of security architecture in any environment, especially environments where the data center based sort of a model has long been blown away, changing the architecture to more a hybrid environment, cloud, public cloud, private cloud, on prem and so on. And because of that, the importance of identity has become much more in, as a foundation of the security architecture [00:07:00] where, controls and security policies and so on, no longer can be applied at the network or perimeter level.

They have to be applied at a, at an identity level that. really transcends the network controls and the perimeter controls. So because of that, we also see the biggest sort of security risks that have emerged because of this sort of identity, transcending the the perimeter based controls.

By that, Users that operate in the public cloud and hybrid environments meet the sort of unfederated, access into the cloud environments, data, resources, and application. And the only, really the only first in line of last line of defense is the logging is that page that you go to, to provide something, To then go into the into that application, right?

So that's why that security risk also is really around that first and last line of defense. I will add one more thing that's become very popular and very actively discussed in the security and IAM community, it's the non human [00:08:00] use cases are not human identity use cases as they are called. Again, with the evolution of the technologies and public cloud technologies, a lot of the automation that's used like CI, CD pipelines, infrastructure as code is really extending the concept of identity to not just humans, but, things, tools, processes, a Terraform script, or a Jenkins, or a GitHub action can have its own identity, should have its own identity, and should be managed like an identity as well.

It's not just like an API token that you can just say, we're gonna, we're gonna save it somewhere. We all know what happens when these things end up in the wrong hands, right? So it's become much more complex than it's ever been.

Ashish Rajan: Is the definition of privilege the same in cloud compared to on premise?

Art Poghosyan: It depends who you ask the question. You're going to get a different answer. For example, if you ask what is a privilege to let's say a typical sort of admin user for a server or network admin, right? It is the admin login. It's the login that is different from the regular user account.

So [00:09:00] for example, windows network, that person logs in for normal. Network activity, they log in with the regular user or for a server admin, they log in with a dash admin or some other privilege. That is the privileged user or the privileged admin. Now, shifting to the more cloud native world, most people don't even qualify it as a privilege.

It's the day to day access they need, whether it's to stand up an S3 bucket and stand up an EC2 instance or configure some other resource. It's whatever access they need. They don't necessarily think of it as it's my usual account versus an admin account. They think about it. What's the resource entitlement that I need?

What's the permission that I need to be able to perform the task? So that's why it's less specific and tied to one credential one login when you were talking about the cloud environments.

Ashish Rajan: For a long time, us IAM folks have been talking about, Hey, SAML everything. Just like anything you think of, Oh, I just do SAML.

There's no, don't worry about it. I guess for people who already have SAML, should [00:10:00] they be worried about privileged access management?

Art Poghosyan: When AD Active Directory became a very important sort of a network management tool, a lot of user access administration became centralized in AD one place to log in and you can go across the network.

You can go to different, database resource, server resource applications, and so on. So great concept. SAML did that for web applications and cloud that didn't stop. Even in the same analogy, like AD concept didn't stop from my privileged access management processes and tools to be deployed.

Reason being, they address two different things. One addresses more like that seamless and more centralized access into resources. The other addresses the high risk in that more powerful level of access it's more along the lines of the authorization. Same concept in the world.in a SAML based environments, right? SAML addresses the authentication and makes it easier for the users to access hundreds, if not thousands of cloud [00:11:00] resources, but it doesn't address the authorization. It doesn't address these levels of, privileges, if you will, in those environments related to specific resources.

And obviously, you, I'm sure you're well aware, your audience is well aware of some of the recent breaches that essentially compromised the SAML controls, like the Golden SAML. Ticket, attack, right? So yeah, so it's not the end all be all solution. It is a great, thing.

SAML is a great thing to have to centralize the access, but it doesn't address the authorization or approval in security,

Ashish Rajan: even though you have SAML. It's just one of the knobs you have in the complex world of cloud at this point. We don't, I actually, I should probably clarify. We're not saying SAML is bad.

It's just basically that it's just one of the tools you have. That allows you a single sign on kind of access into an environment, but that's not covering like to the exposure of, to what you said, the CI CD pipeline, the, I guess the other things that you would have to look into complexity of cloud as well, because another thing that keeps coming up is in the identity access management [00:12:00] space, JIT used to be the just in time provisioning was another one that you'll talk about Hey, if you don't have SAML, go for JIT.

And that's because, and also worthwhile calling out because cloud providers also recommend that you should have temporary credentials. You should not go for longstanding credentials. The way traditional JIT works. And I would love for you to explain that as well. Versus the kind of JIT required for a cloud environment are two different things.

Art Poghosyan: I agree. It's a good segway to look at how privilege management has been done versus how it really needs to be done for the new technologies and new environments, right? I'd say, obviously JIT has been around, that concept has been around for many years. In the traditional sense, the just in time, concept applies to the privileged credential that's in the vault, like that, dash admin account or whatever that definition is.

It's a privileged account, privileged login that's stored and secured. The user is allowed to access that just in time. When they need it, and they go through some kind of a obviously request approval process to be able to [00:13:00] check out that credential and then perform some privileged activity.

Now, when you look at again, the cloud world, the new technologies, new workflows and processes, and I like your correlation to SAML. Just in time access to SAML because it's really important again, as I said before, SAML will be your sort of the front door and the control or the lock on the front door is going to enable more of these fine grained controls into the different, in the same analogy, in the different rooms inside the house. And that's where you look at the JIT as that authorization control that by giving you entrance into the house, I'm still going to restrict you to specific areas that you can go. For example, you can SAML authenticate into Google cloud GCP, but you're just in time authorization only allow you to interact with, let's say certain projects.

Or resources or compute resources within its specific project. And then there's also the [00:14:00] second aspect of just in time, that's still perpetual, that gives access just in time, but it remains there, but there's access that is not perpetual. And that's if I may just inject it, this is how it Britive's technology implements just in time.

It doesn't let that authorization or that access remain 24 by seven. It really has that time to live. Okay. For the just in time authorization, and it automatically expires. So that's more of the modern concept of just in time.

Ashish Rajan: Just in time in the cloud native should be more about that Ashish wanted access to Salesforce, but it's not a perpetual access forever and ever, but it's more the fact that as an admin, I can decide or as a Manager, I can say, Hey, by the way, Ashish has this project that he's working on.

He just requires access for a week because that's how long the sprint is or whatever the case may be. But the access for Salesforce, for Ashish should just basically automatically go away or CI, CD, Python should go away automatically or Terraform should go away automatically after the expired dataset.

Art Poghosyan: Yeah, exactly.

That's essentially up to [00:15:00] the customer and the teams that need that access. to determine what's that reasonable amount of time to perform the task. Obviously in the case of automated, like CICD pipelines, it usually is minutes. It's not necessarily days or weeks.

That's why it is important to synchronize that time that's appropriate for each type of task or activity.

Ashish Rajan: So when I transitioned from IAM to all of these other cybersecurity fields and finally landed on cloud security, there was this phase that used to be a frustrating point for a lot of cloud security people where they would push something to deploy into AWS, whether it's infrastructure as code or whatever, and they would get blocked by access, some kind of access.

It doesn't really matter. There are these thousands of other access on S3 bucket. One of them just happens to be not there. And we're all trying to figure out which one is missing at that point in time. Like you can't expect a security person or approver to be just there. I think, is that the point of, or is that the problem that just in time is solving or is there another way to approach this in the cloud world?

Art Poghosyan: No, I think you, you pointed out a very sort [00:16:00] of a natural use case for the just in time ephemeral access. It's the automated, infrastructure as code, CICD pipeline type of use cases, because. It's true that the, when the team builds and deploys the pipeline, their goal is for the pipeline to, execute smoothly.

Pipeline doesn't fail in the execution because of some sort of an access or some kind of a permission not being there. So the downside of what's being done today is to really give it too broad of an access so that it doesn't fail, which then we all know, it can creates a lot of the security exposure, but the perfect use case is when that pipeline can be configured with just in time access for only the amount of, access to the permission to the specific resources that it needs.

And once the pipeline executes and completes. That access is gone. So it's a very natural use case. And a lot of times, yeah it the teams that operate infrastructure as code and CICD [00:17:00] pipelines don't necessarily use the the traditional tools because of that exact reason that the tools that are built for more like a human interaction, it requires a login.

It requires a ticket to make that just in time access available. And that just doesn't work for automation. You can't really do it that way.

Ashish Rajan: Yeah. And I was going to say it, it hits the point also on the fact that for the same reason, when the account access was blocked in the CICD pipeline and trying to just scratch my head at that point and going, okay, where am I?

Or who am I contacting? Is there a developer friendly way to approach this as well? I think, I feel like one of the things to what you said, people want speed. And unfortunately, access management has not been the best player in this context. So is just in time access something which is almost can be made like a self service thing?

Art Poghosyan: So this is again, one of the very important sort of new requirements, new modern access requirements. That's we put in the center of our technology to address [00:18:00] in the self service. The teams that we're talking about here, the, infrastructure teams and DevOps teams they have to have the ability to, quickly, move and get things done, doing it all the way.

Requesting and waiting days for the approvals is not an option. In fact, I will give you this example. For one of our earliest customers, a major enterprise organization, before they deployed Brtitive, they said that their typical developers, access set up would take about three days , to get them enabled and get them productive, but moving to the automated and more like a pipeline driven approach, it reduced it to about 30 minutes, you completely set up the, all the necessary access. And then by the way, across environments from let's say dev to pre prod and QA and so on, and that's very important because the, because of the sprint cycles they can't just do one environment and wait a week to get the get the access set up for the next thing.

And you're laughing because you've lived the, the challenges [00:19:00] in the past. So that's why this to your point, right? That self service, self driven option to be able to quickly get the access, get the privileges or the authorization to move things forward is so important.

Ashish Rajan: Would you say, I think another thing that I wanted to call out is like these days the CSPM tools have gotten expanded quite a bit. Like they're just not doing misconfiguration. They're talking about identity that came to the world and all of that. So a lot of cloud security people, probably a lot of those people who are watching and listening to this as well, they are getting a lot of IAM alerts that they get to come across.

What are some of the security gaps that you find that a lot of people identify that they have to, I guess maybe just to add to that as well, the gaps that people normally identify and what teams should they be working in? Because I don't believe the IAM team is looking at the CSPM output.

Art Poghosyan: No, I think typically the cloud security teams, and if there's a DevSecOps team, that's where the security posture management is handled and security posture management, initially, obviously [00:20:00] with the first generation of products, it was mostly focused on the, infrastructure services and vulnerabilities in the core infrastructure services. But with the evolution and with some, products starting to also focus on the access and identity related vulnerabilities started bringing that data into the posture management technologies.

Gartner has this category. They probably cloud infrastructure entitlement management CIEM and that's now part of almost every CSPM or CNAPP product. And that is data specifically about access and identities. I think today already, a lot of organizations are starting to, process that data specifically for access and identities to understand what is the risk exposure and in a way they're seeing now what is the result of, over provisioning access and especially over provisioning static access across the environment.

So look, I think it's hard to go just flip the switch and everything magically gets resolved. But that's where I think that, awareness and [00:21:00] visibility is the first step. And to point, yes, now I'm starting to see how identity and access related risks are part of that posture management strategy and the program, which inevitably is going to move the organization towards more proactive and more automated identity and access risk management, as opposed to just like constantly discovering the risks and the findings after the fact.

Ashish Rajan: To people who discover that, they are seeing IAM vulnerabilities CSPM outputs. I would imagine the natural reaction for them would be to reach out to their IAM team.

Have you found that when talking to IAM folks? Who will probably come in and whether an enterprise who may have different functions using all kinds of provisioning, deprovisioning, I'm going to throw some heavy words out there. It literally just means on boarding, off boarding, but we like, as in the IAM world, they like call it provisioning, deprovisioning.

What is the gap they find that they have to fill, which based on what the entitlement management and everything else comes in?

Art Poghosyan: Yeah. Yeah. you definitely speak the language, right? Like you said, the [00:22:00] provisioning, the deprovisioning. Life cycle management, the user life cycle management. So yes, the complexity in the cloud, even if you take just the cloud infrastructure as a service, like AWS or Azure or GCP, if you look at like the just sheer number of entitlements and the fine grained permissions, talking about tens of thousands.

Microsoft has a paper that they published, I think like last year, that it has some sort of that statistic about how many entitlements need to be managed in the Azure cloud alone, right? It's enormous. It's a very complex technology. From IAM team standpoint, they the current tooling and the current technologies and processes that have been implemented, they are more focused on the course grain access.

Meaning, if you're part of a business role and your IGA product, let's say, that business role allows you to be provisioned access into certain applications. Normally, it maps to a some kind of a role or a group in the application. Normally, that's a very coarse grain sort of [00:23:00] a one to one map.

When you shift to the cloud, that coarse grain access doesn't really work again. It becomes too broad, too much access. And if they try to, look deeper in the levels of access. That's where even the, there's a big skill gap. Do I understand the complexity of, AWS permissions, for example, Azure permissions and so on.

So there's definitely a sort of a learning curve from the IAM standpoint to understand the complexities so that then they can build effective sort of provisioning processes and deprovisioning processes. During the user lifecycle, job changes, moves within the organization, you have to take something away to give something new, right?

All these changes happen all the time and it's very difficult to do it with the current process and the current tool.

Ashish Rajan: In the conversations you've had with people, what have you found is an easy step or maybe it could be a tactical steps they could take to level up from where they might be whether it's a gap in their current product that they may be using for IAM.

What are some of the stages you've seen that, hey, [00:24:00] you know what, in my experience, I see these things as, a good progression towards what could be a mature cloud PAM.

Art Poghosyan: You brought up something really important in terms of how IAM teams would implement the access provisioning, but there's also one other important task that IAM teams fulfill it's the compliance, it's the audit, right?

So it's not just let's provision the access, but you have to be mindful of what compliance requirements you have to meet. Now that's where I think the two objectives essentially have to converge when you're looking at the cloud environments, right? So you have to be able to not only build a process of provision access, but also make make it such that you can pass audits.

You can pass the compliance requirements. And also let's just add the whole risk aspect of it. You also want to make sure that you don't create exposure, unnecessary risk exposure. So what we've seen is, let's just say some companies are already leading the industry in the way they're deploying this new sort of new access management, right?

The approach they're taking is to identify [00:25:00] first and foremost the most commonly used entitlements that are currently still being provisioned as a static access, they're essentially moving that to more like access that can be provided on demand, like just in time concept, but could also be automatically removed, recycled when it's not needed.

So from the compliance and risk standpoint, that's a huge step. You're not constantly reviewing data to, to see, to decide who should still have this access. Who shouldn't compliance becomes much easier to show when that access is not standing. So that's like an, almost like a low hanging fruit.

You don't disrupt the users. You don't completely take that access away and start from scratch. You transition them from being static to now it's more dynamic now along the way. There's also learning, right? There's already tools and technologies in place. In fact, we have some of that component as well, that we gather data about usage from the actual usage from the actual users going in every day, using whatever permissions [00:26:00] entitlements.

Now that gives the the IAM team's ability to see what is actually being used. And that is a good starting place to start looking at like how to enforce the least privileged access, how to create new roles that really align with the true needs of the users. And , now they look more like heroes because they not only are, addressing the IAM needs, addressing the security and compliance needs, But also not disrupting the cloud, user's experience, especially the automated processes.

Ashish Rajan: Oh, yes. And I think I'm glad you called it the compliance piece because there's a whole user access review process that a lot of people have to go through as part of being compliant. And this is quite crucial to be able to validate that. Oh, okay. That earlier we were talking about giving Ashish access to Salesforce.

If the default policy or security policy for the organization is, Hey, any just in time access is only maximum available for one week or two week, because that's how long our sprints run. That could be an automatic thing. And people would know the answer. And to going back to the developer friendly [00:27:00] and the speed of access as well.

They don't have to find out, Hey, Ashish, what do you think? Should I give access for one month or three months or six months? No, the policy is as long as sprint is, if you need more access, let's start, ask again, and I'm like, Oh, like saying it's funny. I think, I hope it resonates with a lot of the identity folks as well for, how access management could be done differently in cloud.

I'm also thinking about the security leaders as well, who probably may not be directly dealing with this, but they're dealing with this through people who are in the IAM space or cloud space as well in terms of their security programs, is there other areas that probably I'm thinking of zero trust as a thing here as well, where a lot of organizations want to go down the Zero Trust path, they might, may be tossing the idea for, and they may have considered identity as a pillar for Zero Trust. Does this kind of help in that direction as well? I'm just trying to think from their perspective for if they're already working towards Zero Trust, perhaps there is a different way to approach that, or this makes it even more easier.

Art Poghosyan: This sort of new concept absolutely aligns with the Zero Trust strategy as well, the Zero Trust security [00:28:00] strategy, right? In a couple of things I'll highlight there, right? So when you look at how at the identity level, how zero trust is implemented or should be implemented according to some standards like NIST and whatnot.

You have specific guidance on, trust, verify the identity and always have a way of, verifying before you grant access. So that's one big part of it, but then also trust and verify whether the access level is still appropriate and that goes back to the compliance, the audit, the ability to, have constant visibility to who has what, and then also what they're doing.

That 3rd piece, especially what access has been given, what privileges have been given, but how they're also being utilized, right? So all that kind of is part of the zero trust that framework or the paradigm requires tooling and automation to be able to implement, enforce, monitor and remediate when when things break that non standing entitlements.

It's very much in line with zero trust. Every [00:29:00] time the user wants to have an admin access for S3 buckets or whatnot, as long as their job and title is still appropriate, and as long as they have a legitimate reason, they can have that, privilege. They can have that access when they no longer have it justified.

Need, then they don't have access to that anymore. They can't elevate themselves to that level. And last thing I want to touch on is the whole, activity monitoring, right? So you trust the users to give them the privilege level of access. You trust that they will be doing the appropriate things, but you always have some risks that even insiders can go rouge.

Or they could be, some insiders account could already be breached that you may not know the monitoring aspect becomes so critical to really understand how the activity pattern aligns with normal versus no , it needs to be investigated.

So again, from the zero trust standpoint, that's the other important element that organizations are now starting to actually build the security data links to be able to aggregate activity data and correlate [00:30:00] with their identity or privilege management system data to say, I see this activity. This is the user.

This is the identity. This is the authorization. We gave them, but I still have an issue here because it. It seems very, sispiscious, like the way this activity looks, it looks very suspicious. It gives security teams a much better, controls and ability to enforce security when it's needed.

Ashish Rajan: And I think one big takeaway that I'm taking from this is also that a, For folks who probably are not familiar with some of these privilege access management, I hope after listening to this conversation, they actually dig into how it's being done in their organization, because I'm pretty sure as much as I would like it to be a lot more cloud privilege access management, as we have been talking about, there's definitely things that they would identify within their organization that could be done a bit more natively.

And perhaps maybe it helps you completely remove that entire category from your CSPM alerts as well. So that's what I hope, but that's most of the technical questions I had. I do have three fun questions that we will get to know a bit more about you [00:31:00] Art. First one being, what do you spend most time on when you're not trying to solve the privileged access management in cloud kind of challenges?

Art Poghosyan: In a very little time I have left, I have a family, I have kids, I have three kids. So a lot of the free time is spent with the family, but I'm a big outdoors fan. Hiking is one of my fun activities to do with, especially with kids. Reading, reading some, books and various, material.

Ashish Rajan: Second question for you. What is something that you are proud of that is not on your social media?

Art Poghosyan: I would say, I've really tried to focus throughout my career, a lot of energy and time in helping people develop their strength People that have worked with me on the teams, people that have hired on my team, I really feel that's something that as a leader, as a professional it's so rewarding to, to help people achieve their best potential and achieve, successful careers for themselves and it's very rewarding to see that happen.

Ashish Rajan: What is your favorite cuisine or restaurant that you can share with us?

Art Poghosyan: I have to say it's sushi, Japanese and sushi. That's a,

Ashish Rajan: oh, wow.

Art Poghosyan: Hands [00:32:00] down. That is my most favorite. But I'm definitely a fan of a lot of different cuisines with that, I would say that's the top.

Ashish Rajan: I'm the same as well, man. So Japanese food all the way. And by the way, thank you for sharing that as well. Could you share a bit about where can people reach out to you on LinkedIn socials and learn about Britive as well?

Art Poghosyan: Yeah, I'm definitely active on LinkedIn. You're your audience. Welcome to reach out.

I would love to hear from them. I'd love to engage and chat and if any of the topics that we covered today is of interest to continue expanding on a little bit, I'm more than happy to, engage and communicate.

Ashish Rajan: Awesome. And I'll put the links for both Britive as well as your LinkedIn credentials as all the credentials.

I don't want any credentials on the, put your LinkedIn links onto the show notes in description as well, but dude, thanks so much for taking your time out and it's really awesome to talk about privilege access management and hopefully we're able to uncover a new space for a better word that cloud security folks are probably slowly realizing.

So I appreciate you sharing your time and talking to us about this [00:33:00] as well. so much for taking the time. I look forward to more conversations with you.

Art Poghosyan: Yeah, thank you Ashish. And it was a great conversation. Really appreciate, connecting with a fellow IAM guy, as you mentioned early in your career, you were in the IAM space, but yeah, hopefully this was a helpful for the audience.

Yes. There's a lot of opportunity in the new world and new environments that we're operating in. Yeah. I'm very excited. I'm very optimistic and excited that we together as a community, we're going to tackle any challenge that comes our way.

Ashish Rajan: Thank you for listening or watching this episode of Cloud Security Podcast.

We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast, or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast.tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister AI Cybersecurity Podcast which I run with former CSO of Robin Hood, Caleb Sima, where we talk [00:34:00] about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. tv. I'll drop that in the description and the show notes as well so you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.