Zero to Zero Trust: Implementation, Challenges & AI's Future Role with Uttej Badwane

Listen to the podcast on Spotify

TLDR;

• Zero Trust is a significant initiative and it requires Human effort and budget. Getting Leadership buy-in early would help fast pace the program tremendously.
• There are 3 areas of Zero Trust. Identity, Devices and Policy Engine. Having checks and balances at each of these areas are key to the implementation of the Zero Trust program.
• AI is a double edged sword. Where in It can help with effective and faster automations. It can also cause damage as well especially with Agent AI / Autonomous decision making AI agents running around and performing actions. Basics of Zero Trust does not change even though the technology changes. Ensure basics are followed properly.

Transcript

Host: Hi everyone, this is Purusottam and thanks for tuning into ScaleToZero Podcast. Today's episode is with Uttesh Badwane. Uttesh is a cybersecurity expert and speaker, currently working as a senior security engineer at Carta. With nearly a decade of hands-on experience, he has led cloud and corporate security initiatives at high growth startups in Silicon Valley.

And on top of that, he mentors aspiring security professionals and regularly volunteers with local security organizations to give back to the community.

So, Uttej, thank you so much for your time and thank you so much for coming to the podcast.

Uttej: Yeah, thank you so much for having me. I'm super excited to chatting with you.

Host: Anything you want to add to the journey. I just touched on three things, right? But anything else you want to add to your journey.

Uttej: Yeah, I think you pretty much covered most of it. Just try to volunteer a lot of times to local communities and try to give back to the society and the cybersecurity community.

Host: Awesome, so one of the things that we do before we kick off is we generally ask this question to all of our guests. What does a day in your life look like? And based on the background, based on which field they are in, which vertical, like you might get unique answers, right? So I'm curious, like what does a day in your life look like?

Uttej: Yeah, so my main focus area is around cloud security. So pretty much working across AWS infrastructure, cloud-native Kubernetes infrastructure, container images. So those are the main focus area. Day-to-day is pretty much reducing the risk, reducing the risk for the company that I'm actually working for. And there are various ways of reducing.

So the one common way is like, doing and adding enough security guardrails and also patching tons of vulnerabilities or finding automation ways how we can actually automate, let's say, security faults and many other things. So it totally depends on the project to project basis. But also, I do have a few portion of my day dedicated for just looking at vulnerabilities, patches, and what could go wrong and how to defend it. in a proactive manner. Yeah.

Host: So it's a mix of both reactive, like proactive measures, like putting in proactive measures and at the same time taking reactive actions to current gaps and things like that. Makes sense.

Uttej: Yeah, yeah, that is correct.

Host: So with that, so today we are going to focus on zero trust, right? Like, I love how you put it, that zero to zero trust security, the right way. So we'll focus a lot on what are the challenges, why organizations are attempting and not able to do it the right way, what is the right way and things like that. And what have you seen and learned while doing it at Carta as well?

So let's dive in, right? So Zero Trust is a multi-decade old concept. It's not like something which was coined last year or something like that, right? Experts in the data center world to cloud all are familiar with it. Even CISA has a maturity model around Zero Trust. So for organizations who are, let's say, scaling now and are looking to move beyond just reading.

How do you define zero trust for them in a practical implementable way, especially for folks who are running their workloads in cloud native infrastructure?

Uttej: Yeah, that's a great question. So if I take a step back, before Zero Trust, there used to be a VPN that is a traditional route for accessing anything which is internal resource, whether it is a SaaS applications or infrastructure applications. The issue with VPN was around it's a single point of failure, and it does not carry the context across. And back in the days, every single thing was in office.

Everybody is in the office, there is an office network, there is a networking team managing every single thing. If you're accessing anything internally, you need to have like either VPN system on your device or you need to be in office.

I think like in the recent cloud native world, every single thing is like very distributed and remote places. So there has to be change in the security controls and the shift. And that's where the Zero Trust concept comes in.

What it basically does is it carries the context from, let's say, an employee's laptop to if they are accessing some sort of internal SaaS application.

For example, admin.example.com. If someone is trying to access how the path is going from the employee device to the actual loading of the web page. So that path is being split out with like various steps. And those steps are like pretty much zero trust, meaning like you're not trusting one entity or like one, let's say a VPN profile. You're like trusting multiple steps for like getting into it. So yeah, that's like the stuff.

But the main, I think when you are like starting out, let's say you're zero trust strategy or you decide to go ahead with it. The first important thing is you need to get the leadership on board because it is time consuming because you're going to need resources. Plus you're also going to need leadership buying. Someone from like, let's say maybe your CISO or like a CTO needs to be onboarded so that all the cultural shift will be much easier because you're changing not just for like one entity, you're changing for like every single employee for every single internal resource.

So the first step is getting that communication internally done and showcasing what are the benefits out of it. And the very common way of showcasing those ones is, I'm pretty sure a lot of the companies are distributed. And a lot of times they just don't know who is accessing what unless and until there is a governance mechanism happening.

So that is like the first start I will do is like have some sort of like a governance on the access and showcase the risk. And when they understand like, okay, there is a risk and there's a potential downside, we need to add like enough guardrails plus making it also usable. It should not be like, okay, additional three steps for like an end user to like access their daily day to day job. So that will be the first step to go ahead with.

Host: Okay, makes sense. mean, when you said leadership buy-in, it absolutely makes sense because at the end of the day, it's a long term project. You cannot just switch a flag and then you have zero trust now. It will take time and also you would need budget for the resources that either it could be tools or it could be humans, human hours and things like that. So yeah, absolutely.

So let's say I went to my CISO, my CISO-8 and I convinced them and they are like, yeah, it makes sense. What are some of the initial steps that I have to take to evaluate and even implement a security model? Keeping in mind that I'm just getting started, right?

Uttej: Yeah, so the first you need to have like an inventory of like all your assets. The assets could be cloud assets. Let's say you are like on AWS or GCP or even on-prem, right? You need to have like the inventory of every single thing.

The second stuff is like who is accessing what. It's a very common AWS concept. Understanding your principle, meaning like who is like the end users, like are there employees just trying to access? Are they accessing from like their home network? Are they trying to access from their personal device? You need to have the inventory of that.

And the third thing is like how they are accessing it. Everybody has like admin access on every single thing or do they have like a specific some sort of like a role-based access like RBACs or like in place and have like those three things as your data set.

And when you're approaching the CISO saying, hey, this is the path that employees accessing a resource, maybe you can give them a different edge case scenarios as well. So with this path, let's say something is hacked or someone's device has been manipulated, this access could lead to potential data exposure, or access to unauthorized data for a customer. And go on from there.

Also, it totally depends on you have to take a step back and think as a business owner. Let's say you are in a fintech industry, you will have regulations to follow. You will also need to have a checklist on governance. That is more of a compliance side, but you can also leverage that.

Third thing is like knowing what you're trying to protect. If the data is like extremely sensitive, you need to have like the risk goes drastically up.

But if the data is not, let's say, PII focused and it's very generic data, so you might have like a different approach to the risk as well. So having that risk metrics and a graph showcasing maybe like a rough pointers, that could be your initial step when you're like talking to CISOs and CEOs and like trying to like convince them. Yeah.

Host: So yeah, I like how you structured it, right? Like the understanding your asset inventory and categorizing them in terms of, in a way, priority or severity, right? Like if you are catering to healthcare customers or you are building a healthcare focused app, that means you have to make sure your PHIs are secure, right? Similarly, PII, like you categorize your data and your assets accordingly. And then you also look at the access patterns.

And I like where you pointed out that maybe when you talk to your CISO, you show them what are some of the maybe open attack vectors, like folks are connecting from a cafe using, let's say, the public Wi-Fi, and they are just connecting to our databases, let's say, directly. That means there is a potential of an attack happening there, right? So yeah, I liked how you structured it.

So one question that comes to my mind is multifactor authentication not enough? Can I like sometimes people get confused that, hey, maybe I should do multifactor authentication or micro segmentation and that is good enough for me. How do you see it?

Uttej: Yeah, so I think those are like very good key points. So the way I see, for example, micro segmentation is more of a kind of like a prior step building the zero trust. So for example, let's say you have a production data where all your customer data is there. You also have, let's say, developers playing and like testing out things like a sandbox environment or test environment or dev environment. You can have multiple of those different segmentations.

See, for example, a person who is a developer A needs to, let's say they're working on a ticket, and they have to write a piece of code and try it out and see if that bug is being mitigated. But they can still get access to, let's say, production database to actually helping out the customer and fixing the bug. So even though you have a segmentation between production and sandbox, a person who has access to sandbox can also get access, let's say if it is approved access to the production.

So the micro-segmentation is still there, but from the security lens, the developer is still touching customer data. So there is a data exposure. So the way I think about it is, always go closer to the sensitive data that you're trying to protect and adding and auditing access requests. So that's why the micro-segmentation, the way I see it, is one of the steps within the zero trust. And it's more of a prior step to have a good zero trust strategy.

The same thing happens with multi-factor authentication as well. So it is completely based on a single person's access. Let's say you're trying to access AWS resources. Maybe you have like MFA, but the methods could be totally different, Like SMS based or like you have like a different, like a hardware token based MFAs are totally different.

So when the access is going from user to the cloud resource, there is nothing happening. Let's say if some developer A's laptop is stolen and they have, let's say, for example, Google Authy or Google Authenticator app installed on their system. And if they get into the system, that means they have key to the castle. So they can use the MFA and still go and do different resources and try to access different resources.

So the MFA and micro segmentation, the way I see it is there are multiple checks within Zero Trust and they are of like prior steps for setting up the Zero Trust strategy. So let's say if I want to explain it in a simple manner, Zero Trust has three different steps, mainly.

One is the identity, second is the device, and the third is the policy engine. So when you're doing and dealing with identity, that's where the MFA is come in place, right? You're like saying, hey, this is developer A and I'm obviously authenticating with username and credentials, but I also have like a two factor authentication. So identity is pretty solid. So that's like one of the steps within identity.

Micro segmentation is like, it comes into policy engine and how the infrastructure resources are accessible. So the more granular segmentation you're going to have, you can have more stricter policies and policy engine so that you control who is getting access to what resource with what access level. So those are the two things I would consider in a different manner. But they are definitely useful, but they're not actually satisfying the zero trust fully.

Host: Okay, I mean, they play a role in the overall Zero Trust framework, but you cannot just say that I have segmentation between production and non-production, or I have hardware token enforced to be used by everyone in the organization. That means I have Zero Trust, right? So it sort of acts as one of the steps, but not the whole Zero Trust.

So another question that comes to my mind is, let's say we went to the C-suite, we convinced them, but it's a big undertaking, implementing zero trust. What should I be prepared for? What are some of the common mistakes that you have seen when it comes to implementing zero trust that could either delay or derail the project entirely?

Uttej: Yeah, so that's a great question. are like two, I will categorize challenges into different steps. One is like the cultural challenge. That's where you have to like convince. And it's mainly like a infrastructure focused framework.

So you need to have like a two to three teams on your side. One of them is infrastructure team, like SRE. You can also have developer experience team on your side and the IT team as well. So, and obviously you're preaching for a zero-risk framework. That means I'm assuming someone from security is trying to do that.

So if the platform engineering, these four teams are all aligned, it becomes very much easier to implement. Because it has multiple steps, like as I mentioned, identity. It also has a step called device checks, which is generally controlled by the IT team. Then you have a policy engine and infrastructure step, which can have, let's say, micro segmentation or multi-account architecture. That falls under SRE and infrastructure team.

A lot of times, security engineers, specifically in my role, it's a blurb line. Like I like move across the platform very smoothly. But having that cultural check is very important. The second category or the second step I do is like looking at your infrastructure, having like a small quick wins or like having a staged project.

The way I have done at Carta is - first, we got our identity strategy pretty much right. So having group rules is very important. So you can use identity providers like there is Okta, there are Bing Identity, and there are many more, Okta being the most common one. So you can actually get a really good strategy around identity. What I mean by that is having an entire lifecycle management of an employee.

Like the moment they join the organization, what are the applications they get? Are they part of like a specific groups? And group rules are like very important. So you can have Okta being integrated with your HRIS system. So as a person, you don't need to do anything. It's automated. And based on like various attributes in someone's profile, you can specifically add them in a certain group.

So, for example, if someone has a certain tag in their profile, they can get added to security. Or if they have a department name, they can get added to Developer Experience team. And that is your first step of identity.

The second step is you need to have identity tied with the devices. So there are two components. The first is the most common devices are Mac devices or you have Windows devices. There is also a few portion of Linux, but we can leave it aside for the discussion. You need to have some sort of MDM tools, which can tie with your identity, and it can also tie with your MDM and the device managers.

It's very common to have device certificates being installed on these ones. You can actually automate these stuff. You can write maybe a small script. And sometimes they have a plist config files you can install on all of them. So that will have your organization name, a specific team name, and lot of the attributes you can pull in from the identity. And those certificates stay on the, let's say, employee-owned devices. So that is covering the second step.

And once these certificates are installed, you can actually have more control on it. For example, you can say the device or the firewall needs to be turned on. The device needs to be encrypted. And you can have multiple checks on that.

And the third part is the infrastructure part, which gets very interesting sometimes. Because what you want to do is you need to have a micro segmentation at that time. And you will also have a policy engine sitting on the third step. So what it will do is like, you can have some sort of like a demon.

For example, the policy engine could be used with like Zscaler or like a few other vendors out there. They will have their daemon client you can actually install in your cloud native clusters. And those will be able to like communicate and talk to your different identity and device mechanism or like MDM tools.

So, for example, someone joins developer experience team, they get added to a specific group in Okta, they have specific attributes. Based on those attributes, that person will also have, let's say, Mac system, they will have a device certificate installed. That means their first two steps are checked.

The third thing is based on the policy engine. Let's say they want to access admin.example.com. You can have specific rules on the policy engine saying only this kind of request I can allow. Only some HTTPS request I can allow. Or you can block the ports. You can allow certain methods and how they are interacting with APIs. that will be the third step. So if you have these three things, they always need to talk to each other. And they need to share the context across.

One of the step is broken, the access will be broken. So that's why it is very much, I feel more robust than like having just VPN or like what we just talked about, micro segmentation or MFA. Yeah, that will be the third step.

And like having those things implemented is also like challenging because each company is different, their infrastructure is different, they're unique to like fine tune if it is a cloud native environment, it's a different approach. If it is like just infrastructure, like on-premise environment, it's a different approach.

But on a high level, this strategy kind of be helpful for like many organizations.

Host: Yeah, and I love how you connected all of these points to each of the step of zero trust. So at our organization, we use Google Cloud, sorry, Google Workspaces as like our identity provider. We connect that to, we have groups and users mapped to those groups. And then they all get synced to, we use AWS Heavily, so AWS Identity Center. And from there, we manage which group can have what type of access to which accounts, what role they can have access, and things like that.

And for like MDM, was Rippling. And for all of our devices, we have certificates and things like that incorporated with several controls, as you highlighted, right? Like whether you have encryption enabled or not on the machines, things like that. We do some of those checks as part of it. And regularly, whenever there is like software audit and things like that, they check for some of these things, right? Whether your end devices have encryption or not, and they run agents and things like that on the end machine. So yeah, absolutely makes sense.

So we had reached out to some of our common friends, and Mohit has a question around zero trust. I want to understand your opinion on that. So how do you determine whether zero trust is the right fit for you?

Uttej: Yeah, that's a great question because see, if it's like a small startup, less than like, let's say 20 people, investing time with Zero Trust could be like difficult because you have like different priorities. You want to build the product, sell the product, get the go-to-market motion, right? So all the efforts are focused on that. But as you're like scaling, as you're adding more and more team members, access to the resources needs to be changed.

So initially, let's say it's a five person team, one person has like access on something, it's fine. Sometimes they have like overlapping roles, it is also fine. But if the company is going any time, let's say beyond 100 employees, that's when you have to like start thinking about these ones.

You need to have like a segmentation and like what kind of product and stuff that you're catering to. So I feel like as you're growing, you need to have like a robust policies everywhere because your risk kind of like gets drastically exponentially exponentially high. Because if let's say 100 employees and all 100 of them have access to like production data is might not be a good strategy.

Like when the team is small, it's a closed-knit group. They're all mission-driven. Obviously, like same at the 100-level company as well. But things could go in the wrong direction. So in that scenario, having like various policies, like a policy of like, let's say someone needs to access AWS resources, they can be granted access, like a read-only access. They don't need to have like an admin-level access, right? So those kind of like at least fine tuning you need to like start off with. And like see how it's actually reducing the risk or not. If they're reducing the risk, that's great.

But it also like totally different approach for like, let's say you're working for Department of Defense, right? So every single thing is like top secret information. So like you need to have like enough very finely-grained policies. Also, you need to have audit on top of it as well. So having those kind of different approach is varied based on the organization.

But always think about what you're trying to protect. What kind of data it is. What kind of product and customers you are serving. And what are their normal service level expectations. If it is extremely sensitive data, even if it is like, let's say 10% company and you're like dealing with, let's say, like a defense contracts, you should think about fine tuning in that scenario as well. So you just have to like go based on the risk and the what data you're accessing.

And as a security leader, you have to think, are you comfortable everybody having access to these kind of data? If the answer is no, then you have to start thinking about it.

Host: I don't think any security leader would be comfortable, even if it's a five person team. If you tell them that, hey, all of them have admin access, they will be like, what? We have to fix it right away. I don't think security leaders will ever be comfortable with that.

But I understand. If I summarize what you said is there is no formula at search, right? That you apply and then you say that, whether you should do Zero Trust or not. It depends a lot on the vertical, the kind of customers, the kind of data you're dealing with and things like that. There's many factors that play a role.

Another question that Mohit also has is, like, let's say I convinced my team, I found out that Zero Trust is the right fit. I want to implement, I did the implementation. It involves a lot of cost and it involves a lot of changes operationally as well. Right. So there is some complexity that gets added to your day to day business.

How do you sort of stay on top of it? And how do you make your organization aware that, we have added operational complexity because we need to be zero trust compliant. So how do you strike that balance?

Uttej: Yeah, that's a great question. I have seen that pinpoint as well. So my strategy is like, if you're going like two fine grained granular access, things get little tricky because it will add a lot of manual work. You can also like automate it, but there has to be some sort of like a check. someone like, if you go too granular and there are like too many security guardrails you have in between, then it's, think, too much of security, but not enough usability.

You have to think, at the end, you're serving the employees. They are your customers. That's the mindset I try to have. And you have to, again, put yourself in their shoe and see what are the pinpoints.

Certain tools we have used, they used to have so much of like manual steps on their local device. one of the example is like certificates being let's say device certificates and there are like browser certificates. Device certificates for like just authenticating and showcasing this is the corporate-owned device. Browser certificates is for like managing the cookies and access and like it will expire 24 hours. If it is expiring 24 hours that is definitely gonna add some sort of like a friction to the end users.

So you might have to like look at maybe like extending the expiry of that certificate, right? That will like, let's say you do it for like seven days. So at least the end users are not able to like do anything manually on their own. You also want to try to like automate these things in the backend, because let's say you have like access to MDM tools and stuff like that. You can write config files and you can push it to the devices.

So you also need to see what are the frictions and how many clicks and what are the things employees like seeing. If they're seeing too many things and not focusing on the work, then OK, you need to change certain things. It's either too restrictive, there are too many policies, or there are too many steps for for the developer to like even get access. That is how I will like try to like balance it out.

And also let's say in the cloud native environment, if you have, as we talked about AWS identity center, you have like permission sets, right? Sometimes you can have and write as many permission sets as you want and you can apply them even to like very, very minute kind of like teams and groups. Sometimes that could be too much. You just have to strike a balance.

If people are having to hop multiple steps just to get their day-to-day job done, then you might have to remove one or two checks. But still have those identity, device, and policy engine checks happening. But in each step, there are multiple sub-steps where there is a fine granularities, you can actually try to eliminate those. And maybe having a quarterly or yearly service, like, hey, what do you think about this product? is your access easy? Or is it more cumbersome? Or you have to deal with these things? And get those surveys that will give you enough data points and try to fine tune it.

So, but yeah, that's what I've done. I think that might be useful for other folks as well.

Host: Yeah, I mean, you're right. When you apply very strict security rules, your user experience gets impacted. And at the same time, you cannot have year-long valid certificates also. That means it's not secure enough. So finding that balance is always tricky.

So we touched on, we spoke about identity. We touched on that briefly. When it comes to cloud, a lot of folks say that network is not the perimeter anymore, like identity is the perimeter. And when it comes to like identity and access management, what are some recommendations that you have to sort of implement Zero Trust? Whether it could be humans, it could be like non-humans, like workload identities or FMRL credentials. How do you think about implementing Zero Trust when it comes to Identity and access management.

Uttej: Yeah, that's a great question. And I have worked with AWS Identity Center. And they have amazing, obviously, concepts of IAM users, IAM roles, and there is also permission sets, which is just IAM policies. So as I mentioned in the past, you can go granular on permission sets and policies. That could be one way of adding more limited access. You can look at the principle, you can look at the resource, you can look at the conditional access as well and apply those policies. That is the first step.

And obviously you want to tie your, let's say, for the example of AWS, you can tie AWS SSO with Okta. So all your access is not using IME users.

So for example, the common stuff people will do, let's say you have a company, you will go to IM webpage, you will create an IM user for like a developer one, and it has like access key, right? And those with IM users, the issue is the access keys are like valid forever. You can actually use another thing called IM roles. IM roles are like more kind of like short-lived credentials and I think the maximum time they are live for like eight hours. And I think you can also like shorten it to like one hour or so.

So when developer one is like trying to access something, they don't need to have like this access key, right? Once you generate access key, they can have it on their laptop. They can share it anywhere. They can use, let's say, AWS SDK like Boto3 for like interacting with the AWS console and that becomes tricky. Like the managing the access and the access keys becomes tricky. So having IAM roles is like a really good strategy so that you're not worrying about like access keys being leaked or something, you don't need to worry about rotating it.

Same thing happens with AWS SSO and Okta. Instead of IAM users, behind the scene they use AWS IAM roles. So let's say a developer one, they go to their Okta, click on their AWS tile, there is like a AWS STS token will be generated and assigned to them. And they can access the console. They can also get like access keys, which are only valid for like, let's say one hour. And they can do their local stuff. This is like one strategy has been working really well, at least for in my experience.

Same thing you also wanna apply for machine identities. Those are generally tricky because as the company is growing, the machine identities also, they're gonna grow. Because if you have many microservices, each microservice is doing a certain job, and lot of times you don't have a naming convention for these non-human identities. It's gibberish numbers. And you just don't know who has this.

But all you can see is, when is the last time it is accessed? How it is accessed? What are the policies attached to it? Maybe you can run AWS Access Analyzer and try to filter out, is this even being used somewhere? What are the resources attached to? So I think those are the stuff I will apply on the identity side. Obviously, there are more stuff you can do.

The one thing is you can have like various VPCs. It's again getting into the concept of like micro segmentation because like every time you have identity, whether it is machine identity, it is attached to certain resource. And how it is attached is where you wanna have like multi account strategies.

So we generally have like multiple AWS accounts. So that not all your X in like one basket. So you wanna like isolate and segment as much as possible. Then you can use VPC peering, VPC kind of like a VPC to VPC communication. There are like private links and like transit gateways that are different ways depending upon what is your cost appetite because they could get like pretty expensive.

So yeah, all these identities you can tie it based on what resources, how you can segment them, and having some sort of rotating access keys on these machine identities as well is workable. Yeah.

Host: So yeah, when you mentioned access keys, I wish AWS had a way where you can define what's the expiration of an access key. Like when you create an access key, it's sort of blanket. You get a key and a secret, right? And you can use it anywhere. You can distribute, as you said, right? Like I can just add it to my GitHub actions and it just stops to my AWS. I wish AWS had that expiration field and when it gets deactivated, but that's not the case.

I think, yeah, I like how, again, you structure it to human and non-human. With the non-human, at least, hopefully nowadays, folks are not using access keys. AWS has OIDC and things like that. If I take an example of GitHub Actions, of course, you can do AWS access keys, which is not recommended. AWS, like GitHub, also supports open ID-based federated connection, where you can get temporary tokens and you do not have permanent access to AWS and only when build is happening, it gets a token and it connects to AWS and things like that. So yeah, these are some good suggestions.

One additional question I have is, we spoke about operational complexity, right? Now, when it comes to IAM with with the org, let's say you have an org structure defined, you have management account, you have different OUs, and then within the OUs, you have your accounts, and you are using identity center, which let's say Okta is the identity provider, you do the setup, you have groups and everything defined, and you are assigning permission sets and things like that. How do you stay on top of all of this? Like what kind of governance do you generally recommend or have you seen work?

Uttej: Yeah, that's actually another great question. And as the teams are scaling, it becomes more tedious. So when you're doing governance, are, again, two ways. It's like someone getting access to the resources for the first time. And the second thing is, OK, someone already has the access. How do you audit it? So let's talk about the first one.

The first one is like, As I mentioned in the past, we have a lot of HRI systems being integrated with identity, pushing in certain profile attributes. Based on those profile attributes, you have a trickle-down effect based on what specific app you will need, and they will get access to it. There are tools like IGA tools, managing someone's access is also tedious. Sometimes teams do it through, let's say, a JIRA ticket. Sometimes they do it through, I think, Okta, IG, or some other. And they have inbuilt features nowadays.

But it's all about someone is requesting access. They will file a ticket. Let's say in AWS scenario, whoever is the owner, they will approve it. And it's going to get sent out to the someone who is gonna actually write, let's say maybe a pull request for like creating their specific access. It totally depends on like what access they're trying to like the request. We generally try to have like someone actually creating pull requests because people don't get AWS access by default unless and until there is absolute need.

And that's why we need those kind of like access requests being approved and then someone is actually creating a pull request and that pull request is being reviewed and approved by some other person. So no one is like directly getting access to, let's say a root account or they're getting access to admin role by default. That's why we have like a two step method.

Like the way I think is there are like two things needs to fail for someone to accidentally get some sort of elevated permissions. Let's say they get added to, for example, infrastructure team, automatically we get added to AWS. What that will do is that will just give them access to the landing page. It will not give them access to any AWS account. You just have landing page.

And the second step is someone needs to write a PR. So, in that PR that is being reviewed and approved. Why we do that is mainly for production accounts, sensitive data accounts. The rest of the stuff, we don't have these kind of mechanisms.

So that's the first part is about getting an access. The second part is about login auditing. So if you have a multi-count strategy, I'm just specifically talking about AWS. With Control Tower, comes with log archive and audit account. So log archive account, you can actually dump all the of like a cloud trail logs into them, maybe feed them into some sort of like your SIM, like SIM tools like Splunk, Panther, and maybe write detection rules on top of it.

And sometimes you can also like get kind of like a smart, like, okay, this person has the access but not used it for like last 60 days. Create alert, ping the user. can actually pick, like, for example, from Splunk or Panther, they can have like direct integration with your internal communication tools like Slack or Teams. Pick their Slack ID and look at the logs. Find the principle based on the email because it's one identity across the different system. So it is easy to find the user and ping them.

So this can get automatically done. And the user will say, yes, I still need the access or I don't need the access. And if that is done, then someone else will go and create a PR. And creating the PR could also be automated. But when it is like, sensitive access, we wanna have like, again, two-step methods, someone is actually doing it. But yeah, that's how I would recommend for getting someone first time access and auditing for like some, let's say annual audits or something like that.

Host: So yeah, I love the automation example that you gave. let's say you write detection logic in your SIM platform. And if someone has not used it in the last 90 days, today a lot of tools, what they do is they show you that, hey, Utej has not used or Utej has 100 permissions out of those only 50 are used.

But the example that you can go to the user, right? Slack or Teams and you can say that, Hey, are you using it? We see that these are not used. If you don't acknowledge maybe in a week, you will lose that access. Maybe you don't automate that at the first go, but it makes sense, right? Like you are as a security team, you're not doing it on your own. You're rather sort of checking with the user, end user and verifying it if they still need it. If they need it, you have an audit trail of that as well. So it not only helps the security team, like it helps with the user experience and also the auditors if they are evaluating that, why does Uttis have access even though he didn't use for 60 days or something like that. So yeah, that's an amazing example that you gave.

Speaking of automations and all, so today we live in the AI world, right? So we cannot end the podcast without talking about AI. So there is a lot, the usage of LLMs, AI, the agents, is exploding, how do you see AI playing a role in Zero Trust? Like, do you see it helping you automate some of these things, or do you see it creating more pain for you?

Because, like, I'll just give an example, right? When the MCP was rolled out, there was no concept authorization and things like that which was rolled out with it. Authorization is an add-on in a way on top of MCP. So how do you see AI either helping or hurting the overall zero trust journey that an organization might be going through?

Uttej: Yeah, it's a challenge at the moment. So there are like, again, like many components to it. I think every single organization is trying to be AI-enabled or like they're trying to use products. have AI inbuilt in them. So same thing happens with your identity, device and MDM and like various like those checks in Zero First. They are also becoming AI first or AI enabled.

So they can actually see someone's access in the past. Like they can also like draw a graph saying like, this person is only accessing these things in like last six months, they have not accessed these many apps. So they can like definitely surface those information. So that is definitely useful.

So when you're implementing, let's say zero trust, or you have like implemented, it can definitely give you that kind of like a one less work of like automation and auditing. So it is already in one, a few of the products.

The other side is, let's say you have like enterprise search tools. They can go across every single place, right? And they can grab and they can get trained on the data. So it kind of like bypasses all the zero trust stuff because you have like, let's say someone give admin role access on Google Workspace in a main OU and they can read through all the details, emails, documents that basically just like bypasses all the rules, right? But in that scenario, you need to have a strong vendor due diligence process. That's what I feel.

This is I'm talking about AI enabled products. That means there are companies who are like actually have valid contract before they're like installing anything. The other stuff is Shadow AI. Let's say like meeting notes app or even like apps like Grammarly and stuff like that. Sometimes they might have like a policy of reading the data and training on top of it.

So having those kind of audit of app is also a challenging because let's say 100 employees, they might be using 200 tools overall. Out of which 50 of them might be heavily AI driven and that's hungry for grabbing more data because they can train and be more precise the next time.

So it needs to be like a vendor due diligence process with like a strong SLA agreements. Like, hey, you can use AI, you can embed in the product, but you cannot train based on our data. You can also have like data residency policies as well. Like if you are like using it, you cannot scrape, or you have to like mask the PIA information. It totally depends on like organizations appetite, risk appetite.

And you can also like tell them like, like what is your retention policy? If you are using the data, let's say I'm writing a prompt, I use the AI tool and the product, are you like retaining this data somewhere else? Are you training on top of it? So you can have all those things in the legal contract. That is the one way of like adding the control.

The second step is like, let's say engineers and developers are like trying to like build out MCP tools for they have MCP clients hooking up to any of the servers. Again, all these servers will need specific sort of API keys on some tools because it's adding the context to the model. So also having that control who controls those API keys, who has access to creating API key. That again goes back to the permission sets and having fine-tuned granular policies.

So it's a bit challenging and I think I'm super excited about AI and all the stuff, but it also brings in new challenges. This is still in a developing mode. So I think in the next few months, we will, I think a few months or a year, we will know, this is the norm.

And additional stuff is, again, like when we talked about non-human identities, these could be like a shadow AI identities, like a developer has like a normal access, but they have created like a shadow AI identity, which can also have the similar access and how we can distinguish between those two and like add the similar controls. But yeah, I think I'm super, super excited and looking forward to like, what can be what can be done. Yeah.

Host: So on the shadow non-human identities, like Karan, Karan Dwiwedi, has a question. Like, how do you see Zero Trust model change? How will it change if servers are running AI agents? Because now we are talking about agent AI where the agents are autonomous enough that they take the decision, they talk to other agents and things like that, right? How do you see Zero Trust change in that environment?

Uttej: Yeah, that's a great question. And I have actually done very similar stuff for that. It's all the concept of like a blast radius. Like if something is broken, like how big is the impact?

So let's say you are like onboarding a vendor or let's say you're even like building AI specific application. It might have like resources. It can have access to RDS. It can have access to let's say S3 buckets and stuff like that.

What you want to do is like you want to have like a micro-segmentation and isolation in the same terms of like multi account strategy. You can actually have like vendor specific accounts. Let's say you want to build out AI enabled application or like some sort of like a tooling. It can be in a specific different AWS account, which is not tied to your production account and so on. You can have like a specific identity going into it. And if it needs to run on certain kinds of like, let's say data, you need to use a private link or like having like inter VPC communication. And again, going back to the same policies and like fine tuning those policies or like what it can do, what it can and where it can actually send the data.

So that's the, I think strategy I have been like implementing. If it is like a new product or a new vendor or any kind of like a new tool coming into from outside. The first is like isolated account. The second is granular access to like whatever resources it needs access to for doing its job. And the third thing is like, see if it is actually communicating somewhere else.

And like lot of the tools, have like a generally two methods, like a self-hosted or like a cloud hosted version. If it is cloud hosted version, you don't need to like worry about this infrastructure setup. You fall back on like how they are like accessing your resources and what kind of like API keys and like what kind of API request it can do.

And if it is like a self-hosted isolated accounts with like a stricter VPC to VPC connection and like so that you still have like enough quadriles and it's not directly attached and talking to your main customer and production database.

Host: Yeah, yeah, makes sense. And I think if I summarize the podcast, like even though we are moving to AI, we are using AI agents and everything, the basics of Zero Trust do not change. You have a different technology that you are working with, but you still have to work with identities. You need to have the device controls in place and you need to have the policy engine not only implemented, but also governance on top of it. So yeah, makes a lot of sense.

And that's a great way to end the podcast. But before we end the podcast, I have one last question for you.

Do you have any recommendation, reading or learning recommendation for our audience? It could be like a blog or a book or a podcast or anything like that.

Uttej: Yeah, I think there is like one newsletter, which is pretty, famous in security is like tldrsec.com. It's like very, very nice newsletter. There is also, I think, Frankly Speaking, is like another good newsletter. definitely like, I have also like watched many of your podcasts. So this is also like a good, good place to like just learn and know different topics.

Yeah, so I think those are like my few recommendations.

Host: Thank you for the shout out. Yeah, TLDRsec, Clint and the team does a great job. Frankly speaking also, yeah, I read regularly. yeah, so what I'll do is when we'll publish the episode, we'll add it to the show notes so that our audience can also go in and subscribe and start learning.

Yeah, so with that, thank you so much, Uttej, for joining and sharing your knowledge around Zero Trust. How we should think about it, how we should evaluate it, how we should implement it, and what we should think about in the AI world as well. So yeah, thank you again for coming.

Uttej: Thank you so much for having me.

Host: Thank you. And to our audience, thank you so much for watching. See you in the next episode.