Shashwat Sehgal: [00:00:00] I think most organizations are still trying to figure out where should cloud identity governance lie. And in the absence of any clear guidance, it usually comes down to some combination of platform teams, SRE teams, and cloud people. How do you even define what is something that a developer should have all the time versus not where you draw the line of what is privileged, what is not root access inside the cloud, like not the AWS root access, but inside the cloud, how do you even define what is privileged or not? Is access to a particular S3 bucket privileged? You know what, guess what? It depends on what the contents of the bucket are.

Ashish Rajan: If you're a cloud security person who has been looking at all those identity alerts on your CSPM provider dashboard, or if you are an identity person who probably considers that cloud identity should be the same as identity on premise, this is definitely the episode for you. In this conversation, I had Shashwat Sehgal from P0 security.

We were talking about what is cloud identity lifecycle management. There are terms which are probably familiar with to identity people [00:01:00] like IGA, like PAM and all of that. We spoke about a lot of those and what they are. So if you are someone who's probably trying to help your identity folks understand what that could look like.

But I wanted to start the conversation about cloud identity, lifecycle management, talk about how complex the space is. And each one of these layers are within themselves quite deep. So I would definitely encourage you to look into each one of those steps as you hear the conversation here as well.

If you are here for the second or third time and listening to this on iTunes and Spotify, definitely gives us a review or rating. It definitely helps more people find out about us and makes us realize as well How you're enjoying these episodes but if you're watching this on youtube or linkedin give us a follow subscribe and a because that's how the algorithm gets to know that.

Hey, you're enjoying this and we should produce more of this

Hello, welcome to another episode of Cloud Security Podcast today I have Shashwat with me. Shashwat, welcome to the show, man.

Shashwat Sehgal: Good to be here. Nice to meet you again, Ashish.

Ashish Rajan: Just to set some context, could you share a bit about yourself and where are you these days with the, why are you in the identity of lifecycle management in Cloud, man?

Shashwat Sehgal: Yeah, it's a question I ask myself every day and I still haven't found a right answer. Jokes aside, I'm [00:02:00] right now. I started a company P0 security. I'm the co founder and CEO. We've been at it for the last couple of years. Prior to that, I spent many years in engineering and product across security, DevOps, cloud, network those kinds of spaces.

So Identity is something that is near and dear to me.

Ashish Rajan: How would you describe identity lifecycle management? Cause I think it's a very If you're from the identity world, you almost get it, but if you're from the cloud world, suddenly it's I don't know what that means. So how would you describe identity lifecycle management?

Shashwat Sehgal: Stepping back for a second, right? I think every organization, whether they know it or not, has some sensitive assets. It doesn't matter what space they are in. Sometimes those sensitive assets could be physical assets. Sometimes they are, but increasingly they are located in the cloud. They're digital assets, right?

A CISO's job literally is to protect access to those sensitive assets. In the era of the on prem era, before the cloud era, these sensitive assets usually used to be [00:03:00] applications, enterprise apps sitting behind a network boundary in a data center. Here the identity problem was very easy. You control every identity's access to the edge of that network boundary and that's it.

Voila, you're done. Increasingly in the cloud, that is becoming more and more of a challenge for a variety of different reasons. Mostly they happen to be the fact that the cloud is complex. It's got many different kinds of resources, S3 buckets. Easy tools, they're like thousands of services across each cloud, each with their own set of identity entitlement sets.

Even more importantly, there are many different kinds of identities, right? It could be human users trying to access the cloud, your engineering teams, your support teams, your contractors, many different groups across your identity providers. And increasingly workloads, machines, service accounts, quote unquote non human identities.

At the end of the day, a CISO's job, a security team's job is to protect access to your sensitive data no matter where it is. [00:04:00] So even though people do not realize it, I think ultimately preventing access to your sensitive data in your cloud, your sensitive infrastructure in your cloud becomes a problem of managing the life cycle of access of every identity.

That can access your cloud, right?

Yeah.

Even if you don't think about it, your dev ops teams, your platform teams on a day to day basis are busy managing access to your cloud in different ways. Sometimes there'll be rotating keys. Sometimes they'll be providing access to engineers for on call, all of these are various activities that are part of what I call as lifecycle management or managing the lifecycle of access for every identity.

Ashish Rajan: In the traditional world. How was this done in terms of like your privilege access management? And a lot of these terms probably would not mean a lot to people from a cloud space and I wanted to level that as well. So what is IGA? What is PAM? That the identity people talk about,

Shashwat Sehgal: Identity folks are very familiar with the two, the terms IGA and PAM for those who [00:05:00] of your audience who may not be familiar.

IGA stands for Identity Governance and Administration and PAM stands for Privileged Access Management. Yeah, now what are these things? The specifics vary from product to product and maybe even from person to person as to how they define it. But at its core, IGA is around managing which identity has standing access to your company's resources.

What does standing access mean? It means access that you have all the time. An employee joins, a sales employee joins, do they have standing access to Salesforce or not? An engineer joins, do they have standing access to AWS or GCP or Azure or not? Someone in finance joins, do they have access to Workday or if they are in HR, do they have access to Workday or not?

These are all what I would loosely define as the default level of access any identity should have. And these are usually defined by IGA tools and the use cases are typically a new employees joining or employees leaving or an employees changing teams. How do you provision access for the [00:06:00] apps that they need for the day to day work, right?

That's one piece. And the other piece is to satisfy our regulators, you probably need to do some kind of reviews of their levels of access every few months. So how do you do your access reviews on a periodic basis? These are broadly what I call the scope of a typical IGA product that historically people are, have been familiar with.

And the PAM space. Yeah. And the PAM space is privileged access space. And again, going back 10, 15 years to how PAM started, ultimately it was all around providing and keep in mind 10, 15 years ago. This infrastructure looked like data center, lots of boxes in a data center, and you requiring access to stuff within the data center.

So right. So IGA would have been give me access to certain apps that are being hosted in a data center and it was mostly enforced by the means of a network boundary. It is. That's how it started. Implement your network into various subnets, give people access to [00:07:00] those subnets, and then regulate those access.

Suddenly they'll have access to the right applications. That's at least how it started, even though it didn't look like that five, 10 years after it started like that. But PAM was a very different beast. PAM was privileged access to these Linux boxes. What does that mean? Because most of these were Linux boxes, each and every one of these had a root account.

Yeah,

so mostly Pam was okay. There's a server. I need root access to that server, right? How do I manage the keys or the root credentials in a safe way? Rotating those, giving those for a short period of time for someone who needs to do admin tasks.

Yeah.

Yeah. It was still very different because one was access to the network IGA was access to applications via a network and PAM was access to root credentials on Linux boxes. And then a funny thing happened as we moved to the cloud, the line between these just got blurred to the extent that now you cannot even tell the difference. What is IGA? What is PAM? Why do I say that?

Why do I say that? Okay. Like I said, previously, the [00:08:00] line was mostly clear. You require access to apps, you enforce that by some kind of network segmentation versus you have access to Linux boxes and you require root access, right? So that was the distinction between PAM and IGA. In the cloud firstly, network segmentation makes no sense.

Everything is ephemeral, everything spins up and down quite rapidly. Plus, more importantly, what you're trying to do is regulate access to a vast number of resources, S3 buckets, EC2s, Kubernetes clusters. Take any example of the latest and greatest cloud service, Bedrock, for example, right? How do you even define what is something that a developer should have all the time versus not?

Where do you draw the line of what is privileged, what is not? Root access inside the cloud, like not the AWS root access, but inside the cloud, how do you even define what is privileged or not? Is access to a particular S3 bucket privileged? You know what? Guess what? It depends on what the contents of the [00:09:00] bucket are, right?

Who knows what the contents of 10, 000 buckets across an enterprise are. And this comes back to what I was saying. The complexity in the cloud is so high, there are so many different resources and no single person has the right context into any of these resources that for a random individual, it's impossible to say, is this kind of access privileged or not?

Is it standing? Should someone have standing access or should someone not have access, right? There's so much context. No single person can make that determination and which is why I believe that the notions of PAM and IGA are just morphing into the cloud. They're just coming together as one. It doesn't make sense to have these two as separate categories.

Ashish Rajan: But Shashwath, I've got SAML everywhere, man. I think I should be fine, right?

Shashwat Sehgal: Yep, exactly, right? That's literally how IGA worked in the pre cloud era, right? Just use whatever you want all over the place. And guess what, if, how do you bring those concepts into the cloud and you think you are safe? Suddenly everyone will [00:10:00] have SAML access to AWS all it means is they have an account great.

You have within that account. Who knows, right?

Yeah. And it's usually comes down to all or nothing. And it's usually all, it's not nothing.

Ashish Rajan: That's right. Yeah. And, I'm glad you called out the complexity as well, because you kinda even gave another perspective as well. You gave the example of S3 bucket.

And the access is not just the fact that, Hey, I have SAML and rightly I've been guilty of that as well. Then initially, when you, as a cloud person, you talk to an identity person, the first thing they'll say, Oh, okay. Just a new app. So I just need to SAML and you'll be fine. Just let me know what do I need to include in the scope and that should be the end of it.

I'll say with the API tokens and everything, and we're not even talking about access tokens and stuff as well. At that point in time, I usually find that, Oh, okay. The fact that I got access to AWS doesn't really matter if it's at the entire all resources. And like we talk about how complex is it to do least privilege in AWS.

We haven't even spoken of multi cloud yet. Like we aren't into that category. A, I guess my question is people who probably are listening to this and have [00:11:00] an identity background, they might question the fact that why is it that we believe that the traditional approaches don't work in the cloud.

Now that we, Understand that, Oh, PAM is different. Like privilege access management is different. IGA is different. It's a lot more complex as well. And the fact that giving access just means that I've given access to another data center to someone instead of one service or one app, I guess for people who are from the identity background, what's the reality of the cloud environment and identity, because you touched on non human earlier.

I spoke of multicloud as well. What are some of these other complexities outside of the fact that it's just an app, what are some of the other complexities that people need to understand for, Hey, this is not just another app.

Shashwat Sehgal: The single biggest thing that people need to understand is that you just cannot secure access by defining a network boundary.

You have to go much more granular than that. What does granularity even mean? It means that firstly, you need to be cognizant that you have to think about securing access by an identity first approach. In other words, the three things you should do is [00:12:00] first start off by a strong baseline, which is who can access my cloud, right?

Who, or what can access my cloud? You should have a strong inventory, a solid inventory. or a discovery process of every person or an entity, machine, service account, you name it, right? Any entity that can access your cloud, right? That should be step one

You should have a firm understanding of the risks posed by every entity, right?

Is that entity, if it's a human user, do they have MFA? If it's a human user, it's an interesting question. That many people don't even know if human users are legitimate employees or not, right? In the cloud, deprovisioning does not happen as easily as it might in other places, right? You just need to have those connectors to your IDPs all set up.

Many people do not. You should also have a sense of which keys and credentials are stale, which ones haven't been used, which ones need to be rotated. You need to know for every identity, be it a human user, be it a user group, be it a service account. What is the levels of [00:13:00] access? Are they over provisioned or not?

You need to have some kind of a baseline on the risk posed by every entity. And then last but not the least, you eventually need to think about the governance or the life cycle management for just about every identity.

Ashish Rajan: What you called out as, I feel like it's a level one of maturity where you do discovery.

You identify what the risks are associated with it as well. Even in the discovery phase, I think it's worthwhile calling out that the human, non human part that you called out earlier, I want to just double click on that whole non human part for a second. What is a non human identity in this context?

Shashwat Sehgal: I think the meta point here is that the way clouds are architected, the architecture assumes that any entity with the right credentials can take some access, some actions on the cloud.

They don't make any strong assumptions on who that entity is, right? So if a human has the right credentials, they can take actions on the cloud. If a service account has the right credentials that can take access some, actions on the cloud. The cloud APIs do not distinguish very strongly between [00:14:00] humans and non humans.

Indeed, humans could assume a service account and. Take actions on the cloud, which is why it's important for cloud people or security people or even IAM people to think about all kinds of access to the cloud, no matter where it's coming from to your question, what are some specific examples of non human identities?

It could be a service account, right? GCP defines service accounts. So if you're, if you have an external workload that needs to access any, resource within GCP. You need to set up a service account. You need to provide that workload with some means to authenticate as that service account and then take action on any GCP resource, right?

An equivalent concept in Azure is that of service principles. Same thing, different name, service principle instead of service account. AWS is slightly different. AWS allows you to define IAM roles. For whatever entity that needs to take action on any AWS resource, right? And [00:15:00] that IAM role could be assumed by a Kubernetes workload, or it could be assumed by an EC2 instance, or it could also be assumed by a human user, right?

But at the end of the day. If you have an IAM role in AWS, it means it's an identity that can be assumed by either a human or a non human, sometimes even both. These are the common examples, service accounts, service principles, IAM roles. Others could be access tokens. Folks in the early days of the cloud, people used to have these personal access tokens or PATs.

Floating around, which is obviously a very bad security practice. If you have those in your organization, you want to turn those off ASAP, nevertheless, they still exist. And of course the list of non human identities keeps on going on and on, there are certificates some constructs use certificates based authentication. The general idea being that there are all so many ways to authenticate into the cloud and take actions or access various cloud resources. Ultimately, from the perspective of the cloud, all of these should be just one cloud access problem.

Ashish Rajan: Probably the best example for this is the CapitalOne hack that happened as well. It's probably [00:16:00] the best example here where the malicious actor was able to get onto a box, which is a web server, which is vulnerable. And they were able to use the credentials associated with that server to access the S3 bucket, which eventually was the credit card information, all of that, because technically all people hear about is S3 bucket open the internet.

This was a private S3 bucket that was basically people, someone was able to pull out information from itself. And that technically is a great example of non human identity too as well. So if people want to. Look for real world examples where this has been misused as a very good example of it. Where I want to like to take this as well is that now that we kind of explained what cloud identity lifecycle management is in terms of the components for defining this in a program, because I imagine a lot of people either they're working towards building a program on the cloud security pieces or probably are facing identity alert from CSPM providers and going, what does that look like? And perhaps they're bringing in a new cloud because they acquired a new company. What's your recommendation on the different levels of maturity people can have as they build a cloud identity lifecycle [00:17:00] management?

Shashwat Sehgal: It again goes back to my three big use cases that I talked about, but maybe I'll spend, especially around a third use case around governance.

Maybe I'll spend a little more time. The very first step is always around doing an inventory of every identity that can access your cloud. If you're acquiring a company, if you're acquiring a deck, if you're setting up a new project, new cloud, going multi cloud doesn't matter. First step should always be start off with a baseline of who can take action in your cloud, who or what can take action on your cloud.

Who or a human user, but a what or a machine, right? Always. That's the first step. Second step is especially if you have some kind of a program where teams are taking actions on, on, on risks that you define or running periodic reviews, right? A second step is always around this risk posture of that identity, right?

Get some understanding out of all the identities that you have, which ones have overprivileged access. Are there any service accounts or non human identities whose keys or [00:18:00] credentials haven't been rotated, right? Are there any human users who do not have MFA turned on or things of that nature? What are the risks associated with every identity?

And lastly, when it comes to the actual governance, first step is always around identify the core set of users, the core set of machines that are highly privileged. in your environment and set up the right level of standing access for them, right? That's one second for everything else, especially on the human side, set up some kind of a program around just in time access.

And last but not the least on the service account side, identify who those sensitive service accounts could be, or what the credentials are and set up some based on the risk appetite or based on the policies of your organization set up some kind of key rotation.

So these are some of the things that you need to do in order to make sure that the life cycle of access for every identity in your cloud is managed according to best practices, standing access, [00:19:00] just in time access.

And some kind of secrets rotation for non human identities.

Ashish Rajan: Where would you put SAML in all of this? Because you know how most enterprise, especially the ones who have identity teams dedicated for this kind of space, they obviously have been working on the SAML path for a long time. And that's been the step one.

Obviously, I don't think we're saying that's not the right path. You should still do SAML, right? Absolutely. Saying you should do SAML is like saying you should have passwords.

Shashwat Sehgal: Password less people are just like going roaring at the moment. Of course you should have SAML, that is like a given stable stakes.

But again, that's only around getting together with passwords. Having SAML is just about configuring front door access, right? You should have access to the cloud. But it doesn't go more granular than that. So absolutely you need to have SAML, but that's just step one. Beyond that, once you get serious about lifecycle management of the identity, once you get serious about governance, you just cannot stop at SAML.

You have to go many levels deeper by setting the right amount of, figuring out who those privileged users are. setting up the right [00:20:00] levels of standing access for those, and giving them just in time access for everything else and then managing secrets in a safe and efficient manner.

Ashish Rajan: So I guess to what you said, maybe the level zero, make sure you have at least single sign on because I'm going to have industry standard, like a SAML or a web auth or something to your point, table stakes, at least have that as bare minimum. So you at least know that, Oh, okay. So sheesh. And I know Ashish is a current employee because my SAML provider is linked with my payroll team.

So if ever we had to get rid of him, the SAML access is also disabled and he or she cannot access the provider. It doesn't matter which cloud or which app it is. When we say cloud identity lifecycle management, do we consider SaaS providers and third parties in there as well?

Shashwat Sehgal: Some people argue you should.

I happen to think that SaaS and cloud are sufficiently different that it's very challenging to combine those in a single product, right? SaaS are used by employees. Cloud is usually used by developers. The use cases are very different. The complexity levels of apps are very different. Yeah, I think [00:21:00] it's my guess is that eventually these will probably become two different products, two different companies, but the companies who provide access to cloud versus companies who provide access to SaaS.

Ashish Rajan: But I guess the SAML were probably the only single thread that would be common between the two that if you have Salesforce, you might want to do SAML over there, but the granularity of access to Salesforce, I guess it would primarily be IT operations versus security team looking after that.

Shashwat Sehgal: Exactly. So in one it's IT operations, in the other, it's security teams versus DevOps or platform teams.

Ashish Rajan: So far in the entire conversation, we've been talking about the fact that identity in the cloud is complex and the way it works is very different to how it would have been worked traditionally.

Like in the traditional identity access management world, there was a line drawn in the sand for, Hey, these are people who are responsible for anything to do with access provisioning that is onboarding, offboarding of users, SAML authentication. Hey, new applications coming on board. Any of that access management stuff.

Now that we're saying that this is a blurry line in the context of cloud. Where do you see the responsibility for it? And cloud people [00:22:00] perhaps given the information on what could be bad in by a CSPM provider, and I don't know if the current identity solutions who's responsible now in this new world?

Shashwat Sehgal: This is something people are still trying to figure out, right? Ultimately your apps. Okay. So you're absolutely right. That historically it's been identity people who've been thinking about IGA, SAML, all of those. things, right?

Yeah. But they don't have a whole lot of visibility or even the right skillset to be managing the cloud just yet.

But obviously as with every new technology, there's some kind of a timeframe or a lag before people are fully equipped to, to handle the risks. In the meantime, as you said, cloud security people are filling the gap. But they are strictly speaking, doing so more from the perspective of architecture and using, as you pointed out, is to just create reports and do SOC like actions on using those reports.

So just setting up some programs around taking all the the risks and findings [00:23:00] generated by Wiz, Orca, et cetera, and then just setting up programs to remediate those. I think most organizations are still trying to figure out where should cloud identity governance lie. And in the absence of any clear guidance, it usually comes down to some combination of platform teams, SRE teams, and cloud people.

Ultimately, though, I think. Identity teams will have to play a stronger role in, in this eventually until then it'll be like I said, some combination of SRE and cloud security.

Ashish Rajan: And maybe to your point, this is already happening in the space of the pure cloud security infrastructure world as well, where the SRE teams technically are the sole owners and cloud security people perhaps are the ones who are notifying them of the change that's coming in, Hey, we need to do this misconfiguration or whatever as well. The traditional solutions, a lot of people have had, the identity access management space used to be all about products before. It was never like I can just use Active Directory and everything's fine. I had to use a third party product to do onboarding, offboarding, SAML, access [00:24:00] management, everything required a product. And we've been talking, this is like a 20, 25 year old situation that a lot of CISOs have been talking about for a long time.

Are the current solutions not approaching it the right way? That's why we're talking about cloud identity lifecycle management now that it has to be called out separately. What's not working from that perspective on the cloud world that people should reconsider?

Shashwat Sehgal: Without taking names of the big identity providers, right?

Not the identity providers, but the governance providers, IGA providers. The challenge they face most often Is that because they treat the cloud as yet another connector to be built, right?

Ashish Rajan: Cause it's funny that word, the connector word is so much like an identity word. It's not even funny.

That's why I had to laugh. I'm like, Oh yeah, actually that's what we used to call every new application, oh I just need to put a new connector

Shashwat Sehgal: exactly. It's yet another connector. The challenge is if you treat it as yet another connector, you're not thinking past SAML. Yeah. So most, the way most connectors are architected. You connect to an application, you provision a user using SAML, you give them some [00:25:00] basic level of privilege, right?

Either an admin privilege or regular user privilege. And that's it. You're an IGA program which works well and good for 99 percent of the apps. But for the cloud, it just does not right.

So the legacy IGA providers, they're caught in thinking of the confines of their existing architectures, which is treat everything as a connector, except that this approach completely falls flat in the cloud, where you need a much higher granularity of access control, just providing someone with admin or regular user or provisioning a user via SAML, it's just not going to cut it. You might think you're secure, but you're not going to be. That's one. The second challenge is that the form factor of the product also needs to be very different. What do I mean by that?

Most of such solutions, legacy solutions. Again, were built for applications who uses applications on a day in day out basis. Guess what? It's regular employees of a company, right? But it's also important to [00:26:00] realize that those, the levels of access to those applications do not change a whole lot, right?

Sure. There'll be events like an employee joins a company and employee departs a company. They change a team, but for the most part, those events do not happen super frequently. They do, but it's not like cloud where your levels of access for anything might be changing several times a day. All of this means that because it's just applications and because there are only a finite number of applications within a company, you can just create a simple dashboard in a web application and create a very respectable solution out of that.

Which is what historically most legacy IGA vendors are focused on, right? But the moment you step into the cloud, many things change. Firstly, you are serving developers. The bar for user experience for a developer is much, much higher than it is for a regular employee who's just accessing. A bunch of, applications, you need to [00:27:00] worry about lots of resources that are being spun up, spun down, whose access levels could potentially change much more frequently, especially during on call, right?

That needs to go in and do a troubleshooting exercise. You need to ultimately meet developers where they are. And you need to craft a user experience, maybe in command line, maybe over Slack, maybe over teams, maybe over Jira, depending on the tools that developers use most often, you just cannot create a web portal and expect that developers will, use them.

Ashish Rajan: Yeah.

Shashwat Sehgal: This is where, legacy operators fall short. They have this old architecture of thinking of considering. of looking at everything as an application and their existing solutions were built not for developers, but for regular employees for very different use cases.

So the form factor of the product becomes very different.

Ashish Rajan: And funny, I remember any identity project for us, if it's access management. And I remember if it's access management used to talk about the fact that within a week you had, I don't know, like you could at least have two or three applications just to SAML in a within a week now.

[00:28:00] But for the identity complexity side used to be the fact that someone still had to install something on a machine and do it like a web server thing. And in the context of cloud where resources keep coming up and down. So is there like, is there challenges from that native space as well? Where I think, We still have the identity solutions on premise trying to talk to cloud, but then say, Hey, we only do SAML and that's the end of this conversation.

What you're trying to say here is that, Hey, by the way, the same way on premise, your SAML was primarily for applications that are used by employees. SAML could be for Salesforce or Workday or whatever those applications. But if you had a developer who required a root level access, you still go to sysadmin.

You don't come to a IAM person. We haven't really defined what that is in the cloud context, but to what you said, The majority audience of your customers for an identity team in an organization for cloud is not even like the regular folks who are in the HR team or in the finance team or whatever, like now most people require access to GitHub, GitLab or whatever, and the [00:29:00] cloud and your CI CD pipeline.

And whatever else comes with it as well as a lot more complexity there, other areas as well, where the cloud becomes a bit more unique for people who are, and I'm thinking more from perspective of separating the signal from the noise. How should that be approached differently in the cloud world than from like a being, keeping it native for lack of a better word?

Shashwat Sehgal: I think where it mostly comes down to is that most organizations start off with what they know, which is SAML. Yeah. Then it's up to us as a community, not just us as a company, but to start educating them.

Okay. You do what you have to do. Put bare minimum controls, but here's how you think about governance over and above that. So again, three use cases, start off with inventory, move on to risk posture, and then do those three levels of governance. Start off by setting up standing access, then move over to to some kind of a privileged or just in time access, then start layering in access for service accounts and machines by putting in some kind of a program around secrets rotation.

Once you do that, I think that's your journey to the [00:30:00] highest level of sophistication for a cloud access governance program.

Ashish Rajan: Those are most of the technical questions I had. I have some non technical questions for you as well. Just three. First one being, what do you spend most time on when you're not trying to solve the cloud identity lifecycle management challenges of the world?

Shashwat Sehgal: I spend time with family. Obviously, that's a big part of my life. I try to create time for reading. Although that I don't always succeed. I do create time for exercise. I like playing tennis and hitting the gym and going to the pool.

Ashish Rajan: Yeah. Awesome. And a second question, what is something that you're proud of that is not on your social media?

Shashwat Sehgal: I don't know what is on my social media to be honest. That's a good start. I get everything else I'm proud of, but I don't have anything on my social media

Ashish Rajan: I've got my third question, which is what's your favorite cuisine or restaurant that you can share with us?

Shashwat Sehgal: My favorite cuisine is Mediterranean.

I like kebabs of all kinds and flavors, right? I'll tell you my most favorite non Mediterranean restaurant because I recently [00:31:00] went to Tokyo and I fell in love with the place. Every restaurant there became my favorite restaurant. I'm definitely going to go back there again, but I'd say that if you're a foodie, Tokyo is definitely the place to be.

Ashish Rajan: Where can people find you and connect with you? And could you tell about, I guess what you guys are doing as well?

Shashwat Sehgal: Yeah. So I'm on LinkedIn. I'm on Twitter. My handles at both places are my full name, Shashwat Sehgal. At P0, we are in the business of helping customers secure access in their cloud for all kinds of identities.

So along the lines of what I already talked about, doesn't matter if your engineers how they are accessing the cloud, whether they're trying to SSH into EC2s whether they're trying to access databases. Or any one of the thousands of entitlements across engineers and across non human identities, as long as you have an entity that's accessing the cloud, our mission in life is to help you secure access in the cloud.

Yeah, awesome. And I will put the links to your LinkedIn and Twitter as well in there, but so much for spending time with us, man. I really appreciate [00:32:00] your spending the time as he's explaining what that cloud identity lifecycle management is. So hopefully. We can convert a few more identity people into cloud identity people and make that a movement as well.

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 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 podcast called AI cybersecurity podcast, which I run with former CSO of Robinhood, Caleb Sima, where we talk 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 chat, GPT, and everything else continues.

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

‍